I haven't had much time to update myself on the state of ksaffairs, but the linked video should give you an idea.

Features implemented since my last post, off the top of my head, includes (but aren't limited to):

• Craft building
• Collisions
• Docking
• modular BOOSTERS!
• Official linux builds
• Improved smoke/exhaust plumes

As before, the game is available for free at the official site. It is funded partially by donations, including from yours truly, in an effort towards making the game available to everyone and anyone. Any cent contributed to help this business model succeed is greatly appreciated by anyone involved.

Disclaimer: I am not affiliated with Rocketwerkz or KSA, but i can forward any feedback or issues people may have.

The same definitely cannot be said for the sequel

From Dean Hall on Discord:

Apologies it has taken this long, but we are now trialing linux build deployments. These builds are deployed untested. I have changed <#1406840455093682258> to now split out preparing the builds and deploying them. The windows build will now refuse to deploy a build that fails digital signature. Both builds will now indicate if they have successfully be deployed or not. The master server MAY indicate an incorrect build for linux, if linux fails to deploy. This will be changed soon when I can update that side of the deployment process.

You can download the trial builds for linux directly at:
https://ksa-linux.ahwoo.com/[](https://ksa-linux.ahwoo.com/)

Please consider contributing
It will increase our costs significantly to host this separate linux deployment. We are already spending x10 as much as we get in contributions - so it would make a great deal of help if folks who find the linux deployment useful consider contributing. If you do contribute - please do note in the contribution message if you can that it is FOR the linux deployments. I will use this data to help push that we should continue to integrate this going forward.

Report Linux issues
Discuss on the forums and in <#1438972207433912474>. We will try and be more active on the forums as, due to 'recent stuff' on discord, we understand this is not a perfect place for everyone. So feel free to post on the forums as well.

Official announcement:

Pre-Alpha Public Release We have now moved from a closed pre-alpha to a public one. The build is now available for download from https://ksa.ahwoo.com/. It is important to manage expectations, with the current build being certainly much more than a tech demo, but less than a game. This is expected as we have focused on establishing solid core fundamentals that will provide a safe scaffold to build all that we want to on top of this. It is this that you should see in the build.

https://ahwoo.com/posts/019a8091-b519-7fd6-b0e8-cda461864d8b

Official download link: https://ksa.ahwoo.com/ (This is also where contributions can be made for those who wish to do so)

Mirror (HTTP)
Mirror (Torrent)

I won't have time to test it myself for a while, so I'm happy to hear what you think and whether you manage to make it run on linux.

From Dean Hall on Discord:

tldr: No blockers identified, launch to proceed estimated in 19 hours

(Neidu's comments: timezones and sleep schedule means that this means roughly... uh... I have NFI when. Discord timestamps are weird. Very soon, that's for sure)

Sorry for the delay it has been a very busy time here at the studio. Our steering group went really well and while issues were identified, none are so far considered blockers to public availability of the launch. Some remaining work was identified but engineering was confident, so we gave them today to be sure. If this continues, that means at the end of this week. It is vital to note that it is ultimately our engineers who guide the decision on whether to release, there remains the chance that a significant blocker comes up and the public availability is delayed.

About the build
It is important now to discuss what the build is and set expectations. What you have been seeing in ⁠dev-updates updates and videos from content creators, is what you will be getting. We aren't hiding things, or holding back stuff for marketing purposes. The current build is more than a tech demo but less than a game, deliberate as we have focused on the foundational technology to deliver the game to the future. What you can do is play around with this foundation, primarily controlling the loaded rockets and seeing how the orbital physics and basic collisions work. Only Sol is simulated currently, and you can never leave its SOI - this means if you do get further out than Sol's SOI, you will see precision issues. A sample kitten in EVA is included. While basic modding is supported (and mods already exist!) the data structures are heavily in development so will change a lot, especially things like vehicles. All our internal debug tools are generally embedded in the game and are there for you to use (at your own risk) as well, such as part editing and such. The current system, Sol, is only for testing and will begin to be replaced with a custom designed one in the coming months.

We need you
The studio has found that our old ways of making and selling games just simply wasn't working, and that if we didn't try new ways we would end up as many other studios have. This project is the culmination of probably a decades worth of work building the studio. If you're here, then you're part of that journey now. We'll provide some more details of how all this will shake out later - in the meantime a 'save the date' for in 19 hours. When it does go loud, we need you as a spokesperson not a sales person. You know the project, you'll have the build - so you can make your own assessments about what the project has done, and where it is heading. Use that voice out there in the community with the project. If you can, and you feel the build meets expectations - contribute. Support content creators as much as you can as well. Developers, modders, content creators, and players will form what we hope is a "rebirth" of the spirit that Felipe bought with KSP. But in times like we are now it is so much harder, so we have nurture all parts of that.

A huge milestone
I am immensely proud and somewhat awed by what the team has pulled together. We have not only met, but exceeded even our stretch goals for what we wanted to have for the foundation of the project. This puts us in a very strong technical position to build up from here. More of this will be outlined when the public build goes live.

Known issues
We are tracking issues with older cards, especially AMD 5000 and 6000 series. Expect other weird edge case issues around GPUs and such. The technology we are using (BRUTAL) is brand new; and this is a huge ask for any engineering team to work through. Much of the work you would get for "free" with an engine is oriented to try solve a lot of these issues, and so we have to work through the various different platform and GPU idiosyncrasies. We also have not optimized our GPU handling, so cards that don't have a lot of VRAM may run into issues. The settings default to the highest level, when you boot the game.

A note from me, some random dude on the internet who is not affiliated with the project:

• Once the build becomes available to the public, I will of course provide the official download link. I also intend to mirror the download myself.
• While Linux isn't officially supported, various bits of pieces along the way has indicated that it is at least somewhat linux-friendly. I will make an effort into providing instructions for running the build on linux in case some hacking is required.
• This is not a game. The devs are even hesitant when it comes to calling it a "playtest". If you're expecting a game and are afraid of disappointed, I suggest you sit this one out. Earlier comms have indicated that this is more akin to a tech demo with the intent of gathering as much bug reports and constructive feedback as possible on the overall engine and architecture. If you're able to set aside any expectation of a fully fledget Kerbal Space Program replacement, and evaluate it for what it is, then go ahead and play around with it.

It was supposed to happen this week, but they decided to delay, maybe in one more week. Statement by Dean Hall:

Public Build and Contributions delayed again, review next week

The disappointment, especially for the Ahwoo team, is palpable. But its essentially the best reason for a delay: opportunity. We really want to get the Kitten pipeline into the first build and allow more time hardening startup crashes and input issues. We feel that the startup crashes and input issues can present some issues with achieving what we want in those first builds. Additionally, having the Kitten actually controllable in game in EVA, allows us to directly tackle one of the more challenging aspects of the project for people to wrap their heads around. The overall discussion from the team agrees the build is "fine" for an initial pre-alpha, but another week might well allow us to progress so much further.

I mentioned last week the project is somewhat a victim of its own success, and this is more evidence of that. We have the opportunity to push updated rendering and animation pipelines into the first build. In my opinion, the end result of this will do more than anything to convince people that we are making the right decisions with character compromises. I should stress this is not about getting the build perfect and there will be, obviously, a lot that is missing. It's going to be very much a pre-alpha, and short of flying around missing all that we want such as vehicle building. But we are going to give the build another week. That does not mean, for certain, the build comes out next week. We will, again, review for "go or no-go" on Tuesday our time. If the answer is "go", then it won't come out immediately, it would be later that week.

The currently remaining priority work includes:

• Kitten EVA in game
• Investigation of crash-on-boot (especially certain AMD cards)
• Fixing of input issues (selection of non-controlled vehicle orbits making burn node creation difficult/impossible for some vessels)
• Default vessel will be old "Rocket", with lunar aligned orbits

Secondary work may include:

• DearIMGUI upgrade (might fix a variety of viewport issues, or enable future fixes)
• Maybe some Jupiter cloud work (to be confirmed, unknown status)
• Situation selection on boot menu
• Additional optimization and bugfixing

Content creators got an early business ld for testing. While not confirmed, it is my expectation that the next test release will be public.

Saw this nugget in the git log today. I've seen similar in the past, so this is good news.

From Linx on Discord:

WIP preview of a 'heightmap decal' terrain modifier. This will give us the ability to create points of interest using hand-placed terrain detail in a desired location at a higher quality than the planet's base height texture. It's not 'painting' detail in (it's more like slapping on a sticker!) but it could be used to create some interesting locations - the example here shows off the dynamics of the modifier

First of all, I can't be bothered linking every source, so I'll just list what I remember hearing from official sources, mostly Rocketwerkz CEO Dean Hall. I will update this post as more information becomes available.

• Current status: Active development. Some semi-playable tests have been seen. According to the devs the first milestones have been reached: "universe simulator" and "yeeting around in the solar system". These are currently being refined. The next milestone is parts building (not to be confused with ship building) to allow for easy additions or modification of parts from which ships can later be built. The gitbot has reported many code changes related to parts.
• Platform(s): Depends on the popularity of the end result. The main development target is windows, but some of the devs are on other platforms, so porting is highly possible, just not a priority. It is worth noting that Rocketwerkz' other games run fine via wine/proton. They have internal Linux builds, so while Linux is not supported officially, it's not directly unsupported either.
• Engine: Developed in-house. The name is "Brutal framework". Highly flexible and purpose-built for KSA. Seems extremely efficient and optimized with great multithreading. The name comes from the fact that "it's quite brutal to use" (Citation by Dean Hall), in that you have pretty much raw access to Vulcan.
• Modding: Confirmed and highly prioritized
• Pricing/business model: Not set in stone, but Dean Hall has said on multiple occasions that he would like to have some sort of free access. This may or may not involve pay-what-you-like, freemium, or other models. Hall has expressed the desire to have the game funded via contributions, an distributedfor free via bittorrent. However, they will not be taking contributions before they have something playable.
• Multiplayer: Confirmed
• Early access: Unknown in the traditional sense. However, the intention is to have early playtests (free) available during 2025
• Interstellar travel: Confirmed
• Currently our real solar system is being used for everything, as it's easy to find assets for it and it's a known model they can test against. However, the intention is to have a smaller and more game-like system later.
• Similar to KSP in how maneuver nodes work, but with more QoL feature such as automatic calculation of transfer orbits, porkchop charts, and movement of maneuver nodes to best fit for intercept. These have been seen in gameplay.
• No Online-only or DRM. Dean Hall during a townhall livestream: "All my homies hate DRM"
• Scripting and automation: "Absolutely! I'm a big fan of kOS". Not surprising, as Stationeers (also by Rocketwerkz) has an implementation of MIPS for this purpose.
• Water buoyancy: "float and interact with water at minimum". They just started working on the graphical aspect of water, and the physical aspect is still not 100% determined. Some impressive screenshots of water have been seen.
• Colonies: Unknown. Dean Halls doesn't want to say anything on this topic because "colonization can mean so many different things to different people."

From Blackrack on Discord:

Early water surface previews. We're currently putting in place the foundation for the ocean system, these shots are using placeholder gerstner waves which can be used to test the shading/geometry and integration with the other systems. Later on the waves will be replaced with a more realistic system.

Posted by Blackrack on Discord.

1

2

Another showcase of the dust storm's front, these are currently exaggerated in scale but can be toned down as needed:
3

...which allows for some nice plots when you're at semi-synchronous orbits. Can't wait to position site survey (spy) satellites this way:

Bright green is current orbit. Darker and more faded greens for subsequent orbits.

Pretty fresh off the press, judging from the nav computer and ground tracking window.

From Gravhoek on Discord:

Here's a quick look at my most recent pass on the autopilot control panel. I'm already planning on making a few more changes in the next few days (specifically around burn execution), but you can see what's been done so far. This will also get a pass from Dean and his fancy new UI.

From Linx on Discord:

A quick look at the detail heightmaps in action and how fast it is to make edits to the terrain. It's pretty satisfying to see the textures update to reflect the new context of the terrain. I spent longer than I should have playing around with this!

Detail heightmaps are per-biome so planets won't have the same one everywhere. Due to their tiling/repeating nature they won't be used in places where that becomes obvious; I'm thinking they'll be applied to slopes or cliffs to add some extra detail to stop them from looking lumpy. I'm also going to be looking into procedural elements! Procedural noise is great for adding non-repeating detail that also isn't limited by the resolution of a texture, but requires a lot of care so that different locations don't look "samey". The planets will still be mostly driven by heightmaps, but closer to the surface where the heightmap resolution becomes too low is where procedural elements shine - KSP uses this. Not sure how far down that rabbit hole we'll go as I've only recently started looking into it, but it's something I'm interested in.

I leave you with a fun fact: Minmus in KSP is entirely procedural. If you change the seed using a mod you get an entirely new version of the minty moon 😉

.

From Gravhoek on Discord:

For anyone interested in how RCS control works internally, I thought I would post a couple shots of its "brain" during a maneuver.

If you have some familiarity with how automatic controls work you've probably heard of PID - that's not how this controller works. The problem with PID is that it doesn't handle actuators (RCS jets, in our case) that have a "minimum impulse" very well. That is, you can't fire an RCS thruster for an infinitely small amount of time. In practice, this means every correction you make is always at least a slight overcorrection, which means you're going to have to accept a bit of "wobble" around your target.

To handle this without constantly firing back and forth and wasting fuel, you need what's called a "dead band" where you just coast and allow your pointing angle to drift away from your target angle a little bit. Then, when you get too far away, you make a small correction and drift back the other way. When you end up in this pulse-drift-pulse cycle around your target and the pulses are minimum pulses (meaning the smallest possible RCS firing time), this is called a "limit cycle", which we will see in this graph.

The graphs here display something called "phase space", which is a general term in control theory. For our purposes, it is a graph of two errors - error being the distance from your target state to your current state. The two errors we care about for each axis are angular error (the X axis) and angular rate error (the Y axis). Basically, how far you are from the target and how fast you are going relative to the target.

The big red dot on the graph is your current location in phase space. The lines on the graph are called switching lines - hence why this is called a "switching line controller". If you are below the lines, it means you need to increase your angular rate. If you are above the lines, it means you need to decrease your angular rate. Between the lines is the "dead band", where all thrusters are off. You can see the lines converge towards zero rate and zero angle at the center, which is why this controller guides the spacecraft to its pointing target.

The three images here show a complete maneuver.

1. The initial angle offset where the red dots are far outside the lines.
2. Mid maneuver where the red dots are inside the lines but we are rotating around towards the target. This is the coast phase where we are spinning but there are no thrusters firing.
3. The "on target" phase where errors are close to zero.

Once you get close to the origin (zero rate, zero angle), the shape of the lines change into the squarish structure you can see on the zoomed picture. Here you can see several things more clearly:

1. The yellow lines are the switching lines described before.
2. The green line is the target line - when you are outside the switching line, you try and fire thrusters to hit this target line.
3. The gray box shows the expected "limit cycle" - the path you expect to take if the spacecraft is doing the least amount of work possible to keep the target within the dead band.

In the video you can see what the limit cycle looks like in practice. Note that the thruster firings in pitch and yaw are slightly coupled (e.g. firing in yaw causes a small change to pitch rate). This is because the thruster pods on the Apollo CSM are slightly rotated around the vehicle, so e.g. the "yaw" thrusters are actually "mostly yaw and a little bit of pitch" thrusters.

Note: The referenced video doesn't want to embed. You can see it here.

From Gravhoek on Discord:

Celebrating finally getting my RCS controller committed! Here is a "solar marathon" while holding a nose forward attitude using RCS.