r/kittenspaceagency

Just had this realisation. It's not just a QoL thing, it enables new gameplay.

Minimum time brachistochrone trajectories (a la The Expanse), multi pass aerobraking, long low thrust burns, "MechJebbing" through a multi burn sequence under warp.

Lots to try!

Title. Are the physics going to be sphere of influence based like KSP or n-body like with Principia?

While watching some videos on the Apollo and Artemis program, I had an idea on what if for KSA career mode, there was a system where you had to manage the manufacturing of your rockets.

It can be just as simple as making it so that it takes time to build a rocket, but further it could be you have limited production slots, first time builds taking longer (encouraging standardized rocket models), and managing construction and expansion of your space centre to scale with the space program.

More unrealistic ideas I had were managing production of individual parts like engines and probes, out-sourcing production of certain parts to contractors, and or having to deal with a scenario like current NASA with difficult small scale production because of poor management or something.

Ofc I assume there would be an amount of automation involved in some of the wilder ideas to prevent KSA from turning into a spreadsheet manager game.

I am a sucker for detailed yet readable UI and UX in games where you constantly interact with menus, systems, and information panels, and I think the game could really benefit from a stylistic approach similar to the Raster prop monitor mod for KSP. I think KSP 2 aimed for that kind of aesthetic, but not for the full functionality and immersion that the mod itself provides.

What I think makes raster prop monitor so immersive is that basically every important function and piece of information can be accessed directly from the IVA cockpit screens inside the spacecraft itself, and the cockpit feels highly functional and alive. I also really like the visual style of Raster prop because Its interface looks properly digital and "aerospace-y" inspired, with dense technical information and "nasa-punk" monitors, while still remaining readable and intuitive during actual gameplay. It manages to feel like real spacecraft instrumentation without becoming visually exhausting.

I understand that the current UI in KSA is still placeholder and will evolve over time, but because of that I think it’s also important to make strong stylistic and functional decisions early regarding what kind of interface identity the game should follow. Personally I think the Raster prop monitor approach would fit extremely well not just in IVA, but as the whole UI for the game: a unified interface philosophy where every gameplay screen, telemetry panel, navigation tool, and spacecraft system available in the standard HUD is also replicated inside the IVA cockpit displays. The modular nature of the screens in Raster Prop Monitor would perfectly match the kind of independent, floating, and customizable windows and menu system that KSA seems to be aiming for. Being able to rearrange, resize, or pin different information panels while still maintaining a coherent visual language would make the general UI feel both highly functional and deeply immersive.

P.S. This is my first post in the KSA community, so please be gentle :)

Ignore the text that says "Attach Thrust Plate"
I forgot to remove it.

NASA is pronounced... Well, as NASA, likewise with ESA.

I have a suggestion, that KSA be pronounced as "kiss-sa," as the Finnish word 'Kissa,' which means Cat

Although the development team has only created the Sun, Earth, Moon, Mars, Jupiter, and Saturn so far, they’ve already done an excellent job capturing the unique characteristics of these planets—Earth’s grassy vegetation, gas giants, planetary rings, moons like Pan, comets, and more. The remaining planets in the solar system would essentially just require parameter and texture adjustments. Moreover, the current experimental technology is already being developed within the solar system; logically, with the latest tech at their disposal, the team wouldn’t just create a small “Kitten” star system and then redo the solar system from scratch.

I understand the team’s desire to develop a new star system. On one hand, orbital insertion wouldn’t be as challenging, making it more beginner-friendly. RSS (Real Solar System) takes a very long time to achieve Earth orbit, whereas Kerbin only takes a few minutes. On the other hand, a new system allows for fresh creative ideas and fun mechanics without being bound by realism.

But since so much work has already been done, and there’s considerable demand from players, why not keep both systems? Let them coexist. With future interstellar travel, players could journey from the Kitten system to the solar system, or start from Earth and travel to the KSA-created system.

Dean also wants this game to be used in classrooms, and having the solar system would make it much more intuitive for teachers to demonstrate real-world space missions.

I believe this game could have very long-lasting value. Twenty years from now, when humanity launches new space missions—like probes to Uranus, Neptune, or even Pluto—this game could still be used to demonstrate them, thanks to its outstanding graphics and excellent physics simulation, along with its authentic recreation of the solar system.

I hope the development team will consider this. Although the game is mod-friendly, I would much prefer an officially supported RSS in the base game, so we never have to worry about mods breaking due to game updates. Even though the game is free now, if it ever becomes paid in the future, the solar system could be offered as a DLC. Or the game could sell at a higher price because it includes the solar system—I believe people would be willing to pay for it.

Thank you to the developers for considering this. Finally, best wishes for smooth game development 😘

Prefacing this with saying KSA is already amazing and it's already insanely impressive. The work done in such little time completely from scratch is amazing. I also really appreciate the idea of building a strong foundation before working on gameplay stuff, considering the current state of the game industry releasing broken games. If it takes another 5 years to finish, I don't care because that'll mean when it's done it'll basically be real life.

I'm just curious about when the simulation foundation will be considered good enough to start doing stuff like making the space center and making rockets in a rudimentary but not beta style VAB (more early KSP than current KSA). To me it seems the foundation is already very very strong, so I'm just wondering what other foundational things still need to be finished before the game-y elements start getting added. Again, I don't mean to sound like I'm criticizing the team in any way! Just curious about what foundation/simulation thing being done will give me the dopamine of "omg the game stuff is next" :)

• Optimized the hapke lighting. Simplified or factored out all trig functions (multiple instances of sin, cos, tan, acos) and ensured variables needed multiple times in different equations are only computed once. All that remains is an unavoidable atan2 which is pretty cheap. The tangent of mean slope roughness is now computed and passed to the planet UBO in place of the raw mean slope roughness, since only the tangent is used in the literature. All equations still follow the literature exactly, so the lighting should be identical.
• Increased the strength of the Moon's surface textures' normal maps from 60% to 80%, making it look more powder-like.
• Fixed imgui UI error in set orbit debug menu showing the Sun twice.
• Clean up Milky Way shader code. Settings have been added at the top of the shader to modify how the Milky Way looks.
• Added WIP launch debris particle emitter in XML. This is not setup to execute in game yet.
• Particle spawn on surface logic now offsets the start position slightly based on the normal. This helps to prevent particles from spawning 'inside' of vehicles.
• Fixed some sync hazard validation errors for Atmosphere, Clouds and Ocean
• Fixed an issue where the vehicle update task was not updating engines correctly after staging or altering the rocket due to an issue with how it is handling global engine state. It's a temporary bandaid, the side effect is the worker task will run more often than it should for updating the engines.
• Remove redundantly clearing caches twice.
• Sort the Activation InputEvent processing so we handle in this order: Decouple, Engine Controller, Thruster Controller.
• Fixed camera state deserialization loading save games. If no previously controlled vehicle was set in the save, tghe camera would not correclty deserialize.
• Particle emitters can now sample the color of the terrain. While not currently used for anything, this is important ground work for dirt and debris when vehicles crash into the planet. As part of this change, new fragment and compute shaders have been added for this.
• Cleaned up and reviewed how particle data was getting packed, this allowed us to remove some redundant packing data, aswell as abstracing some variables that were previously explicitly named for a specific function, when the parameters should be treated as generic data used in the compute shader and should not have had explicit usages in their parameter names. (All emitters had parameters for screen space collisions when only one particle updater used that data for collisions).
• Renamed the particle updaters in ParticleEmitterManager from ComputePipeline to Updater to follow the naming convention of the Renderers.
• Added ParticleUpdateShared.glsl, this contains common functions for the compute shaders to prevent code bloat.
• Made LightDebug Spawner available in production build
• Added more debug spawn options for lights
• Fixed handling of invalid vehicle saves when attempting to launch them from the launch menu UI.
• Added WIP PlanetImpact particle emitter in XML. This is not currently used anywhere, and will be a usful reference when we do implement impact particles properly.
• Fixed issue where if you tried to use the F7 Vehicle save dialog in the vehicle editor to save your vehicle, you ended up with an empty/invalid vehicle save.
• Major refactor of gauge editing first pass. This system replaces the old and broken gauge editor. This system allows the live editing of gauge information in prep for saving out as XML changes. Includes handles for resizing, moving pivots and anchor points. This is done via the Gauge Hierarchy and Inspector windows. Additional work remains to full functionality. This should also enable gauge position saving/loading between sessions in future.
• Fixed UI jitter at low frame rates.
• Added visibility of burn markers in Target Tracking Window.
• Added ability to create and modify burns in the Target Tracking Window.
• Fixed vehicle lists and view/projection matrices not being updated for a frame after loading a save.
• Consolidate burn editor UI between main viewport and target tracker into one function.
• Fixed the timing of when we process the exit from the debug vehicle editor vs the vehicle worker threads causing conflicts and bad data, which resulted in lots of red console messages in some cases depending on what you did in the vehicle editor.
• Updated all part emissive textures with fewer mips so there's less bleed as you zoom out from parts. Also changed to BC4 compression from BC7 since it seems to be only greyscale for now.
• Updated CoreElectricalA's diffuse and PBR textures.
• Updated CoreFuelTankA's PBR texture.
• Add ImguiHelper.DrawDiamond function.
• Changed TargetTrackWindow to use DrawDiamond.
• Added initial implementation of volumetric particles. This is not implemented into any particles current, however the core framework is there when needed. A basic volumetric particle has been defined in XML for reference later.
• Refactored the screen space collisions particle updater to transition the depth image after updating particles, as previously this was handled externally by the particle emitter manager.
• ParticleEmitterRenderer now takes the depth stencil state and color blend attachment as an input on construction. This means that the volumetric particles are able to still use the same ParticleRenderer as all other particles, helping to reduce code bloat for specific rendering systems.
• Particle Emitter Manager now renders opaque and translucent particles seperately, previously all particles were renderered through the same function, however there is are now specific opaque and translucent functions.
• Renamed particle shaders to remove 'Frag' and 'Vert' from the shaders names. They are already denoted with '.frag' and '.vert' so this was unnecessary.
• Added initial volumetric particle shaders.
• Fixed Vulkan validation error caused by screen space collisions returning early when no emitters are registered to the system, resulting in depth image not transitioning correctly.
• Fixed particle emitter 'extra' data not getting set from XML correctly.
• Added ability to change the number of orbit periods to show in the Target Tracking Window.
• Added support for billboarded particles.
• Added basic plane mesh for use by billboarded particles.
• Refactor of Gauge UI editing second pass. Added fit/stretch to component and rect as a context menu item. Also includes new approach to adding rect instances on Components that is context sensitive, better reflecting the actual use case.
• Changed SerializeWithoutNaN streamwriter no longer disposes the callers memorystream so that it can be utilized by the caller.
• Refactor Third Pass of Gauge Editing. Now you can multi-select gauge elements in the hierarchy with standard selection conventions (CTRL for non-contiguous elements, SHIFT for continguous). Introduced an intermediate transform type to handle scaling for these selections.
• Fixed crash when setting range to 0 when using the Light Debug Spawner
• Added small padding to the light range when culling meshes to avoid flickering shadows.
• Fixed regression in gauge editor that would reset pivot/anchor when using the stretch/fit context menu elements.
• Added context menu item for gauge elements in hierarchy to allow reseting pivot, and switching anchor points to cardinal points on parent.

i just came from ksp and i tried delete and backspace and also dragging it to the parts section but i still cant figure it out

I am posting this to ask if i can run KSA on my pc
my specs are:

OS: bazzite (steamos but fedora based)
CPU: intel i5-7500 3.80ghz
GPU: amd firepro w5100 4gb ddr5 vram
Ram: 16gb ddr4

note: im not on controller or steamdeck i just really like bazzite and im not on big picture mode

sorry if this has been answered somewhere, i dont keep up and am curious

are there plans to add USSR style pods like the vostok capsule? I think itd be really cool, it was the very first manned ship in space after all!

I am getting a laptop with a gtx 1650 card and i am interested in what kind of performance i could be looking at. Thanks in advance.

Basically, as the title says - does the current version of the game include some sort of updater, or do users still need to download each new version manually?
If there isn’t one, are there any plans to add it in the near future?

• Fixed SoundFiles not getting assigned to their soundgroups.
• Removed ParticleMeshData from ParticleEmitterRenderer as it is now redundant.
• Removed CPU->GPU dependency when destroying particles. This now results in a stable framerate when simulatenously destroying ~2 million particles. This is not a perfect solution however it is substantially faster than the current implementation.
• Added Custom audio ChannelGroups can now be defined in xml. Custom groups must declare a parentId, which can either be another custom group or one of the static groups (Master, Sfx, Ui, Music).
• Updated Existing sounds to point to new custom groups where appropriate.
• Fixed Rcs sound group setting was causing audible popping due to having no mutefadeSpeed set.
• Fixed bug with particles that spawn overtime not reusing particles correctly.
• Fixed Keyframe Animation not applying itself when it is created causing the visual state to not represent the animation state.
• Extraced particle renderer and updaters into interfaces so that more custom emitters can be created.
• RaytracingRenderer no longer uses the RenderGlobals descriptor pool. This means that acceleration structures no longer need to be allocated when raytracing is disabled.
• Particle system refactor to use generics for particle data. This provides more flexibility in how particles can be created instead of relying on a single set of render and update data.
• Add a separate exhaust template for the A1's plume to make it visible: A1's exhaust density is much lower than other engines, but it's exhaust temperature and velocity are much higher, use a different configuration with a higher emission value. Scaling emission by temperature was attempted but the values varied extremely between sea level and vacuum making the brightness inconsistent, this is only an issue with extreme values such as on the A1
• Better match the point light brightness and color to the exhaust plumes
• Fixed scenario where particle emitters might not spawn correctly due to nextParticleIndex.
• Particle system cleanup removing redundant variables and minor optimizations.
• Added particle mesh buffer interface. This allows for binding particles with only the required data, e.g position only without UVs or normals. Additional mesh buffers can easily be created to bind any required data.
• Added virtual OnPartCreated() method to Module base class. This can be override by modules that require it to initialize references to part/subpart modules as it will be called once all Modules and subPart Modules have been created.
• Added SolarTracker part Module. It's job - track and rotate to face the part to towards the Current Systems Star. We still need to add ability to rotate only some of the Part - for now it rotates the whole part.
• The Solar Tracker will use the KeyframeAnimation - via supplemental rotation setting if there is a KeyframeAnimation module on the part. Otherwise it will perform the rotation of the part itself.
• Added supplementalRotation to the KeyframAnimation module so we can supply a supplemental rotation (eg: solar tracking rotation).
• Changed SolarPanel module to identify and use KeyframeAnimationModule state to determine if the SolarPanel is active or not.
• WIP Optimizations to how particle emitters spawn using 'OverTime' or 'Endless' spawn mode.
• Milky Way shader v1. Currently a disabled checkbox option under "view -> debug -> show milky way (last item)". For the first layer of noise, a blurred cubemap texture is used to get the color gradients, then layers of cloud noise of different frequencies are applied on top to get detailed noise.
• Remove old stars irradiance descriptor layout from GlobalShaderBindings
• Added initial screenspace particle collision implementation using depth and normals from the prepass.
• Refactored particle renderer and updaters into their own seperate directories.
• Added temporary hardcoded collision values to ParticleEmitters.
• Set tighter bounds for the plume while respecting the turbulent noise
• Add NaN guards for the cloud shaders
• Added Convolution Reverb for sounds that are playing near an atmospheric body surface.
• Added Support for adding dsp processing to ChannelGroups via xml.
• Added XMl support for creating: Send, Return, MultibandEq, Compressor, Delay, ConvolutionReverb.
• Changed BiomeSoundController is now owned by the viewport rather than the Controller.
• Fixed some popping issues coming from starting playing engine cluster sounds.
• Fixed validation error on startup caused by particle emitter manager creating the wrong ParticleUpdate type for screenSpaceCollisions.
• Added ability to change the focus of the orbital camera to different parts of the current vehicle via the part UI windows.
• Added Audio Filtering effect of external sounds when in Iva camera mode.
• Changed Dsp parameters are now handled in a generic fashion at the base class level.
• Added ability to exclude a list of subparts from solar tracking animation in the SolarTracker module.
• Added additional raytracing resolution settings. Previously a single raytracing resolution setting was offered which controlled all raytracing outputs. Now the resolution of each output from the raytracer can be controlled individually. This can provide huge optimizations by reducing certain less noticable outputs while being able to keep more visible outputs at full resolution.
• Raytraced materials that have a high roughness value no longer contribute full reflection bounces and will exit early if possible.
• Cleaned up particle mesh buffer implementation to calculate buffer sizes correctly.
• Added Iva ambience loop.
• Improved mix of Iva audio perspective.
• Added Volumes of ChannelGroups can be authored in xml.
• Changed More polishing to Iva audio perspective, improving transition across atmospheric density levels.
• Changed Reduced environment ambience volume when in Iva mode.
• Particle emitters now update after the main render pass. This means that they have access to the depth buffer for any update compute shaders that may need it. As a result the screen space collisions now work on all surfaces that have written to depth already, instead of meshes that wrote into the prepass renderer.
• Moved the KeyframeAnimation part UI window processing to match other modules with buttons before information.
• Added the Hapke lighting model.
• Improved planetary lighting model - added cheap blend between Hapke and Lambertian-like models via the shadowing factor, since Hapke is only valid for powders.
• Added two new planet maps 'Scattering' and 'Surge'. Scattering stores RGB = Powder-ness, b, c and Surge stores RGBA = Bc0, hc, Bs0, hs.
• Added 'MeanSlopeRoughness' parameter (Hapke's Theta) to the surge texture reference.
• Added scatter and surge maps for Earth and the Moon.
• Added default scatter and surge maps for non-powdered materials.
• Added default scatter and surge maps for regoltih (specifically the Moon's regolith).
• Added the hapke shading model to the distant sphere renderer.
• AddedHapkeScatteringReference which owns MeanDiffuseLuminosity and MeanAlbedo parameters for the hapke shading model. MeanDiffuseLuminosity is gamma corrected at runtime and used to normalize the diffuse texture before being multiplied by the MeanAlbedo in the shader. In theory this should result in the correct albedo for each celestial body. Note that currently the light intensity does not fall off with distance from the Sun, so the reflectance is too high.
• Added default hapke scattering and surge textures to HapkeScatteringReference and HapkeSurgeReference respectively.
• Added hapke maps and paramaters for Earth, The Moon, Mars, Venus, Phobos and Pan. All other celestial bodies fall back to default maps and parameters.
• Change volumetric exhaust sampling strategy to place more samples near mach diamonds when they are active, this highly reduces artifacting/pixelation on exhausts which can be especially visible when looking from the rocket towards the plume when the plume is expanded
• Moved GetLlaFromCcf() from Celestial to IParentBody.
• Draw physics debug info even when around the Sun.
• Added Mu to IParentBody and consolidated uses from Celestial.
• Increased tolerance on SafeAcos() and SafeAsin().
• Small improvement to Orbit.Hyperbolic.GetTrueAnomaly(Radius) which reduces the intermediate quantity magnitudes to improve precision.
• Handle a flight plan escape logic case where the orbit is entirely outside its primary's SOI.
• Handle the corollary bad case in vehicle physics where the escape time is in the past.
• In plume length calculations, handle the case where the target density is higher than the exit plane density.
• Fixed a regression where the flight computer was not being notified when engines were activated/deactivated.
• Added a tooltip condition for the auto-burn button for when no engines are active (previously this would show up as "no burn duration").
• Cull vehicle rendering based on apparent size, not hard distance. This should make vehicles smoothly transition from distant sprites to fully-rendered objects.
• Cleaned up how particle mesh buffers initalize buffer sizing.
• Added low poly sphere mesh for use with particles. Previously thruster and decoupling particles used a sphere mesh with 4K tri count, their new mesh has only 80 tris, this may need to be reviewed but the current usecases are small enough that there is no quality difference.
• Reenabled writing to depth for particles.
• Particle buffer memory is now set to prefer gpu memory as previously it was undefined.
• Milky Way shader v2. Fixed most of the clouds seam using noise. This seam occurs due to the cloud noise needing to wrap around at the ends of the cylindrical projection. Changed the texture from rgba32f to rgba16f format to reduce vram and found no visual difference.
• Added GalacticPlane transform to the XML. Used the GalacticPlane to transform the Milky Way to be in a more realistic position.
• Revert Milky Way seam fixup code for the cloud noise as it looks worse.
• Rename Milky Way texture to follow the naming convention of other textures.
• Add Milky Way shader code to narrow the band so that it doesn't take up too much of the screen.
• Fix seam in cloud noise. This seam occurs due to the cloud noise needing to wrap around at the ends of the cylindrical projection.
• Changed interior ambience sound to be less mid heavy.
• Reworked settings on interior reverb.
• Reduced volume of engines when in IVA mode.
• Added WIP PBR particles. This is currently not used by any existing particles emitters.
• Particle Emitter Torus preset now has an option for the length of the torus.
• Cleaned up particle PBR data. This was previously explicitly named as roughness, metallic and ao, however for particle renderers that do not use PBR data these values do not make sense. This has been changed to a float4 in ParticleRenderData which can be reused for other renderers.
• Add Milky Way Quality setting. The Milky Way now has its own quality slider in the Graphics menu. The Milky Way fragment shader generates a realistic Milky Way visualization per pixel using cloud noise (fbm noise and ridged noise). This gives a much better result than using a texture.

Would love to see a kitten replacement option. I don’t wanna see kerbals or kittens. Not that I don’t see the appeal, or like the style, but I would love to see just, straight up humans. They could be proportioned like the kittens; stylized/cute, but seeing as it seems that we have rss in game, why not have the option for “kitten replacement”?