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

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.

Posted by Dean Hall this morning.

.

.

.

.

From Blackrack on discord:

Atmosphere rendering improvements: Ozone and multiple scattering

As you've probably noticed in the last few videos, ozone is now supported. Unlike other atmospheric components, ozone only absorbs light (mainly green) instead of scattering it. This enhances the look of sunsets, as without ozone the atmosphere takes on a greenish hue.

The first screenshot compares a sunset without ozone on the left and with ozone on the right. The second screenshot shows the ozone layer from space which can be spotted as a distinct blue band, similar to this photo from the ISS.

Multiple scattering is also now implemented and can be seen on the third screenshot. It allows light to bounce several times in the atmosphere instead of just once. This can be subtle but helps with the realism of the atmosphere. It also works well with godrays, where objects block only the first light bounce, but the atmosphere can continue to receive light from the sky itself, softening the look of atmospheric shadows. The last screenshot shows a mountain casting a shadow on the atmosphere, with both ozone and multiple scattering, similar to this photo

Additional pictures:

.
. .

Loads of updates in the graphics area over the past couple of days. I'll post a summary to morrow, but this one was stunning enough to justify it's own post.

From Gravhoek on Discord:

Here's what I've been working on since my aerobraking video ~1 week ago. This is our RCS attitude controller which can both null out rotation rates (detumble) and track pointing targets. Unlike in other space sims, our RCS thrusters have minimum firing times. This means spacecraft will use small pulses to steer themselves towards their targets, then "wobble" back and forth with the occasional thruster firing to keep themselves pointed in the same direction.

The extra special trick of KSA is this works at any time warp! In this video you can see the full timescale from 1x real time to 1 month/second of warp, with the controller holding its pointing targets and even transitioning between targets with perfect stability. No more sending your craft spinning into infinity if you time warp a bit too much!

When we eventually add reaction wheels and/or control moment gyros to the game, they will feel meaningfully different because they will be able to do very fine pointing without all the wobble (but won't be nearly as powerful as RCS).

Posted by Dean Hall today.

4k version available here