Star Citizen Live SPECIAL EDITION: A More Stable Universe - TEXT SUMMARY

[Montoya]

This was a long 3hr video, a lot of important information, changes, shifts in strategies and more for this new year starting 2025.

Warning: Wall of text below, but its an extensive summary that covers everything!



Star Citizen Live SPECIAL EDITION: A More Stable Universe

Monologue About the Future 00:00

• The first couple of months of the year at Cloud Imperium Games (CIG) is a period of examination, planning, and using lessons from the previous year to chart an improved way forward for the development of Star Citizen and Squadron 42 00:42.

• The focus this year is on evolving the existing patch relief cadence and content within Star Citizen away from the previous new feature-laden model and into a more content-driven and stability-focused endeavor 01:10.

• This means pulling engineers and programmers off new feature work and putting them on quality of life-driven efforts like rebuilding elevators, fixing issues with hangars and cargo, and introducing unique item recovery 02:08.

• There will be a greater focus on refining the gameplay that's already there in the persistent universe and less time spent on continuously introducing new features every 3 months or so 02:38.

• A new content and gameplay delivery schedule will be introduced, tied to the introduction of new ongoing story narratives for the persistent universe, allowing players to reshape the galaxy around them 02:52.

• The development of new gameplay like Resource Network, crafting, and Base building will continue in the background, but at a slower and more deliberate pace, with more time to test and refine before release 03:15.

• New features will go into expanded dedicated Tech preview testing instead of the PTU to ensure their functionality and stability before release 03:42.

• The goal for this year is a recommitment to making Star Citizen a place where everyone can live out their sci-fi dreams 03:49.

• The goal is to create a more stable universe in Star Citizen with little to no reversal, achieved through an ambitious monthly patch cadence focused on content rather than features, including progressive bug fixes and refactors that build over time 04:05.

• The monthly patches will primarily utilize game systems already in place, continuing to develop the stories of Stanton, Pyro, and Beyond, including new in-game adventures and discoveries 04:34.

• The development of Star Citizen is shifting towards a more content-driven universe experience, with big feature work taking a back seat to fixing existing issues 05:05.

• The weekly video offerings will change to preserve the discovery of new story content and avoid spoilers, with Inside Star Citizen and Star Citizen Live being combined on Thursdays 05:18.

• A new behind-the-ship series will be added, alternating with other content as the stories demand, and will include in-depth chats with developers, such as Chief Technology Officer Ben W. Boser 05:51.

• The focus on stability will continue, with efforts to address persistent bugs and provide a better experience for players and developers 06:14.

• The cancellation of the Lunar New Year free flight was done to avoid further destabilizing the current Star Citizen experience, and the changed programming will provide benefits for players and developers 06:49.

• The developers will be able to focus on making Star Citizen and Squadron 42 the best they can be, with fewer distractions, and there will still be videos dedicated to the making of Star Citizen, just fewer than before 07:12.

• New ships will be added to the verse, but most will use existing gameplay systems to avoid creating instability 07:37.

• There will be more patches than before, with a focus on stability and content-driven development 07:43.

• A new approach is being taken, with a focus on releasing updates approximately once a month, which will include bug fixes and new story-driven content, but fewer big-ticket features until stability is achieved 07:45.

• The upcoming year is expected to be interesting, with efforts focused on improving the overall stability of the universe 08:04.

• The proof of these efforts will be seen gradually, month after month, over the course of the year, and support is hoped for on this new adventure towards a more stable universe 08:16.

Show Begins 08:30

• The show is being broadcast live, with no pre-recording, and is a special edition episode titled 'A More Stable Universe' 08:30.

• Jared Huckabee is the host of the show, and he welcomes viewers to Star Citizen Live, noting that this episode is a good starting point for new viewers 08:47.

• Jared Huckabee is joined by chief technology officer Ben W, and he invites Ben to say hello to the audience 09:02.

• Ben responds with a greeting, stating that he is doing well 09:06.

• Jared Huckabee begins the conversation by asking Ben to introduce himself to viewers who may not know him 09:09.

 

[Montoya]

Meet Benoit Beausejour 09:15

• Benoit Beausejour is the Chief Technology Officer, also referred to as the Chaos Team Organizer, and is responsible for leading the engineers in their development efforts, the development of the Star Engine, and both games, ensuring engineers have the necessary tools and priorities 09:17.

• His role involves overseeing the development process to ensure engineers know what they have to do, have the tools to do it, and have the right priorities overall based on the two projects 09:27.

• The discussion will be divided into sections, covering various aspects of development, and will include a review of JIR to address some of the most pressing bugs and understand the current status 09:56.

• The conversation will start by discussing how the team used to work and then move on to a significant change that has occurred 10:09.

The Old Ways 10:10

• The 4.0 patch was in testing for 3 months before it went to preview, and then it was left on for another month and a half, with the development process involving a lot of new technology, including server meshing, which was previously showcased in tech previews 10:34.

• The decision was made to split the 324 release and the 4.0 preview, leaving 324 up as a stable release while giving players access to a 4.0 preview, due to the patch not being ready for a live release and the need for more concurrency to discover issues 11:28.

• The 4.0 patch was always intended to be a full wipe, which allowed for the preview to be released without affecting players' persistent progress, and the decision to do this was made months in advance 12:32.

• The 4.0 preview was released to de-risk the initial release, which had a lot of issues, and to allow for important fixes to the underlying technology, with the Skeleton Crew teams working throughout the break to document and fix issues 12:55.

• The "clock" that 4.0 had to go out before was the need to release the code at some point to move on to bigger projects, as the PTU process has its limits and additional builds would not provide any further benefits at a certain level of concurrency 13:29.

• The project's goal is to release the code to move on to bigger projects, and the PTU is a great process, but it has its limits, and at some point, additional PTU builds do not provide any further benefits 13:41.

• The PTU will have concurrency and the goal is to maximize those moments, especially for 4.0, to get the technology out and fix issues, with the additional benefit of planning for the release 14:05.

• Despite some issues, the decision was made to allow players to keep playing 3.24 as a fallback or primary play environment while also trying the new content in 4.0, showing a change of mentality in respecting the live environment 14:58.

• This decision allowed players to have a stable experience to fall back on, and a fairly large contingent of players continued to play 3.24 during the 4.0 preview, possibly due to issues at launch 15:50.

• The decision to run both environments provided the ability to do live comparisons of the two workloads, fix early issues, and provide a test environment while allowing players to keep an escape hatch 16:44.

• The comparison of the 4.0 preview and 3.24 workloads showed that the 4.0 preview workload was bigger, and the team was able to identify and fix some of the most egregious issues that would have been a disaster otherwise 16:51.

• The decision to run both environments also allowed the team to gain valuable insights and data, which will be discussed further, and provided a test environment while allowing players to keep playing 3.24 17:15.

All About Alpha 4.0 17:33

• Testing for Star Citizen began in Evocati in October and moved to Wave 1 in November, remaining in Tech preview over December and January, spanning around four months of testing 17:36.

• The majority of development during these four months focused on finishing features to ensure server meshing compatibility 18:29.

• A server meshing play test was conducted at the beginning of October, which identified issues that needed to be addressed 18:41.

• Upon reintegrating the streams and running server meshing in Pyro, major issues arose, including poor network performance in the first couple of Evocati builds and large PTUs in October 19:04.

• The size of levels and content creation in Pyro differed from previous tests, significantly impacting the streaming and replication systems 19:31.

• A change in the engine aimed to optimize streaming radius, but it introduced an issue where the bounds of objects were inflated, causing every game client in Pyro to bind a large part of the environment 20:06.

• This issue led to increased workload on the hybrid service, which replicates data, resulting in poor network performance 21:20.

• The problem was eventually identified after several days of investigation, and a solution was found, although the exact process of finding the solution is not specified 20:52.

• The game's network usage is substantial, with upwards of 15 to 20 megabits per client, which caused interaction lag and functionality issues in the past 21:29.

• The first build of version 4.0 was the beginning of the journey, where the team gained confidence from their tests, but encountered issues that couldn't be discovered until the game was scaled up 21:53.

• The team established player accounts for launch, aiming for a 500-player Shard with a soft cap and 600-player hard cap, which provides flexibility in matchmaking and performance 22:25.

• The team identified the need for more gateways for hangars, as the game wouldn't support a large number of players without them, and made adjustments accordingly 22:55.

• The team worked on finalizing elements for launch, including network bind optimizations, which took a full month to complete and resolved quick stalls 23:21.

• The teleport API was also completed, which allows for cross-server teleportation of objects, and is used by several systems, including respawning characters 23:34.

• The territory configuration was also updated, allowing for larger shards and more experimentation, resulting in the current setup of five servers on each side of the star system 24:47.

• The game's architecture involves a space server that handles open space and jump gates, while each major planet has its own dedicated game server for its zone, allowing for full server meshing mode 25:19.

• Issues arose from having more servers, which had ripple effects on entity behavior and game performance, requiring adjustments to be made 25:23.

• One of the features that was not finished for version 4.0 was the "co-location" of instances and territories, which will be discussed further, particularly in relation to hangars 25:39.

• A major concern for version 4.0 was that server meshing would improve performance, but initial tests showed that it did not, prompting a company-wide effort to address the issue 26:12.

• To improve performance, "Joker card initiatives" were launched, allowing teams to cut through red tape and prioritize performance fixes, with a focus on identifying and optimizing code hotspots 26:42.

• The network team, which had a "Joker card," was able to request resources from other teams and make significant progress on performance improvements 26:54.

• The company's engineers and tech teams worked together to review hundreds of captures, identify performance issues, and implement fixes, with a goal of delivering at least 15-20 FPS per server 27:11.

• The AI team discovered a navigation mesh generation issue that was costing 15-20 milliseconds per frame, which was refactored and optimized to improve performance 28:04.

• The physics code was also identified as a major issue for server performance, with a high demand for physics simulations, prompting further profiling and optimization efforts 28:37.

• In Star Citizen, when an object is spawned intersecting with another object, it can cause performance issues due to the physics engine trying to solve the intersection, unlike in other games where the objects would no longer be colliding after a map reload 29:23.

• To address this issue, the "Joker card initiative" was started, focusing on physics expensive event resolution, which detects and raises events for resolution, allowing the game to handle intersecting objects, such as ships, debris, and players 29:47.

• The physics expensive event system raises events for the game to handle objects, such as debris, and the game can then delete, stow, transform, or move the objects to clean up intersections and improve performance 30:16.

• A bug was fixed where some ship components could stay static in the world after an explosion, causing intersections with spawned debris, and a system was added to raise issues with debris for automatic cleanup 30:47.

• Another issue was fixed with AA turrets, where their components would overlap and cause server load issues when destroyed, and this issue is now being completely evicted from the system 31:32.

• Between 3,243 and 4.1, the team fixed 2,900 bugs, which is over 3,300 tasks, as some bugs require multiple tasks to fix, but the question remains whether the right bugs were fixed 32:39.

• There are many long-term bugs in the system that have been ongoing for a long time, and the second half of the program will address these issues one by one 33:34.

• The complexity of some issues requires specific handling, and the capacity to fix them depends on having the right person available for the problem 34:14.

• Some problems require experts, and the manpower is extremely specialized, making it challenging to address certain issues 34:45.

• Older systems, such as ATC, ASOP, terminal hangers, and Transit, are particularly difficult to make quick changes to, and are often referred to as "sandworm" features 34:55.

• Not everyone works on everything, and there are a finite number of experts available for any one thing, making prioritization a challenging task 35:35.

• The team has to make difficult choices when it comes to prioritization, weighing the importance of one issue against the potential to fix multiple other issues in the same amount of time 36:09.

• Prioritization is not made by one person alone, but rather through a committee-like process where everyone has their perspective, priorities, and ideas on what is most important 36:49.

 

[Montoya]

Letter From the Chairman 38:30

• The primary focus for Star Citizen teams in 2025 is improving playability, which surrounds three critical areas: performance, stability, and content, with the goal of delivering a more reliable and consistent live environment 38:48.

• The current game, if it ran smoothly with fewer obstacles and bugs, would provide an unparalleled experience, and the teams have experimented with different approaches to improve quality of life and tackle tech debt 39:14.

• However, the ongoing challenge has been balancing efforts to improve quality of life alongside the introduction of new features and technology, which has led to instability, hindered performance, and impacted gameplay 39:29.

• To address this, the teams are re-evaluating their approach to feature and content roll out, focusing on steps to bring the game to a better state while maintaining steady delivery 39:54.

• The first step is committing more resources to fixing issues that affect the live environment and those reported by players, which means slowing down on features and allocating resources from feature development to issue fixing 40:19.

• This involves increasing bug fixing quotas for teams and prioritizing issues that require expertise from multiple areas, such as physics, audio, graphics, and gameplay 42:07.

• The teams will still build features, but they will prioritize those that can be done while investing in correcting problems that have been in the game for a long time or are newly active and complicated to solve 41:35.

• A significant amount of time will be dedicated to bug fixing, aiming to jumpstart the process and address key issues that affect players the most 42:15.

• Despite fixing 3,000 issues, there are around 15-30 issues that significantly impact players and need to be resolved, which have been added to the "director's list" 42:26.

• The director's list allows directors to flag critical issues in their domain and prioritize their resolution, which will also serve as release criteria 42:37.

• The current process of moving through development waves is being re-evaluated to focus more on game quality, rather than just metrics and stability 42:56.

• To move away from being an alpha game, the development process needs to become more professional, with a focus on launch criteria and resolving critical issues 43:20.

• The goal is to make a significant dent in the director's list, even if it continues to grow, by allocating resources effectively and making tough decisions 43:45.

• To achieve this, experienced engineers and programmers will be reassigned from new feature development to focus on bug fixing and less glamorous tasks 43:59.

• This approach involves utilizing existing experts, rather than hiring a large number of new people, to address critical issues and improve the game's stability 44:17.

Stability 44:25

• Working on stability in the game means aggressively monitoring various metrics, such as server crashes, hybrid crashes, client crashes, and client disconnects, to ensure a consistent and reliable experience for players 45:35.

• Stability also involves improving observability, which allows teams to see issues from the server side and cloud environment, providing a more immersive experience for players 46:40.

• The goal of stability work is to change problematic systems into self-healing systems that can repair themselves when issues arise 47:25.

• Establishing budgets for errors and performance is also crucial in stability work, affecting everyone in the company, and involves identifying and solving offenders that go above these budgets 47:47.

• Reducing error rates is a key part of stability work, and the challenge lies in the fact that it's a constant process, with new bugs and crashes emerging as old ones are fixed, creating a "fog of War" 48:22.

• To address this challenge, a more robust hot fix process has been implemented, allowing for quicker fixes to big problems, but it also contributes to the "fog of War" 49:07.

• Stability work involves ensuring that content and features do not use too many resources, such as CPU, GPU, server calls, bandwidth, storage, and networking 48:01.

• The stability team focuses on making interactions consistent and reliable, such as successfully connecting to the game, logging in, and performing actions like joining a ship's cockpit 46:04.

• Stability is about providing a consistent and reliable experience for players, with the goal of making the game more enjoyable and immersive 46:31.

Performance 49:22

• Performance is a larger issue that touches on the client, hybrid, and server, with the hybrid being the replicant that handles networking, and it's about frame rate, loading times, memory utilization, and resource utilization of the machine and network connections 49:31.

• Loading times refer to making sure load times are acceptable in all areas, including the loading screen, loading assets, streaming in an area, and fully initializing a full location 49:51.

• Memory utilization involves using efficient memory and staying within the memory budget, with a need for stricter budgeting in this area 50:12.

• Resource utilization involves improving the use of the machine's resources and network connections, including latency, bandwidth connectivity, and stability of the connection 50:25.

• The people working on performance and stability are primarily engineers, who have a large focus on these areas, although other teams may also be involved 51:32.

• The work on performance and stability is a major change that involves taking people off of feature development and putting them on existing features and work, but does not affect certain teams such as vehicle artists and environment team members 50:48.

Who Does This Work? 51:40

• The team responsible for site reliability is the first to watch metrics and call out issues that need to be solved, and they loop in engineers as needed 51:44.

• The way things are made in the game can have a big impact on performance, and content teams are also responsible for performance, although to a lesser extent than stability 52:08.

• Content teams can use techniques such as group merging to reduce the effective size of objects and improve performance 52:25.

• While content teams are not totally free from performance responsibilities, they are less in the line of fire because typically an engineer is needed to identify a problem first 52:42.

• The difference between an engineer and a programmer is almost non-existent, with the terms being used somewhat interchangeably, although "engineer" may imply a more architectural approach 52:58.

Putting Words into Motion 53:25

• The conversation is about prioritization and delegating responsibility within the company, specifically regarding the assignment of tasks to engineers and programmers across different studios 53:47.

• The company has a large number of talented engineers and programmers with varying levels of experience, from juniors to seniors, each with their own specialties and aptitudes 54:16.

• The decision on who works on what is based on the principle of ownership, where the person who wrote a system is considered the best qualified to make further iterations or bug fixes, as they have the least on-ramp time 55:55.

• However, this approach can be challenging due to factors such as churn, people leaving, and internal movement, which can result in systems ending up with no owner 57:01.

• The company's unique development process, where they release a game before it's fully developed and run a live game environment in the middle of development, adds to the complexity of task assignment and prioritization 56:20.

• The "cost of shipping" is a significant factor, as any priority issue for the live patch needs to become absolute, making it essential to assign tasks efficiently 56:29.

• Chris Roberts has set a mandate and directive for the company, which guides the decision-making process for task assignment and prioritization 53:38.

• Assigning work to developers needs to be balanced to ensure that the work is distributed fairly, and that junior developers are paired with seniors to encourage growth and development, while also considering the need for leadership and management within the team 57:15.

• The goal is to have a healthy engineer team with a balance of junior and senior developers, and leadership that can manage and orchestrate the team, with lead developers spending around 40% of their time on management tasks 58:44.

• Junior developers need to be paired with seniors to learn and grow, and sometimes two people may work on an issue not because it's necessary, but because it's part of the junior's training and growth 57:37.

• Leadership is a key element in managing the team, and lead developers are responsible for ensuring that issues are moving forward, plans are sound, and quality is maintained through code reviews 58:13.

• The team needs to avoid overburdening developers, especially juniors who may be eager to take on more work, but may become overwhelmed and compromise quality 59:06.

• The team has moved away from the "go go go" process, which was a mentality that prioritized features over quality and stability, and is now focusing on releasing patches with features that are ready, rather than waiting for specific features to be completed 01:00:23.

• The project has been feature-driven since the Persistent Entity (PE) was introduced in 2015, but this approach has led to a cycle of constantly chasing new features without making progress, which is unsustainable 01:00:49.

• The team has realized that they need to try a different approach, focusing on stability and core systems rather than new features, which is a scary but necessary change 01:01:37.

• This new approach will require programmers to work on less glamorous tasks, such as elevators, rather than new features, which may create problems with keeping people engaged and interested 01:02:07.

• The team is aware that this change will create struggles in marketing and positioning the game, but they believe it is necessary to make the experience better 01:02:36.

• The decision to focus on stability and core systems was made in December, and the team is eager to implement it, as seen in the example of a big streamer experiencing issues with elevators in the game 01:03:27.

• The team is faced with the challenge of assigning critical but unsexy tasks, such as rewriting the transit system, to either senior or junior developers, which is a difficult decision 01:03:42.

• Previously, the team would have assigned such tasks to junior developers with some support, but this approach has not been effective in the past 01:04:29.

• A transformational fix or rewrite is being implemented for the PU, which will provide a support network around team members and allow everyone to grow into a superstar, regardless of their current role or position 01:04:39.

• The previous setup would have given a support network but the person in charge would not have been the leads or people who really make a difference, whereas now transformational players will be used to solve problems because they have to be solved 01:05:16.

• Resources from transformational elements will be taken to fix the foundation, and Transit, which has affected a million people at CIG, will be a major focus area 01:05:26.

• The company has called themselves out on their own BS and is now putting everybody where they need to be, with a focus on fixing the foundation 01:05:50.

• The decision to fix or refactor an old feature is based on whether the way the feature or system was constructed is compatible with what the PU is going to be or what the technology behind the PU will be 01:06:29.

• The company will look at the underlying system and decide if it needs to be rewritten to take advantage of streaming and server meshing properly, rather than trying to patch it together 01:07:07.

• A collective effort is being made to re-evaluate everything, with all prior assumptions being thrown out, and a fresh start is being taken to decide who should go where and what tasks should be prioritized 01:07:51.

• Delegating engineers and programmers between tasks is hard enough, especially with a limited number of them in the company, but a fresh start is being taken to prioritize tasks and allocate resources effectively 01:08:10.

• The development team is working on two games, Star Citizen and Squadron 42, with some shared gameplay systems that benefit both projects, but also require context switching between the two, which costs time 01:09:37.

• The gameplay teams need to be more fine-grained in their resource allocation, taking into account the different needs of each project, such as Squadron 42's internal milestones and aggressive release schedule for 2026 01:10:10.

• The resource allocation is not a fixed 50/50 split between the two projects, but rather a flexible model that allows for reinforcements to be brought in as needed, with some engineers dedicated to Squadron 42 but able to be flexed to Star Citizen when necessary 01:11:14.

• The two projects have an adjacent cadence, with milestones that are aligned to allow for flexibility in resource allocation, and features that are similar in both projects, such as actor-related bugs that need to be fixed on both sides 01:11:41.

• The development team aims to find a balance between the needs of both projects, with a focus on achieving the milestones and release schedules for each game 01:12:06.

• Chris and Yens have discussed the resource allocation and flexibility needed to achieve the goals of both projects, with a focus on finding a balance that works for both Star Citizen and Squadron 42 01:12:11.

 

[Montoya]

All About Alpha 4.0.1 01:15:45

• Alpha 4.01 was released, but it did not solve all the problems, and some players may have had unrealistic expectations of a "silver bullet" patch that would fix everything at once 01:15:48.

• The patch did make some drastic improvements in many areas, especially for issues that affected a lot of players during the break, and it includes all the hotfixes from 4.0 01:17:59.

• However, the patch also regressed in some key areas that are very problematic, and the forward-facing elements of the patch have taken a step back, while the infrastructure level has made a step forward 01:18:30.

• The approach going forward will be to release patches month after month, focusing on bug fixes and building on existing features without adding new ones, with the goal of slowly improving the stability of the persistent universe 01:17:12.

• The team is frustrated and exhausted, just like the players, and they are working to address the issues and improve the game 01:20:07.

• The next patch, possibly 4.02, will not be the next "silver bullet" either, and it will likely focus on bug fixes and improving existing features rather than adding new ones 01:17:09.

• The current state of the game is plagued by issues such as players getting stuck, elevators not showing up, and people falling through trams, which will not be fixed with just one or two patches, but rather a series of patches over time 01:20:15.

• The plan to address these issues involves a shift in the company's focus and priorities, which takes time to implement, especially for a company of this size 01:20:50.

• Chris's letter has set the commitment for this new direction, and the leadership is on board with the changes needed to increase playability 01:20:41.

• To support this effort, teams need to be properly supported, which includes tackling technical debt, improving processes, and building tools to ensure confidence in fixes and bug validation 01:21:40.

• The goal is to improve output through better processes, pre-submission checks, and validation, allowing teams to have confidence in their fixes 01:22:03.

• A common issue has been the discrepancy between reported fixes and actual fixes, which can be frustrating and is often due to multiple causes for the same outcome 01:22:21.

• The proof of the plan's success will be in the action, with a focus on monthly patches, although not every month will have a patch, with around 9 or 10 patches scheduled for the year 01:23:20.

• The patches will focus more on bug fixes and content that doesn't require new features, rather than feature work 01:23:46.

• Events that don't require new features can still be successful and are not the cause of the current issues 01:23:55.

• The focus is on the output and whether the product quality improves, specifically if the new method works and solves existing issues such as interrupted missions and bugs 01:24:05.

• The Siege of Orison event is cited as an example of an event that required substantial feature work, but the underlying feature work was not ready for prime time 01:24:45.

• The approach to building events is crucial, and it's better to build on existing, proven technologies rather than trying something new and untested 01:25:05.

• The team will continue to try new things, but with a dramatically reduced risk and a more cautious approach, using the new tech preview situation and methodology 01:25:20.

• There may still be moments where trying something new doesn't work out, but the team is more hopeful for this year due to a collective realization of the need for change 01:25:43.

• The upcoming year is expected to be different, with a focus on improving the product and content, rather than introducing a lot of exciting new features 01:26:11.

• The team is more hopeful for this year than in previous years, with a sense of uncertainty and excitement about the new approach 01:26:07.

Persistent Bugiverse 01:26:24

• The discussion revolves around the "Persistent Bugiverse" in the game, where long-term existing issues have plagued the game since version 3.24 or longer 01:26:27.

• The community has expressed frustration about these long-term issues, and a list of problems has been compiled to ask for status updates 01:26:45.

• A meeting was held with folks from the community team, including Tyler, Lenny, and Freya, as well as the player relation team, including Bayer, to gather information on these issues 01:26:57.

• Chris Roberts also provided some information on these issues, which will be shared 01:27:10.

• The list of issues will be discussed in no particular order, but some preparation was done beforehand to look into a couple of these problems and gather updates 01:27:25.

• The person presenting the information does not have knowledge of the current status of every single major bug in the game, but they did research to gather updates on most of the issues 01:27:39.

 

[Montoya]

Server Instability and Character Stowing 01:27:50

• The current server and stability issues in the game include frequent login issues, being stuck at position one in the queue for extended periods, Shard locks, and servers becoming unresponsive or dead, with players often relying on joining friends in instances to find working servers 01:27:55.

• The login issues and being stuck in position one are being deeply investigated, with the problem appearing to be related to the matchmaking service and the authorization call taking multiple minutes to close out 01:28:18.

• The matchmaking system finds available Shard instances and tries to match players to a Shard with affinity, either because the player is already in that Shard or has been in it before 01:28:40.

• The authorization call is a process that tells the Shard that a player is coming, but sometimes takes multiple minutes to close out, causing the player to be stuck in position one 01:29:21.

• This issue can be fixed with a hot fix, which is a type of fix that can be rolled out without requiring a patch, but some fixes require a patch and cannot be hot fixed 01:29:48.

• Hot fixes can be used to roll out code changes to game servers, but there are requirements for this, including no data change, no asset change, and maintaining network compatibility 01:30:26.

• Some bugs cannot be hot fixed because they would cause client compatibility issues, and must wait for the next patch window 01:30:54.

• Maintenance windows are being discussed to allow for data fixes and client upgrades, which would require taking the environment down and forcing players to upgrade their client 01:31:08.

• Life changes are being performed more aggressively to improve the stability of the universe, and a process is being nailed down for this purpose 01:31:29.

• Hybrid fixes are challenging to implement as they require disconnecting all players on a Shard, and with fewer game shards available, disrupting them can have a drastic effect on the live environment 01:31:39.

• The team is preparing for an official maintenance window to perform infrastructure changes or upgrades, which will be scheduled and announced in advance to minimize disruption 01:32:27.

• The lack of a regular maintenance window, unlike other MMOs, has been considered, and the team is working towards implementing a systematic approach to downtime 01:32:15.

• Load times have increased significantly in version 4.0, especially for Pyro system players, who may even time out during loading 01:33:10.

• The current hypothesis for the increased load times is that the Pyro system's entity, which holds the space scape, is not assigning authority quickly enough, causing delays 01:33:32.

• The delay occurs when a server hosting the Pyro spacecap entity is rebooting due to a crash, causing all players to wait for the server to complete its provisioning loop before loading in 01:34:54.

• A potential fix for the issue has been identified, but it is still being investigated and tested 01:35:30.

• Chris Roberts messaged to inquire about login issues, and it was mentioned that some players who shut down their client and logged back in were still experiencing issues, while others were not. 01:35:46

• Players have different methods for fixing login issues, such as disconnecting, shard hopping, loading into AC, rebooting, and more, but these methods are not always effective. 01:36:42

• The testing process for the game has been identified as missing a crucial element, which is testing with multiple clients in a persistent universe, leading to issues such as concurrency problems when players log in and out of shards. 01:36:57

• The difference between the Public Test Universe (PTU) and the live environment is significant, with a 20x increase in player activity, and players on PTU tend to be more patient and less likely to shard hop, which can make it difficult to test for live environment issues. 01:38:10

• The live environment is where many issues are discovered, and it is necessary to test the game in this environment to identify and fix problems that may not be apparent in PTU. 01:38:56

• Many of the issues currently affecting the game are remnants of problems that were not fully addressed in the past, and the team is working to identify and fix these issues, including concurrency problems and login issues. 01:39:25

• Shard loock is a community term that refers to a situation where a character is temporarily locked into a Shard, meaning they can only be in one Shard at a time, and if they get matched into a Shard, such as us_e1b_010, their character will get unstowed and moved from the global database to that Shard 01:39:59.

• When a player quits the client, gets disconnected, or their client crashes, they are supposed to be rematched to the same Shard when they come back, but if that Shard is no longer available, they will receive a 60k error, indicating that their character is still in that Shard 01:41:05.

• Behind the scenes, there is a process that takes the crashed Shard and stows the character back, but during the 4.0 preview, some players got into a state where their character could not get stowed back due to a bug, causing their character to become seemingly corrupted 01:41:31.

• In most cases, time will resolve the issue and the character will be stowed back, allowing the player to re-enter the game, but in some cases, manual actions were required to solve the problem, such as in the case of error 60,3 01:42:01.

• The term Shard loock has gained a reputation, particularly with Shard us_e1b_010, which is often referred to as being "cursed" due to its frequent issues 01:40:24.

Elevators and Trams 01:42:27

• The current issues with elevators and trams in the game include broken or missing elevators preventing access to hangars, and trams that let players fall through the floor or launch them into lower orbit 01:42:45.

• The transit system in the game is composed of multiple components, including peripherals, gateways, and carriages, which work together to manage the movement of elevators, trains, and trams 01:43:37.

• The system is complicated by the fact that it is a non-trivial problem to solve, especially in the context of streaming, where not all components are always loaded 01:43:26.

• In other games without full level streaming, all components of the transit system are always loaded, making it easier to manage, but in this game, the system unloads carriages when not in use, which can cause issues 01:44:48.

• The current iteration of the system destroys and recreates carriages as needed, which has led to a ton of issues, including problems with streaming and the way the system fulfills orders 01:45:20.

• The system needs changes to its communication layer to be reliable and a fundamental change in how it fulfills orders, instead of just sending a message to a carriage and hoping for the best 01:46:19.

• The transit manager needs to be able to self-heal for any kind of issues, and always tend towards the state that it should be in, to resolve the current problems with elevators and trams 01:46:33.

• A new system is being written to solve communication issues with streaming and make the system self-healed, but fixes to the current system are also being implemented immediately to address current elevator issues 01:46:38.

• A "crack team" has been formed to significantly increase the size of the group looking at the current elevator issues, which have regressed, and they are working on adding a self-healing component directly into the system 01:47:02.

• Proper reproductions have been found for at least a couple of cases where gateways become defunct, including when an elevator is called but never shows up, and when a lift shows up but doesn't move 01:47:24.

• The reproductions are not just happening to players, but the team has also been able to replicate the issues and understand what's going on, allowing them to implement self-healing fixes 01:47:53.

• In the past, the team has been hesitant to implement short-term fixes because they knew the long-term solution would involve replacing the entire system, but they are now doing both to address immediate issues 01:48:07.

• Two groups are working on the issue: one is writing a brand new transit system built for the server meshing reality, while the other is focused on a short-term self-healing fix to the current system 01:48:37.

• The short-term fix may not solve everything, but it is hoped to dramatically improve the system's reliability, making it function as intended, although it may take longer for lifts to arrive in certain cases 01:48:59.

• The idea is that the system will no longer just fail, but will instead have error checking and self-healing, allowing lifts to arrive even if it takes longer 01:49:25.

• The elevators in Squadron 42 use the same system, but with a higher streaming bubble, which reduces the likelihood of issues, and they are designed for single-player use 01:49:50.

 

[Montoya]

Hangars 01:50:14

• A recent issue in the game caused ships to be destroyed while stowed, which was due to a backend change made to alleviate server load, and the location ID of ships not being updated when they changed, resulting in the ASOP terminal showing the ships as destroyed even though they were still present 01:50:47.

• The issue was caused by a change made by Beno, and it has since been resolved 01:52:22.

• The game's hanger system is instance-based, with each player's hanger being accessible based on ownership, and all hangers on a given ATC Gateway are stacked on top of each other 01:52:44.

• When a player wants to access their hanger, they have two options: using the lift or going through their hanger, with the lift creating the hanger and giving permission to access it 01:53:30.

• The game's render culling system ensures that players only see their own hanger, even though all hangers are stacked on top of each other 01:53:54.

• The ship elevator has several issues, including ships spawning in the wrong location or getting stuck, and these issues are currently being investigated 01:54:08.

• The game's developers are working to resolve these issues and improve the overall stability of the game 01:52:26.

• The current platform and ship physics combination can cause issues, such as flapping, due to the platform not being physics-enabled while the ship is, and a solution is being discussed to either make both elements statically moved or physically driven 01:54:29.

• The layout and setup of the hangers are being reworked to prevent issues with server FPS and performance, ensuring that ships can move up the platform without problems 01:55:22.

• The unstow issue is believed to be a bug related to the timing of leaving a hanger, which can cause a ship to be stowed with the hanger instead of on its own, leading to issues when un-stowing the hanger again 01:55:32.

• The timing of the hanger stow process is being reviewed to ensure that it is correct and that data corruption does not occur, with a dedicated team working on resolving these issues 01:56:34.

• A previously reported issue with exiting hangers has been solved through a hot fix, which addressed problems with the hanger cues managed by the ATC, including issues with timers and players getting stuck in doors 01:57:17.

• The issue of staircases in hangars is not a solution to the problem of traversing between the real world and the instance world, as stairs would still require a portal, similar to an elevator, which would involve queuing and pushing a button to create a portal, and the problem can only be solved through the hard work of developers and engineers 01:58:17.

• Obstruction tuning is related to the physicalization of platforms, and the problem is that the obstruction code is too aggressive, preventing the ship elevator from moving even if there's a small obstruction, such as a speckle of dust, under the platform 01:58:52.

• The developers are doing cleanup to try to stow back ships that are stuck on the platform, but the system still needs work to ensure that it functions properly even if a ship is stuck 01:59:39.

• The developers are also working on self-healing for these systems, trying to prevent conditions that cause problems and also working on aggressive cleanup to keep the system working in case problems occur 02:00:02.

• Bugs that affect the traversal of the game, such as those that prevent players from going to their ship and leaving or entering and refueling, are of the utmost priority and must be solved because they are critical to the game's functionality 02:00:23.

• There is an issue with hangars being assigned incorrectly, with location IDs not matching, and the system sometimes picking one hangar over another, leading to players not having a hangar at all 02:00:40.

• Other hangar issues include hangar lifts clipping player ships and destroying them, doors not opening and closing correctly, and losing personal hangars completely 02:01:22.

• The developers are also working on density cleanup, including ship cleanup, and have discussed physics events, which are helpful for the game 02:01:52.

• Server performance has been improved by evicting debris that cause intersections and slow down physics, resulting in better overall server performance 02:02:07.

• The same system responsible for improving server performance is also responsible for a pink glow that appears on ships, which is a visual indicator of physics intersection issues 02:02:20.

• The pink glow is a temporary solution to help identify problems with the physics intersection system, which is still being tuned and adjusted 02:03:16.

• The current system is too aggressive and can cause ships to be removed from the game, but the goal is to adjust the system so that only unattended vehicles are removed after a long period of intersection 02:03:06.

• The team is working on adjusting the system to make it less aggressive and to prevent attended vehicles from being removed from the game 02:03:04.

• The team members, including Pete, Dave, and Lauren, are discussing the issue and are willing to continue working on it, with Beno being told that he can leave if needed 02:03:35.

Inventory and Item Issues 02:04:00

• Inventory and item persistence issues have been reported, where items disappear from inventories, ships, and storage containers, including bought items, looted items, and mission cargo 02:04:04.

• The issue is caused by the way entities are tracked in the item system, with entities having entity classes and tags or configurations that define what they are and how they should be handled 02:04:25.

• Some items were flagged for auto-destruction, which caused them to disappear after certain conditions were met, such as debris or items spawned on the side 02:05:33.

• The auto-policy has been adjusted, and some items have been re-tagged to prevent them from being destroyed 02:05:54.

• Caching issues have also been reported, where inventory changes are not reflected in the cache, causing items to appear or disappear 02:06:14.

• The query cache is being revamped to ensure consistent updates and prevent caching issues 02:06:37.

• Long-term persistence (LTP) is a complicated system that involves creating and destroying ownership records when items are stowed or unstowed 02:07:06.

• LTP issues can cause items to disappear, but the system is being improved to prevent these issues and ensure that ownership records accurately reflect the player's inventory 02:07:56.

• The current Long-Term Persistence (LTP) system only persists a select set of entity classes, such as ships, which are controlled by designers, to the database 02:08:06.

• When a ship is stored, its entire hierarchy is examined, and any attached or loosely connected LTP items must be added to the list to be persisted 02:08:17.

• Perception issues can arise when items are not persisted as expected, such as a ship left in The Shard between patches, which can result in lost ships 02:08:35.

• The current system has issues with recording events, particularly when ships are claimed, which can lead to lost inventory data and ships 02:09:01.

• The LTP record is not recreated in some cases, resulting in lost ships and inventory data, which is not an acceptable solution 02:09:38.

• A two-prong approach is being taken to address these issues: finding and fixing cases that don't behave as expected in the current system, and developing a new system that allows for forward-compatible data persistence without wiping the database 02:09:49.

• The new system aims to keep inventories intact between patches and allow for non-destructive data persistence, where data is not lost or destroyed when a patch is applied 02:10:02.

• The goal is to differentiate between important serialized variables on entities, such as ships, and runtime-only variables, and to store the important data in the global database 02:10:51.

• The target for the new LTP solution is to ensure that data is not lost between patches and that the database remains consistent, with no loss of records or data 02:11:23.

• A long-standing problem with unique item recovery has been ongoing since 2017-2018, and efforts are being made to address this issue as part of the new LTP solution 02:11:42.

• A major priority this year is addressing the issue of losing items, such as those obtained through pledge purchases, due to falling through planets or other game errors, with a three-tiered solution in development, including short-term, long-term, and super long-term fixes 02:11:58.

• The short-term solution aims to provide immediate relief, while the long-term solution will offer more comprehensive improvements, and the super long-term solution will involve crafting and base building, allowing players to create their own items 02:12:52.

• The first stage of this solution has been signed off and is currently in active development, with a show planned to discuss the details further 02:13:16.

• The aggressive ship despawning mechanic, which sometimes causes ships to despawn while players are still inside, is being addressed, with the goal of preventing this from happening in the future 02:13:43.

• The system is designed to prevent despawning if there are passengers on board, and the root causes of this issue are being investigated, including problems with physics detection and the "Ping glow" 02:14:00.

• A previous issue with ships despawning mid-flight when leaving the area has been solved, but confirmation is still needed to ensure the fix is working properly 02:14:42.

• The issue of ships despawning while players are still on board and the ship is considered "attended" is being treated as a high-priority fix 02:14:57.

 

[Montoya]

Mission Bugs 02:15:00

• Mission bugs have been a persistent issue, with problems such as AI not spawning, mission objectives failing to register, and cargo disappearing upon completion, particularly affecting the Fight for Pyro event, with many players unable to complete it due to bugs 02:15:03.

• The 4.0.2 patch had more mission content, but the mission system was not compatible with server meshing, requiring a large engineering task to refactor the system 02:15:44.

• The previous mission system had a single server managing all entities, with an invisible entity created to manage each mission, but this system was not compatible with server meshing 02:16:06.

• The new mission system is outside of the game servers and orchestrates the global flow of missions, including phases, objectives, state tracking, requirements, and rewards 02:17:40.

• The new system eliminates the need for a mission entity on the server, instead having mission modules communicate with the mission system to tick the logic of the mission forward 02:18:00.

• Markers have been a long-standing issue in Star Citizen, and with server meshing, they became even more problematic, requiring a solution as part of the mission system 02:18:42.

• The problem with markers is that they can cause issues when players are on different servers, such as when one player is on a Pyro game server and another player is on a different server 02:18:54.

• A new technology has been developed to allow the streaming system to stream entity markers across different game servers, enabling players to see each other's positions in real-time, even if they are in different star systems 02:19:03.

• This technology is a fundamental change to how markers work in the game and has required significant development, but it is now in place and has been fairly reliable 02:19:29.

• The marker system is used for various game features, including the mission system, and touches on all markers in the game, which has led to several issues 02:20:06.

• The mission system has not been fully refactored, and the current system is archaic, making it difficult for designers like Elliot, James, and Nick to build compelling missions 02:20:14.

• The current mission system relies on game designers managing markers, which can lead to complicated systems and logic that are not very robust 02:21:08.

• The development team is working on modernizing the mission system by replacing the old scripting system with a new Star script Foundation, which will provide designers with better tools to create missions 02:20:50.

• The new mission system will focus on making it easier for designers to create content that is fun and reliable, rather than getting bogged down in details, and will prioritize features for content creation 02:22:37.

• The goal is to make missions and events that have been problematic in the past more reliable and enjoyable for players 02:22:56.

• The goal is to make the universe fun and reliable, which is especially important for the mission part and the idea of a narratively driven content-driven year. 02:22:57

• This year's focus is on providing a place to go and things to do, connected to the narrative, rather than 8 to 10 new features every single patch. 02:23:16

• The mission system seems like one of the larger priorities, and there will be more conversation about the narrative on next week's ISC. 02:23:28

• There will be a discussion about how to affect priority at the end of the show, and Quantum will be mentioned. 02:23:38

 

[Montoya]

Quantum Travel 02:23:40

• Quantum travel has been a persistent issue with bugs that cause starting and stopping, repeating actions, and lingering problems with fuel states not syncing between meshes or vanishing, and in some cases, ships disappearing during travel 02:23:42.

• The issue of Quantum travel has been present since the beginning, with the first test showing that Quantum stops when crossing a server boundary 02:24:23.

• The same symptom has been triggered by multiple issues, and the latest ones are related to the resource container, which is a component that defines the functionality of entities in the game 02:24:41.

• Entities in the game have classes that define what they are and components that define their functionality, and the Quantum Drive is made up of multiple components that need to deal with the change of authority when crossing a server boundary 02:24:50.

• The team has been fixing issues with the transition of entities for Quantum Drive to function, but a fix would often work for a short period before being broken by a change to how the game deals with certain points 02:25:36.

• To solve the issues with Quantum travel, the team needs to focus more on validating the issues and performing more QA to ensure that the fixes work as intended 02:25:52.

• The team is in the home stretch of fixing the issues with Quantum travel, but more work is needed to ensure that the fixes are validated and the game is stable 02:26:11.

Prison 02:26:40

• The prison system in the game is based on an old mission module that runs the prison logic, which has been causing issues with the prison escape feature. 02:26:49

• The bug, which lasted through the preview and the beginning of version 40, prevented players from escaping prison due to desynchronized logic and state of the mission. 02:27:15

• The issue occurred because the old mission system was not part of the refractor, and the new system requires persistent modules that accumulate logic changes. 02:27:41

• To fix the issue, the developers have moved the leave prison flow logic to the law component on the player's character, making the system more reliable. 02:28:46

• However, the reliability of the fix is dependent on the elevator working correctly, and there are stairs in the prison that can be accessed with the prison escape code. 02:29:22

• The developers have a good confidence in the fix, but acknowledge that there could still be issues if the elevator does not work as intended. 02:29:20

Mining 02:29:50

• Mining has been a problematic gameplay loop in Star Citizen, with some players experiencing up to an hour-long delay for mining to fully load in, making it nearly impossible to mine 02:29:50.

• The issue is caused by the conversion from render node object to entity, which is slow due to the large quantities of mining and harvestables, leading to a performance hit 02:30:34.

• The Rock DS has never been functional for mining, and the team is working to resolve the issue 02:30:21.

• Mission sharing has been reduced with new strict rep Gates, which has affected payouts and made the experience miserable for players 02:31:21.

• A bug previously caused everyone in a mission to receive the full reward, but it was fixed, and the team wants to encourage players to play together by improving the reward system 02:31:44.

• The current system doesn't work as intended, and the team wants to improve it to encourage cooperative play 02:32:30.

• The fix for the mission sharing bug was implemented, but it's not the desired outcome, and the team is working to improve the system 02:32:35.

• The team is committed to transparency and open communication, with this episode being an example of their willingness to discuss the game's issues and challenges 02:33:11.

Vulkan and Nvidia Drivers 02:33:33

• Players using Vulkan with the latest NVIDIA drivers are experiencing graphical artifacts and crashes, with some users reporting multiple instances of the same crash, which may be linked to third-party software 02:33:40.

• The cause of the issue is still being investigated, but it is believed to be related to a specific NVIDIA driver version, particularly the upgrades for the 5090 cards 02:34:09.

• NVIDIA drivers have two components: one for Direct 3D and one for Vulkan, and the issue is thought to be related to the Vulkan driver 02:34:22.

• Downgrading the drivers may resolve the issue temporarily, but further investigation is needed to confirm the cause 02:34:35.

• Other games are also experiencing similar issues with the same NVIDIA drivers, indicating that the problem may not be specific to Star Citizen 02:34:45.

• Users are advised to be cautious when using third-party apps that inject into the 3D pipeline, as they can cause crashes and may be caught by the ESC sandbox 02:35:09.

 

[Montoya]

Issue Council Issues 02:35:25

• The issue Council is a crucial tool for reporting and addressing bugs in the game, with significant discussions around its effectiveness and usability among players, including frustrations with the dupe system and reporting process 02:35:25.

• Despite some issues, the issue Council reports are generally of high quality and are used daily to confirm issues, with many problems on the director's list originating from IC reports 02:36:23.

• The signal-to-noise ratio in the reporting process can be challenging due to varying levels of effort and quality in reports, ranging from brief to extremely detailed 02:36:50.

• Improving the dupe system is a priority, with the goal of making it easier for players to identify and report duplicates, and to give more weight to contributions that help identify dupes 02:37:11.

• Identifying duplicates is considered a valuable contribution, as it helps the team focus on unique issues, and the current system does not adequately reward this type of contribution 02:37:55.

• The team is exploring changes to the issue Council process, including giving more weight to community-identified issues and potentially adding a "police fix hammer" button to upvote issues 02:38:17.

• There are also challenges in accurately identifying duplicates, with some issues being incorrectly marked as dupes, and the team is working to balance this process 02:38:47.

• The team is considering ways to give the community a more direct voice in the issue Council process, including potentially adding community-identified issues to the director's list 02:38:34.

• When a bug is reported from the community, it is attempted to be reproduced internally to determine if it's a new symptom or the same case as another one 02:39:24.

• There is a possibility that some individuals may have semi-malicious intent, such as using bots or dupes, to exploit incentives for participation in the Issue Council (IC) 02:39:42.

• Incentives for participation in the IC can be weaponized, but so far, the worst seen is brigading a specific issue 02:40:09.

• Rewards for the IC are given carefully to avoid encouraging the creation of false reports or duplicates 02:40:30.

• There is a commitment to investigate the possibility of manipulation in the IC, especially if there is a sense that it is happening 02:41:06.

• Not all bugs and topics are covered, but efforts are being made to address as many as possible 02:41:20.

Error Codes 02:41:38

• Error codes in the game can have multiple causes, with some codes having 40, 50, or 60 different possible meanings, and even the 630 error code has multiple causes 02:41:46.

• Initiatives are in place to improve error codes, including merging error pop-ups into a new system called EriCos, which will make them more readable and aligned 02:42:39.

• The current error pop-ups date back to the original start of the project and have not been updated in a long time, with issues such as misaligned cancel buttons 02:42:42.

• A change list (CL) is in place to update the error pop-ups and make them more readable and aligned 02:43:03.

• The error codes themselves are being improved, with categorization for issues and efforts to surface more information about the causes of errors 02:43:15.

• The 30,000 error code, for example, is typically related to character login issues, but there are many possible causes, and the team is trying to provide more information about these cases 02:43:50.

• The wording of some error messages is being revamped to make them more clear and effective at representing the issue 02:44:12.

• The team is also trying to eliminate default error codes for unknown conditions and provide more clarity on these cases 02:44:42.

• The goal is to provide more clarity on error messages, such as the 19k error, which is typically a client-side problem, but the current error message is unclear 02:45:08.

• The improvements to error messages are part of a larger effort to address issues that have been plaguing the game for a long time, including the error pop-ups 02:45:32.

• In the past, the error pop-ups were lost during the 4.0 update, causing a black screen issue, due to a fix for another issue that inadvertently hid the pop-ups 02:45:45.

 

[Montoya]

Going Forward 02:46:46

• The focus for Star Citizen this year will be on stability, performance, and content, with less time and resources spent on new features, although some will still be worked on in the background 02:46:50.

• The project has been heavily feature-driven in the past, with new features being released every three months, but this approach is being stopped in favor of focusing on fixes and quality of life 02:47:27.

• The marketing approach will also change, with no more trailers showcasing multiple new features, and instead focusing on the game's stability and performance 02:47:53.

• The change in approach is scary because it's a departure from how things have been done in the past, but it's necessary to create a great game that can be built upon 02:48:53.

• The goal is to create a game that functions as intended, which will be a great game, and this is why it's time to commit to this new approach 02:50:03.

• The team is aware of the current state of the game and is committed to working hard to make it stable and solid, and to make the game that they want to be 02:51:03.

• The proof of the team's commitment will be in the progress made over the next year, and the team is willing to put in the effort required to achieve their goals 02:50:55.

• The team chose to have an open and honest conversation about the game's state and their plans, with Ben, a team member, choosing to be part of the conversation instead of attending a celebratory party 02:51:54.

 

[Montoya]

Dad Lando 02:52:00

• The community team and player experience team will create a thread on Spectrum to discuss pressing issues and allow the community to vote on which ones they think are most pressing 02:52:16.

• The community's input will be used in conjunction with the internal prioritization, including the director's list, to determine the most important issues to address 02:52:30.

• A thread will be posted on Spectrum, although the exact subsection and timing are not specified, where the community can participate in the discussion and voting process 02:52:42.

• In November, an episode of IE Show featured a puppet song created by John Crew and the speaker, which was a source of pride and something the speaker's dad enjoyed 02:53:18.

• The speaker's dad was a long-time Star Citizen fan, having become involved in 2017, and was proud of his son's work on the project 02:53:50.

• The speaker's dad passed away on December 9th after a series of heart attacks, and the speaker discovered the extent of his dad's involvement in the Star Citizen community while going through his computer and records 02:54:42.

• The speaker's dad was a professional Star Citizen player, with over a hundred unread Discord messages, involvement in at least 14 different Star Citizen discourses, and officer roles in several organizations 02:55:33.

• A personal rule was established to not discuss Star Citizen until after dinner when visiting family during holidays, to maintain a balance in life and keep one aspect not completely consumed by the project 02:55:56.

• The engagement of a family member with the Star Citizen project was due to the community, and some Star Citizens attended his funeral and wake 02:56:21.

• The family member's retirement was spent playing with the Star Citizen community, and many names from the chat were recognized, showing appreciation for their role in his life 02:56:53.

• A personal thank you was expressed to the community for being there for the family member when they couldn't, making the last six or seven years of his life some of his happiest 02:57:03.

• Appreciation was also expressed for the community's feedback, including those who call out issues, and for being a supportive community 02:57:31.

• The show concluded with a mention of upcoming episodes, including a behind-the-scenes episode and an ISC episode, and a farewell message to the audience 02:57:40.

 

[CitizenDad]

TL;DR we will have an actual, playable, legit game...

Soon™

it game... Seriously tho, they really nailed a ton of details and drilled down on a few technical details I was curious about. That being said I never doubted the beliefs and intentions of the middle management, the minions, the marketing guys, shoot even Chris and his bro, and Sean Tracy, execs

I only ever doubt the ability of our patience and how long can we all can really go on. All the things they are doing take so much development time and some truly brilliant, out of the box thinking to pull off, not to mention technological advances that have to be made, accomplished.

Personally, I am setting a timer for 365 days and when that comes I will be judging. I am very judgy when it comes to all things NOT SC but after this "promissory note" of a PR event I am going to be.

I need a year for 16th gen 7GHz/10,000MHz DDR5, and it'll probably take that long to get a shipment of damn 5090's that are not tariff'd to hell manufacture-scalped anyway :)

Oh and 2 Nvidia driver team dudes are looking into Star Citizen and Delta Force issues, specifically though neither of them has an account but i gave them logins of one of ours so we'll see they are all super busy with 5000 series BIOS, drivers. Their team is huge. Like 10x the size of AMD's. I would not suggest using the 517.16 if you are on a 3000 or 4000 series GPU, and maybe even if you are on a 5000 series I have not even had time, ability to get any 5090's in from PNY or Asus so have not done any testing (sad I know). You can get away with not using Vulkan and using the new driver but there are some issues that I would not want to mess with at 4K 144Hz Gsync, Triples, even 1440p OLED's (HDR). The next couple drivers should? sort it out or the next few patches from CIG.


What exactly do ya'll think their message was on "duping" though? It was not crystal clear to me. "Don't dupe to make creds/exploit - dupe to do an issue council report?"

Sounds like they really might be turning a page tho with the whole party, celebration event they had, and giving us a clear message of "We are going to focus on making the existing PU experience good and QOL good, not just disregard it and focus on the final experience" :) Maybe.