Here i will add a update to whats happening at the games i develop. The older stuff i will move away to the "old Blog" section.
Before i started to do the Tutorial by myself, i tried to give the ai access to the GameObjects, but it didn't work out so well, so i did it than by myself. I regred a bit using the gameobjects for the Tutorial, it feels like a big effort, even for smaller things, but not sure if the code variant for it would be even better.
The last week i spend learning about LLMs and what they are capable today and what they can be used for. Its pretty fascinating. First, i don't plan to add them to the game, and i will just use it for small tooling to do the game like reviews or smaller algorithms. I played around with N8N and implemented a very tiny bot, that you will be able to ask questions related to the game. For the start i did a "simple" knowlage base. I added a workflow, that when the bot is thinking on this message, it adds a think icon. If he has no clue, it adds that reaction too. I can than answer you and that the bot will mark with a lightball when it added it to its knowlage base. From there on he can answer that question.
I plan to add also the recipies and help systems of the game into it to make him able to answer the game related questions in the future. All of that cost a lot of time, so i will focus more on the game for now
For now, i don't have an AI Server yet, but i planned to use one of my old PCs and buy some GPUs and convert it to one. Maybe starting of next Year. Since than my PC act as the Server, so if my PC is off, the bot will not work
In the morning i played around with more ai stuff to create tools to be more productive. I created a tool similar than whisper flow, to have a simple hotkey, recording and pasting it to the textbox. Everything local using the open whisper library, and it went very nice. The first prototype was working in around only one hour. The fine tuning, fixing some bugs, tray icon, configs and so on took the rest of the morning. Also the compile to an exe was not so easy, but all in all its pretty amazing how far the ai tools can work.
So it has now small sound effects, a big settings menu and also a paste last transcription. And everything is local, you can set up the model that it's using, it's downloading it and then and all in all it become a very nice tool I think. also an auto start with Windows feature and if you're interested I'm happy I will be happy to share it with you.
After finishing the DeltaV Summary and fixing some bugs, i migrated the ContextMenu of the Starmap to the new Navigation Planner approach.

I also added more Navigation Errors when trying to takeOff and there is not enough fuel, or try to dock on a ship that is spinning very fast.

In the morning i polished more the KeyBindings. It can now be declared everywhere in the code, so the original enum is resolved. It now behaves similar than the I18nSystem, where i also can define them everywhere to be most flexible and less coupled.
I also added a deltaV Panel, so its easier to see when navigating how much fuel the vessel still have.

Today i worked more on polishing the KeyBindings. I added an element, that listen to changes there and make it also available in the I18n. There is now an easy way to add custom tags like <inputAction="CameraUp" mode="Image"> to directly use those new Elements in the I18n Texts, showing the current bindings of the player.
I continued the Keyboard configuration from yesterday, polished the editor, created an options field and migrated all input bindings i could find. I also added categories and read only field, that are more critical or not changable in general, like pan the mouse. We have now a huge list of all the shortcuts, maybe i will add more to structure that later, mabe icons, or sub categories. Maybe also another column, but for now this will be fine.

I extracted the dynamic max Tasks logic from the TaskManager to reuse that also for the Astronomic System. This adapts the maximum executed Navigation Iterations, depending on the players computer, to prevent lags.
I added now also the PiMenu Items for the Docked Vessels, what was missing before.

At the playtest it was not really clear what the percent values were at the Maintain and Efficiency part of the PiMenu Items, so i added the current state now more obvious.

In the evening i played a bit around with some AI tools, i found a separate topic to discuss with it the architecture for the new Input system and let it create it. In total i think i didn't save time with it, but was interesting. I changed its approach to use my icons instead of plain text, so it might look pretty clean i think.

I started the day by planning the new Tutorial for the SupplyShip and Navigation System. Due to the new Navigation Plan is now ready to be used i thought about a new release strategy. The Idea is to go earlier to the next minor version, when i add a big new feature and than polish it in the patch versions. E.g. i will add the tutorial for the new supplyship and navigation plan in the next patches. When i start the next big feature, like doing the shuttles and moon missions also with the new orbital mechanics, i will increase the minor version again. So its more clear what version includes what. Due to that i did another minor release, but i will release the news just when its a bit tested and keep it on the latest branch.
I also did a longer Playtest of more than 2 hours and it seems working very well so far, but as usual i got a big list of todos where i will work on to improve the gameplay. After those polishings are done i plan to do a tutorial.
I started also to fix the issues this evening and improved some ui elements like readding the overview to the supply popup, this time showing cargo space, crew capacity and deltaV instead of the old space, weight and cost.

Today i added other Navigation Planners for the start of the game, till you have build navigation consoles. There is no crew involved and its just taking the regular working hours to finish the tasks.

Due to this seems a bit too easy, I also added an event appearing after around 6 months that the groundstation is destroyed. Till than you should have been advanced to have the navigation consoles already or you can control it by yourself. On easy this event will not appear to keep it boring

After a longer break on the weekend i fixed the rest of the tests today. It was a lot of changes in the last months, so it took a while to adapt the tests to the new architecture.
Than i continued with the Navigation consoles, adding the model and logic. I also added a chooser to the Vessel Selection Panel.

After some testing and polishing i also added the Navigation Planner UI inside of the console.

Today i worked more on getting the automated tests of the game back running and searching found issues. One thing was a very strange behavior when doing the 2. test out of 2 in a row. It seems the new unity version destroyes the internal companions leading to an exception deep inside of unity... Most of the other things were related to the companion change what i did some weeks ago,
The next part was to polish the new Nativation Tasks, mean dealing better with problems and adding a Log to it, so you can see whats happening.

I also started to design the new console that will be used to do the navigation planning by the crew. Tomorrow i plan to implement the usage of that.

Today i started with the next big feature: The NavigationPlan should be planned by the crew. So the first thing was to refactor that system, to split the check and the execution. The idea is, that there will be a task what do be done for the vessel. The crew than do that at the assigned control panel. Its also periodic checking for problems of the plan and fix them if possible.
I was able to finish the first most difficult part to split up the system and doing that now more async. For now without the crew, that will come next.

Today i did some of the smaller things in my list before i start the next bigger iteration. For example i added the tooltip for the mass calculation of the vessels. It got a general restructuring, so its now more generic and usable for other items too.

Today i started to finish the server case. Than i worked on some internal things like simplify the orbit transfer and the crash events, so they are now done in the astronomicSystem and not anymore with the simulation tasks. I first tried to let this be done by the ai, but it was completely not working well, so i did it by myself. Maybe a too complex task to start for them. In the evening i played more with the new AI Tools and redo the games webpage. Its actually pretty amazing how good they are with that already.
Today i played a bit around with the new AI tools, firstly at the server part to add some admin capabilities. To make that work well i had to update the docker of my server, what seemed risky, but worked well so far! I also tested my new case for the server, due to its already an old server it needed some special cables and also the case is too long for my case, so i have to shorten that too.
Today i worked more on the orbit transfers. Currently i create simulation tasks to transfer to the other orbit, but thats not very nice and leading to a lot of new task creations. The reasonable position for that is the astronomicSystem.
In the morning i just wanted to add a tooltip, but there was already one. Turns out seems to be a bug in unity for the tooltips again... The system fires tons of geometrychange events due to an interal bug in the scroll view... It turns the scrollbar on and off 3-4 times each frame, causing the geometric change events toggling back and forth, so my tooltip system thinks the button is no longer under the mouse, causing an instant closing of the popup... To fix that, i just show the scrollbars all the time. Not nice, but it seems the only usable solution without implementing my own scrollview.
I decided to release a new major version, due to it looks stable enough now. There are still some things i want to improve over the next days like removing warnings, update unity, smaller ui improvements, camera improvements and some other internal things.
https://store.steampowered.com/news/app/1638030/view/497209000041906641
The next Iteration will be the crew Navigation Planning. The idea is the navigation planning is done by the crew instead of an instant change. So depending on the task, the crew will take effort on a console or planning table till the update is done. E.g. the caluclation of the takeoff time will be fast, but planning maneuvers to reach the moon or the docking process will take longer.
In the afternoon i played a bit around with some ai assistents and make visual studio code work for the games untiy project.
I also tried to update to the new unity, it looked pretty good, but the compiled version was not working, due to some strange change in handling entities in the new version... So it took the whole late evening to figure out what the reason is. The reason was the Lens effect of the sun, that is now dealed in ecs completely different than before and causing crashes...
I tested the game today after a longer time and found several smaller and medium issues and several improvements.
I searched the reason for the warnings i recieve from the new GameTimeSystem and was able to fix the error. It was a bit strange, that the calculated nexttime differes by some milliseconds, causing my warning. The reason was, that some callers like the ui called the analyse thrusters function not with the current astronomic time. This lead sometimes to a renew of this cache (due to the mass is different some seconds ago). That causes slightly inconsistencies in calculating the max Acceleration and break times.. Using the correct time for all callers seems to fixed that, so all warnings are now gone from takeoff till reaching an orbit.
This morning i fixed hopefully the last issues with the new Task System. It was some special timing issues when separating a vessel it might happen that a task was scheduled for some milliseconds in the past. Nothing big, but just to get rid of the warnings and get a stable state.
Than i finished the migration scripts for old savegames and due to the new stages cost a lot of money, i added a constant increase of credits depending on the difficulty.
After that i tried a docking and found more issues, maybe related to the performance update 2 days ago, so it still needs more investigation. With a workaround i was able to release a build in the test branch if you want to try it.
In the morning, i profiled again the performance of the navigation system and was able to optimize several things. Now its in the editor much smoother and take around 10s for a takeoff fast forward (12min gametime), so in the release it should be extremely fast with less than 1s.
In the compiled version with much faster timesteps, there was still a problem when skipping a complete hour, so something was still not completely correct. The vessel did not get into orbit, when using extremely fast forward, so skipping one hour without animations. That happened just in the Compiled version where everything is much faster and more things are done each frame.
Even after fixing 2 potential issues it was still the same. Sadly this bug took the whole afternoon evening and night... In the end i finally found and fixed enough bugs to make it work. It was a combination of wrong ordered tasks, using the wrong time, not updating the currentTime inside of the jobs when triggering the staging, not updating the tasks fast enough when the thrusters get enabled, updating the maxProductivity for the thrusters after staging too late and the update of the mass when thrusters turn on, so the mass is removed in a constant amount...
After several days of pc problems and sickness, i got finally back to development this evening. I was able to fix bugs for the new Time System and try to continue tomorrow finaly finishing this long iteration.
Today i worked on the new Fuel consumption, so the astronomic system now gives precice throttle change events. Due to internal architecture i had to merge the events, so it happened that there were an update of 75% to 100% and back at the exact same timestep. That happens, due to it balances first roughly and than fine, leading to more of those updates.
After fixing more issues, the 1h timewarp while getting into orbit is now stable. Just the autopilot did some wrong things, depending on the timings, so i was able to find the problems and fix those issues.
Today i implemented the new Time System that i planned yesterday. It went actually pretty straight forward. The new System is now the only responsible for the time and target times that the systems are executing. Due to there are now more than just one system that can slow the time down, i added indicators to the time speed, so its more clear why its slow. For debugging i implemented a developer only tooltip for it, showing what system is doing what.

It took a bit time till it run smoothly, but it runs already very nice for the first day and i hope to stabilize that over the next days while starting making real use of the new system like the more precice fuel usage.
I finaly was able to merge the Navigation Planner ui with the Pilot UI, so its now more reasonable, when these two things are close related together, due to it can be seen as 2 different levels of auto pilots.

Than I worked on the performance. In the editor i had very bad performance when launching the new supplyship. One reason was the calculation of the kepler orbit, trying to get to the highest precicion possible, leading to a huge calculation time of around 4ms each calculation (in the compiled version it was very fast, but also for slower computers that might be needed). The second thing was the balancer, that always tries to balance to the optimum, leading to a lot of fine tuning, that also cost around 4ms. Than i added a lot of tracking code to find good spots to optimize and found several smaller and larger ones that i optimized. It should now be much better!
The next thing i worked on is the fuel consumption. I thought there might be minor errors, but turns out there is that a huge error can happen, when running the simulation very fast. Its due to there are 2 simulations now, one the astronomic one and the simulation task one. For now, the task simulation run first and the astro one follow up. But e.g. the tasksim runs +2h and the thrusters were on full thrust, the fuel is empty than. Than the astro sim runs and turns off the thruster after 1h, so the fuel would not be used, but the tasksim already removed it and maybe already separated the stage. After thinking this through, it looks like i need a new architecture to manage these things, so i spend the afternoon to create a new approach for that.
Today i improved the UI in many places. I started to add tooltips for the Thrusters, so you can see more details there.

As you see in the tooltip, the fuel consumption per day is not really useful, so i added an algorithm to find a better matching number in a generic way, so its now everywhere in the game using the new algorithm.
Than i worked on merging the NavPlanner and found out, that i didn't implement the Orbit Planner yet, so i added that firstly. There you can setup a target orbit on any planet it its taking care about transfers, orbit adjustments and circulating. For that i moved also the orbit setup to the Navigation planner, to prepare also for the next gameplay feature where the crew has to calculate that.
This morning I watched a video about Project Orion — the classic concept where nuclear bombs are used as a spacecraft propulsion system. But it also mentioned more advanced versions: instead of large fission bombs, they use small fusion pulses that are magnetically compressed and directed. These engines are relatively compact, around 4–5m in diameter, produce about 3MN of thrust, and with an Isp of around 10.000s, they are even more efficient than many ion thrusters — while still providing usable thrust.
After fixing the rest of my found issues i realised, that my servers harddrive is broken and it looks like the raid has to rebuild, so i spend the afternoon to fix that. Tomorrow i will do some last UI Improvements and testing,s so hopefully i can release the new version with the new supplyship logic soon.
Today just some polishing in several different places, starting from the ui preventing to round so keeping always one digit e.g. at the altitude, fixing some alignments of the supplyship, so they are set to ground always the same way, fixing some autopilot specialcases and so on.
I tested the docking process and fixed some bugs. After the docking was complete i figured out, that after those local changes i did some weeks ago the thrusters are now automaticaly getting part of the main ship, so they can be used for steering the main ship!
After i added the new Planet Renderer to the Earth and checked the groundstation, the vessels were moving alot over it. It was not visible with the earth far away (due to the low poly sphere). I analysed a bit and it turns out the error each frage come from the unity method to save the rotation. Its saved in floats, what is usualy fine, but for space dimensions with thousands of km, there is a too big error. After i created my own quaterinon with double precicion its now changed to <1mm accuracy. So the error in the KeplerOrbit calculations seems also be fixed now!
Than i added an algorithm to automaticaly adjust the size of the plane to the visible area. That was the last puzzle part to make it work. There were still some unity specific rendering issues i had to solve in the morning, but now it realy looks nice and i can continue with the regular gameplay.
Than i analysed more bugs i found. Thrusting straight up from a planet caused a bounce back when turn the engines off in the mid of the flight. The reason were numeric instabilities in these extreme special cases when we fall back directly to the planets center. I added another calculation method for these cases so it should be stable now.
The end of the day i spend improving the floating origin algorithm, to also do that with the new Planet Plane, due to i run into the float issues of unity with it. It took a very long time and i end up using another approach, not using the real astronomics for the Plane, but using the local transform, so it should fit always.
Today i finished the migration and worked the whole day on an algorithm to have a smooth surface. The idea is to have one plane mesh with many vertecies that dynamicly adapts to the planet. So as closer you get, as smaller it will be and as higher will be the vertice resolution. Its always 50x50 verticies big, compared to the planet with a fix resolution of 5000 triangles. Those triangles are fine in orbit, but when you are landed, they are like 50km² big. The other one can scale down as much as needed. The Texture will stay the same for now so it will be improve so much, but the landed vessel will realy touch the ground.

At the end of the day i was able to finish also the UV mapping. It was a lot of work to get that done, but now it looks pretty stable.
In the morning i found some reproducable situations where the ship did really strange things, so i started hardening the decimal algorithms in the mornings, to prevent crashes in that situations.
Than i worked on the migration, what was pretty hard this time, due to there were huge changes in so many core things, like the shipsections, complete new supplyships and the new mass calculations.
It was still wobbling a lot at the takeoff. Turns out the reason was the rotate of unity. They use float for the rotation, so the errors are very high, when trying to rotate a vector with the length of the earth, causing errors in around 1m range. The solution was pretty simple, we just reduce that vector to 1, rotate than and multiply it with the original length. With that fix its now very smooth.
The next thing to finalize that was the rotation updates in the surface mode.
After checking some problems with the landed vessels i came to the conclusion that i have to refactor how i deal with landed vessels. Currently they didnt have an orbit component. That results that the autopilots will not work when landed, what looked very annoying. Also to support further atmospheres i will now keep surfaceTransform AND KeplerOrbit at the same time. That meant i had to refacor the IsLanded check everywhere in the game.
It took the whole day to get a prototype working, its not that easy as it sounds... I refactored the calculations to have it more structured and now it decides what mode its using, depending on the altitude. There is also a new SurfaceVelocity data, so the keplerorbit is not used anymore in surface mode (just for autopilot and the ui). The main reason are the big numerical errors appearing at these orbits. Its still far away from finished, but the ship now fly up when accelerating and it detects the landing perfect.
Today i finalized the Buy Sell Buttons and used it everywhere where credits are added or removed. I also created a small script finding a nice way to show the automatic buy sell actions. It searches for e.g. the storage ui element or the vessel icon. If nothing was found it shows up at the credits panel of the ship.
The rest of the day i polished the mass update and did some small ui fixes, getting closer to finalizing the iteration.
In the evening i added a maximum linear acceleration setting. This also causes the takeoff to not work anymore, so i had to improve the takeoff profile. Turned out, it get too long straight up, causing a too early apoapsis, so i have to get to the 7.9km/s in less than 2min. I changed it, so the gravity turn is earlier. Than it had more time to increase the AP, but it was still not enough. I also added a logic to deal with the situation after the AP. It than turns again to work against the gravity, to keep the height.
I worked more on the stages. It was still annoying, but after increasing the thrust and fuel another time, it looks good now. the first stage ends with .8km/s deltaV in orbit, so enough to navigate a bit in low orbit. The regular stage keeps 3km/s, enough for bigger burns and inclination changes. The Large stage with 2 additional thrusters keeps 4.3km/s, enough e.g. for example to the moon. In total (including the supplyship) they have 10km/s 12km/s and 14km/s deltaV. To orbit they said it takes around 10km/s, what perfectly fit to my one, due to i have no atmosphere yet.
The second topic for today was the pricing. I wanted a more clear usage of credits to make it easer to see where you spend your credits on. So the first thing was to add a price component instead of having different setups for different parts of the game. They will add together instead of having a single price.
To make it simple and easy to understand, i created a generic Buy/Sell Button, with some basic features. E.g. it checks if its buyable, setup the colors of the Credit icons and added also a generic Tooltip, that shows how the price is calculated.

I also added an animation showing that credits were spend on something. I did this now for the buy sell button and will add this in other places in the game.

In the evening i converted the crew capsule buy buttons, so they are now also for buy/sell containers and the complete crew capsule in place. That needed some more features in the buy button like custom problems like "Not enough Space" and also needed to add the resource with units and detecting if its a sell of buy button.

Yesterday and today i worked on the serialization. Before i had some optimizers when loading the supplyship. it loads the prefab and merged it. The main reason were the visual effects and audios. Unity uses an internal special think to bake game object components into the entities. But its not possible to add that at runtime. I tried it again to workaround that and came to a custom companion system, more or less having similar features than the original one. For now it will just take place for loading games. I started to do it with the visualEffects and it seems working smoothless so far.
Today i worked more on the Stages. Its seems to become a bigger thing than expected. The deltaV seemed completely wrong, so i checked a bit and it seems the deltaV is more for the Vacuum. For Takeoff, there is another kind of deltaV relevant. This surface attribute respects also the gravity of the planet to start from.
I also improved the calculation of the delta V and make it also calculatable for the prefabs. I started to show the different presets and tried to figure out how to show it in a more understandable way. Here a quick preview whats the current state.

I also worked on the performance, that was very poor, showing the supplyship popup at liftoff.
In the morning i changed the logic of the stages. Instead of having a increasing stage index, i changed to "activate in ... stages" logic. So a next stage will reduce that value of all entities inside. This makes it easier to precalculate things.
After some days break, i fixed some issues with the inertia tensor. It used the old tensor with the new supplyship after the main stage was separated, causing a huge energy increase for a way smaller tensor. This caused a extreme high angular velocity, so the ship spinned with 3 rotations per second.
It now also shows a popup, when you try to takeof a vessel without the needed thrusters. This enforce that you have to choose a main stage.

To make it more clear i added a DeltaV Calculation including a popup, showing more details to that stage. That also makes it easier to balance and debug them.

After fixing some smaller mass issues again, i added the logic for the vessel separators. In the first step i just removed the other parts, to make it easy. It also reuses the enable logic from the staging, so it was easy addable. I added the main Stage and played a bit around, to find a good setup. I end up in a setup, that is just enough to bring the vessel with the autopilot to orbit.
The new rocket is massive, so it has several thrusters and so on. Its very much, so i had to come up with a better ui for that. I created separate stage groups showing the things that are separated from at the ship in the different stages, to group it better.

To make that complete thing usable, i had to add some kind of ui to buy/sell it.
It took a longer time to fix the mass, turns out i also used a strange spacing in the localForce, the basic of the astronomic system. It has to be refactored a lot to make it work nicer. It took the complete day to make these things work again, but in the end it works. Now it respects the local positioning even on the supply ship.
I continued with the plan from yesterday and added the Thruster control to the staging mechanism. To make this viewable,i added them to the selection panel. I also implemented the automatic staging when all available fueltanks of one stage are empty.
While trying to add the center of mass mover to the supplyship i realised some problems with it. i used the difference to the optimal value for the big ship. Thats a huge problem, due to the supplyship needs a different calculation. Also when the supplyship is docked, it gets confused about the different mass position calculations. So i had to rethink the concept of that and do a big refactoring to make it work again. The new system now only uses local positions of the mass, so it doesn't matter where its added.
In the morning, i started creating the boosters for the supplyship.

I played a bit around and it looks like these boosters are not enough to get to the orbit So i needed to add also a main stage for it. After playing a bit around with some sizes and realistic calculations, i want to add a main stage, that is around double the height of the supplyship. Next to them i add a scaled verison of the small boosters. The big engine can do around 5-6km/s deltav. With the boosters a 2-3km/s it will have enough to go in the orbit. The shuttle itself will have a around 4km/s, what is enough to go to the moon.
This is quite complex and needs an rocket stage system, so i thought a bit how to implement that... I thought about several different architectures, due to i just have a simple limited usecase. Turns out, i estimated the complexity similar doing a hacky solution that just works for the supplyship, or the better more realistic implementation. So i will now go with a staging approach like in real space programs. I make sure, the components can be disabled, like the thrusters already supports that. I also added that to the fueltanks and also make them being used equal when burning. Than a separate staging logic, that will cause a disable at start and enable automaticaly when the stage is reached. The stages will change automatically when no more fuel is available. I keep all of this very simple, but extendable, so maybe i will add more customizable things later for you. After that i plan to do a sepator logic (what i anyway need for the boosters). Step 1 will be very simple to just delete the components, later maybe separate and let it fall back to earth. In the end i want to create some preconfigurations, to give you some choises of different setup, depending on the delta v needs.

Today i created the Fuel Tank in the ship. Its like the Cargo and Crew Capsule a separate part of the Supplyship. Maybe i add the possibility later to extend it, but for now, its fine. The Thrusters got now part of the simulation and act as real users of the fuel, like everywhere else in the game. If the fuel is empty, the main thruster will stop. For now, the small RCS are not using other fuel, to keep it simple and steerable till its stable.

On earth the Fuel is autobought, like the other resources of the crew vessel. These fuel and the o2/ch4 boxes are independent for now, but you can also unload it at the ship if you want. Need to figure out whats the best there. But buying cost the resources! To make this clear, i think i have to add kind of a "Bill" for the credits. More an advanced History, so you can see the expenses and income too.

The a bit more problematic thing is that the thruster of the supplyship is way too powerful. Its 15x stronger than one of the engines at the station, but using the same amount of fuel (to make it easier to start/land). To fix that, i want to add kind of boosters, that are added at the side of the ship (like in the real world).
In the evening, i worked on some visuals. The supplyship got an openable docking port on the top. It was a bit tricky to make that work, due to i didn't use my tools for a long time now, but in the end after solving some bugs, it worked. It's at the moment just visual and on dock its overwritten by the dockingport scripts, but that i will do tomorrow.

I checked the reports and fixed several things to make the game more stable. I also added a quick fix for vessels, that got out of controll and were on the way to the sun. I still have no idea how this happens...
In the morning i finished the cargo capsule of the supplyship. I also did a patch release for it and tested it a bit. Its now the default branch in the playtest on steam. At the Demo you can access it by changing to "latest" in the beta section.
The next bigger thing is using rocket fuel. I started researching how much fuel engines needed. Turns out my original values were very bad and i had to multiply it by sever thousands... Than i also adjusted the storage there, so it can take fuel for a 10min burning phase. For now its not very nice, due to persons need to fill it up by hand, so they will be completely busy filling them. But i anyway planned to reusing my pump model, that can than pump interior items from storages, so you can fully automise that part soon. The good part is, that i was too high for the created thermal energy, my guess was 50kw, but its just around 5kw. Most of the heat leaves the engine. For the electrical energy: the pumps need around 20-50kW, what is much higher than i thought. There are other options, using a separate burning chamber to run the pumps. With that option it will be just 1-5kW, so i will keep at my original 3kW.
The downside of so high usage was, that too many o2 boxes were needed to store that. I rechecked the box sizes (i setup many years ago). Turns out there are also passive cryo bottles. I will use them, to reduce the amount and ignore the usual 1% loss per day. So the storage amount of these boxes increased a lot. E.g. you can store now 700kg O2 in one box and 250kg CH4, but only 50kg H2...
Next big thing today was to make the vessels as a first class simulation entity. This means, it now fully supports resource events for its containers and the tasks can be created without being docked. The tasks will be disabled with the "not docked to ship" reason. This also fixes the issue, with preconfigured tasks in all kinds of situations.
Today i started finishing the supplyship container interactions by adding the PiMenu for creating connections to other items. This is now bond directly to the cargo entity, so you have now a setup for each supplyship instead of the docking port, what should make it much easier for many usecases.

I also added I18n Names for preconfigured things like the planets or the ground station, so they can be translated now. Dealing with loading and a proper undock is now also done.
In the evening i designed a complete new kind of storage for the CargoCapsule. It should be a mixture between the general storage and the other items, it should not be filled automatically with random stuff, but should be changable by the player. It ends with the same interface than the regular storage. I just do something else at the reserved marker, but its not visible for you.

The last days i didn't work so much, but i was able to finish the new docking process, with the separate Container usages. It looks easy, but was a bit effort to reuse the existing mechanisms. Its also prepared already for the missions, where you need to be able to setup more specific filling tasks. With that its now also possible to bring resources back to earth, to maybe harvest He3 from the moon to sell on earth, or grabbed enemy satelites to sell back on earth to the groundstation.

I also worked on the Storage Item Element, to be also able to setup when not docked. The max is now also more gray and smaller to make a nicer look. Also its possible to setup showing the delta e.g. for the crew capsule, to prevent having another ui element in it. Its now also showing the Users in the crewCapsule, so its better do understand

The last days i didn't had much time, so i was just able to do the crew capsule. Each crew capsule now has its own ui element in the selection panel. The persons are assigned directly to the capsule and they use the O2, Nutriton and water of it, when the vessel is traveling. They also create CO2 and Brownwater on the way.

After that i decided to do the update of my server. It got a brand new 2TB SSD, with that i hope the disk space problems i got every few months are gone, and it's prepared for many players sending a lot of feedback. It took a longer time, due to it was the main drive i replaced, so the complete windows with docker and the raid setup had to be copied well.
After a very long 10h tryout session it seems now everything updated and running and working again. I hate this administration things ^^
Today i started with the more advanced gameplay. The crew capsule now has Resource Containers that can be setup to auto buy/sell the resources for it. There is also an option to automatically create the auto-tasks when docked on the ship, so they can be also filled or emptied when the ship is docked.

I wrote down some concepts what i want implement for the supplyships. It should also work similar for the missions later, so it had to be a more generic concept.
The new UI contains another Tab to maintain and enhance the supply ships. You have to buy now a separate Crew capsule there to recrute more crew. Its also possible to add multiple ones, so compared to the old version, you can now bring 12 passengers at once to the ship. The next step is to equip these capsules with food, water and oxygen, so they are reusable for the mission shuttle.

There will be also a repair, fuel tank and booster section where i want to work on tomorrow.
I started to fix some lighting issues with the engine. The outside part was not marked as space, so it was enlightened with the room lights. I also fixed some shadowing issues in the navigation camera where shadows were disappearing when zoomed out. Than i worked on the lighting of the connection areas. Till now, they all got a room lighting, so it looked very strange when the ship was in the shadow part of earth... The door was a bit more complicated, i had to split the mesh into 2 parts so just the outside mesh is affected.

In the morning i checked again the old reports, and updated the supply tutorial. Than another quick release till i continue with other things. I did alot of small things like aligning the ui buttons shwoing the real target for landings, fixed warnings for the orbit maps and much more, to prepare for the next bigger tasks.
The rest of the day i spend more updating some smaller things, to start with the newer features with a more polished ui.
Today i started adding some runtime debugging to the vessels, so its recording it easier to see problems. I also added an autopilot direction hint to the ui, to see what the autopilot is doing.
Bild
Than i worked on an annoying bug where the ship was not able to break to the correct angle, so it was spinning back and forth on the docking. Also a lot of other smaller issues have been solved. Not so much time on the weekend, but next week there will be more time.
Also a lot of debugging code has been added to have a better chance to find bugs in later reports.

Than i worked on an annoying bug where the ship was not able to break to the correct angle, so it was spinning back and forth on the docking. Also a lot of other smaller issues have been solved. Not so much time on the weekend, but next week there will be more time.
Also a lot of debugging code has been added to have a better chance to find bugs in later reports.

Today i worked on the migration, using old savegames from the users to check that they still work. I hope i catched all cases for that. It took a bit time, but it seems working so far for the supply ships. The other ships for moon missions i will do in another iteration later. First this part has to get stable, so i decided to do a preview release after some testing!
After trying it out, it was still not perfect, but after fixing one major bug with calculating landing orbits and i will go with it now. I firstly release it on the latest branch and do more updates now, so the stable branch is not touched yet.
After playtesting it a bit, i found still a lot of things to polish and fix, i guess it still needs one week or so to fix the major things and get realy stable. The performance looks fine at the compiled version, but in the editor its soo slow.
Than i planned the next iteration, its around 55 items on my list i want to finish related to the new navigation system. I proritised them and started already with the first ones.
In the morning i aligned the vessel UI elements to have a nicer common data viewing and also added some pimenus, to let the ships dock and undock very easy.

Than i worked more on the takeoff again, to fix more special cases. It really gets stable now, its less and less problems but i keep improving the autopilotes more and more and fixing issues there. I think its one of the last things to do now till i can finaly release the next version to the first ones of you! I'm not sure if i should already do some tutorials yet, due to it will still change over the next iteration when the crew will get more involved.
Today i worked more on the takeof autopilote, to get it more stable. The first thing was to create an algorithm to create a acceleration vector, that not increases the apoapsis when we are takeoff. On some constelations that was the biggest issue and we end up in an orbit that was very high.
Than i worked on the planner pilot, to wait for a good time to enable the takeoff pilot. With both of these things the first launch and docking took less than 2h to the ship! It not even needed some maneuvers, after the takeoff it was directly 400km next to the station and could start the regular approach.
While testing i found some strange specialcases, like the first landing calculation needed one turn around the planet. Than the new position of the target at that time is being calculated to calculate the final target position. But the second one dosn't need the orbital change, so it could land instant, but than the target is at the wrong position again...
Than i also improved the landing slightly. Its now just breaking till we crash next to the station instead of landing somewhere else. Due to the automatic moving towards the satation, and no crash/landing differenciate, this will work for the first iteration, more comming next.
To make the states easier to see, i also added the current positions to the icons.
![]()
I added a more dynamic sidemenu, so its better fitting to the needs of the view. In the navigation tab, there is now also the myShip visible. After that Supplyship UI looks now nicer, i worked on the mass. Till now it was a only handled for the main ship, now its supporting other vessels too. Than i changed the money usage of the supply popup, so its decrement directly when transfering things to the supplyship, before it was done at the launch button. The next thing was to move the ship towards the station. For now, this is a temporary system, that directly moves the vessel, so it doesn't matter so much where its landing, to prevent broken games due to wrongly landed vessels, till everything is stable. I also increased the thrusters of it, so it can start when its pretty full loaded.
I started to create new UI Selection panels for planets and Vessels. For that i also created 2 new icons for navigation planning and ship selection. You may notice the 2 empty boxes at the side, these are for the interior items i will add later, so your crew will do the piloting and navigation planning.

There is now an easy setup for the supplyships when having them selected. Its showing now the Close To Items like the ground station, where you can buy things.

After a lot of polishing there i thought about the next steps to finaly get this iteration finished. I want to finalize the supplyship and the new resource buying and transfering first. Than the landing procedure looks not accurate enough. To fix this easy, i will make an automatic moving to the landed vessel on earth. I also have to deal with the new mass, so there will be no mass limit anymore, but instead showing a warning, that takeoff will be hard with the weight. In the end i have to polish the navigation system again to make it more robust.
Here a current preview of the new way how to interact with the supplyship. Still some convenient features i planned, but roughly thats the idea
Today i worked more on the Ground station and selection mechanics and fixed some more issues with the autopilotes. I designed the ui for the new Vessels, planets and Bases that i plan to do tomorrow, so you can get more control and it should be easier to understand the mechanics.

I also found a visual problem at the landing, due to earth is already 6000km in radius, the logarithm scale already took place there and the startup looked very slow. I fixed that now by respecting the distance to the surface, so its not that big problem anymore. The real solution that had to be done would be creating a dynamic mesh, that is updated and layed over the planet on landing, to improve the textures, or do a google maps kind approach. But that would cost too much time for a feature, that is currently not planned to use often.
In the morning i finished the docking progress, so the supply ship is now attached to the main ship and the resources are accessable.

The next thing was to remove the outdated supplyship ui, so i added the status to the autopilotes and assigned targets. Also for the DockingPort.

Than i also implemented the undocking function today and it looks pretty nice for now. Still a lot of work to do, but i think its going in the right direction! There is a new Autopilot, that pushes the vessel away from the docking port to a safe distance. It might be also used later for example to abort docking maneuvers from the maneuver planner.
In the morning i worked again on the bugs in the maneuver from yesterday, there were so much trouble with relative body changes, but i think i got it in control now. I also tested and polished a bit more the landing, dealing with some special cases.

After everything looked smooth again, i started to think about the final docking procedure and more gameplay related stuff. First i wanted to make the ships selectable, so i worked on the contextmenu showing now up on right mouse. It was a bit tricky, due to the right mouse is alrady used for rotating and it looked not working from time to time, but i found a nice way not using the unity methods for that and implementing it by myself.
Than i tought a bit how to implement the new SupplyShips. I migrated the old fixed ones, that have a separate autonomus Entity. The idea is to just setup the autopilotes. So the next step is the docking itself, so i will craete 2 systems, that check if 2 dockingports are close to each other. If yes, i will move the ship as a child of the dockingPort. On undock i do the opposite. That has many advantages and i hope there will be not much troubles with it!
I was able to prepare a lot for tomorrow. The Systems that calculating the close vessels for the docking check and later collision detection and the one that calculate if two dockingports are hit are done so far. Tomorrow i plan to do the real docking, to be able to transfer goods.

Yesterday i added Maneuver names to give you a hint what is being done by the planning system. I changed the UI for the Planned Orbit again adding these things and make it look not so overloaded.

Than i wanted to land on the moon, but there was no marker added, so i changed the landing logic to surface coordinates and show that in the ui too.

I found also some strange maneuver burns, caused by some other bugs with maneuvers and MidFlightCorrections between 2 bodies and also the engines were not turned off in some situations of the maneuver autopilot, causing wrong burns and wrong orbits.
In the morning i did the last things for the maneuver executions on high speed, and also show the slowed down astrotime in the ui if needed. Than i started with the Landing on a planet. I implemented the calculations to get to a good orbit with the right inclination to get above the target and played a bit with the breaking. But it seems even a rocket with 13m/s² acceleration is not able to land on earth without atmosphere. So the next topic has to be atmosphere... From the first thoughts its not that complicated, its like a thruster, that adds a force to the retrograde direction, depending on the current speed and height over the planet. Lets see how complicated it gets. But for now i finished the landing even if i touch the ground with 2km/s... Maybe i reduce the weight on landing, or increase the thruster of it for now.

Today i worked more on the precicion of the docking algorithm. I found a nice way to do the calculation logic much simpler and alighed the approach and docking to the new way.
I improved the approach autopilot on high speed timewarps and also polished several things, adding timewarp buttons, adding camera reset functions and so on, to have a good base for the next updates.
In the morning i improved the estimations for the AstronomicSystem autopilots, to make it more stable on high speeds. I also added another debug mode, that just uses this estimations, to make sure its working well.
Some days ago i created the algorithms for Mid Flight Correction burns, but till now there was no easy way to see if they are necessary. So i added a position offset to the ui and also prevent the autopilot to do it if the offset is too big.

Than i started with the Navigation Planner. So in total there will be 3 new consoles added. One pilot console that will do the current autopilot things like executing maneuvers, docking or approach. The second level is than the new Navigation Planner, he gets a target like docking on the ship and its planning the maneuver nodes and enables the pilot targets. E.g. its planning the transfer orbit to the moon and enable the landing. Its also responsible to do the MidFlightCorrections if needed. The level above that will be the mission console for e.g. the moon missions. This one setup the navigation planner, like fly to moon, gather resources and dock back on the ship. Maybe the last one will be automatically like now without a console, not sure yet.
The first thing i did was adding the basics for that feature, than adding some UI to set them up and getting a bit feedback from the new system.

There is also a new Navigation Planner Panel to set this up.

The Navigation planner is now working so far, but still need some polishing. In the video i give all controll to the navigator just showing what the element is doing. Still some warnings, specialcases and timewarp issues need to be fixed, but all in all, i think it's getting very nice!
I continued with with the surface Transform and make a simple landing and takeoff logic. Its converting now the orbit to the surface transform and it looks pretty precice so far. Don't mind the thing, that its not exactly on the surface, due to the planet is still a big sphere of thousands of km, so the surface is not smooth. To prevent escalating and doing a google maps like approach for the planets, i think i go with keeping it or hide it from the players.
Than i checked some bugs i found and do more polishing, like aligning the camera mouse buttons to all views, so middle mouse now always moves the camera, and right button rotates it. Also other things like a better target lock from the algorithm from yesterday, to be able to focus easy to e.g. the moon was included there.
In the evening i fixed some bugs appeared in the approach autopilot, due to the feature of child targets, e.g. a docking port. I also figured out, that the hofmann transfer really need accurate starting orbits, or it result in a far away orbit.. So i have to respect that in case of a docking.
I continued working on the new StarMap with the rendered planets. It took a bit time to refactor the specific 2d mapping to a real 3d rendering, but in the end it looks working fine so far. Now you can see the real planet rotations also in the starMap, including sun lighting. Its a partial step towards the complete 3d rendering also of the paths, but thats another step for another day somewhen in the future.

It took me the rest of the day, to polish the new Starmap, removing laggings and fixing strange bugs. In the end its also possible to move the camera around, like it is a complete 3d rendering, but the orbits and icons are still on the 2d canvas, so there is no depth hiding yet.

In the end i added also another feature for the starmap to easy follow objects. All objects moving fast in the game, so e.g. earth is moving very fast around the sun, and the sun very fast around the center of the milkiway. so also your ship is moving extremely fast with the sun. To have a usable camera, it has to move with another object. Before, that was always the ship itself, causing the problem, when you zoom close to another object of interest, the camera was moved away from it, due to your ship is moving maybe around earth. To fix that i have now a dynamic locking mechanism depending on the current visible elements. For the start i just use the ships orbit parent if the ship is out of the screen. This already fixes most of my current issues.
As a next step i wanted to add a Navigation Planner, so the target is to define a target like dock on the ship, and the planner should do the needed steps. To make this reliable, i worked today on mid flight corrections. If a burn was not perfect, it might happen, that even when the deltaV is done perfectly, there the orbit not perfectly hitting the target. To fix that, mid flight corrections are used. Calculate them seemed pretty difficult, whatever i tried it wasn't working... In the end i got a working solution, that gets me much closer to the target. Maybe i can do that several times or i can try to work on the algorithm again. For the interested ones, its the Lambert's Problem where you have 2 points and a target time and it calculates you the required starting velocity, respecting one body gravity influence.

In the morning i started fixing some bugs i found, placing thruster items had the wrong rotation on on the gimbal changable part, smaller tooltip issues due to my latest support of rounded corners and those small things.
Today i didn't had much time, so in the evening i checked an error with the engines on low energy. The reason was, that i used a relative throttle, so the throttle relative to the current maximum of the engine. So if there is not enough energy, and the engine is cut down to 50% max, the throttle 50% will cause a final 25% from maximum speed. But that is not very nice working with the energy cut, so when the energy tries to push the energy consumption now down to 25%, the final throttle will calculate from 25% and 50%, so 12% and there is energy left that is unused. The balancers are build to use the maximum possible thrust and setup the trottle to that value. So the result: I had to find a solution to have both requirements together.
I got a lot of problems with the savegame logic, and decided to also completely change the approach to use the LinkedEntityGroup of Unity. It got fast outdated and inconsistent, causing realy strange errors. So for now on, i just go with child/parent relations. It was useful to already refactor most of the code in the past, to not use the linked feature, but it still took a while to fix all of them.
Than i found a few issues with my own entity inspector due to the last unity updates i had to fix to work better.
After all of that i was able to finish the Docking Procedure, aligning the docking port with the targets docking port and get a perfect aligned docking autopilot!

In the end i also polished the calculations and ui for it, so the distance calculations now also uses the selected parts.
I thought again about the autopilot ui and decided to change it back to the original navbar and redesign the autopilot to an pilot area. The autopilot off is now named as "Assistent", so the pilot will steer towards the prograde and so on. This should make it easier understandable. The Target buttons are anyways not accessable while an autopilot is active, so these will be hidden and replaced by the status of the pilot.

After that i readded the target panel, to have a good place to setup the target docking port. It took a bit to make also childs possible to be selected as a target, but it looks working fine so far.

I also polish and posted the news from yesterday on steam to prepare for the steam event i join tomorrow!
https://store.steampowered.com/news/app/1638030/view/528726842982533006
The end of the day i worked on selecting the own ships dockingport for the final docking step, but it turns out it was a bit hard to do, due to my first design, the rooms were not attached to the ship entity. I finally started to refactor all the code, regarding to the rooms what took a longer time.
I found some cases, where the player has to do something with the autopilot, like the maximum time appears at the maneuver node, where the maneuver can't be executed anymore. I added a way the autopilot can report that to the player. I also added a state reporting, so you know what its doing.
This needed a bit more space than before, so i decided to move the stuff that is not realy related to the autopilot stuff to the nav ball. It looks a bit crowded, but i think its still acceptable.

Than i worked a bit on a news article i will publish tomorrow, due to i will be in an upcomming Event.
I stored the camera setup now in the entity, so when you switch from one ship to another, it will stay keep in that position. Also the other camera setups like overlays are stored there.
I also worked a lot on the maneuver executor, to get it more precice. Its very tricky to calculate good times to fire updates and keep the performance high. Than i also updated the Approach and docking pilots, to be more reliable on high speeds. Its a long hard testing process to find the problems, so it take a lot of time.
While doing that, i also updated the approach autopilot to turn on high speeds towards the target, so it can use the main engines for the big accelerations. After that it will turn with the main engines towards the ship, so it can break with them too.
I started with adding thrusters to the other controllable vessels, to make them able to steer.

Than i also added RCS Thrusters to the shuttle, to be able to steer nicely. I found, that the main engine is used a lot, even if its not the ideal thing to rotate, due to it creates a lot of forward thrust.

The RCS thrusters were not used properly, due to the main engine is able to provide a lot more torque even perfect aligned and just 10° gimbal possible. The algorithm just checked for the best torque to be applied, so i added an efficiency calculation to that balancing to make a better use of these thrusters.
I found a strange behavior in the compiled version, it seems the hash codes are calculated different in jobs and outside, leading to a detected change all the time when the ui fights with the astronomic system.
The next thing i was struggling with was an inaccurate maneuver autopilot. Due to it just checked for start and end time, it had some troubles. The new way is to accelerate directly to the wanted deltatime.
After that i worked more on the UI, adding a better docking icon and added the distance to the TargetWorldMarker.

It was also a problem, to start to a Rendezvous when being in a low orbit. To fix that, i added a check if we are very close. if so, we add a separate orbit change in between.

Than i had a very strange bug, that just happens on the compilied version. It lookes like unity rewrites my double3 values in the burst jobs... It looks like there are special cases where the burst don't initialize the values due to it thinks its not needed. But the value is passed to another function that uses it, so the result is, the forward 0 0 1 arrives at e.g. 0 1 1 and everything the thruster analytics for forward can't be found later on... To fix that, i had to refactor my own struct wrappers as readonly to fix that issue. It took a while to figure that out, due to i had to compile the code always and a debug logging caused an initialize of the data, so it works when i tried to fiture out where it happens...
In the morning i did a refactoring of the thruster logic, due to the several changes its now not not needed anymore and can be done a lot easier and more flexible. The main reason for it is the selection of the other ships, so they need thrusters too. It took a while to refactor the systems, so they don't need a fix ship anymore, but in the end it worked well.
The next thing was some performance optimizing. The algorithms needed to know the maximum acceleration. For this it used the Balance system to calculate what it would accelerate, when that would be the target. This was done a few times per physic iteration, so i cached it and only calculate it, when its outdated, so like a lot of fuel is burned, big masses were moved in the ship and so on. Now the performance looks much better, but still i have some inaccuracies on high speed.
Today i started with some UI Polishings like adding a tooltip to the closest Approach Marker.

Than i finalized the Approach Autopilot supporting a target on the other side of the ship. Its picking a temporary in between target 90° away from the real target, to make sure, we don't fly through the other ship.
After that was stable, i started with the Docking Autopilot. The basics were pretty simple to implement and i was able to close up to the target vessil, even the own dockingport was missing, it worked pretty well.

Than i had to align the rotation to the docking port of my ship, so it can dock now in any position, what will later be the shuttlebay or supply ship arm. It looks pertty nice an stable so far, even i dock now the huge ship on the small one instead of vise versa

I recorded a short sample of the fully docking. I think it can still need some work e.g. mid flight correction burns and another performance push in some cases, but in general it looks already working fine so far.
After that was done, i started to make the ships selectable. For that i added in the lower right corner of the navigation and orbit screen. The idea is that you can also steer your supplyships and shuttles to the ship. Thats what was the original intended docking procedure was build.

I realised, that the navigation prograde did not allow a big timewarp, due to each second, the thrusters had to correct the position. I added a precalculation of the direction and calculated the needed velocity to adapt to that. On a perfect orbit, there is close to no need to steer. Its now the state from before when i had the simpleorbit calculation^^
I worked also more on the automation, they now steer not always, to increase the passive flight, what is much more performant than correcting it always. I also added more deadzones where the thrusters are completely stopped and now on timewarp the maneuvers look very nice. Still i have to analyse the performance a bit, but some major calculation costs i have already an idea to cache them away.
The approach now targets a position away from the dock, so the next docking steps can be done.

I also added another Stablize Mode when a target is selected. It will use linear acceleration to balance the ship at the same distance than the target. It has still a few problems, due to small linear adjustments, it will not turn so good, but for now its good enough.

In the morning i searched a bug in the astronomic system, turn out due to some tollerances in a specific part of the orbit calculation, the update was slightly inaccurate. I just saw this now when i was close to the target rocket and the rocket jumped a few meters. It happens, when an acceleration is set, so the orbit has to be recalculated and there were some special situations, so most of the time it was actualy fine, but this big movement (when being close) causes a big change in the angle causing the vessil to steer a lot.
After that i profiled a bit and found a huge bottleneck when the maneuver autopilot is enabled. It calculed each physic update the next maneuver from scretch. That was "just" 3ms in non burst, but it was done hundrets of times.
After some bugfixes in the morning, i worked on the approach autopilot. It will neutralise the movement relative to the target and steer towards it till it reached a close distance, slowing down by the rough formular for now. Maybe i will add break calculations later. The autopilot to approach at the target was pretty easy to do, it just neutralize the drift and setup a speed relative to the distance. It stops at 100m distance.

The next step was the closeup. To do so, the ship has to be at the correct angle to the ship, what is a bit tricky. I tested a bit around and found that my Navigation System is still to much chaos in responsibilities and a mix of acceleration, torque and velocities. I throught a bit about another architecture with clear responsibilities and refactored the complete navigation system.
In the evening i refactored the rest of the navigation system and started with a second version of the approach autopilot, this time with the new api. Still some fixes needed to get it stable, but good progress is visible.
The ship was still struggeling with the balancing, and after some debugging it turns out, i forgot to turn off the balancer when the target was reached.. Now its working again. Than i did the last improvements of the fine tuning, by doing it multiple times till we reached a good level, so now the linear acceleration works perfect for that ship!

I also improved the prediction of the Astronomic System, so its more stable to fly on high speeds, but still not perfect. Than i wanted to retest the maneuvers and sure, it was broken again and i fixed it, all in all good progress so far. I have now more control over the balancer.
I still fighted against the balance system, after a whole day i finished it so far. Main problems were the hot reload killing some of the data, so the arrows did a complete broken thing... But i found also several other small issues and fixed them. There is now an alignment of the thrusters to the desired linear acceleration, so they first turn into the up direction. For testing they can gimbal close to 90° so they are all able to steer upwards till i have other thrusters. Than i added another angular acceleration neutralizer, using gimbals to steer to neutral to prevent unwanted rotations. I still have more things to do, but at another time, first i want to work on other things after two days of debugging on them.
I also realised, that the effects were local, what was a bit strange when the big engines changed their gimbal very fast, so it looked completely wrong. Here a nice sample picture with increasing the z rolling

Today i refactored the drift data and than i found a strange behavior in the gimbal balance calculation. It was a big try and error session over the complete day, i end up in having it similar as before but with a way easier code with less special cases. The old implementation was with linera equation solving, ending up in a lot of special cases when the thruster is perfectly aligned or can't change an thrust to a direction. My lesson learned will be, that i should have tried an numeric approach, so a try and error solution. This one works now very nice and is way easier to handle. Due to the late day, i will continue with some more details tomorrow. For example setting different metrics for a good target. My current ones are good for neutralise torque and another one for steering to a direction. I need another one for linear thrust, so to point to a given linear direction. I also found some bugs in the followup thrust calculations for some special cases i will also check tomorrow.
Today i finaly started with Docking Mode, so the NavBall and Navigation System can now be switched to the target.

Than i tried to dock by myself, but it was very hard, due to the thrusters were not perfectly setup, so i debugged a lot to find the reason. I got it at the gimble setup, that didn't work perfect enough, so i improved that, till it got a perfect setup to prevent unwanted rotating. As a test, i make the engines rotateable by 90°, what i plan to add kind of RTS thrusters that can do that angle later on.

After that i was able to fly very close to be able to see the target the first time!!!

In the end of the day i found a nice way to know where to linear translate to to hit the target. It calculates the local speed in the drift in all directions, so you can exactly steer to zero to these values with the translate keys (arrow keys and page up/down). This allows nice nulling without any need to turn the ship.

I also allowed rotating with enabled stablilizer, that will set a target angular velocity of a given value. So with that on, the ship will steer similar as in the e.g. "prograde" Target.
In the morning i started working on a better overlay for the CenterOfThrust. Its now showing all movement directions now in the 3d world with an arrow pointing to show what center of thrust it is. At kerbal we just have a single one for the main one. To indicate the distance to the center of mass, the length of the arrow is how long it should be to hit the center of mass, so if the end of the line hits the center of mass, its perfectly aligned. There is also the tooltip from the thrusters analytics to open up on hovering.

Than i also colorised them and make them nicer, so putting the arrow on the other side. Also the Thrusters got now a 3D rendering when fired.

To visualise them nice, i added a over to the center of thrust icons on the screen and the labels at the side. I hope this makes it easy to see the problems.

I also added the thruster details, so you can see what engine effects what direction and also how much the engine will burn and the gimble setup. Maybe this gives also some hints how to build the ship.

I worked the whole day on the thrusters, a lot of refactorings have been done to get a nice view. Its working in paralell to calculate each possible target direction and calculates how stable the ship can steer of move to the different directions. Its showing the maximum Acceleration and shows if there are side effects. This picture is from the starting ship, it can accelerate very good forward, with close to no side effects. It can also steer a bit to x and y directions, but its not that good, due to each change in x will cause adding a lot of y and z rotation too (lower 2 lines).

It also has a popup to show more details. I plan to improve that tomorrow more to show also the engines that are used and changing the overlay to the current selection. Maybe i also allow a selection to keep the overlay on.
I worked more on the Navball. I wanted to show the Z Key shortcut to the ui and found, that i have no chanche to detect the keyboard layout propery... It looks like the only propper way in unity is to wait till the player press y or z the first time. Than i can compare the keycode with the input string and can detect what is realy pressed... Unity uses physical keyboard bindings, so Z will aloways be next to X, but i can't show it right to the user. I store that now also to the settings when changed, so it should not be a problem anymore.
Than i thought how to show the acceleration and speed values better. With small adjustments it always looked like the ship is turning a lot. I added a color gradient, depending on the improtanty, so its not longer so crowded of numbers.

I finalised the new Navball including new steering features like smoothing, throttling to a direction and so on.

Another needed thing for docking is to accelerate to all directions, so i improved the Navigation System to also be able to thrust to a specific direction. There is now also a toggle button to rotate with the spinning ship or not, to support propper docking.
After playing a bit with a small increased startship i found very starnge behaviors of the navigation system, maybe due to not enough good aligned engines. It's close to impossible yet to see that problems, so i thought a bit what is needed to analyse and found one way. The idea is to show in what directions the ship can steer stable, so without steering or translating to other directions.

I started with some UI Polishings and moved some Transfer and other things to the context menus of the planets, to make it easier to find and to have space for a replacement of the Create Maneuver Place later on.

I finalized the new ContextMenus for the Targets and added I18n to it.

I also found some strange behaviors, that i had to fix in that part. The Over Events appearing in the rectangle, not supporting the border radius. As a result the orbit was not clickable anymore, due to the cursor was detected over the planet, so i had to workaround that unity problem this morning too. Than i continued with the Target finding to add it to the Orientation panel, the Navigation Control (and system to steer to it automatically) and to the Third Person View.

Than i added a hint to the navigation Screen to show the direction towards the target, to faster detect it.

I improved the ui more and more and come closer to the docking procedure. After some research, i thought about how to do the ui for that, but it looks like it has completely different needs than the others, but i want to avoid having too many. My idea is to create now separate ones for NormalShip, CenterOfMass, Navigation, Docking, Orbits. Each of them specialized to the target.
In the evening i started to work on a new navBall, aliging all current data. Till now there were several panels with different data, now that i need to change the mode form orbit to target, its a good time to align these things to one navball. In the todo section the steering and thrust will be added tomorrow.

In the morning i worked more on the Return to Parent and created a job doing the iterations to find the best starting point. Before it took around 2s to calculate it for 30 start points, now it took 200ms for 100 start points without burst, so i will keep it like this for now, its getting a nice result as far as i can tell.
Than i started with the Rendezvous. Thats one of the major game concepts to plan the supplyships and mission shuttles orbits as well as the huge generation ships one. I saw, that its very close to the Transfer to moon calculation and the first try was already a success and i come close to the test vessil. Whats missing is the final steering towards the vessil and the final docking of course.

To make that easier, i will first implement a better target and current item choosing, so its possible to move the controlls and camera from one to the other. So the idea is that you will be able to select the vessels.

While testing the orbits, i figured out, that there is a situation, where the astronomic system had to jump over a longer time at the starting ship. due to the navigationsystem can't react the spinning speed was extreme high (accelerating for 2minutes at max in one direction is not good ) So i refactored the complete logic there to allow also left over deltatime.
In the end of the day i was doing some performance profiling and analysing to improve the performance and found some very easy wins
Today i finished the polishing of the transfer to moon. Now i'm on the tarnsfer to parent. It sounds easy, but it turns out its much more complicated than the transfer to the moon... To leave the orbit of the moon, you need to increase the orbit until you leave the SOI. So far so easy, but it fully depends on the starting time in what orbit to end up. there is everything form very close to earth to leaving to the sun, completely depending where you start the burn.

I did find a close approach for the return close to earth, but its not perfect and not very nice, so i adjusted the algorithm, to tryout several values to find a good starting time. I guess this kind of approach i can also reuse for different other szenarios in the future like finding the best deltaV with different parameters for moving to the moon or something. It worked so far, but it took ages to complete. For the simple 300 tryouts it took several seconds, due to the orbit calculations for each of them. All of them checking all planets and moons to check for SOI Entrance. I tried to boost that code, so its now possible to run that inside of a single job by storing the children of the entities only, due to these are anyway the only relevant checks. In the end of the day i could finish that huge refactoring to use now single jobs for the entities, what also makes it possible in the future, to update all vessils in paralell. Tomorrow i will continue with the maneuver planning system, so it can calculate these calculations in parallel bursted jobs too to get a big performance boost for that stuff.

I worked more on the moon transfer algorithm. There were some bugs with merging maneuver nodes. Its not that easy to merge them, due to after finishing a maneuver node, e.g. the new Prograde vector is diffrerent than before. I also refactored again the orbits, to fix some other issues when switching the maneuvers. Now it looks good so far with my test moon.

The real moon has some inclination, so its way harder to meet, first we have to align the inclination.

But its still too unaccurate and need improvements.

In the morning i worked on the inclination planning, it was a bit tricky due to i had a bug in calculating the expected orbit from maneuvers. Now its working, but still changing the orbit a lot, not sure why but on low inclination changes it works fine enough. I think its rare needed for my usecase, but its a base for the more advanced algorithms.
The next step was a transfer to the moon. First it looked fine, but turns out it was just a special case.

It was not that easy, also due to some bugs i need to debug while trying to work on it. But it works roughly to hit the moon, the rest should not be that complicated. Here a state in progress hitting the test moon (that is closer, so its easier to see problems)

In the morning i added Tooltips for the navigation and Shortcuts like Num-0 centers the camera, X and Z/Y will controll the Thrusters.
After the basics were done i found still problems for the starting ship, so for ships, that are not so good in rotating to a target, i have to analyse this another day. First i wanted to do the next stop, calculating orbits. To test this better i first added a auto-maneuverNode Execution feature.

While testing it, the orbit was a bit different than doing it wihtout a fast speed, so i analysed and found the reason in the linear acceleration, that didn't respect the acceleration good enough at high delta time. It took a bit time to find a stupid misstake, but now it goes in 1 frame far away.
Than i started with the Automatic Maneuver Planning, what will be done later by the crew. Today i focused on the easy things like changing the orbit to a specific height and also 2 step maneuvers, to setup the architecture around.

Today i worked the whole day on optimizations. The steering was fine on normal timespeeds, but on extreme high speeds it was broken, oversteering and even killing the complete orbit. I found several small issues where i added the acceleration twice and wrong in old code and also calculated the angular difference correct when accelerating or breaking. The final thing was to change the navigation target steering, so its now time based and try to steer always at max engines. The reason for that is the timewarp, i calculate now a good deltatime, related on the values, so it can now calculate when to start to break and skip all deltaTimes in the meantime and is still accurate.
In the end of the day it looks pretty nice, i just do one expected update and calculate the required ones in between and its working perfect so far as i tested today.
I tried to play around with the new Maneuver execution, but somehow it was bad changing the planned orbits. So i checked a bit how other systems implemented that part. I decided to reimplement that part a bit, so the planning will stay always fixed and the Next Maneuver calculates it from there on.

Today i worked on the execution of the maneuvers. The planned maneuvers use maneuver space to be consistent, but when accelerating the ship, it would change that resulting in wrong orbits. So instead of that, a currentManeuver had to be added where the planned orbit should be transfered to. While accelerating, the expected planned orbit had to be adjusted. All in all very complex stuff.
I created a new Panel for that new Maneuver, showing all relevant things you have to know. First some details about the plan, an idicator where the target vector is and how far you are away from the correct direction with that orientation circle. Right is the delta V bar, going down when you accelerate and below a timeline to hint to the optimal timing when to turn the thrusters on and off, to hit the planned orbit.

Today i polished and finalized the rest of the OrbitMap UI. Changing the spin and orbit to a new Acceleration view, showing the "current selection" what is for now only the ship itself. Also showing a Target area, what is now by default the planet itself, showing the moons and adding links to sun and so on. Also improved close to all texts there to have icons and better roundings, to make it easier to read. New Icons and much more, so i think its now pretty clean, feel free to give more suggestions.

Tomorrow i will start with maneuver executions, so i think to add some kind of "Next maneuver" Panel showing the target, duration till reach and how far the steering is away from the target. Showing also how long it will take to reach the target. With that i think i have to improve the maneuver Nodes too, due to they will disappear when outdated, so you can't accelerate to the target anymore, due to its not visible. Also showing somehow the expected change will be needed.
In the morning i worked more on the UI to get it nicer. First thing was the maneuver Node value box in the Orbit Segment details. It now has a nicer value view, grayed out if not used and supports dragdrop of the mouse.

The next thing to polish was the maneuver node. It was not realy usable and intuitive, so i added draggable icons to the orbit map to plan it very easy.

In the end of the day i polished it even more, so its now a bit bigger, has a delete button and works perfect even when moving it above other nodes. The selection and unselection looks also working fine to me now.

Today i worked on the overview camera and completely redid the scripts there. Its still fixed in the roll rotation, but you can change the yawn and pitch of it with holding the middle mouse button. Its also possible to zoom to fit to the needs of it. Due to the center of mass is now in 3d space, it might be needed to view that too. I have to add the optimum center of ship as a line now, what i plan to do somewhen else.

Than i worked on a small but nice visual for the engine. Due to they have now also gimbal, they has to rotate visual, to let the player see the effect.
Today i worked on the balance system and added the gimbal to it. Now its possible to steer with the starting ship pretty nice. Its also possible to add artificial gravity with just 9t of water and the mass balancer. The ui need still improvements, for now, if its enabled it scales to a big area to set it up easier, but i guess its anyway just used in the navigation system usualy.

I changed the Thruster UI by moving now all sections to the right of the screen. The reason is, that its still possible to select the single engines. Now the engine overwrite can be done at the interior item selection panel itself, also showing the individual orbit and touque changes of that single engine. Its not needed anymore to steer by yourself, so i could srink the thrusters in the navigation screen.

The main physics are done now, now the gameplay is starting, so first i turned the ship 90° and adjusted the intro to the new camera. Than i found, that the starting main engine is not enough to use it right for the ship. Its impossible to steer with it and due to not perfect aligned engines, it will create a big touque. As a result i have to implement a gimble system to the thrusters, so they can steer a bit by themself to balance it even with less engines. This has to be integrated in the balance system to steer well.
I added the spin stress today. Its calculated by using the distance to the spinning center (so the center of mass), the gravity angle to the floor and the spinning speed. Its very interesting to figure out why these values are like that, so e.g. the distance to the center of mass is relevant, due to korreolis forces and the gravity difference from feets to head, due to the head is closer to the center so it got less gravity than the feeds. Due to its now allowed to spin the ship without checking the center of mass, its also possible to have a non 90° angle in the gravity, causing other issues, so thats also part of the calculation.

I wanted to add the spinning speed change when changing the center of mass, to have that effect when the you spin and put your arms in or out. I didn't store that mass distribution and researched a bit how that is done. Turns out, the usage of the cylinder inertia tensor was not correct and i adapted the calculation of the center of mass to also store the correct one.

While testing i always used the num 1 and 3 buttons to switch between the views. Due to some don't have them, i added view change buttons permanent to the top right of the screen.

The rest of the day i just did other polishings like new 3D icons for orbit map, maneuver node, distance and so on. Also some bugfixes related to the latest changes, but i can see the end of my list for this iteration already.
Today i finished the Room Gravity and fixed some smaller issues in the test verison. Than i worked on the orbits. I integrated the Nasa API, to be able to read the real orbits so they should fit the correct location in space at the time of the game. I also added textures for all planets and added them to the game.

I finished moving the camera to the center of the ship, changing all camera logics and interaction code parts to that logic. As an result, i fould that my old thinking was wrong. Originally i thought, that the wobbling around the center will cause different gravity over time, but it turns out its stable if you choose a fix point on the ship. So its possible to wobble not centered, but as a result, i calculate now the gravity for each room by its own. So when the persons moving through the ship, the gravity will change. In the in between areas, there will be also not 90° aligned gravity. Next to gravity, i will also add a "SpinStress" that will influence the persons later.
After doing some small polishes i run the tests and found some strange issues due to some mass updates, but i found the issue in some restrictions of unity. Than i updated to the new Unity and had to deal with some strange light reflection issues... It looked like there is a bug related to a lod level of my water box, reducing the lod-decimate helped there.

Than i worked on adpating the old game logic, so now the Gravity in the ship aligns to the spinning. For now, there is no restriction or consequences when spinning too fast or out of center of mass, that i have to add later too.

The next thing was a bit more tricky. Till now i just rotate around the center of the ship, but it should be the center of mass. So the positioning has to be relative to the center of mass offset. Updating the rest of the ui was more tricky, due to there are several ui calculations related to the mouse cursor and other ui elements, so this take a bit longer.
In the evening i refactored the complete systems related to that, i combined the astronomic ship and the logical ship to one singleton entity, to have this better structured and be also able to maybe look and steer the other ships too somewhen. It had a big impact on close to all parts where GridPositions were involved and rendered.
Today i tested all features again and it looks pretty nice. As a polishing i improved the usage, so the manual steering is now done with wasdqe buttons and i added a small ui for it instead of the toggle buttons. The steering is done like a airplane, so s will move the ship up. When a target is set, the manual steering is disabled, due to not needed. Instead of the 3 buttons for the directions, a simple slider is controlling the forward speed. You can also disable the complete system to toggle the engines by yourself if wanted. In the end, there is a gravity button with a slider, to controll the target gravity. If set its independent of the other steering controls.

I also changed the group panels, due to the new navigation system features. There is no more group or individual throttle, due to its not realy necessary. To give more control, i added a manual overwrite of the throttle.

Also a lot of other ui improvements were done for the navigation screen, so i hope its now pretty good understandable. Next will be migration of old ships if possible and making the start of the game stable, to get a test verison out as soon as possible. Than translations and a help texts, maybe a tutorial for it, also maybe nice to let players try it out.
After the changes yesterday i found a slight problem, that turns into a huge one. I used the same rotations for the astronomy and unity space. That was just wrong, so one axis was pointing to the wrong direction, leading to problems in some special cases. The result of that was a big mess in all algorithms... To make this more stable, i replaced all double3 values to separate types for the different coordinate systems and build in many util function to convert them into each other. Now its more error proven, and most of the space issues were gone. The balance system was still not working properly, due to its balancing in the wrong coordinate system, so this also had to be updated. All in all i spend the whole day in bugfixing and understanding quaternions and writing tests to make sure its working properly.
After the basic logic is working now, i started to jobify it. This would mean that the performance of the systems will be increased dramaticaly. Also i added more delta time updates, to fix the problems on high time scales. It now have a kind of a physik deltatime, what will be reduced in ultra high speeds and it will do maximum 100 updates per frame inside of a bursted job. I will meassure the performance tomorrow and tewak the amount. But on 1d/s it should be still lower than 1s physic updates including navigation target calculations and balancing adjustments to the engines. The engines will not update inside of a frame, otherwise this would not be possible, i guess it will be in average fine.
There is still a camera offset of 1 frame to the rotation and its not perfectly moving to the target, but in total it looks very smooth now.
Today i worked on the Navigation system, that is the system above the Balance system. It got more detailed steering options like spin targets relative to the camera. This is necessary, due to the artificial gravities z spin of the ship, that makes it very hard to steer by hand. It has to switch on and off the engines while rotating, to focus a target. The next thing is the Target adjustment, so the system identify where e.g. the prograde direction is and setup the target touque of the balance system to meat and keep that.
It was extremely tricky, due to i had multiple bugs that just appear in these special cases now due to the 4 differnt coordinate systems i had to use. It took the whole day to debug and fix the issues, but it looks working now!

In the morning i worked more on the balancing system. So i fixed some special cases like when engines can't fix an error. Also the issue, that the thrusters not balancing as much as they could is now fixed. I also started to make it controllable via the ui. There are basic orientation buttons with a "balance" button in the middle. For the z axis, that controlls the artificial gravity. Besides that there are control buttons for the navigation adjusting the engines to avoiding touque.

After testing a bit around i found again that my camera is not working well when there is an x pitch on the ship. The camera is very complex and tries to align the background of the z angle, to balance the gravity. Otherwise its not realy nice. After some research, it seems there is no easy way to calculate the current roll back from the final rotation.
In the morning i fixed the last issues with the units and orientation of the thruster ui and finalized that so far. There will be still a change with some sliders and tooltip but in general all infos are shown nice i think. The arrows on the map also adjusting automaticaly and the rotational engines also got the center of thrust aiming cross.

After that i started with the first more automatizing system. I will create several systems on top of each other to automize the movement as much as wanted by the player. The first basic thing was a torque balancer. It gets a target spin and try to stabalize the ship to that given values. It took several approaches, till i found a usable algorithm that works fine. This balancer sets additional steering values (grayedout sliders) adjusting the thrusts of the different engines to reach the target.
Today i worked more on the engines. After adding some visualizings, i found problems with the acceleration directions and spend a longer time to find and fis the issues. Than i readded a controller for the engines. Before it was controlled by the ShipEntity, but thats outdated now and the controll will be set to another system, maybe later steared by the crew. There is now an individual throttle and a group throttle for all engines in the same direction.

Today i worked on the thrusters and changing the simulation, so its using the real thrusts. Before it was just a simple container changing, that gets now more complicated to do it physically correct.
After the basics were working, i added some orbit and navigation details to the Overview Camera, there will be more adjustments later on.

Today i started to convert my rotation of the ship, to prepare for the real engine velocities. First i changed the old euler angels with quaternion and the old SelfRotation with angular velocity to start using real physics.

Than i thought about the new UI for the engine adjustments and came to an design that could make it hopefully easy to understand.

The rest of the day i tried to figure out how engines effect the rotation speed and found that i did that not correct a few years ago. So i started to understand the concepts there, its very strange: The engines seems to have always the same thrust e.g. 10kN. But they not adding always the same amount of rotational energy to the system. As faster the ship spins, as more energy they add to the system. It took a while to understand, and i think its due to the fuel is also accelerated so its even faster relative to the outside world when pushed out of the engine, so they contain already more energy.
In the end i worked on the arrows on the map to visualize the thrusters

I polished a lot of the Orbit Rendering, like showing the current mouse position also on the secondary rendered orbit around the moon and render the current position of the planet while hover over the orbit segment. I also make the camera of the game just move when the middle mouse is started over the scene, so its not moving with the star map. Besides that several other smaller improvements have been done on the Starmap, i think it feels very nice now.
Another bigger thing was to make the movement of the maneuvernodes smoother. They should not interfear with the result orbit, or they flicker not nice in some cases, so i had to calculate the closest point to the planned orbit without the node and the resulting orbit change. It was a bit tricky but after some refactorings, it worked well.
I also support now the other Axis of maneuver Nodes, even if there should be no need in the gameplay itself.

Than i worked on the Crash logic. So when the orbit hits the planets surface, the game should end. I realised, that there is no game end screen yet, due to the other situations are not so clear if you can save that.

To make this look nicer, i also stopped rendering the orbits at these crash positions. and added a hint to the UI, so its more clear.

Today i improved the transfer time, so its not depending on the game speed anymore how the orbits with changing planets are. Its scheduling now game tasks to make sure its transfering at the right time to the other planet.
To improve the performance i found a way to do the complete Orbit calculations in burst jobs, so its more performant and can be done in paralell. With that i bring it down from original 30-40ms for a complete recalculation down to 3ms, for around 6 orbits with 4 relative other orbits, so 10 renderings in total, including the full calcualtion of the planned and current orbits.
Than i worked on the next feature of the orbits what is the closest aproach position. Thats also needed for the automatic calculation i maybe want to add later. For now, you can choose a target like in the picture the moon and it will show the closest approach like in kerbal.


I added some convenient functions to the map, so there is now middle mouse to pan the map and the mouse zooms to the mouse position.
While working on the manover nodes, there was a big problem, related to the positioning. On normal orbits, due to it was positioned on its self created orbit. So the best way would be checking only the orbits before the manover nodes or something similar. To make this happen, i need to draw dotted lines, but my old orbit draw algorithm was not able to do nice steps. So i thought about an alternative way to draw the points, using the velocity at the positions. Its more expensive, but it allows to draw nice dotted lines and also get rid of bad resolution on

In the end a complicated example will look like this. I still have a lot of ideas to improve the ui and interactions, but for today, thats it.

I worked on the UI for the Maneuver Nodes and worked also on the Markers. I also created Icons for the directions, so its easier than x y z. After that was done, i moved some of my editor utils to the ui, so its easier to change them and make them more robust.

In the end i tested a bit around and fixed more issues with some special orbits and improved the UI with a nice drag drop feature to change the Values of the velocity.
Today i worked more on polishing the orbit. There were still some special cases i found and had to fix, that were not so simple like detecting a good realtive Element for the Orbit. Turns out, it should be only ONE realtive to, or the Orbit line is cut off, what looks wrong (but is correct). I found more special cases like it calculated an entry of an orbit, what never should have happened.

Today i tested more and fixed some smaller issues. I also improved the UI, starting with the orbit list

Than i also updated the hover elements. That was a bit tricky, due to i can't reuse the original find position, due to that just works for the orbits around the current position, not respecting orbits relative to other bodies.

I also worked on a nicer layout for the Navigation screen, removing things that are not needed anymore and cleared the ui for it.

Than i started with maneuver nodes, so we come closer to the planned feature. For now they are directly executed, till i implement the other features around it.

Today i added the system, that moves the ship to the other orbits. It keeps improving and it seems now working pretty well already!
Than i played a bit around and checked if the catapult manover is working well and found that the entry and exitspeed is the same. After some research thats totally correct, but it changed the direction, so its different relative to the parent planet or the sun. Finally i understand how that manovers are working 😄

After 2 more days of debugging, refactorings and analysing i final found the issues of the calculations! Here the example of an earth orbit. What you can see here is the blue orbit stops when we come to the influsphere SOI of the moon (visible for debugging). The moon position is also rendered at the entrance and exit of the SOI and the orbit is shown in purple with low alpha around the moon. The purple line is the line the ship will take relative to the earth (so in the current view of the other orbits). The circles always start with high alpha to mark the direction.

Next steps now are to make the transitions realy working with a system (with planned tasks to not overshoot). And also manover nodes like in kerbal, where you will be able to plan the accelerations and breaks.
I worked on the orbits on moons and found several other slightly wrong calculations and logical errors i had to fix first.

In the morning i tried to do a test compile, but it failed due to the decimal conversions i did that are not allowed in burst.
Than i worked on the Orbit Transition. So there is an algorithm detecting a point where the ships gravitation will be higher at the sun and not the earth anymore. At this point, the orbit will change from around earth to around the sun. In the end of the day i added that feature also to the UI, so the transfer orbits are also shown and the highlighting is working. Next would be showing the transfer points like the Apolipse and the different sections in the UI. This alrady prepares planning by the user, like in kerbal! What might be one of my next plans to add.

At the moment that just works for parent objects, so from earth to sun. The way back is much more complicated, due to e.g. the moons are moving by itself, so its harder to find the correct timings.
In the morning i found some problems in the calculation that i was able to fixed and the orbit looks now stable, even if i update every frame the orbit without acceleration. With acceleration, there were still problems, that the position changes too much. I was able to fix even more special cases and hope i covered all now.
The next step was to check what happens, when the speed is high enough. It was a bit difficult, due to there are many special cases for that in the kepler equasions, but in the end of the day it seems working fine!
After finding more and more rounding issues, it seems to get more and more stable!

I tried more to find the bug in the algorithm, and give up with it. Than i started the physical approach, where i calculate small delta times to calculate the positions. For testing, i compared them with the Kepler Orbit and it was really strange. With these tests i finally found the bug in the kepler orbit! I have now several tests for that algorithms to make them stable. The problem with the physical one is the calculation time. for around 1h of updates in 1s iterations it took 100ms, so for the 1d/s speed it would took 2seconds. Even when this is 10 times faster in burst code, what my algorithm supports, it would still took 250ms. Maybe i optimize that, but for now i try the original approach changing the kepler orbit. Each frame the error is now around 6cm or 0,0000000001% in the sunsystem.
Today i tried to add Thrust to change the orbit. But it looks like there are too big errors for now. I researched a bit and found a way to use decimal for the astronomic Values. With 1mio Lightyears it should still be better than 1cm correct. I also found a way to serialize it properly.
After that i tried again the algorithm but it still seems to have some bugs or rounding errors to accelerate. I will look the next days into it again.
Today i added a tooltip for the position on the orbit and added more calculations like the time till the position. To test this, i used the real positions at the start of the game 2050.

The next thing was the orbit rendering. Till now i just rendered the full circle in 360 steps, but e.g. for the earth on close zoom, that have to lead to just showing a part of 1 segment and a wrong shown value, that looked wrong. I created an algorithm to detect a nice start and end value, to have always a nice resolution. You can see a test radius with just a few points with markers at the points, to see the resolution.

I thought a bit how to implement the Navigation Gameplay and started to make the map better usable. First of all the size of the planets are now shown correct, so its better visible if the ship hits the orbit. I also improved the icons, to make it look more real.

Than i implemented Apoapsis and Periapsis including the position calculations and added it to the map. This will be needed when trying to change the orbit of the ship.

Than i added a mouse Point on the Orbit Element, showing a circle there.

There was still a problem in converting position and velocity to Kepler Orbits, so i created several test cases to make sure its working properly. In the end it was a simple error my code at a completely strange place. Its now working with 1cm precicion in earth/moon distance to calculate to position and velocity and back to kepler orbits.
After i finished that logic, i continued with the UI, to render the current kepler orbit to the map.

Today i worked on the new Starmap. After adding a background and a nicer border, i moved the center elements into the map, support animated and manual zoom and show a scale like in google maps. Here an example with a high eccentricity of an kepler orbit.
Next step was to try to calculate an Kepler orbit, so i have a chance to adjust them with a velocity. It was very difficult, but with the help of chatgpt i was able to do that in only one day, without any knowlage about most of the formulas there. I created some basic tests for it to make sure its working. Tomorrow i want to continue with that.
In the morning i released a new version and created the news for it.
https://store.steampowered.com/news/app/1638030/view/528720244719486741
In the next iteration, i want to add Navigation. To start with that, i have to improve the Orbit Calculations. Till now i just had a simple circle orbit, that is not changable. So the first thing is to create a better orbit. I found kepler equations and read a bit it. With a bit help of chatgpt i created the algorithm to calculate that. The rest of the day i tried to test that and bring it into the game.
In the morning, i finished the logic for the last Room Shielding. It introduced some special cases for the Recipes, but it was all straight forward and easy to add.

It was already a lot of new Content, so i decided to move the medical things to other iteration and focus on the help and polishing first. For example the Change Door state button was hidden by the newer Overlay, so i moved that to it.

I also worked on very old notes and added an efficiency label to the Resource Users. This should give the player a direct feedback why a value is low. The main purpose are e.g. Humidity to show the problems also in this UI in a clear way. I hope its understandable what it means

Today just fixed small issues and painted the new Interior Item.

I started the day painting the new Water pump item. It took a bit time, till i setup substance painter with the new blender version again, but in the end it worked well.

The rest of the day i finished the things i found in the last playtest.
Today i added the shielding of the room with water. It is additionaly to the steel shielding of the room and needs an interior item and water to pump in the rooms hull.

So the next step would be an interior item to get the water in and out. I reused my old big pump and added a small storage container in front of it.

The activity to fill up the room was very fast and straight forward and worked pretty fast and simple.

Since a few weeks i had troubles with my Remote Logging Systems, lookes like the new Unity libary didn't support my old websocket library i used in the server, so i updated the monitoring server using a new library. Also it looks like the new Unity version had a problem with newer SSL Certificates, so i had to reconfigure that also.
After another sucessful playtest with some smaller things to improve, I first finished the basic UI for the Room parts. It took a bit longer, due to i improved the calculation of the Resources to make the min/max value easier calculatable.

After that was working, i prepared for water shielding. The idea is, that the modules can be filled with water via a new interior item to increase passive shielding. That required another multiplyer, so i added a resourceType to visualize the different shields.

I started with the last Person effect of Radiation i planned. The persons health is now also effected on high radiation. It will start slow with around 1 year to die and get up to a week to die on radiation.

Than i started with the Radiation Protection mechanisms. The first is another Room Type, but i found it a bit strange mixing the types. Earlier it was planned that they just have the floor size, where it would not be a problem. Now they have shielding and other specific features, so i had to change that behavior.
Today i added the CME Event, so you will have several days preparation time till the radiation goes up for a specific time. Later this will time will depend on the sun sensor interior items. I created a special event for that too, so i will add a help system for that too.

Than i added impacts for high radiation. I started with the walking speed:

Due to my preparation when i created this features, it was now very simple to add that. Also add an working speed impact:

I researched a bit what the cosmic radiation effects. It seems the sun is also creating a magnetic shield for us, to protect us from the cosmic radiation. So for now on i just add the sun radiation. Due to my research, its about 100mSv/Year on the ISS. The body repairs around 50mSv/Year. I added that values to the game.
Than i worked on the shielding feature. For that i added a specific multiplyer of the contents, including a type filter, so only radiation from outside is shielded from them and not e.g. nuclear reactors i will add later.

I wanted to add the new Radiation to the room, and came to the conclusion, i have to add another feature to the ResourceContainers. Now they can have a specific Content. They can act now as "sum of something", so its easier to handle. I had a similar feature for the noise, but there i just add and removed it and had a special case in the UI to show that different. Now everything is aligned to the new feature and the Radiation is ready to be added.
With that feature there is also a fix for wrong calculated values. I created the migration scripts for the old savegames too.
Than i tried my tests and found some small issues i fixed, related to recent changes. Always good to have the tests!
The new Sievert Unit had some troubles with the unit stringify, so this also had to be fixed first. Than i added it to the person, with a realistic self regeneration value.

Today i created a new Release and wrote the release news. I did this now before i start with the next big radiation topic. This will include several new gameplay elements.
https://store.steampowered.com/news/app/1638030/view/528718979655532671
I improved the person creator to get also an estimation of the room level. The idea is to get lower requirement persons at the start of the game and can change that over time, objectives or events. It was a bit difficult for new players to choose persons, due to they always wanted high skills. This cause worse traits and higher room requirements, leading to unhappy persons where the player can't do much except restarting and ordering lower skilled ones that require not so good rooms. To fix that this feature was added, so on easy it starts now with max room requirement 2 and for normal games with 3. While the game progresses with the objectives, i added rewards to get higher skilled persons.

After that i also added an event, that makes the persons worse or better for a specific time. I made one positive and one negative one.

In the end i made some small improvements of the effects, due to the persons usualy get updated when the ui is opened, i also update them before the effects get changed, to make it independent from the ui.
Today i just game event speaking and an avatar for the event bubble.
Today i added more possible effects of events, especialy the effects on the earths supply chain. There can be resources added or removed and also changing the delta for a specific duration.

To make this clear in the supply popup, i added also some hints in the style of the thoughts to it.

I also added another event, increasing the cost of some resources and the game logic for it.

To make my life easier, i improved my drawers and support now float2 values. It needed a complete rewrite of the old view logic, to adapt it to the new Unity mechanism.

I was able to continue development and did a first event.

I also added the first effect, that will be an effect on the mood of the persons.

Today i started with the game event system. This are random events, that appear in the game. These will have different kind of effects, for example a mombardment of an enemy destroyed some factories, causing resupply problems for specific resources or dead crew family member causing a very bad mood for some people. I also planned to add something like new Missions appearing on events, like another generation ship is broken and can be used to gather high tech resources from there. The main reason i add this now is the new planned radiation feature, to start sun erruptions.
I worked on some smaller things again and prepared the next bigger topics today.
In the playtest there were some issues with the sound. Turns out, that i can't use the original Unity sound effect mixers in the ECS system of unity, and had to overwrite it by hand. There were also not so annoying bugs and minor things related to the last changes.
I fixed some small issues where persons droped garbage into gas containers and some pimenu items, that shouldn't be accessable anymore. In the evening i did a playtest with a new weekly tester.
Today i added an alert sound to the rooms when the air is toxic. This will round up the experience of the bad air, and i will go to the next topic.
To make the slots more easy to understand, i created separate Resource Boxes for the three slot types. The old Tools become the new Toolbelt slots, due to its only used there since a longer time.

To make it more obvious, that there is a problem with the air, i also improved the lighting of the rooms. They can now react on specific situations and the first usage is the bad air of a section.

I also created an event for toxic air, so the timewarps will stop and its showing a help for new players.

Today i tried alternatives to Substance Painter. I found amorepaint, but it looks really annoying and have close to no features that i was used to. It would be a big effort to change everything and make it work like before. Too sad, that blender also is not capable to have that, so i decided to buy substance painter again.
I tried to improve the Dynamic Volume again, but nothing seems to be perfect, so i keep the one from yesterday.
Afterwards i continued with the O2 Masks i did before the long break. There is now an Rescue O2Mask slot, that will be used to put on unconcious persons, to rescue them. When they have the mask on, they can walk again and refill the masks by themselfs again, or get out of the section with bad air.
It was a bit tricky to get it working fine when changing the sections. To make that possible, the persons can now use their Rescue O2 Masks also for their own O2 Masks. This also helps the firefighters to survive longer.
The sound was still a bit strange, the maintaining was hearable all over the ship, even when no worker was around. The reason was the unity default logarithmic setup, making the sound silent, but not turning it off on high distances. Also when the camera is 30m high over ground, i want to hear it, but not 30m at the side 4 rooms away. So i found a nice way to solve this, the maxDistance where the sound is hearable will be relative to the zoom level. If the camera is close, its 10m high over ground its 40m hearable distance. It feels way more natural now.
Than i also added the inflatable walls sound to the new Architecture and make it loop better.
In the end i also added Talking sound. I choose a female and male blabla sound and added it relative to the gender of them.
The Items can now have a start and stop sound. I used it for the toilet to flush and maybe i will also add some clicks when starting machines. To make the startup of machines smoother and prevent needing for everyone a starting sound, i added a fade in/out feature to them. As a last feature i make the volume and pitch adaptable to the productivity, so you can hear how hard the machines are working.
I jobified the system from yesterday, so it should not impact the performance and started with sounds of items.
I decided to start with the sounds first, to get back into the daily working. It was easier than i expected to add it to the person itself. I was also able to adapt it depending on the walking and game speed. I added several sounds as a first try. Tomorrow i plan to add also to the interior items like the machines, to let them make noise, depending on their usage level.
I worked on the reports and found still very long loading times. So i tried to optimize the loading process and found some smaller possibilities. The main time still goes to analyse the json, but i was able to make it faster by improving the History data of the Resource containers. I could reduce it in the editor from 45s to 25s.
I finaly got my now pc. The last week was still some family things, now i realy want to get back to work on the game more regular
Today i fixed some bugs for new players and made some small text improvements. Slowly getting back to the development, due to my house controlling system needed improvements too.
I played with the new Steam Demo feature and try to setup everything to prepare for the first big steam festival i will attend.
I added another Feedback popup to gain more data while the player play the game. It will popup after tutorials are finished, or when the fire extinguished. Also while playing the game for a specific time it will show some feedback screens. I hope its not too annoying and i will also add a feature to disabled them for the final game.
I added some small things to get back into programming after that long pause. I also restarted the weekly tester, this time in 2 weeks, after that i want to go back to weekly. The last thing i was working on were the O2 Mask usages, where i fixed a bug to get back into that logic. I also added a help for use once resources, so its understandable, why the amounts drop to zero for some production items in some recipes.
Hello community, finaly we arrived back in germany and i setup my working area again. I started to update to the newest Unity and get everything running again on my PC. Sadly i was not able to work in the last 3 Months on the project, but now i'm back and highly motivated 🙂
It took a longer time to get it work again, due to it looks like my git lfs has many broken files..
As planned i started with the O2 Mask as a temporary item. Its created when the air gets bad and persons try to fill them like before. Before, all persons instant fait when that level was reached, so i added also a random timer to that. If they don't wear a O2 mask in that time, they fait like before. It was very easy to do with the systems i already build.

Today i just fixed some smaller bugs and prepared my todo list for the next iteration. The topic will be "Emergencies"
After getting very good feedback and ideas to make the emergencies better, i want to directly do that, so the main thing will be temporary person slots, using the O2 mask. It will be later also used for more garbage creation, maybe for cleaning the floor with water and instant converting it to brownwater while cleaning.
Also the effect of the humidity problem will be lowered with the following idea. When the humidity reach 100%, the water will condense in the rooms. When a person cleaning the room, this water will be removed to its slots.
It also allows to help persons putting O2 masks on in emergencies and heal them when they are dying, so medics gets more important. To continue with the main progress of the game i will continue adding radiation, so the persons might health is affected more. The plan here is to add an interior item, that allowes the player to pump water into the walls of a room to shield it from radiation. The game should be prepared for that feature, so i hope its not that much effort.
To make this good usable, i plan to add the event system in this iteration too, so there can be "sun flare" events, where the persons have to go into a good shielded room. Not quite sure how i will do that, but maybe similar as the new Bad Air alert, where persons will grab o2 masks by themself. Also other events, affecting the person moods i plan to add, to create a good event system, like the war on earth is going bad, so less resources can be used.
Last but not least a bigger list of smaller improvements are planned. All in all its a tough plan, but i hope i can finish it in the next month. I'm not sure if i can hold that timeplan, due to its pretty unclear how much i will find time to work on the game, due to our appartment movement.
I added another common problem as a thought in tha game. Sometimes the persons working on something are very slow, due to e.g. the mood of the person. To visualize that for the player, i created another thought for tasks, showing low mood or low skill impacts with the new thought bubbles. I hope this will now hint the players enough to that problem.

I also improved the bubbles, by keeping them at least some seconds alive. This was needed, due to at a timewarp, the max 20s gametime are over very fast or might be skipped, before the bubble was shown. So at a timewarp, the player did not see those.
Than i started with the last planned part of this iteration. I want to have a better person overlay, showing where he live and works. First i added Residence and Worker Icons above the things the player set up.

The next thing was to add routs to the places, so its easier to find. I also worked more on the paths, to visualize them better.

Yesterday, i got a big report with several of new Ideas and improvements. Most of it belongs to emergencies and how to handle them. Due to this will be a big update again, i will first do a major release before i work on them.
The last days i was very busy with preparing for the appartment movement, but i finalized the Thought bubble, making it look nicer and fixed some last special cases.
Today more fixes and improvements, like setting the room level with a basic value of 1 star, to make it easier for uneducated persons to find a room. Additional i setup the room requirement up to 5, so its more spreaded between the persons.
I also did some changes to the priority, to prevent extreme priorities and fixed some small performance issues.
There is now also the possibility to setup the supplyship when its not ready yet, so it can be preconfigured when its undocked from the ship.
Afterwards i prepared the visual thought bubbles. The idea is to hint the player to the feelings of the person, due to i saw many players that didn't know why the persons don't work. I'm not yet sure when i will show them. In the evening i was able to create the logic for it. First i added another short thought, when a task has been stopped, to do fulfill basic needs. Than i implemented the system, showing or hiding the thought bubble i implemented in the afternoon.

Our appartment movement has been started, so i'm very limited in working on the game for the next months. I will try to do my best to keep the improvements, at least working on the bugs and reports for the next time 🙂
I also found an easy workaround for the looping ui error when using window mode. To prevent endless changing, i just ignore the size change when its getting less than 2px smaller, so the cols will might stay 2 px to large.
I also worked on some overlay and pathfinding things. Its now showing the concrete activity type for the person path overlay and fixed some warnings and special cases.
Today more improvements on the pathfinding. While profiling i found, that the adding to the cache takes a lot of time, compared to the calculation. Also the cache hits are not much faster than the new pathfinding itself, so i decided to remove that part for now.
After the change of yesterday, the baking time got realy high (for development). I found that the main bottleneck is the icon creation. I can use multiple images to create the icon, but for the fast path rendering, i just use one texture. This baking took a long time, so i moved it to the runtime and its done just when it was needed. This caused now a big lag when using it the first time (around 1.5s), so i converted that logic to a bursted job what uses all CPUs and takes now with burst just 100ms.
I will redo now the Thanks to the commits i stopped a while ago. To make this as easy as possible i created a tooling today. I can now commit with an @Name in the headline, and the name will be replaced by a superscript number, like ². Below there will be added a Thanks section where the community member is mentioned. I also updated the Server, Steam News generator and ingame elements to adapt to that.
The rest of the day, we prepared for our movement to Beijing.
Today even more fixes from the last days playtests. One of the things was a new I18n Feature. Its how possible to use multiline <help> tags, result in a Questionmark with a Tooltip with the given content.

Besides that more than 10 other issues and reports i worked on.
Yesterday was a streamer online playing the game. I wantched a longer time and found several things that should be improved. So today i worked my big list i created there. Most of them were just smaller improvements and some minor fixes. In total i fixed around 20 small things and one larger simulation bug, related to the energy.
The last days an old fiend visited us, so i didn't had much time. In the meantime, a new tester brought a lot of improvement ideas and things that need to be more clear. Today i worked on many different parts on the ui. The other tester reported no errors on the new performance update, so i did also a release for that, looks like it worth the 2 days spend on it.
Today i worked on the tests and fixed 2 bigger simulation issues. I also analysed another game that was very slow. The reason is a bit complicated and is related to the event system for the resources. It seems some events fire too often, like energy update. I tried different approaches, ending up in a small change, that helped very good! While working with the big savegame i also found, that some easy container updates took ages, even with the new extreme fast pathfinding, they took 300ms (without burst). The reason seems to be that i update the persons when i found a possible task and than the person is doing something else instead.
While doing so i also found the bug, that the persons don't talk to each other and fixed it.
I also found that my sorting method for the Container users was too slow, it took around half of the time of the simulation on larger ships. So i optimized by precalculating the improtant values. With my new approach, i could make it 66% faster.
Today i finished the performance updates and did some smaller improvements and fixes from my list.
Then i read the news that the new Unity i use get to the LTS version, so i updated it. It got a major Entities package update, causing a lot of changes in my code.
I had a talk yesterday with an old friend, loving to 3D print things. He want to print out a Generation Ship. To start i tried to create a high res model to be able to print. Due to i paint the details in substance painter it was a bit tricky to get that painted normal map back to blender, but in the end it looks pretty easy

I finished the big change what i started yesterday. The new approach seems a lot faster than the old one. In the editor, a path calculation goes down from 1-2ms to below 0.1ms. On the huge ship from a player it was even more extrem, there it get down from 47ms also to 0.15ms! So i think i am on the right way to solve that performance issue!
In the end the game got a huge boost from today. It started with 9seconds of simulation and end up in 200ms. The preparation with the bursted job is done in 22ms on that huge ship, what is really amazing. That will be triggered, when something has been changed, like a new room or you add an interior item.
Today i started to analyse another error, reported in a savegame with a huge ship. In the editor it was pretty slow, so i decided to do some performance updates first. I found something related to the newer bar change and was able to reduce that from 50ms to 0.03ms per frame. I also found, that the consistency check causing some dirty calls to the checked entities, causing the ui to update, without any need. The gaugepanels now also behave better and just update when its needed. Than i found several jobs without burst and updated them too. Also other smaller things i was able to improve, so it looks now better.
The next thing i found were huge lags on the big ship. A single update of a person cost several seconds, due to some special situations the optimizations could not be done. This is a huge problem for larger ships. To solve this i first improved the pathfindings internal algorithm what had not much effect. In the evening i had an idea to precalculate the door to door connections, so its fast to check for interiorItem connections in the simulation. The precalculate is running asyncron on other threads, can run in paralell and can be done between two frames, next to other graphic things, to have less impact as possible. I used my A* algorithm and adapted it for that, without a stop. Than i just visit all nodes and add their paths. I also reduced the memory usage of the new and the old algorithm. Tomorrow i plan to implement the new fast way to reuse these door to door precalculations and hopefully to boost the simulation with that.
After a longer travel, i fixed the rest of the tests that were failing, due to the bigger change to the new non-interioritem mode. I also worked all the reports from the last week like fixing some rare simulation loop cases.
The sad news is, that i will not have a good working environment the next months, so the development will slow down. The reason for this is, that we are moving from Shenzhen to Beijing and than to Xiamen and than back to Germany in the next months. While traveling, i just have my laptop to work on, so i expect a big slow down of the development in that time.
Due to we go to another short vaccation tomorrow, i just fixed the last issues i found in the playtest yesterday and run the tests and fixed there more things related to them.
After i fixed all the things from the last playtest, i did another one, this time around 2h. The major gameplay went pretty smooth and i like the new way without crafting the interior items more and more, so i switched all game modes to the new non interior system. I found again a big list of 25 todos for myself that i will work till tomorrow, before going to another short vaccation trip.
After another small vaccation trip, i fixed today the rest of the bugs i found in the last playtests and did another one. I must say, it looks better than before, but i still found many things i had to fix.
In the morning i did a small playtest to see the results of the new gameplay idea without interior item boxes. I actualy like the new gameplay, it feels easier to manage, you don't have to craft too many different things and don't need to check so much about the crafting queue.
After the playtest i had again a bigger list of things to do, but all very small or graphical things. For example improving the view for the Skills in the supplypopup tooltips.

Also many other things like showing an overlay when hover over a persons activity or the queue behind. It now also shows the path to the item, this can make it more clear what item is ment, without selecting it.

I improved the Feedback screen. Than i started with a tryout i wanted to do a longer time. The idea is to remove the interior item boxes again, so the interior items directly need the resources. I struggled with it, due to its not realy logical to do everything there. But on the other hand, it also has no logic to fit a complete shuttlebay in one box
The main difficulty is now to separate the different levels of construction. One way would be to add a research feature, but that would be a bit much for now. The other way was to add more ResourceTypes to craft, so there is still crafting, but the items can be reused for different items. It also makes the storages easier to manage and i can also add a panalty for unmounting items by creating e.g. 10% garbage.
To make that easier managable, i created an editor window, that can directly show and change the construction resources. I worked the whole day to try to get useful values there, also to use the relevant things. Not sure if its good like it is now, but i will do a playtest tomorrow and check it out.
I also added another way to create Prepared Earth. Till now, you have to have an purification plant to recycle the garbage water. To make the start with food easier, i created a new recipe for the chemistry table filter garbage water to water and directly prepared earth. I hope this can improve the speed there.
Today just small improvements to the Thoughts and some planning how i want to restructure them. Since the time i implemented the mood and thoughts there came a lot of new things in. Now this part is a bit crowded and not good understandable. My idea is to merge some of the things toghether into thoughts. For example when all basic needs are fulfilled, they get a positive thought, leading to the positive impact on the mood. This will merge already several of them to one new one.
I decided to make this simple and just add a nice text to the thoughts, without using the real thought system for now. It will react on the different parts of the calculation. I hope this will makes it easy for new players to understand the problems, and also no need to check the Calculation Tooltip.

I analysed a bit the performance and found an issue with the ResourceOverview. I could push it down from 6ms to 1.2ms, including some other optimizing helping in other parts of the UI. I also found an performance issue with one of my loggings, causing realy bad simulation speeds.
Than i worked more on the Residence Impact. Another influence on the Persons Mood, that should relate to the selected residence and its Room Level.

After having a break yesterday, i did some bugfixes from the tester and finished a new design for the person selection panel. After adding all the new features, it get pretty fast crowded, so i decided to move the skill and traits together and also the assignments. The assignments now get back to a line-layout to easy add the mood delta (i want to do tomorrow) to it.
.jpg)
All in all it looks running pretty well except some rare crashes of unities core, what unity don't tell me the problem. I hope they fix this soon...
In the morning i added the plants. Yesterday i prepared already that i can switch multiple meshes of the items, that i use now for the plants. You can change the pot and the plant separate from each other. There are 5 pots and 5 plants, so 25 variations. I designed them as plastic plants, so no need to use water or oxygen production. Maybe in the future i will add bigger ones to do so.

I decided to stay with that new content for this iteration. I still have some others i might add in another iteration: SoundBox, Piano, ArmChair or Sofa,... But for now the content should be already good to test the behaviors.
The next step was to calculate a RoomLevel, related to the new Values i added recently.

I also reworked the interior items of the room overview, to make it more useful.

Today i worked on the next Appearance Item: A scultpure. With that i created a new feature, that makes it possible to change the sculpture like the texture for the picture frame. In general it was very similar than the texture changing. For Texture i could just use the color texture of the texture, but for the mesh, i had to create a picture for all of them. I added it to my image generator, using the current item setup, so its easy to do for further additions.

The Lion i used as it was from a bought asset. The Lion i painted by myself and optimised the mesh. For the rest i used a preset as a basic idea and created my own one and painted it.

Today i started the new Appearance Environment items. First thing was a picture frame.

The challange there was to add a changable material, so the player can choose between different pictures. This system will also work for other items in the future, where i can switch complete materials to make completely different looks possible.

For the start i created 3 pictures out of the Games Logo.

Than i added the logic for the Appearance. Due to it was the same as the noise, it just worked without more setup.

I added the selected material to the Blueprint system and randomize it for each drop of a new Item. On Clone it will always drop the current one.
Today i worked on the graphicy for the new Cleanliness environment value. I decided to make it more simple and just have one cleanliness value at room level, but the interior items are adapting to that. It was pertty easy and quick, and the result is way nicer than i expected for the short amount of developing time.

I also used the same logic for the interior items. Just needed to make sure the dirt is just inside of the ship rendered.

I also created a cleaning animation for the new Activity. It was a bit tricky, due to i updated to blender 4.3 and the export wasn't working anymore, but in the end it worked.

After that i added another source for dirt in the room. Some interior items got now to a source of dirt when active.

The rest of the day i spend brainstorming about new interior items, tht will improve the new Appearance level of a room. I searched through the asset store to find some nice ideas and assets. I know i will have to repaint them or adapting most of them to the style of the game, but it might save lot of work anyway.
Today i finished the last parts of the release to continue with the next bigger step. The next topic is also close related to the persons: the environment. Besides that its planned to improve the thoughts and show more obvious the mood problems. But first i start to finish with the smaller issues i noted the last days.

I started with the Free Space Value. Its calculated when something is added or removed from the room. All in all it was very easy and fast to implement.

The second thing i created is the Cleanliness Environment variable. The idea is, that that value is increasing when persons are in the room or special machines are activated, that could make the room dirty. As an Icon i created a simple broom icon.

Today another big bugfix day. There were still special cases in the automatic rotating algorithms. Also some endless simulation loops due to the talkto feature i fixed. I also adjusted the new Efficiency values for all interior items to give it to the testing stage.
Today i implemented a new work type for the persons. There is now an efficiency value for several interior items, effecting the productivity of the items.

While doing that i improved also several other things starting from adding the speed calculation to the Activity tooltip, up to moving the SkillRequirement for Construction and Maintenance to the Task to align it with the rest of the ui.
I also updated all the Interior Items, that don't need direct working and added the efficiency indluding the animations for them.
To make the skills more clear i added a better visualisation for the value. It now shows from level numbers from 1..4 to make that easier to use.

I also polished the Not enough Skill Problem, so its easier to see what is missing.

Today not that much time, so i moved the new Feature to tomorrow. After discussing a bit with the community, i updated the Fitness devices. They now have always a basic priority of 1. To make them use them, i also added a fitness schedule item. Its like the education or sleep, so all work items are restricted, regular items auf -50% priority and the fitness items gain +100% priority. They also do the fitness when having nothing else to do, so i think thats fine so far.

Instead of doing what planned a report from a good tester arrived. There was the missing stackoverflow exception i searched for a long time, so i had to deal with that first. It took a long time, due to unity did not handle that well and didn't tell me where it is. So it took a lot of logging and unity restarts till i figured out the reason for it.
Afterwards i worked on the performance. He reported, that the fps drop down a lot on fast timewarps, so i tried to profile more and analyse problems and bottle necks.
After that parts were done, i started with next big gameplay change of this iteration will be the usage of skills. They should have a more obvious influence on the work, what i prepared last week the logic and ui for it. Adding it was much faster than expected, the

After a longer family weekend, i found several things in the logs with deleted entities, where i had no chanche to identify what this could be. To fix that i created a system to store the old names and try to show them in the logs. I also send it with the report to find the issues next time.
I profiled a bit the game and found several smaller things to improve the performance.
Besides that i fixed the last issues from reports and my findings, to start tomorrow with a new improvement.
Next i tried to fix the issues with the consistency check. It was very slow in the editor so i debugged a bit and found a perforamnce improvement for the persons. While doing that i reimplemented an old idea to completely do the consistency check for ALL entities but iterative, so they will just take around 10ms per frame to reduce the impact of the gameplay. This also means, the autocorrection will work without pressing F5 when its enabled.
I also worked on the tutorial for next tuesdays weekly testing and added a repeat part for the connect interior items, due to i saw still problems in that part.
To make the worker speed and the reasons for it better visible for the player, i added tooltips and a bunch of the value-elements i added on wednesday.
The calculation tooltip will be extended later including also the required and current skills and its working speed effect.

I added it also to the task itself and in its tooltip, so its now everywhere easy visible.

The last place was the worker slot. Its now just added like everywhere else.

The other speed impacts like Skills i will do in another iteration, and focus on polish this part first. Another thing i added is the increase of fitness while transporting things inside of the ship. This is a prototype example for increasing other things like skills later on.
The rest of the day i spend analysing some reports and try to make the consistency update faster and the game more stable.
Today i added the traits to the randomizer for the persons. They now all have the new traits when choosing them. The starting person will always have the same setting like before, to have a good start. The traits are now also added to the supply popup and to make them better readable, i created an automatic created icon, depending on their effects.

The special persons now have a very good rating, so they will spawn always with good values. Later i will change the target rating also for the others, when i add the event system, so at start there will be medium ones, and later the good persons are needed for the war on earth, so there will be not so good ones anymore and the player have to train them by itself.
Than i worked on the working speed traits. First i refactored a bit, so all parts of the working including transport, crafting, maintain, construction and so on are using an speed calculation now for modify the speed. The activities respect now also that speed for the workers. To make this visible, i added it to several places of the ui. It started with the PiMenu, so to check the possible speed, the player can just rightclick on the target with the person to see that.

Today i added the Traits to like or hate something. It can be an interior item or an activity. As a first start, it will incrase the fun, while doing something with it. This can be using it or just constructing, maintaining or extinguish a fire on it. I also created an Like/Dislike icon using the persons of the game for the model.

After the UI like/Dislike part including their Tooltips are were finished, i started with the person randomizer. Thats a bit tricky to not get too overpowered or underpowered persons.
Today i worked more on the fixes. There were still some annoying rounding issues in deeper simulation logic i had to fight with. After all known bugs were fixed again, i continued with the Trait system.
I was able to finished the walking speed trait, so there is now a "Fast Walker" and a "Slowpoke" Trait!
A good tester got back from summer break and found several smaller and larger issues i worked on today.
Yesterday evening i made a first list of traits i want to do and planned the architecture around it. Today i started to implement it. All in all its going on faster than i expected. After the model and setup was done, i did the activity effects, so here you can see that the person increased the sleep need way higher. It can be a fixed value or a dynamic percentage of the resourceType.

Afterwards i worked on the UI to make them visible and inspectable by the player.

In the end of the day i added also optimist, pessimist and with it the feature for permanent change of needs.
In the morning i added the ui for the new transport capacity, depending on the fitness value i implemented yesterday.

I also implemented the simulation logic for the increasing social value for persons when they do something together. Afterwards i worked on the last weekly tester result by enhancing some tutorials. Than i released the new version to focus on the next bigger feature to make it more important to choose the right persons.
Today i worked on the second impact of the fitness. The person can carry more things when being fit, so it will have a much higher impact on them. To make that work better, i changed the logic of the transport again, so now they can carry around 200kg per slot or half a box maximum. It will be depending on the fitness level, going from 50kg (weak) up to 300kg (max fitness). The values are quite high for now, maybe i will reduce that in further releases.
Afterwards i created a simple new interior item: A starmap screen, that can be placed on a wall, without using too much space. It will slowly increase the fun. The main purpose is for the starting ship or later in private quarters. When i add the Environment, they will also make the room nicer.

After yestdays burocracy to apply for new visas and I started to work on the impact of the fitness value. To make that visible for the player, i added it to the person selection panel.

The next thing for the socializing is to have activities, that can be done together. For that i started to improve the small table. I split up the chair from the table to reuse it and created a large version of the table. I found, that its not very nice that the person need to stand next to the chair to use it, so i had to change that animation, including the small table. Due to i want also more things doing while sitting, i also thought to split up the sit down/stand up animation from the other animation, so i can reuse it easy e.g. for meetings or controlling items.

After a whole day to try a different approach for rigging the persons, i worked on an animation testing scene to be faster in development. After having the basic setup i fixed an annoying bug in the animation framework, not ending an animation correct in some special cases.

Today i couldn't work so much, but i was able to finish the talk to each other simulation and animation part. Its not perfect, but for the first try i will leave it for now.

The social need goes down very slow, so 100% in a complete month. In a normal game, this will not happen so fast, so even at the start of the game, i might add a trait that the first person don't need so much social and it takes even longer to reduce it to zero for him. Next will be a bigger table, where the persons can talk to each other while having food. This will also make the schedule more useful, due to all persons will eat at the same time.
Today i finished another new item increasing the Fun need. Its a home computer i prepared several months ago.

I also planned the rest of this iteration. I want to finish the social and fitness needs. For social it means i want to create another easy interior to increase the social need. It will be a earthphone to call the relatives on earth. Another bigger feature will be talking to other crew members. I plan also to create a larger eating table for multiple persons. When they use the same item it will be similar than talking to each other and increasing the social. In a later stage, so not in this iteration) i will add friend levels when talking to each other, so they can get friends as a preparation for the family and children feature in the next level of the development.
The next thing i want to do in this iteration will be the fitness impact i created yesterday. I plan to do two things with it, one will be the speed of the person and the other will be adapting the carry capacity of the persons, so stronger persons can carry maybe 1-2 boxes at once, weaker ones just 0.5-1 box per slot.
Depending on how long i take for the things before, i will also create traits in this iteration, with several impacts on the persons, so it gets more relevant what crew members you recrute. The generation of the persons will also be enhanced in that step.
I started with the most complicated one, the talk to other persons. As expected it was not that easy and needed a lot of things to do. After the easy part creating a new TaskType, there was the pathfinding, that was optimized to find paths to interiors, not person to person. Than both persons need to stop the task, when one stops it. Also they need to stop in front of the other person and need to turn towards them.

For the new Treadmil i created the needed fun icon. Due to i already work on it, i also added a fitness value, that should influence the speed and carry capacity of the persons. Also a social icon was created for the next step i plan to add for them. Due to so many new needs, i had to split them up in the UI, to make it more clear to work with. I decided to do the "Fast changing" ones in the first row and the slower improvements in the second. So Mood, Health, Fitness and Social will be in the second line. The skills move to the third line and maybe later somewhere below.

For the animation i plan to refactor my animation system, to save graphic memory and be able to add more animations without much overhead. Till i have that, i just use the walking animation. After trying it out i found it very complicated and not very handy to implement the new way, so i skip that for now and might do that another time. The advantage might be anyway not that much.
Today started to work on the persons. The plan is to let the persons have more things to do in the ship, to get a nicer gameplay. One new need will be fun. I start with a treadmill, where persons can do some exercise. I could finish the model, painting and basic setup for it in around 4h.

I tested more on the batteries and its still not working well... Its realy a hell to make that work well. There are so many sideeffects and algorithms involved and due to unity its horrible slow to debug... In the end i revert the split to two activities and solved it another way. The old architecture was actualy a good plan, but i needed to handle the change from consumer to producer in my algorithms correct. With the new way, i'm pretty sure it's that this problem will not appear anymore.
Today i checked the logs from the last 2 week players and found several things to fix before i start with the next topic. Besides some smaller loggings and ui bugs, there was a big endless loop issue with the batteries i started to debug. After getting deep into the game logic, i had an idea to solve it. I used a script to change the recipe of the battery from charge to discharge, causing the main issue at the battery. Due to the single recipes worked correct, also stopping themselves, i came to the idea to just add two activities so both recipes work the same time. It was still tricky to find the problem, but in the end i found it at wrong priorities, so all batteries have to be lower priority than the other items.
The only thing is now to change the ui to show the user both recipes, but that was an easier task. It was a lot of work, so i move the rest of the polishing to tomorrow, here the current state.

I fixed more special cases for the new single storages and started with the dynamic material, so the object can represent the selected ResourceType by changing the textures.
For the polishing, i added also a pi menu item to setup the resource type for that kind of storages.

In the afternoon i started with another single storage for liquids, so for now Water and garbage water. It's similar than the Mass Balancer, but act like a normal storage.

After a very long break i was finaly able to get back to work. I started with some modeling tasks, due to thats what i plan to focus on more. First thing was a gas storage, that the player can switch the types. Tomorrow i plan to do also a liquid storage switchable between Garbage Water and Water. It went pretty good, for the whole model with neutrals and ch4 design i took just 3h. I still need to take care about my kid, so i can just work a bit over the day.

In the evening i started with the logic so the player can switch it. This part was not that easy, due to there are a lot of special cases to handle.
Today i worked on some open errors and reports to get a clean state when i'm back from the business trip. At some points i struggled again with unity endless loops in the ui rendering engine, that cost a lot of time.. I found a workaround, but there is still some fishy rendering errors in that special case. I hope its not crashing the ui again and wait for newer untiy updates.
After a longer weekend i started the working day handling a special error in discord, when the player blocked the discord bot or prevent letting him send him messages. I handle the situation on the server and show a nice message with solutions to the player if that happens.
In my own playtests, the savegame crash bug happens now also after playtesting it a longer time. I did many debuggings with log files, to get closer to the error and finaly i found it. In some situations, there are destroyed entities, that still exists to cleanup e.g. memory. Passing them to the copy world of unity causing asserts in the editor, exceptions in the game and crashes, when burst is enabled.
I have to go for a business trip starting from wednesday, so i just clean up the rest of the things, checking some reports. I also prepared a bigger release and prepared the news for it, what i plan to do tomorrow.
In the morning i worked again on the new crash report. It looks like its crashing in the clone method of unity. I added more debugging to it, to see what entity is effected. It cost a lot of performance, but due to the complete game crash, i have no other choise till i figure out unities problem.
Than i worked on the next feature related to the work schedule. In space there is usualy a setup for the light, to indicate if its day or night to adapt to the regular day-night cycle on earth, what the human body is used to. I prepared this already a longer time ago and make it now configurable for the player.

I think i'm close to the next release, the Person Groups looks already a big gameplay changer.
I checked the loading and savegame again this morning and it looks now fine. None of the problems i had yesterday raised up again, so i decided to do a release after some smaller ui fixes due to the person group changes. The Work priorities and schedule are still not functionable, but i still do a patch release to fix the savegame issues now. I also improved the text for the migration part when loading a game, to let the player know whats happening there.
Than i started with the working priorities. It's implemented as a general multiplyer to the metric, so normal will not change it and e.g. very high doubles the metric value. It need to be balanced a bit when trying these things out, but as a first try it should be fine. Also Pause is working as a "Don't do it", not sure if players understand this, or i have to add a special case for that. Its due to i reuse the TaskPriority enums for that, to make it everywhere look the same. All in all it was very very fast to add this feature.
Afterwards i implemented the day schedule. It was also easier than expected, so in total i spend only around one day to do all the group logic! I think i will disable the subGroups for now, due to there is no real usecase for now. I guess it will become more useful later when the ship sections gets more useful.
This morning i worked more on the reports. Yesterdays downgrade try and the not responding unity team leave me no choise than trying to implement my own copy method to workaround the bug in unity. I started with a first try and hope its already fine enough now, but can be that i need to replace more unity core systems there.
Afterwards i tired to implement a fallback for the unity exception to get rid of it, but everything failed. In the end i implemented a custom Instanciate Method for the entities, to work around the annoying unity behavior...
I came to another bug in the loading mechanism and spend the half night debugging. It just appears in the compiled version what was very strange and time consuming... In the end it looks like it was the async loading mechanism, that caused problems randomly by removing my childs again. Seems in Unity 6 they changed the mechanism how to update the child components and these systems updating while rendering a frame while loading...
I checked some reports from players, but they look all very strange, that it could just be bugs of the new unity. Due to there was no help in the forum at all for any of the problems i reported the last 2 months, i tried to downgrade unity back to the latest stable version, but there the other bug what many other games had still appears. I couldn't compile due to the compiler can't find a resource created by the compile process. This bug is already over 1 year reported with hundrets of forum entries, but still noone of unity cares... So back to the newst version.
I also had trouble with the internet here in china, my server wasn't reachable the whole day, so i was very limited in what i could do...
Today i did the functionality of the Slots and Uniform setup. It was pretty easy and seems working fine. The Slots now have a changable value, so the player can't change a slot defined by the person setup. I'm not sure what i should do when i change back to "none", for now, i will keep the old setup, but make it changable.
I started to make the Persons group directly editable in the person selection panel. To make it simpler for new players, i hide the schedule when there is no item added yet. The Groups now also just shown the Shift and Group, if they have some, so its just shown when the player is so far in the game, that he use it.

Than i added it also to the Supply Popup, so you can directly setup the person before he arrived. I plan also to give him full forced slots, so in case of emergencies, you can send some with already applied oxygen masks and tools to repair things in the ship.

After that i started with the last big ui change related to the new groups. The Person Overview Area has been structured with the new groups. Before it was not good usable when having a larger amount of persons. Now they are structured in the Groups, and you can see what the persons are doing in what shift.

In the end of the day, i Polished more the ui and added the groups also to the Person Popups.
Today more work on the Person Group Ui, i improved the hover/drag effects of the persons, showing the Area Names in the drop targets, improved the removal of the items and polished the add and remove buttons. The Popup is now also fully translatable and have names and descriptions for the work priorities.

Afterwards i concentrated on the other ui elements, first for the one in the person selection panel. I refactored the schedule element to make it usable also as a smaller not editable version. It was a bit tricky due to i implemented it as a fixed width at the first implementation. Than i also added a "Current" marker to the schedule and highlight the current item (related to the gametime).

In the morning i polished finalized the polish of the new Schedule planner. It get into detail, so when 2 schedules are together, there is a "Drag Both" option where you can move the slider back and forth. Also some last ui errors i found were fixed like wrong aligned hour bars. There is also now a separate layout for small items, where the type icon shrinks to the wanted size. Also i prevent overlapping when dragging them, so they will not shoot over instead stay at a minimum/maximum size. At last, there is now also the possibility to keep ctrl pressed to copy a complete one, e.g. when moving something to other shifts it keeps the duration. All in all, many small things, but ending up in a nice usability.
![]()
After that i started with the last element of the new UI. The assigned persons with the change feature per dragDrop. Today i just did the basic functionality, tomorrow i plan to polish that with more hover effects and other smaller fixes. Than i will start with other UI parts. One would be grouping the PersonOverview by the assignments, or adding that workschedule to the person selection element and details popup. I hope that i can also start with the easy functionality tomorrow and doing the advanced functionality the day after.

After the weekend i worked on the new Person Groups. The model was done fast, and the basics of the UI doing also a good progress. Now i'm at the schedule creation. I'm not so used to do this drag drop things yet, so this take a bit more time. Also there are many special cases i have to deal with when creating it, to make the user experience good, like cutting the other items when something is overlapping, splitting it if dropped in the middle or merging two following ones.
Afterwards i had do teal with many Unity bugs, starting from crashes all the time without any visible reason followed by wrong render positions of the dragged elements and much more. All looked like a big mess, even the debugging tools from unity showed the element at a different location, than the renderengine rendered it, up to not rendering the rest of the ui while dragging... Very stressful, so it looks like its not allowed to do anything with the dragged item, or unity completely gets into chaos...

Today i planned the next big feature: Person Groups. The idea is to make the handling of many persons easier and allow also the better usage of the ship sections. It's also a preparation for more social things, so the persons will have more free time and time to eat together.
So there will be many aspects to implement. First there is the Groups like Engineer or Assistent. There you can define a Slot setup, to e.g. enforce all persons having a Toolbelt, e.g. for engineers. Than you can define additional priority modifieres for the different activity types like construction, maintenance or working on special machines. Each group can have multiple Subgroups and Shifts you will be able to create.
A Subgroup can be used for different sections in the ship. So e.g. you can assign group1 to only work in one area of the ship, near their residence.
A Shift will have a daily schedule, where you can define strict plans for working, freetime, eating or sleeping.
So a person is always defined as part of a Group with Subgroup and Shift, Engineer-A1 for a Group Engineer with shift A in Subgroup 1.
I already have a plan for the implementation, the most effort will be the UI but the balancing of the tasks will be also a challange.
In the morning i played more with the custom colors and implemented another approach, that makes it easier and nicer to colorize things. Now its up to 3 colors (and i can push it easy to 4) that can be customized and way more details can be added. The blending has also been improved and is now more flexible.
Than i implemented the way to let the player change the colors. I decided to make it easy and just adding some color pickers to the selectin panel.

I fixed other bugs i found for at special situations of the new features i added recently and fixed them. The interior placement also tries out more rotations now for some other special cases.
Another special case was when a person got unconcious or going to emergency sleep in a room, that is dismantled. There was a logic, that they try to leave those rooms, but if they can't, they stay there while the dismantle is finishing and end up in space. To fix that, i added another step to the Construction Process, waiting for them. It's a separate System, counting the persons in a room, that might be used again when i add "lights sensors" for the night.
After that i started with my basic improvements of the persons. First i worked on smaller things like the timewarp panels of the current activity and the problem overlay was not centered when the person e.g. slept. The next bigger thing was to make interior items have changable colors like the rooms. The first usage would be setting the bed-color to the uniform color of the assigned residence.

I also added a Worker and Customer icon to the Activity Overlay, to make it easier to see if its used.
![]()
Than i worked a bit on some I18N and Icon things for the recipes, but skipped that for now, due to low priority and a bit complicated to find a good solution. I also worked on a problem in the late game, when players have created a cycle of rooms, it was not possible to dismantle them, due to all have still neighbors. For that i had to implement a new algorithm to figure out to check if all rooms are still connected after the dismantle.
Another feature i found very useful was commented by some playtesters. When want to move a whole room, it takes too long to dismantle all the interior items inside of the room. To make this easier, the dismantle button now shows a popup to do it for you. It also works if a single room is selected and pressing the delete button.

In the morning i worked on the last reports and logs of the current Reports, improving the logging. Everything were just minor things happening that are already autocorrected by the system well, so they were not recognisable during the game. Afterwards i had an idea to use the opacity, to indicate what state the crafting is in. I hope this prevents further missunderstandings.
Today i just created one new feature. The Items with a wall are now automaticaly rotate towards the nearest wall. They also snap towards the wall. I can setup the distance, what is set to 1 tile now otherwise it might look too sticky. The main reason was that close to all new players first try to set the panel box outside the ship. Another reason is, that its now easier to drop them! Tomorrow i will adapt the tutorials to it and do another patch release.
In the morning i was able to finish all bugs and todos i created in my last playtest, e.g. not shown problem icons in constructions, wrong path overlays for under construction items, not shown paths for construction storages.
I also get through my todo list and identified the next tasks for the next days. Besides some smaller improvements, i plan to do a better interior planning, e.g. items rotating automaticaly to the walls. I also should rethink the ui overlays vs the problem overlays and other overlays for construction, maybe i find a good way to align them all to use ui overlays too. It's a bigger list of around 80 items, but most are very small ones i think. In that time i will create a more detailed game design for the person improvement. You are all welcome to give ideas
The next bigger topic i plan to do are the Person Improvements. There i want to create a game design while doing these small things. You are all welcome to throw ideas for that to me, maybe we plan a community brainstorming event or so the next days. Here a short summary what shoud be achieved:
The player has a lot to do when increasing the population the first time to the 5 persons. Crafting Life support items and prepare crew quarters. Than there is a lack of things to do in the game, till starting to build up bigger production and doing moon missions and preparing for the launch. This is the time where i planned for the player to increase the persons quality of life and make them happy, adding social things, more thoughts, adding environmental things like plants or paintings, have the empty room space have an effect, adding specific hobbies, traits, working schedules, shifts and more. Than the production part continues with maybe 10-20 crew members. I also plan a day/night schedule (visual part is already done) to make the days more visual.
At the end of the day, i worked on something i saw in other games. Its about placing the interior items, it always felt a bit wrong, due to i just used the cursor to find the tile and than just dropping the items 0/0 position to that tile. For larger items it was not positioned well, due to you place it between 2 tiles, so its jumping back and forth. The new implementation respects the size of the item now and calculate where the player realy wanted to place it.
At my last playtest i found it a bit annoying how many clicks were needed to setup the storages, so i tried out a new way. The idea is to move the configuration part to the ui itself. So at storages, there are buttons to create the automatic tasks if it hasn't one already. Than i moved the automatic task to the fill line like in the other interior items. This also brings consistency. The downside of that is that it looks very unstructured. To fix that, i added a orderby automatic type, so it looks more sorted, even if its changing the position when changing the setup, but the better layout makes it worth it.

Another confusing thing in many playtests was that the player selected the door of an unfinished room and wondered about the status. To explain that, i replaced the "Wait for room finish" status to a hint text.

I also saw new players placing the new rooms in the wrong direction, due to the auto-rotate just worked for doors. Now i added also the rotation towards rooms as second priority. It also shows now the new Doors or Door positions and shows a warning, when the player want to create a new room without any connection to prevent that in the future. Instead of asking to add the doors, the doors will directly created. Due to they are anyway shown in the preview, its perfect fitting in the new workflow.

I added an configure button for the Resource Panel. With that its now possible to customize what is shown there. It was a bit confusing what was shown, depending on the situation, it's different what you need to see, so now its customizable. Its also stored in the savegame.

Besides that i added the KeyBindings to the Options. For now, they are all fixed so its more like an overview, due to the compley and not good customizable unity system i plan to build somewhen my own one, there were no requests or complains about the key bindings yet, so it looks fine so far.

Another problem of some players were, that they added connections by accident of not finished storages. They wanted to just configure the construction storage, but created the preconfigure task instead. Even if there is a small "construction" icon to indicate, its not clear enough. So i added a subgroup to make this more clear.

I also polished the timewarp for the construction. It's now estimating the resource arrival better, so also partial arrivals are nice visible and not suddenly stopping when its full. It also didn't stop now when the resources are loaded and continues the timewarp till the item is fully finished. When noone can work there, there is also a maximum speed set to not overshoot, when e.g. none of the crew can construct it or is busy.
To have a better changelog, to be also more reliable and faster, i added also an offline support for the changelogs. For each version a resource file has been created and will be automaticaly in the build pipeline. This will be used by a new UI Element showing the data. The one in the Starting Scene has been improved, so its now showing always the full changes instead of just the version numbers. It was a bit tricky to make this performant, due to the hundrets of versions already out there, but it worked in the end. I also updated the style adding tags and a date to it. Due to a nice script and my server that was already used to store the changelogs, i created all the historic old changelogs from the start of the development.
After that i added the "Whats new" Popup when the game is started with a different version, showing all the changes (using the same elements).
I worked more on the smaller issues i found like closing popups with rightclick too, or that the construction sites had no icons in the tasks. I also added some Loading tips like in most of the games. Even if the game starts very fast, in late game the loading can take several seconds, so it might be useful for some players.
The last days i didn't had much time to do much, but there was a good playtest with the new Tutorial. It looks it helped understanding more things and prepare more for the game. As usual i found many things to update, what i start to do today, like separating better the item boxes from the items by adding a "Box" text behind and some other things.
After fixing and releasing a new version i found that some generated audio files sounds different than before. It seems google updated its text to speech to a higher quality, so i needed to find a solution for that. The rest of the day i spend checking the reports from the last weeks were i was away and fixed several smaller issues.
Today i finished everything of the new tutorial and did a small release. I worked on the new Steam Login Button today. The reason for this was a streamer trying to play the game, but struggling with the username. The new system now can check for the username for a given steam id. After that functionality, it was easy to just adding a "Login with Steam" button, that checks the database for the steamid and set the username. If it didn't exist, it will register the user automatically using the steam name of the player.

I also worked on the Steam Demo and prepared the depos, images and build setup.
In my vaccation the last days i didn't do much, but i was able to do a new Tutorial. Its structured different than the old one. This makes it possible, that the player can missconfigure stuff as much as he wants, without implications on the further game. Its also easier to setup specific ships for the different tutorials, to explain it easier. One example of that the workbench had to be placed in the crew room, to show the transport features.
Instead of being inside of a regular game, there is now a tutorial menu where different tutorial scenes can be loaded.

Inside it looks pretty similar than the old tutorial. The Tutorial window has been enhanced, so you can see the other tutorials too, so its easier to see the progress.

I added another place for the tooltips, sticking on the bottom center of the screen, so they not block the player. The main usage of them will be the new TryOut steps i added to several places. The player can experiment himself if he wants with the shown things to learn and remember things better.

When finished a tutorial, it shows a new tutorial finished window, where the player can choose between do it again. When finishing the basic tutorials, there is also a "Start game" button for players who like to tryout things by themself.

I didn't finish all tutorials i wanted to do, the more advanced ones are not done yet, but i will give it a shot now to try it out now.
Today i finished the big update of the new container user algorithms. It took some time to fix the last issues, tests and adding a migration to the old savegames. Especialy with some special cases with the greenhouses got me a bit in trouble.
The next 2 weeks i will be in vaccation. I will just have my laptop so everything will be slowly. I plan to do the new tutorial and maybe some 3d models.
Today i worked on the update of the container users. A container user is e.g. the generator for the ship energy. There is a complex algorithm updating them when something happens, e.g. when a new consumer is added. Now there is a problem updating the producers when they change the priority, its not reflecting instant. To make this possible, i had to completely refactor the logic behind, starting with the items setting their real maximum, so the algorithm can use that to turn the right ones directly on.
After that was done, the more complicated algorithm part started. In the end of a long day, it looks working, but i have to check tomorrow and doing all the tests, its such a big change, i expect several issues to solve and doing the migration tomorrow. In general i think it will improve the performance of another big simulation performance issue i found last month in the playtests.
Yesterday the first streamer tried out the game. Big thanks to Szenario for that chanche .
Similar than the other testers it was a slow start to learn the mechanics, so i decided to do a new tutorial approach with separated scenes, just for the tutorials instead over the next weeks.
Besides that, a lot of things me and Silver could discover and i improved several UI things and worked on the log files to find and fix more problems like another special pathfinding and the priority filling up the slots were some bigger things, but he was able to find solutions for that.
To make it more obvious what the persons are doing after the current task, i now added the next tasks to the current Tasks in the Person panel. I had the basic already a longer time but after the big refactorings the last days, now it seems stable enough. It was a bit tricky to deal with several special cases i have added to improve the performance, but i think it will work now.
Besides that, i also added the new Metric Calculation to the UI. Each calculation part consist of 2 values: A multiplyer and an additional value, added after all the multiplyers. Its now also possible to see why the person don't wan't to go to work, but i have to add a "Player task queue" to make this more obvious. Then i can show also these rejected tasks, like wanted to shower but cound't find one.

Today just watched another playtest and smaller fixes of some special cases of the pathfinding. I also finished the german translation, due to soon a german streamer want to try out and stream the game
After the Pathfinding improvement there were big lags in the game, due to tons of new Path calculations. It just happened the first time after loading, when the caches get filled up the first time. To fix that i did several improvements. First of all, it detects connected storages and precalculate them. This improves it, due to it always runs with burst (not like the simulation) and can be done in paralell on all available CPU cores. In addition to that, i found that not needed paths were calculated for fill and empty dummy tasks, that are not realy used. The last improvement was for the metric calculations, there its now doing the distance calculation only when the task fulfills all other requirements. Doing this it improved the first calculation dramaticaly in my editor.
I also did a small playtest and found just small things to improve now, its getting good and feels better and better.
I'm a bit sick today, so just slow progress these days. I'm working slowly on the new metric calculation and have now also the more complicated things migrated. I start to have both calculations in paralell, to check that both return the same value to slowly migrate that important part of the game.
I migrated more and more and tried to align the code of the different Activities. All in all a lot of work and big changes, the automated tests helped a lot again. Without them i would have no chanche to do that!
While refactoring, i found another bottleneck in the code. To calculate the best metric it crawled the task list very often. I could reduce that alot and it looks like it boosted the performance 50% or more up! So on the big ship without burst it was around 3h/s in the editor.
Today i worked on the issues found on yesterday evenings playtest. Most of them small improvements, nothing but, but in total over 13 things to make the game more accessable for new players.
Another hint from the testers are usualy, that its too much items for the new players, so i added another filter option for the interior item build menu. Its now by default at "only relevant", that will show only craftable, orderable or things in boxes, to reduce that amount. it can still be switched to everything to get an overview.

After 2 days vaccation, i fixed some bugs with the new pathfinding, related to several small things, like reusing the same cache for the way back, or finding a way to the door in the next room. I also continued refactoring the simulation part, to improve the task metrics next, what are responsible what tasks the persons are picking. There is a performance bottleneck i hope i can improve a lot with the new architecture there.
I finalised the new Pathfinding, so the path between the rooms is now also nicer, took a longer time to refactor and analyse many things due to the new special cases.
The pathfinding has been completely restructured. Now we have more caches for the different things, and the algorithm not relates to rooms anymore. Its precalculating now the interior fields for all items and calculates the distances from all interior items to doors and between the doors when changing something. The Path algorithm than uses that to find the best route, so the issue with long hallways and strange path findings should be fixed. I was also able to simplify the code by replacing the old cache with a new version of it.

The algorithm i created just used a fixed maximum of rooms in a path. To make this more flexible for huge shups, i changed it a gain to a more dynamic approach, keeping all functionality. It might be also even faster now, due to the path data has less data included and the path is just calculated when its needed.

This morning i fixed the last things for the new Transport Mechanics, and also improved the Problems. They are now more clear and aligned between the tasks of both storages.
Afterwards i worked more on the memory leak. In the tests there is still a lot of garbage, killing the editor.
There were still trouble in finding out why a crafting was not started when the containers are close to be full. After some tryouts, the final solution now to just show 1t instead of 1t/1t if its the same text. If the unit is different, it will add a percentage value, like "1t (99.99%)" to indicate, that its close to be full.

Than i got to another problem with the storages. The new restrictions make some kind of connections impossible, so i thought a longer time about a better solution and started to implement it.
Over the Weekend many testers played the game, so i was busy checking the reprots and fixing issues they reproted. A lot of things have been improved and i also did a playtest, finding more things to do, but they get smaller and not so noticable for he normal players.
I started with a dragDrop support and implemented a basic drag dorp functionality. It was easier than i thought, even multiline seems working fine so far.
It took a bit time to make it smooth and support other features like having a garbage container to drop it, or to change the current recipe when drop it there. Also some special cases like when the queue changed while dragging needed some adjustments.
The Clone feature cloned already several things from the original one. To make it more obvious what is done and having the option to just copy a type of an interior item, i added a small panel on the top, showing the settings.

In the morning i finally found a solution for the too high tooltips. The idea is now to let it be width or height as the screen and calculate an offset to the position value. I also adapted the automatic detection, so its putting big tooltips to the left side, to prevent streatching them.

After that i started the next bigger topic, that is already open for a longer time. Its about the Task Priorities were not easy to understand. To fix that, i split them up to the different priorities to make it also better controllable. In the old verison, there were just 2 priorities, one for the construction and one for the rest. Now the rest is split up in Transport, Maintenance, Item and Work. Item is a new one, mentioning the priority in electric control (but also works for e.g. co2). Work is also a new one, that should also fix the problem of some players forcing the persons to work in some bad mood scenarios.

Players still have trouble to setup the toolbelt slot on the start of the game. Also experienced players forget this, so i added a small notice to the player when he didn't do that after 1h of gametime.
I found that too many players fail very often at the start. To make the start smoother, i added an "Easy" Mode to the game scene. It should help new players discover the mechanics easier. Besides the regular setups i already have implemented like more money, less cost, more supply from earth, i also added the possibility to change the fire chance, metabolism and ships heatup value. I also used very low values for that in the sandbox mode.
#
To make the testing faster, i decided to finish the implementation of the Quicksave. Its a separate system next to the autosave, showing the save progress same as the autosave. With F9 you can create a save, that will be shown in the regular saves. With F10 it will show a confirm popup (with enter as shortcut for confirm) to load it again.

The last bigger task for today was to add a check to the tasks, so cycles in the setup will not so easy to create for the player. It impacts the automatic tasks, with corelated storage connections. Otherwise they will e.g. push resources out to the other storage, find there something to import it again.

In the morning i had the situation with the memory leak occuring without a unity crash. I used this rare chanche to check the problem and found several savegame and gradient pictures in the memory. I cleaned this up, hope it helps against the crashes.
I also played a bit with the Steam Broadcast feature and was able to set everything up.

Than i finalized the First part of the ResourceOverview Popup. I decided to do the more complicated parts later, i think its already very useful as it is now.

I also reduced the complexity of the ResourceType tooltip, due to these infos are now in

The issue with tinting the screen in red or green is also solved. The problem was the curved ship and the distance calculation to the camera. If the element is close to orthogonal to the camera, the distance to the camera is so small, that the element was scaled enormous big, so the camera saw just maybe 1px of the original picture scaled to the complete screen. I added a minimum distance to prevent that.
Today i fixed several things i found from yesterdays new weekly tester. Slightly improved the tutorial and some ui issues. Than i started a bigger topic, a new ResourceType Overview Popup. Its an advanced tooltip and should also contain all elements, that are involved with that resourceType. The Target is to show craftings, Supply from earth, Persons and shipsections all in one view. It should give a complete overview about the resoruce. Here a first view of the work in progress

Due to there is now a lot to configure in the not finished items, i make it more clear by changing the border color due to its construction state.

While working on the bigger bug related to the connections of the clone rooms, i came to the conclusion, that there are now too many specialcases for the construction resources. They are stored also in the interiorItem, what makes it difficult to presetup things, like what is needed for the blueprints. All had to be done in special setting data, that are applied when the item finished construction. At the clone, it can still be the case, that the target is not finished, so everything is a big mess. To make it easier, i decided to extract the construction storage to a separate child of the interioritem. It will take some time to refactor everything related to it.
So on the screenshot you can see, that now storage and preconfigure is available via the pi menu. the stored Resources part below is just accessable when both items are finished.

In the morning i worked on the playtest report i created from yesterday, creating tickets from it and fixing already most of them. Besides one problem with some missing update, everything way minor priority, so i think its on a good way to go. While trying to write the next release notes, i found that the changelog list is too long. Also i want to do better minor releases including notes in steam. To do so, i created a small tool, to create me that in different formats. The infos are all comming from the git messages and tags. A bit sad, that steam did not support automated patch notes.
I also did a code coverage run after over a year now. Result is, that the code got around 20% more lines, grown now to 160.000 LOC.
Besides that i fixed around 20 tickets today, and prepared for a bigger release tomorrow.
Today my main task was to do a camera update since a very long time. I got some feedback, that it's missing a "pan with mouse" feature. It was a bit tricky, but it worked in the end, so now with keeping the middle mouse button pressed, you can pan the camera.
After adapting the other usecases of the middle mouse button like rotating items or keeping tooltips open, it feels very nice to me and i'm very happy about that feedback!
The other time i spend watching a playtest. The new tutorial was close to be as i expected, just need to readd the drop of the dockingport and it should be fine. Can't wait for another tester to see if it was the result of the tutorial or just luck.
Again i'm on the tutorial, can't count how often i changed that now... This time the focus is more clear on the crafting. This is used than to show the different transport mechanisms to fill these up. Ill show 3 different ways to do so, to get the player some possibilities and teach him the pi menu interactions that way. It's also focusing more on the important parts and removed some details, the user can figure out by itself and via the ingame help.
Besides that i have done 10 other smaller improvements from the last weeks playtesting.

I completely refactored the customer and worker slots in the morning, similar as the mission slots yesterday. Than i worked on more ui to improve the setup of the storages. there are now bigger buttons and a hint to the modifier keys. Also a max button behind it, due to this is the common usecase to use one storage for one resource type. I also added the lock icon there, to make it more obvious, that this is the value that is shown in the graph.

To make configuration faster, i also changed the Add buttons popup. It has now also a reserved amount and directly the option to enable the fill or empty task.

Today some smaller bugfixes and improved the backend for showing shorter reports on discord. The reports changed a lot since i developed this part, so now all parts are up to date and its easier to filter them to be ready for a bigger playerbase.
While adding icons the the different types, i had the idea also to reuse the flags of the nationalities of the persons for the language chooser and added that quickly.

Besides that just some improvements of my editor, to work easier and some thoughts about a change of the tutorial, to make the start easier for new players.
In the evening i worked on a ui bug with the mission crew. The code for assigning the persons was very old, so i bring that to a new level using the new abilities of my task system. It took a bit time to catch everything there, but now they support everything what the tasks are doing and prevent bugs. One could be setting up Work Requirements for different slots, so it might be useful to have a pilot with a need of astronaut skills later.
Today i worked on the connection feature inside of blueprints. After creating some tests, i decided to refactor the api for it, to have an aligned transport api mechanism. It grown a lot due to different usecases that have to be alligned, to make it more reliable and easier to use.
With the tests if found also some bugs, related to the latest changes i fixed and created more automated tests.
After trying to solve a huge memory leak in unity i downgraded again to the older version. Than I could finished the mass calculations. The simulation take around 150ms in editor on the huge ship, the parallel burst job take 0.1ms in the editor, than using all your cpu cores in parallel another 0.2ms, so in theory it can run now every frame. I will also add the dirty mechanism, so its just updating whats needed to save more time. The old way took around
Today i worked the morning on validating the Dynamic created rooms, due to i found some issues. Now they just update if they need to. It has not much effect on the normal player, but its good when validating the game state in the editor, also for huge ships. It also checkes in the consistency check part for missing updates.
Than i worked on some reports, one said it was not clear what resource is missing. I fixed the bug and enhanced also the ui: The state got now more space than the other production line parts and there is a problem icon, when its not full, to indicate a problem. I think it looks also nicer than before.

In the evening i worked on the mass of the ship. i saw several wrong mass calculations and stript some down to the metabolism of the persons. Some small adjustments were already fine. The mass calculation is one of of the big simulation performance killers, taking several milliseconds. So i think its a good time to extract that from the system. I plan to do this async every few frames and on request by the simulation. The Overlays will also use it to simulate the changes and optimal values. It will take a bit time, but i think it worth it.
In the morning i worked on the Report screens. They are now aligned and using my new Rerport Api to generate it. There is now also a common component showing the data what is send, and everything is in nicer popups. The original reason to work on it was the crash reports. Recently i found where unity stores them and now also creating reports when detecting them.

Afterwards i go back to the ticket list. It was a bit annoying to search in a loaded savegame for the entities mentioned by errors or the player, so i created an easy Ctrl+F window searching by the names. Its also available for you!

I also did some smaller things like painting the cursor position on the reports screenshot or improving the edit icon of the cursor. In total one big thing and 10 small tickets, progressing but still a lot to go.
Today i finished the tests with the new processing mechanic with automated tests for it. I also created a cancel popup when garbage is produced, so the player know what he is doing.

Today i started with the big change of the Production, to add the garbage. First i created some basic tests, to make sure my initial refactoring worked. It took a bit time to create a nice reusable setup for further tests in the future. I also updated all the old Tests related to production.
Yesterday i worked a lot on the recipes, and i completely lost the overview while changing things back and forth. To prevent this in the future, i spend now a longer time to update the Unity Editor for the Recipes. Instead of 2 pages of the classical unity look its now everything in one table and updating correct when changing the values. The calculations to check if it makes sense from a gameplay perspective. It took a bit time, due to i had to convert many other components to the new Ui Elements. With further changes in the future, its ready to be put to the game itself and not restricted to unity anymore.

Than i started improving it to support the new mechanism i want to implement. Turns out with the new Editor its way more obvious where the problem is. After thinking a longer time for solutions, the only good and not so complicated option is a new garbage resource, that can just be thrown away. Later i will change that, so its more recyclable, but for now the only thing what you can do with it is to throw it away. It should just happen when canceling specific things by the player, like in smelting or hydroponics, that should not be the case so often.

Today i worked on another issue the play tester found with balancing. There is missing N2 and CO2 in the ship. I researched a bit, and it seems not a good way to get n2 from the moon. From other atmospheres of other bodies it might be easier later. So i created 3 kind of ores: Sand, Copper ore and Iron ore. For that i decided to create a separate model to separate it more from the others to show, that they are raw materials that need to be converted firstly. I refactored the creation part, so there is now a prefab for each of the kinds to make further updates and fixes easier.

I added them to the Smelting and Chemistry table, so they can both now convert the items. The problem was, that they create humidity and co2 to the air. When canceling the model, the resources had to go back, but the h2 should be partialy in the conversion, so i have to find a solution for that tomorrow.

While adding the new Resources, i found, that my Screenshot tool didn't support the resourceBoxes. Due to the latest change this iteration with the single resource items on the table, i was now able to automate that creation for the resources too. I also used the work on it to improve the lighting and defined special camera angles for each of them.
![]()
In the end of the day i came again to the broken meshes when setting the random offset of the stones too high. The shader just hides the pixels out of the area till now, but i had another idea that solves it. I now move the verticies in the vertex shader further away from the box, so i can hide the pixels far away from it instead. This brings now nicer resource box randomizations

This morning i realised, that the reports sometimes missing the savegame files, so i rechecked it and improved the logic there. It took too long time but now it looks much better, including a progress bar and faster response times.
Than i worked more on the reports from the tester and fixed several things like the that the persons filled things in random storages. The new logic have 2 different things. First the person priotize the target better, and if a task is stopped, they will first try to put the resources back in the source storage where they picked it from. I created some automated tests for that now.
There was also a bug where the connection priorities were wrong, due to at clone an interior item creates the task in the storage, not in the item. Also an automated test now.
My plan is to do more and more with the automated testing again, after a longer break. With the new Hot reload plugin for unity i can work with it way better than before. The latest performance improvements also helped with that.
Today more bugfixes, the weekly tester is still active and find realy a lot of smaller and bigger issues. Big thanks for that, it realy helps to push the game forward!
There were some problems with the transporting mechanism, where i created several automated tests now, to make sure these things keep working.
The last days i updated the complete simulation to the new entity approach, preparing to split up the logic in seperate Jobs. It was a big refactoring day, to bring everything to the next level.
Today was a bad day. I could reproduce an issue with the persons grabbing things to their slot, without any reason. It just happened in burst mode of the simulation. After debugging a while the logs didn't make sense and nothing seems reasonable. Something realy realy bad goes on there. The simulation is grown over ten thousands of lines of code, and i have the feeling, that i reached the maximum of the burst compiler, that he got troubles with addresses or something.
Due to the latest created big ships got troubles with the simulation, it's maybe time to do an other approach that is able to parallise more. The code has been structured so far, so maybe there is a chanche for that. So i worked the rest of the day in preparing the simulation for it.
Today i worked on all the reports of the last days, analysing problems and started with graphic and smaller other bugfixes.
While working on a performance problem, i realized, that the resource holders were much more expensive than needed, due to the ui is anyway not good visible when being further away. So i designed new holders and had also an idea to improve the storage view with the same approach.

I also make the Marker using an icon instead just the triangle, so now i added a reserved icon for it, to make it more clear what it is. The interaction of it is now also easier, on the upper part of the bar a single click is now enough to show it. Also the duplicated tooltip is fixed now.

While trying to analyse the problems of the tester, i needed to improve the performance for my editor. One thing was to do the JsonObject creation more async. The main Mechanism was already added to the Library, but it was not good to use, so i had to refactor the whole library to fulfill my needs.
I did a lot of optimizations today, so i can run the big ship from the tester now with 20fps in the editor. It should also boost up the compiled version!
I fixed serveral issues the last days. While debugging another endless simulation loop, i created 2 more debugging features to step better through the tasks and have a separate editor window with the resource container details with exact values.
Today more bugfixes, first the camera bug had some low level bugs in calculating the ship bounds. I created a new algorithm for that to prevent that.
Also the crafting part got several bugfixes and a better internal state handling.
Besides that i improved the UI when using batteries. It's now showing a more detailed state e.g. when batteries are full or partialy charging or being used.

After fixing more bugs and get through log files, i worked on the main task for today. The tester realised, that there is no way to create food, expect from garbage water. Thats a problem due to that is also needed for plastic. I studied a bit and it came to hydroponic cultures. With that its possible to create food without the recycled garbage water. Usualy there is also a need for more resources to the nutrition water like Kalium or small parts of iron and copper, but to make it simple i just added nitrogen to the cycle for now.
Above you can see the old one using prepared earth and below is the new hydroponic approach. It creates more humidity and needs more co2 from the air than the other one.

I also worked a longer time again on another Unity bug that was found by the tester. The Listviews not selecting the element correct, after rightclicking into it, they work as expected... It took a longer time and i give up finding the reason but adding a workaround for it, till Unity fixed it...
At the end of the day i improved the reporting again. The last playtester played several hours, creating a huge log file. To improve that i also send the last lines and prioritize the file uploads better.
After a week of holidays and birthdays, i come back working on the reports of the weekly tester. He played a very long time and build huge ships, producing a lot of log files, bug reports and improvements for me to work on.
Today i was able to fix some major bugs and did another release. The rest of the issues will take some days, its a lot of things to do!
I worked on some time measurements to have a better tracking for the simulation tasks, that took too long. It was a bit difficult to get around the unity restrictions, that inside of a burst job, there is no way to get the realtime from unity itself and other c# ways seemed all blocked by the restrictions, but in the end i found a way that its compiling with burst but still when called normal or in the editor its measure the time.
Than i continued with the log files, and was a bit lost how to track the errors down. Due to in burst are many things restricted, the log is not so useful. I also played again around with the tostring method. It looks like there is no way in burst to log the entities right, but i extended the support for other entities instead. I created now 3 burstable ToString methods with the EntityManager, own lookups and simulation code for the different usecases. But they still didn't work with burst. In the final testing i found a case where its working and was able to adapt the code so its now fully burst ready! I hope it helps to debug further bugs faster.
Thanks to the current weekly tester i got several things to fix, he played a long time so far so there are a lot of log message i have to check and lot of smaller and larger bugs to fix. All in all it looked pretty stable, no crashes, good performance, even on the larger ship in the later stage. So today and the next days are bugfixing days, before i got some days to vaccation, where i can't do so much.
In the weekend i just did some performance optimizations, related to some jobs. More expensive things are now just done, when the entities have been changed.
In the last playtest were an annoying bug, where the taskmanager got crazy and executed too many tasks causing the game to hang. I couldn't reproduce that if this is happening, please report.
After i tried to analyse the display bug from yesterday and reporting a file, i came to the idea just to switch to another font, till its solved.
I wanted to do some german translations for the weekly-tester (due do i have to do it anyway) and found several issues with the Translator Element in the Game that i fixed and possible improvements that i implemented, to work faster and give you all better tooling for translating the game!
It's a lot to translate, but with the tooling i created it went actually very fast so far and i'm close to done. The weekly tester discovered some bugs i will priotize tomorrow first.
I fixed a strange exception in the new button logic. It seems to be a bug in the unitys ui toolkit, happening when removing the element in a special timing. I also worked long in the night to fix the last known bugs to make a release with the new tutorial.
Today i didn't had so much time and the limited time today i spend in debugging a crashing bug, when exiting the game. It seems something in unity again. The analysing is still very annoying, due to the random appearing unity bug, that breaks the builds...
Due to i struggled a lot with that unity bug, i tried to update to Unity 2023, due to the bug is not in the known issues list. The first compiles were sucessful, looks like this annoying bug is not happening there anymore!!!
BUT i found a strange bug, that "fa" and "fs" in a text causes unity to overwrite 10cm to the left side, so its overwriting something the other text... no idea but i asked the unity developers for it. As a workaround, i will add spaces in between ^^. Its not fixing it for the editor or text areas, but at least for the visible text...
I worked the whole morning on the new tutorial. A mixture between improving the code for writing tutorials and creating the new ones.
In the middle i started the task to improve the crafting ui. The old one used my table, that has somehow a performance problem when used inside of a scroll panel, but i couldn't detect why unity starts a huge restyling calculation.. So the new Design is more box-like and includes only the more important info directly. The amounts can be viewed easy with a tooltip. It also highlights the current and queued items very obvious.

It get on my nerves, that i had to copy paste things over and over again, like "Left click to select". So i improved the Tutorial system. Instead of a automatic generated text-id it can also get now a overwritten id.
I also fixed another issue with the help system. If the UI Element to highlight was inside of a scroll panel, it was a bit confusing. now its highlighting to the scroll button instead.

I had the idea to change the starting ship again, by not having too many interior items at front, so the player has more freedom to start and can learn the mechanics easier.
Due to the CO2 and Temperature are not getting a problem in the first month, this is now the first crafting interior items for the player.
While doing that i figured out that the humidity increased too much, debugging that i found, that the shown ship volume is double the real one.
I also found some smaller issues on several places that i fixed in the morning.
Than i continued creating the ship and adapting the tutorials and the first primary objective. Needed to improve the ui for it, to have a nicer view.

I worked on the Resource Overview Layout panel, trying to structurize this more, to get more overview into it and make it more handy. Due to there are now more resources added in the last iteration, this seems needed to be done now.
First i categoriesed it, so same categories are above each other. I added also the labels, but it turns out, that it took too much space, and the grouping seems already fine enough. I tried 2 different layouts, one like the old one and one with just small icon and text. It looks the 2. one is way smaller, so i go for this one for now.

I also fixed another issue with the Battery calculations. It was very tricky, but i analysed a longer time and think i found a solution. With that i will release another minor version, to prepare for tomorrows weekly tester event.
Afterwards i tried to get more detailed statistic about the resources, to add that also to the tooltip.
I also released the game and fixed some automated tests that were failing, finding and fixing some issues with them too.

In the morning i worked on visualizing the state for the crafting items. I decided to change the color when some resources are missing. I hope this indicates easier that something is missing at the crafting and give a better feedback to the player. It had some special cases but in the end i think its a good result.

Than i also added the setup for the other Workbenches

While my playtests i found it not clear enough what the crafters are doing, so i decided to add a small box on the table, to be visible whats crafted.
To make this work i added for each resourceType a small version. Multiple systems are involved to detect the resourceType showing, switching it and replacing the resource model.
After that basic work was done, i added the main feature on top of it and added the resources to the workbench.

Today i worked on the things i found in the playtest yesterday. There is still the problem with the High humidity, so i improved the help for it, to hint more to the way to solve it and hint in the tutorial, not to order the second person already. I also balanced the Dehumidifier, so it can deal now with 2.9 persons. So even with 2 persons, it can reduce a significant amount of humidity from the air. Besides that it can hold now more water, to be filled later. Additionaly i added a multiplyer for the humidity effect, so e.g. the Eating Table gets as much damage as more electronic devices like machines. I hope all of this solve the issue with the high humidity for new players.
I also worked on a bug that get on my nerves already a longer time. In some animations the persons were stucking in the ground. The problem seems something on the import config of unity. After redoing that it worked fine. Still no idea what is the broken thing about it, but its working now.

I worked also on the original bug that goes even more on my nerves. The selection of the Persons in the bed are not working well. The reason for this is, that its always used a fixed selection box, that is not updated in the animation. To do this, there were several approaches, now while baking the animation, i also bake the bounding boxes of the person to a separate component and update the fixed one.

I did the same thing for the Photovoltaic Panels and the Ship Radiators, so they are not selected from space when not unfolded.
I fixed some bugs related to dead persons and did some other debugging improvements this morning.
I started the new iteration with a new feature to automate the batteries. They now switch between charge and uncharge automatically depending on the ships energy. To have a more usefull ui, i changed the ship overview panel for energy, to support the batteries.
While doing this i also updated the Energy overview, to show the battery state instead of the not useful ship energy value.

I spend the morning to try to speed up the compiling in unity, but failed due to too many dependencies, it would take too long time. I found some interesting tools to debug the compiling time, but i cound't find much..
In the evening i tried another hot reload plugin for unity. It works way better than the other one i had. Supporting way more special things i used from c#, still some edge cases i have, but in general it looks very good and will speed up development.
I finalized the new Workbenches and 3d printer and did a small playtest, to check the basic setup. After that i fixed some small things i found and did a release. I decided to do a major release, due to its already a longer time ago and its a complete new gameplay.
Today i created the chemistry workbench. I used the original workbench as a start and make a corner table. I added a smelting device with a design of a kitchen cooker and a simple centrifuge. With this its possible to create steel, plastic and filter garbage water. Including the setup in the game, modeling and painting it took around 4h.
The first sketch of the model

The painting with substance painter

How it looks now in the game engine

And here the current setup what i start with:

Today i worked on the models and painting of the new Resource types. I choose the box i already had for the plastic and sand. Due to these are small peaces, its the best way to store them in a spaceship. For the other raw materials i needed something else, i decided for a coil where copper and iron are rolled onto.

I also did the rest of the new Materials, all in a simple box or reusing the coil model.

I improved also the box icon turning it more and did all the other icons for the new ResourceTypes.
![]()
In the evening, i tried to make it even more clear how to get a resource, i added also orderable (by supplyship) and harvestable (by missions) to the ui.

I started the day with bugfixes and analysing some errors raised in the last players log and given feedback. Than i setup all interior items to use the new resources and setup the rest of the game. Can't wait to try it out to see the effect.
To get a better overview about the usages, i improved the resource type popup. It took a bit time to show the best data in a good form, hope its clear enough now.

Afterwards i worked on the new Productions. To have a faster start i created the first sketch of a new basic workbench. The plan is to build basic things there, its just a working plate with some tools on it, so everything takes longer to construct with that and not everything is possible.

I started the day with working through the things i saw in the playtest and player feedback yesterday. Some smaller fixes with the overlays and one savegame that was very far i found that the shuttles were not removed correctly. All in all only minor things left, so i think the game gets to a solid state again.
Also i saw people ordering too early too many crew members and getting in the humidity loop very fast. To prevent that i calculated the possible capacity and show a warning if the player adds too many persons.

Also other smaller but important things i added like the escape key now also removes the permanent overlay, or showing the problems of the interior items in the special event helps.
After another week suffering with another infection, i start to get better again. I started slowly with working on the new Resource Types and their crafting recipes, to have kind of a in game order. I worked on the editor and generators, so its easy to create new ones for experimenting with it. The plan for the next days are also set.

The new plan is now to add around 7 new Resources, related to crafting interior items. There will be some basic resources like copper or iron that can be harvested on the moon and electronic parts with 3 levels, needed for many interior items. Also more crafting tables and smaller versions for production machineries are planned, so its easier to start up in the game and have more progression. I hope to finish it in the next 2 weeks to bring out another major release after that long time sickness the last months...
After fixing some strange Bugs in my admin web ui, i refactored the crafting mechanism with a new CraftableAt, so its directly configured at the interior item or resourceType where and how long it takes to craft it. Everything is now prepared for the new resource types and i started to sketched some parts i want to add.
I worked on the concept to add more progression to the game. There are many ways to add this like research or story/progress based unlocking. These two i didn't choose for now, due to it seems not realistic to me for the basic things we need for a space station. The other way i explored a bit is like factorio and good company are doing it. Beside research, they limit the things to build also via resource types, so you need special resource types to build others. As an example, i will add kind of simple circuts and advanced circuts. The small dehumidifier could use the simple, the big one the advanced circuts.
The interaction of the workbench can be used also for the 3d printer and other new factory interior items to craft them. I don't plan to add the hundrets of resourceTypes of Good company, but i like the concept and will use it only for basic progression.
As a start of this concept, i will change the interior items to be made out of other resources. Till now it just creates recipes for the workbench. I implemented the basics and changed the Tools 3D printer and all interior item boxes to that new method.
In the new version there are some audios missing. After checking that i found that its related to a bug in unity, that they fixed for the new not released version.
While analysing a ui performance bug i found, that it just happens on scroll inside of unities scroll element, so i tlooks i optimized as much as i can without building my own scrollview.
The rest i worked on the findings to the playtest and needed to go to the hospital. Still many in my family sick, hope everyone recover fast to get back to the original working speed.
The main part today was to improve the capability to debug log messages. Unitys entity system logs just ids of them, causing a not readable log file. I found a way to get most of them now named properly, so its easier to track down the problems.
Beside that, i fixed some problems with the history system graphs and made another playtest, just found smaller improvements this time.
I finished the ui for my game sessions analytics and worked on a bug, that just appeared in the compiled version. That was very annoying again, due to unities compile bug is still not fixed (over a year now...). So it took several hours to analyse that, ending up in its a bug in unities UI Toolkit, what i can't fix for now.
I checked the logs of some reports and found some errors i can't debug very well, due to its logged inside of burst, where i hvae no stacktrace. I worked a bit on the Task executions, so its more dynamic changing the performance and also be able to turn burst off as much as possible for debugging.
While doing that i found a missplaced annotation, causing the burst mode was never on in the last releases. So the new change did not impact the performance, even increasing it in the regular mode. When its needed it will turn on burst mode. Due to that was a long time ago, it had dozens of small things, that were not supported with burst and each time i need to run the compiler for around 2 minutes... Takes time...
After it was finished, it worked pretty well, now its just using the burst if needed. Burst is exactly 10x faster than the non burst version and and can execute around 250-500 tasks per frame (10ms time)
The big traveling through china with my family is now over and the game development can continue. But directly at the first workingday, i got sick again, so i will start slowly. I just worked on some statistic stuff today, to analyse the games better.
I worked again on the new Transport mechanism. Seems there are situations i forgot to handle well. Also i want to add another feature, what makes it better handlable. Currently the connections are just one sided, so you can't see item->storage connections at the storage itself.
One sad news: In the next 2 weeks i will have no time to develop bigger things.
After finishing the last polishings, i experimented with another kind of overlay. The SelectedOverlay for Persons should show possible targets. It also shows problems of the interior items.

Today i created the new Overlay element as i planned yesterday. It's an add button and when an overlay is set, its showing the current one instead with a remove button.

The GaugeElements for the Ship and ShipSection got a click handler, so they toggle now the shown overlay to be also visible without the large tooltip shown there. While doing that, i refactored the GaugeElements to the new USS way of styling.
Than i worked on the Add Overlay popup and created several categories and search field, to find the needed overlay faster.

There is now also a Overlay for all Ship Section based things like air value and temperature, showing the users of all shipsections at once, coloring the ship section.

Than i also added the highlight to the ship section overlay, so its highlighting the rooms of each section with the corresponding color.

I also did some last polishings for most of the overlays, like adding a highlight for fire overlay or specific colors for the air values. Also you can press "O" to make a temporary overlay permanent, so its also possible for special task overlays to keep it.
I was able to fix the too early darkness achievement and some bugs in the overlay, due to the many changes the last time.
I also improved the overlay for the Container Users. Thats e.g. to see where the power is used.

Still something to do to improve the overlays, to make them better usable, but this i will do tomorrow.
Than we got the first weekly-testers. Like usual i found several things to improve while watching and fixed already some blocking bugs.
In the evening i also worked more on the overlays. First i added a path for the persons, showing now e.g. where the maintain person is moving to the item. Not sure if its that useful, but its working fine now. After that i tried to structure the current useful overlays and create a concept for a new UI i want to create tomorrow. Maybe it's a better way to visualize it. It might also include some kind of Legend for them if needed.

After fixing some last things with the transports, i improved the overlay for the Resource Holders, so items or persons that uses the selected resourcetype. It shows storages in yellow, producers in green and consumers in red. Its also adapted to the new storage concept, so it shows above the space including free space and how many are reserved. For Producers and consumers it also shows it above in the box-layout, so its more clear how much is located in the items itself. To show also the possible capacity, it shows a bar related to the maximum production or consumption of the activity.

Today i added the new Tutorial for the Storage management. It shows how to use reservation, interior item connections and automatic connections.
The rest of the day i spend time for refactoring. This time i removed the old roomtype completely from everywhere.
Today a final refactoring about the Priorities. The code got way nicer to read and it looks now more error resistent.
I thought about the latest changes and found another thing that might be good. The normal interior items can now stop the automatic tasks, so the players tasks can be the only possible ones, to prevent moving resources to the wrong locations. To make it more clear where the item search for targets, i added a room icon to the pick icon.
![]()
Another bigger problem was to make it into the blueprints and to the clone feature. Related to that, it's also removed when the container is removed, so e.g. at the crafting, it got very annoying, due to the setup is lost after each craft.
The mapping of the blueprint names is a bit tricky, so i decided to just remove the not added references.
Today i finished the last part of the new Transport. It's now possible to setup the storages while constructing them.
Today i dealed with the last special cases of the new Transport Mechanism, like removing the connections to other entities, when the container has been removed. Its now also working for Under Construction Items and Rooms (similar as interior items, it has to be setup at the construction site). Also to move resources from one construction side to another is now possible.
I had a nice idea to make it more clear adding the automatic tasks, there is now a "automate" button behind the storage items, showing many options. I also moved the reserved amount to that automate menu and added a marker to the bar instead. Its also changable via dragdrop that marker now.

I also dealed with more special cases due to the change, so its possible to keep a container with max 0 units, when there are still connections.
I worked more on the player Transport connections and its way more complicated than i thought. One bigger thing was to improve the UI for the Storages. Its now showing the added tasks below the Resources. Also showing the Automatic tasks, to make it more clear whats happening. They will have a pick icon, to indicate that.

In the morning i started improving the Create Transport Task popup. Adding the From and To entity and showing some details to it.

Than i added support for the other interior items. Due to the task have to know the state of the interior item container its restricted to add FROM the interior item to the storage. Otherwise the person will do it for each gramm produced e.g. in the generator and walking all the time.
I started to check for bugs from older versions. One main Painpoint in many playtests were the private rooms. Till now the rooms get automaticaly private if a resident is assigned to it. This also blocks non residents from using e.g. the eating table in the room, letting them die. The players didn't get that concept, so i decided to change it, so the player have to set a room separate as a private room. Till now there is no need for it, maybe later persons require their "own" private room.

I also finished the news article about the last update:
https://store.steampowered.com/news/app/1638030/view/3993070504830812676
After that i start thinking about the transport mechanism. It would be very useful to setup hard connections between storages, besides the auto configuration. As an UI, i will use the PiMenu. So rightclick on a target while having a storage selected will show create connection items there. I started to do that today, but i guess i also need the day tomorrow for the fine tuning. I could finish the basic part where the person is doing the created task. Here the UI for it.

After a longer weekend due to a family incedent, i started to fix the tests. There were some small but hard to debug bugs i fixed. Than i thought about solutions for the gamedesign problems, like storage connections and private rooms.
I tried an release but got several release specific errors, that took a longer time to fix..
I could finish the release, its available on the latest stage branch for now. The next days i will promote it to the default branch.
I also finalized the article for the 2023 summary.
https://store.steampowered.com/news/app/1638030/view/3993070504830800555
I worked more on the Achievements today. Adding more Rules like checking the Ship data or restrict by GameTime. I also make the Primary Objectives to Achievements, also causing some special UI handling. I also added other polishings like a progress bar for the total achievements reached and a hint why they are not counting (e.g. due to cheats are enabled, or started a sandbox game). I could finish the first bunch of achievements with the logic behind. Its now 18 Achievements.

First of all, sry for the long queitness, but we got another decease. But happy to year!
After that long pause, i refactored the Rules system, so its easier to extend and more performant for many rules. Its now completely jobified and runs in paralell to the rest of the game. Due to there will be many achievements, this should be valuable.
There is now also a "Close To" feature for the Achievements, so they will show their PlayerTask when they are close to be finished. The main usage for now is for the starting Crafting task, to lead the player to do that. To make this work, i created a global statistic system to keep track of that data inside of a game.
I also added the Achievement Popup to the Mainmenu, and storing the state in the config. Somewhen i plan to add it to the server, so its updating each login and can't be changed so easy.

I also added categories and colored them. The background is now always at the achievement, so its easier visible, that the achievement is meant everywhere in the ui. The generator is also adapted and shows e.g. this.
