Dyson Sphere Program News

[p][/p][p]Hello Engineers,[/p][p]The public test for our newly rebuilt multithreading system is now live! This test is open to all players and focuses on evaluating the performance of the new multithreading system under different hardware configurations. We sincerely invite all engineers to participate in this public test—your feedback will help us create a better gameplay experience![/p][p] [/p][h3]How to join the test?[/h3][p]1. Open your Steam Library → Right-click Dyson Sphere Program → Properties → Betas → Select the branch: public-test-0 - Public test branch for new features.[/p][p]2. During the test, if you encounter any issues, feel free to report them in the #multithreading-bugs channel on our Discord: [/p][p]https://discord.gg/sSVZ4WQ[/p][p][/p][h3]Why rebuild the multithreading system now?[/h3][p]While we’ve been steadily developing the vehicle system and core game features, we realized that the growing complexity of the game was pushing our current architecture to its limits. Without addressing these performance bottlenecks. If the CPU performance bottleneck is not resolved, the addition of the vehicle system could seriously affect the gameplay experience.[/p][p]Out of responsibility to our players, we once again analyzed and reviewed all core systems in the game. We chose to focus this round of performance optimization on the multithreading system and completely rewrote the related code. This will allow us to more effectively utilize multi-core CPU power and alleviate stuttering and frame drops during large-scale factory operations. (See the multithreading dev log for more details:[/p][p][dynamiclink][/dynamiclink][/p][p]More importantly, this optimization will also lay a more stable and smoother foundation for the future vehicle system update.[/p][p]So whether you’re a min-maxing player optimizing every second of production or a relaxed explorer traveling the stars, we hope this update gives you a smoother experience.[/p][p][/p][p][/p][p]Update Log for Multithreading System:[/p][p]● Completely overhauled the \[Multithreading System]. The new multithreading system can more efficiently unleash performance potential, bringing more frame rate improvements in large-scale factories.[/p][p]● \[Game Settings]: Added advanced settings for the new multithreading system. The advanced settings include \[Main Thread Binding Strategy], \[Worker Thread Binding Strategy], \[Thread Phase Waiting Strategy], and \[Thread Frame Waiting Strategy] — 4 customizable strategies. By customizing these strategies, players can better utilize the new multi-threading system.[/p][p]● Overhauled the \[Statistics Panel] performance test. The new performance test is compatible with the overhauled game core logic, helping players better analyze game performance overhead.[/p][p]● Added \[Performance Deep Profiler]. This tool can be accessed by clicking the \[Deep Profile] button in the Performance Test (CPU). It provides real-time operational data for all game logic, allowing players to directly observe the execution methods and efficiency of the game's core logic.[/p][p]● \[Ray Receiver] logic now uses Dynamic Allocation Strategy in multithreading, improving CPU core utilization.[/p][p]● \[Power System] updates in worker threads synchronize with \[Logistics Station Conveyor Inputs] in the main thread, improving CPU core utilization and operational efficiency.[/p][p]● \[Dark Fog Ground Towers and Units] logic added to multithreading with Dynamic Allocation Strategy, improving CPU core utilization and operational efficiency.[/p][p]● \[Various Factory Facilities] logic uses Dynamic Allocation Strategy in multithreading, improving CPU core utilization.[/p][p]● \[Sorter], \[Conveyor Belt], and \[Cargo Rendering] logic adopt Dynamic Allocation Strategy in multithreading, improving CPU core utilization.[/p][p]● \[Sorter] logic updates in worker threads synchronize with \[Storage Tanks], \[Enemy Animations], and \[Trash] in the main thread, improving operational efficiency.[/p][p]● \[Splitter], \[Automatic Piler], \[Spray Coater], \[Monitor], and \[Logistics Station Conveyor Outputs] logic added to multithreading with Dynamic Allocation Strategy, improving CPU core utilization and operational efficiency.[/p][p]● Core logic of \[Turrets] added to multithreading with Dynamic Allocation Strategy. Updates synchronize with related positional logic of \[Dyson Swarm] and \[Dyson Sphere] in the main thread, improving CPU core utilization and operational efficiency.[/p][p]● \[Rockets] use Dynamic Allocation Strategy in multithreading and synchronize with \[Sector Management] in the main thread, improving CPU core utilization and operational efficiency.[/p][p]● \[Statistics] added to multithreading and synchronized with \[Warning System] in the main thread, improving CPU core utilization and operational efficiency.[/p][p] [/p][p][/p][h3]Notes and FAQs[/h3][p]1. About Save Files & Mods[/p][p]Q: Can I use my old save files in the test branch?[/p][p]A: Yes, old save files are compatible with the test branch. However, we strongly recommend backing up your saves locally beforehand to prevent any potential data corruption.[/p][p] [/p][p]Q: Will saves from the test branch be compatible with future official versions or the default branch?[/p][p]A: In principle, yes. Save files from the test branch should be compatible with both future official releases and the default branch. That said, we still highly recommend backing up your files before switching branches—just in case.[/p][p]Default save location (if unchanged):[/p][p]%USERPROFILE%\\Documents\\Dyson Sphere Program\\Save\\[/p][p] [/p][p]Q: Can I still use my old Mods in this test version?[/p][p]A: We advise against using any mods during this test phase.[/p][p]This update includes a complete overhaul of the game’s core logic, with major code changes that may cause conflicts with most existing mods. If you’ve previously used mods, please back up your saves and mod files before switching branches, and ensure your game files are clean to avoid unexpected errors.[/p][p]Of course, we deeply value and support the modding community and are always inspired by your creativity. One of the goals of this test is also to give modders enough time to adapt their mods for the new system.[/p][p] [/p][p]Q: Will logic circuits built with splitters still work?[/p][p]A: If your logic circuits are built using vanilla splitter and traffic monitor setups, they should still work. However, setups that rely on modifications or unconventional configurations may no longer behave as expected.[/p][p] [/p][p]2. Multithreading Settings & Performance[/p][p]Q: Where can I monitor thread performance?[/p][p]A: We’ve added a new \[Performance Deep Profiler] tool. You can access it from the Performance Test (CPU) panel by clicking the \[Deep Profile] button. This tool shows real-time data for all logic threads and helps you better understand how the core systems are running.[/p][p][/p][p][/p][p]Q: How do I configure CPU core binding? What if I don’t understand hardware?[/p][p]A: We add The Advanced Multithreading Settings in \[Game Settings] allows you to customize strategies like thread binding and scheduling. If you’re not familiar with hardware, just use the \[Performance Deep Profiler] to test different presets and see what works best for you. We’ve also provided a default strategy that should work well for most setups. You can always discuss tuning strategies in our community groups.[/p][p][/p][p][/p][p]Q: What kind of performance boost should I expect? How can I feel it?[/p][p]A: The main improvement is in the CPU's "game logic frame" time. As shown in the dev log, there is a noticeable boost in logic frame performance. If your save contains large factories or intense combat, the difference will be more noticeable.[/p][p] [/p][p]Q: My CPU uses a hybrid architecture (e.g. P-cores/E-cores). Will this update help?[/p][p]A: Our system supports hybrid architecture. If you're using Windows 11, performance will generally be better than on Windows 10.[/p][p] [/p][p]Q: Does this optimization reduce the hardware requirements?[/p][p]A: This update mainly improves how efficiently CPU threads are used—it doesn't lower the hardware requirement overall. There is still significant GPU load in DSP.[/p][p] [/p][p]3. Other Questions[/p][p]Q: What are the future update plans? How’s the vehicle system coming along?[/p][p]A: We’ve planned our 2025 development roadmap, and the vehicle system is progressing steadily. We'll share more updates when ready.[/p][p] [/p][p]Q: What should I do if I encounter bugs during the test?[/p][p]A: If you run into bugs, please first make sure your game is in a clean (unmodded) state. We suggest removing all mods and restarting the game before checking again.[/p][p]If the bug still occurs in a clean environment, please report it in the #multithreading-bugs channel on our Discord. Our team will review and address the issues as soon as possible.[/p][p] [/p][p][/p][h3]Final Words[/h3][p]Thanks again to all our engineers for your patience and support! We truly hope you’ll take part in this public test and help us fine-tune the new multithreading system.[/p][p]And of course—we’re extremely excited to see just how far the power players among you can push the game’s limits with this massive optimization boost![/p][p]Let’s build a better Dyson Sphere Program together![/p][p]Discord: [/p][p]https://discord.gg/sSVZ4WQ[/p][p][/p][h3]Other updates in this version (excluding multithreading):[/h3][p]V0.10.33.26465[/p][p] [/p][p]\[Features][/p][p]● Remade \[Video Settings] display mode. It provides 3 options: Borderless(cursor freed / confined), Exclusive Fullscreen, Windowed. The maximum resolution for Windowed mode is the maximized window size excluding window borders and taskbar space.[/p][p]● Now shadow casting can be set in \[Video Settings]. Turning it off can slightly reduce rendering overhead.[/p][p]● Now the maximum duration of ground Dark Fog debris can be set in \[Video Settings].[/p][p]● \[Statistics Panel] Production: Added sorting by ascending / descending consumption rate.[/p][p]● \[Build Menu] Upgrade Facilities: Added upgrade/downgrade by 3 levels functionality.[/p][p]● \[Blueprint Library]: Added \[Facility Only] button. When pasting a blueprint code, information related to the blueprint such as description will remain unchanged.[/p][p] [/p][p]\[Change][/p][p]● \[Statistics Panel] Power: Facilities not connected to a power grid will no longer be recorded in power demand.[/p][p]● When opening the \[Blueprint Library], it now defaults to the latest browsed folder from current session.[/p][p]● \[Replicator] Recipe tip now only displays the formula for that recipe, and no longer shows all formulas for this item.[/p][p]● Optimized the pop-up position of \[Dashboard] tooltips to ensure that the content is not obscured by other UI elements.[/p][p]● Adjusted the box colliders of miniature particle collider. After dragging to build, it allows a Tesla Tower to be built between two miniature particle colliders.[/p][p]● The maximum level of \[Communication Control] has been modified to 88.[/p][p]● Click the in-game clock in the bottom-right menu to toggle between 12-hour clock and 24-hour clock.[/p][p] [/p][p]\[Bugfix][/p][p]● Fixed an issue where opening the Dyson Sphere Panel (Y) while the Dashboard was active could cause incorrect background colors on side UI elements.[/p][p]● Fixed mouse wheel zoom responsiveness in the Dyson Sphere Panel (Y) when accelerating logic frame rates in outer space.[/p][p]● Fixed incorrect display of the 3×1 layout of \[Facility Storage Stats] for conveyor belts and logistics stations in the Dashboard.[/p][p]● Fixed a bug where the number of \[Facility Storage Stats] for storage tanks is incorrect after selected monitoring current and overhead facilities.[/p][p]● Fixed a bug where destroying space units such as Relay Stations and Lancers may leave black shadows at the original location.[/p][p]● Fixed a bug where disabling the construction function of mecha construction drones might cause an error.[/p][p]● Fixed an issue on the \[Load Game Panel] where pressing \[Esc] after clicking “Load” would exit the entire panel instead of just closing the dialog.[/p][p]● Fixed a bug where "Matrix" text fails to highlight when the mouse quickly moves across different matrices in the \[Matrix Lab Panel].[/p][p]● Fixed a bug where some plants are missing icons in \[Combat Tab].[/p][p]● Fixed a bug where abnormal detection could be incorrectly triggered upon reaching extremely high mineral utilization levels.[/p][p]● Fixed several UI layering issues.[/p][p]● Corrected various localization text.[/p][p] [/p]

[p]On July 20, 1969, humanity set foot on the Moon for the first time, opening a new chapter in space exploration. When Icarus leaves its initial planet and soars among the stars, with the galaxy unfolding in breathtaking detail across the screen, a new chapter of Dyson Sphere Program begins as well.[/p][p][/p][p]Decades later, we still remember that historic first step on the Moon—and we will also remember every moment Icarus lit up the stars and strove to build a Type III civilization.Now, it's time to capture your own mark on the cosmos. Snap the shutter, and share your journey across the stars.[/p][p] [/p][h3]About Screenshot Mode[/h3][p]“Screenshot Mode” is a new feature added to Dyson Sphere Program this year. Press \[Shift+F11] to enter the mode, where you can adjust various parameters and camera angles to help capture your most awe-inspiring moments.[/p][p][/p][h3]Contest Timeline[/h3]

• [p]Submission Window: July 18, 2025, 5:00 (PT) – August 5, 2025, 24:00 (PT)[/p]
• [p]Winners Announced: August 12, 2025[/p]

[p][/p][h3]Rules[/h3]

• [p]Submissions must use the in-game screenshot mode of Dyson Sphere Program (default shortcut: Shift+F11), with a resolution of at least 1920×1080.[/p]
• [p]No theme restrictions — show us your most unique and memorable moments![/p]
• [p]Each participant may submit up to 3 screenshots, but can only receive one prize.[/p]
• [p]You’re welcome to include captions, inspirations, or stories behind your images (this could earn bonus points!).[/p]

[p][/p][h3]How to Submit[/h3][p]Choose any one of the following methods:[/p]

• [p]Post your screenshots in the #screenshot-contest channel on Discord[/p]
• [p]Share your screenshots on Reddit under /r/DysonSphereProgram[/p]
• [p]Post on X with the hashtag #DSPScreenshotContest and tag @DysonProgram[/p]

[p][/p][h3]Judging Criteria[/h3]

• [p]All entries will be reviewed by the Dyson Sphere Program development team, publishing team, and Discord community moderators. Winning submissions will be selected based on creativity and visual impact.[/p]

[p] [/p][h3]Prizes[/h3]

• [p]Judge’s Choice Award (50 winners): $10 Steam gift card[/p]

[p] [/p][h3]Notes[/h3]

• [p]By participating, you authorize the official team to showcase your screenshots and display your username/nickname.[/p]
• [p]Plagiarism, unauthorized use of others' work, or any content that violates local laws will result in immediate disqualification.[/p]
• [p]@GamirrorGames reserves the right of final interpretation of this event.[/p]

[p]Greetings, Engineers![/p][p]We are proud to announce a special milestone for Dyson Sphere Program — we are hosting our very first fan concert this summer.[/p][p][/p][p]This is uncharted territory for both our development and publishing teams, as we have never organized an event like this before. The idea was born rather unexpectedly on a winter afternoon:[/p][p]“What should we do this year?”
“What if we held a concert?”
“Let’s make it happen.”[/p][p]And so, an ordinary day turned into the beginning of something entirely new.[/p][p][/p][p]To all our engineers who have supported us over the years — thank you. Your continued enthusiasm and love have brought us this far. We are committed to going even further, to creating more meaningful, joyful experiences that resonate not only across the stars and galaxies, but also in our shared imagination and memories.[/p][p][/p][p]We sincerely hope this new endeavor will be a smooth and successful one. The Dyson Sphere Program symphony concert “Cosmic Harmony of Light and Strings” will take place on August 1st at the Jaguar Shanghai Symphony Hall. We warmly invite you to join us in person as we celebrate this journey together through music.[/p][p]And before we forget — here’s how to get your tickets![/p][p][/p][p]Ticket Information:
Tickets are available via the Shanghai Symphony Orchestra official website.
(Special thanks to Republic of Gamers for their generous sponsorship.)[/p][p][/p][p][/p]

[p]Hello, Engineers! We're excited to share that development of Dyson Sphere Program has been progressing steadily over the past few months. Every line of code and every new idea reflects our team's hard work and dedication. We hope this brings even more surprises and improvements to your gameplay experience![/p][p][/p][p][/p][p](Vehicle System: Activated!)[/p][p] [/p][h2]Bad News: CPU is maxing out[/h2][p] [/p][p]During development and ongoing maintenance, we've increasingly recognized our performance ceilings. Implementing vehicle systems would introduce thousands of physics-enabled components—something the current architecture simply can't sustain.[/p][p] [/p][p]Back in pre-blueprint days, we assumed "1k Universe Matrix/minute" factories would push hardware limits. Yet your creativity shattered expectations—for some, 10k Universe Matrix was just the entry-level challenge. Though we quickly rolled out a multithreading system and spent years optimizing, players kept pushing their PCs to the absolute limit. With pioneers achieving 100k and even 1M Universe Matrix! Clearly, it was time for a serious performance boost. After a thorough review of the existing code structure, we found that the multithreading system still had massive optimization potential. So, our recent focus has been on a complete overhaul of Dyson Sphere Program's multithreading framework—paving the way for the vehicle system's future development.[/p][p] [/p][p](A performance snapshot from a 100 K Matrix save. Logic frame time for the entire production line hits 80 ms.)[/p][p] [/p][h2]Multithreading in DSP[/h2][p] [/p][p]Let's briefly cover some multithreading basics, why DSP uses it, and why we're rebuilding the system.[/p][p] [/p][p]Take the production cycle of an Assembler as an example. Ignoring logistics, its logic can be broken into three phases:[/p][p]1. Power Demand Calculation: The Assembler's power needs vary based on whether it's lacking materials, blocked by output, or mid-production.[/p][p]2. Grid Load Analysis: The power system sums all power supply capabilities from generators and compares it to total consumption, then determines the grid's power supply ratio.[/p][p]3. Production Progress: Based on the Power grid load and factors like resource availability and Proliferator coating, the production increment for that frame is calculated.[/p][p] [/p][p]Individually, these calculations are trivial—each Assembler might only take a few hundred to a few thousand nanoseconds. But scale this up to tens or hundreds of thousands of Assemblers in late-game saves, and suddenly the processor could be stuck processing them sequentially for milliseconds, tanking your frame rate.[/p][p] [/p][p](This sea of Assemblers runs smoothly thanks to relentless optimization.)[/p][p] [/p][p]Luckily, most modern CPUs have multiple cores, allowing them to perform calculations in parallel. If your CPU has eight cores and you split the workload evenly, each core does less, reducing the overall time needed.[/p][p] [/p][p]But here's the catch: not every Assembler takes the same time to process. Differences in core performance, background tasks, and OS scheduling mean threads rarely finish together—you're always waiting on the slowest one. So, even with 8 cores, you won't get an 8x speedup.[/p][p] [/p][p]So, next stop: wizard mode.[/p][p][/p][p]Okay, jokes aside. Let's get real about multithreading's challenges. When multiple CPU cores work in parallel, you inevitably run into issues like memory constraints, shared data access, false sharing, and context switching. For instance, when multiple threads need to read or modify the same data, a communication mechanism must be introduced to ensure data integrity. This mechanism not only adds overhead but also forces one thread to wait for another to finish.[/p][p] [/p][p]There are also timing dependencies to deal with. Let's go back to the three-stage Assembler example. Before Stage 2 (grid load calculation) can run, all Assemblers must have completed Stage 1 (power demand update)—otherwise, the grid could be working with outdated data from the previous frame.[/p][p] [/p][p]To address this, DSP's multithreading system breaks each game frame's logic into multiple stages, separating out the heavy workloads. We then identify which stages are order-independent. For example, when Assemblers calculate their own power demand for the current frame, the result doesn't depend on the power demand of other buildings. That means we can safely run these calculations in parallel across multiple threads.[/p][p] [/p][p] [/p][h2]What Went Wrong with the Old System[/h2][p] [/p][p]Our old multithreading system was, frankly, showing its age. Its execution efficiency was mediocre at best, and its design made it difficult to schedule a variety of multithreaded tasks. Every multithreaded stage came with a heavy synchronization cost. As the game evolved and added more complex content, the logic workload per frame steadily increased. Converting any single logic block to multithreaded processing often brought marginal performance gains—and greatly increased code maintenance difficulty.[/p][p] [/p][p]To better understand which parts of the logic were eating up CPU time—and exactly where the old system was falling short—we built a custom performance profiler. Below is an example taken from the old framework:[/p][p][/p][p](Thread performance breakdown in the old system)[/p][p][/p][p]In this chart, each row represents a thread, and the X-axis shows time. Different logic tasks or entities are represented in different colors. The white bars show the runtime of each sorter logic block in its assigned thread. The red bar above them represents the total time spent on sorter tasks in that frame—around 3.6 ms. Meanwhile, the entire logic frame took about 22 ms.[/p][p] [/p][p][/p][p](The red box marks the total time from sorter start to sorter completion.)[/p][p][/p][p]Zooming in, we can spot some clear issues. Most noticeably, threads don't start or end their work at the same time. It's a staggered, uncoordinated execution.[/p][p][/p][p](Here, threads 1, 2, and 5 finish first—only then do threads 3, 4, and 6 begin their work)[/p][p] [/p][p]There are many possible reasons for this behavior. Sometimes, the system needs to run other programs, and some of those processes might be high-priority, consuming CPU resources and preventing the game's logic from fully utilizing all available cores.[/p][p] [/p][p]Or it could be that a particular thread is running a long, time-consuming segment of logic. In such cases, the operating system might detect a low number of active threads and, seeing that some cores are idle, choose to shut down a few for power-saving reasons—further reducing multithreading efficiency.[/p][p] [/p][p]In short, OS-level automatic scheduling of threads and cores is a black box, and often it results in available cores going unused. The issue isn't as simple as "16 cores being used as 15, so performance drops by 1/16." In reality, if even one thread falls behind due to reasons like those above, every other thread has to wait for it to finish, dragging down the overall performance.Take the chart below, for example. The actual CPU task execution time (shown in white) may account for less than two-thirds of the total available processing window.[/p][p][/p][p](The yellow areas highlight significant zones of CPU underutilization.)[/p][p][/p][p]Even when scheduling isn't the issue, we can clearly see from the chart that different threads take vastly different amounts of time to complete the same type of task. In fact, even if none of the threads started late, the fastest thread might still finish in half the time of the slowest one.[/p][p][/p][p][/p][p]Now look at the transition between processing stages. There's a visible gap between the end of one stage and the start of the next. This happens because the system simply uses blocking locks to coordinate stage transitions. These locks can introduce as much as 50 microseconds of overhead, which is quite significant at this level of performance optimization.[/p][p] [/p][h2]The New Multithreading System Has Arrived![/h2][p] [/p][p]To maximize CPU utilization, we scrapped the old framework and built a new multithreading system and logic pipeline from scratch.[/p][p] [/p][p]In the brand new Multithreading System, every core is pushed to its full potential. Here's a performance snapshot from the new system as of the time of writing:[/p][p][/p][p][/p][p]The white sorter bars are now tightly packed. Start and end times are nearly identical—beautiful! Time cost dropped to ~2.4 ms (this is the same save). Total logic time fell from 22 ms to 11.7 ms—an 88% improvement(Logical frame efficiency only). That's better than upgrading from a 14400F to a 14900K CPU! Here's a breakdown of why performance improved so dramatically:[/p][p] [/p][p]1. Custom Core Binding: In the old multithreading framework, threads weren't bound to specific CPU cores. The OS automatically assigned cores through opaque scheduling mechanisms, often leading to inefficient core utilization. Now players can manually bind threads to specific cores, preventing these "unexpected operations" by the system scheduler.[/p][p][/p][p](Zoomed-in comparison shows new framework no longer has threads queuing while cores sit idle like old version )[/p][p] [/p][p]2. Dynamic Task Allocation: Even with core binding, uneven task distribution or core performance differences could still cause bottlenecks. Some cores might be handling other processes, delaying thread starts. To address this, we introduced dynamic task allocation.[/p][p]Here's how it works: Tasks are initially distributed evenly. Then, any thread that finishes early will "steal" half of the remaining workload from the busiest thread. This loop continues until no thread's workload exceeds a defined threshold. This minimizes reallocation overhead while preventing "one core struggling while seven watch" scenarios. As shown below, even when a thread starts late, all threads now finish nearly simultaneously.[/p][p][/p][p](Despite occasional delayed starts, all threads now complete computations together)[/p][p] [/p][p]3. More Flexible Framework Design: Instead of the old "one-task-per-phase" design, we now categorize all logic into task types and freely combine them within a phase. This allows a single core to work on multiple types of logic simultaneously during the same stage. The yellow highlighted section below shows Traffic Monitors, Spray Coaters, and Logistics Station outputs running in parallel:[/p][p][/p][p](Parallel execution of Traffic Monitor/Spray Coater/Logistics Station cargo output logic now takes [/p][p](Previously single-threaded, this logic consumed ~0.6 ms)[/p][p] [/p][p]Thanks to this flexibility, even logic that used to be stuck in the main thread can now be interleaved. For example, the blue section (red arrow) shows Matrix Lab (Research) logic - while still on the main thread, it now runs concurrently with Assemblers and other facilities, fully utilizing CPU cores without conflicts.[/p][p][/p][p](More flexible than waiting for other tasks to complete)[/p][p] [/p][p]The diagram above also demonstrates that mixing dynamically and statically allocated tasks enables all threads to finish together. We strategically place dynamically allocatable tasks after static ones to fill CPU idle time.[/p][p][/p][p](Updating enemy turrets/Dark Fog units alongside power grids utilizes previously idle CPU cycles)[/p][p] [/p][p]4. Enhanced Thread Synchronization: The old system required 0.02-0.03 ms for the main thread to react between phases, plus additional startup time for new phases. As shown, sorter-to-conveyor phase transitions took ~0.065 ms. The new system reduces this to 6.5 μs - 10x faster.[/p][p][/p][p](New framework's wait times are dramatically faster than old )[/p][p] [/p][p]We implemented faster spinlocks (~10 ns) with hybrid spin-block modes: spinlocks for ultra-fast operations, and blocking locks for CPU-intensive tasks. This balanced approach effectively eliminates the visible "gaps" between phases. As the snapshot shows, the final transition now appears seamless.[/p][p] [/p][p]Of course, the new multithreading system still has room for improvement. Our current thread assignment strategy will continue to evolve through testing, in order to better adapt to different CPU configurations. Additionally, many parts of the game logic are still waiting to be moved into the new multithreaded framework. To help us move forward, we'll be launching a public testing branch soon. In this version, we're providing a variety of customizable options for players to manually configure thread allocation and synchronization strategies. This will allow us to collect valuable data on how the system performs across a wide range of real-world hardware and software environments—crucial feedback that will guide future optimizations.[/p][p][/p][p](Advanced multithreading configuration interface)[/p][p] [/p][p]Since we've completely rebuilt the game's core logic pipeline, many different types of tasks can now run in parallel—for example, updating the power grid and executing Logistics Station cargo output can now happen simultaneously. Because of this architectural overhaul, the CPU performance data shown in the old in-game stats panel is no longer accurate or meaningful. Before we roll out the updated multithreading system officially, we need to fully revamp this part of the game as well. We're also working on an entirely new performance analysis tool, which will allow players to clearly visualize how the new logic pipeline functions and performs in real time.[/p][p][/p][p](We know you will love those cool-looking charts—don't worry, we'll be bringing them to you right away!)[/p][p] [/p][p]That wraps up today's devlog. Thanks so much for reading! We're aiming to open the public test branch in the next few weeks, and all current players will be able to join directly. We hope you'll give it a try and help us validate the new system's performance and stability under different hardware conditions. Your participation will play a crucial role in preparing the multithreading system for a smooth and successful official release. See you then, and thanks again for being part of this journey![/p][p] [/p][p]Ends[/p]

Engineers, hope you're all doing well! Our in-house GameJam has now passed the halfway mark. Since the last update, we've received a wealth of valuable feedback and have been working on bug fixes and optimizations alongside the GameJam.

Don’t forget to grab the latest update when you get a chance!
 
Here is today's full update log:

[h3][Feature][/h3]

•  A new dashboard chart, [Entire Cluster Resources], calculates the amount of resources in all planetary systems (within the scope of cosmic exploration tech). (To add it: Starmap → Planet Info Panel → Popup Menu → Add Entire Cluster Resources to Dashboard)
  
•  Add a tool to set the target Logical Frame Rate in outer space. When Icarus is in outer space, press [SHIFT+F12] to open this tool. The target Logical Frame Rate that can be set ranges from 6 UPS to 240 UPS.
  
•  Five new combat SFX (sound effects) are added: the SFX of the Mecha Energy Shield being hit, the attack SFX of the Dark Fog Raiders and Rangers, and the explosion SFX of the Dark Fog ground units.
  

[h3][Change][/h3]

• Optimized the layouts of 1x1 and 2x1 of Production Chart in Dashboard.
  
• Optimized the layouts of 2x2 Planet (Planetary System / Entire Cluster) Resources Chart in Dashboard.
  
• Now, the Construction Function and the Repair Function of the Icarus' drones can be disabled separately.
  
• When Logistics Bots unload for Icarus, there will be a more intelligent item stacking logic: Try to neatly fill the unfilled inventory slots first. Then, attempt to fill the remaining items into the delivery package. Finally, try to place the items that cannot fit elsewhere into the inventory.
  
• Now, you can click on the version number in the upper right corner to view the changelog during gameplay.
  
• In Sandbox Mode, the storage space of the Logistics Station can now be locked as empty.
  

[h3][Balance][/h3]

• The Logistics Station now adjusts the dispatch frequency of Logistics Drones dynamically based on the busyness of intra-planet transportation tasks, up to one per frame.
  
• The mechanism for consuming veins (Upgraded by [Vein Utilization]) has been changed from the previous random consumption (where the "Ore Loss Per Mining Operation" serves as the probability) to a fixed frequency (where the "Ore Loss Per Mining Operation" serves as a fixed increment).
  
• Significantly increase the item stacking quantity of the exclusive dropping items of Dark Fog.
  

[h3][Bugfix][/h3]

• Fixed the bug where the power statistics details are not refreshed when open Statistics Panel or change the planet filter after turning off the real-time testing in Power Tab.
  
• Fixed the bug that vfx and sfx would be spawned incorrectly when Dark Fog is destroying vegetation on other planets.
  
• Fixed the bug that in some cases, the conveyor belt connection data was incorrect.
  
• Fix the bug where the percentage of the Constructible Area on exoplanets might show 0%, and on the Maroonfrost planet does not display as 100%.
  
• Fix the bug where, in certain situations, the drone only repairs the building that is being attacked and does not repair the buildings that are not under attack.
  
• Fix the bug where, sometimes, the turret will keep aiming at and attacking the enemies on the back side of the planet.
  
• Fix the bug where the system alert and the Dark Fog assaulting alert UI overlap due to a hierarchy conflict.
  
• 
  

[h3]PS:[/h3]

1. The priority of filling the inventory and delivery package when the Logistics Bot unloads items has been adjusted to a more intelligent logic.
   First, the system calculates the maximum number of items that can be added to the inventory by counting suitable slots. Suitable slots include those already containing the same item or those marked with a filter for the item but not yet full.
   
   Example: The player needs 4,500 Conveyors, while the maximum storage capacity of the delivery package is 10 stacks (3,000 Conveyors), resulting in an overflow of 1,500 Conveyors (5 stacks). If the inventory already contains 42 Conveyors and has 3 empty slots marked with a Conveyor filter, the initial calculation determines that 258 + 300 × 3 = 1,158 Conveyors should be prioritized for the inventory. However, since the demand exceeds the delivery package limit by 5 stacks, an additional 300 × 5 = 1,500 Conveyors are added, making the final priority allocation 1,458 Conveyors to the inventory. (If the overflow is less than 5 stacks, this additional calculation will not be performed.)
   
   Item distribution order: The system first prioritizes adding the calculated amount to the inventory. If there are remaining items, they will be placed into the delivery package. If the delivery package is full and there are still excess items, the system will attempt to add them to the inventory again. If the inventory is also full, any remaining items will be sent back.
   
2. Now clicking on the version number on the top-right corner allows you not only check the major update logs but also grants access to our dev team's "Maintenance Log" — where emergency patches and stealth bug fixes not listed in official updates would be all documented in the in-game update logs in real time!