karolus10

I believe that incorporating scripting/programming into the game mechanics would be very beneficial as it could be a core part of many systems like staging, action groups or programming behavior of "smart parts". If a scripting language similar to kOS is a part of the stock game it means that under the hood it can be used as a part of staging or action groups. This way you can add a command/program block directly into a staging list or even edit staging itself as a script. This approach would be vastly flexible as it could be used both for more complex programs when needed but it wouldn't be necessary to be touched by beginners unless they want to do very simple things very like unfolding solar panels or editing part tweak-ables who doesn't appear in staging. I think that scripting with text is better than visual forms of programming like Scratch, LabView or even KSP action groups as they seem great and simple for very basic things but beyond that this approach is pretty tedious and limiting. Also I do resent an idea of having instant solutions like mech-jeb available in a stock game. I advocate for having more creative tools rather than playing with training wheels.

I personally hope for 2 things in Ksp 2, highly tweakable parts and functional flight computer which allows you to write simple scripts in a way that would seamlessly work with the rest of the game and be interchangeable with things like staging or action groups. Tweakable parts are pretty self-explanatory, it's better to have a manageable amount well refined parts that can be customized and used in many creative ways rather than having a plenty of parts that are pretty much variants of the same thing. Those wouldn't be completely procedural parts but you would be able to pick different variants of a part and adjust it's size and attributes to a certain degree allowed by part designers. Good example for this is adjusting the nozzle and mount type of an engine, tweaking the size of the spherical tanks or adjusting the length of a ladder/landing gear. Wings/winglets with a tweakable size and shape are also desirable. For basic programming, I would see incorporating a clean and simple scripting language whith intuitive buit-in library(so most of useful functions and features are already implemented into the language) that could be used both for complete automation(Like landing scripts made in kOS) as well as simple macros and scripts triggered by function keys or staging events. Action groups and Staging list itself could be based on the same scripting language under the hood so you either add an item on the staging list containing few lines of code to do something simple(like change throttle setting or unfold solar panels) or decide to dive more into details and rely on scripting entirely if graphical editor is holding you back. I think that this approach would be a pretty powerful tool for advanced players but also people who just want to automate only few commands or use pre-made components shared by the community, especially if they are saved together with a craft file.

I believe that making KSP2 is a great idea, obviously it is not going to be as original and fresh as first KSP but it has a massive potential to be designed better than the original. KSP started a small passion project and it grew in small increments, with every new concept layered on top of an existing prototype. New title have a chance to design and implement most of the core features as one, elegant system in a way that is not possible with current game. I do love KSP more than any other game I ever played but we all know that this game is held back by it's core design, I don't think that it could be done much better at that point in time but hindsight is 20/20.

"Broomstick" antenna will be useful as it can be folded on service module/station or be used as small relay antennas, independent with larger hull mounted ones. There is a place for all types and sizes.

Lightweight service modules or payload delivery pallets(if you deploy constellations of satellites).

I guess that also it would be great if hot-key action groups would be separate for every command part, for example lander could use other action groups than orbiter despite being launched on single craft and it would make things more clear with multiple vehicles docked together.

It reminded me this: I think that STS-75 was a mission worth mentioning, shuttle had deployed satellite attached to the shuttle on 20 km tether (but cable have broken from stress 19km from shuttle), mission was designed to learn more about gravity gradients and feasibility of using tethers in space.

Due to recent news about KSP interface being re-made by the dev team, I think that it is an opportunity to suggest and talk about part of the interface that could greatly benefit from the changes applied, staging and action groups UI. I would like to suggest merging both systems together so staging is a sequence of action groups and every actions available on parts could be added or removed from staging sequence as well as any action groups could be added as items on staging list. Every part actions currently visible in staging UI would be added to staging list by default so arranging staging would be done in the same way like it is done now but it would allow to modify every item on the list if we want to. For example, we could throw away LES tower(or turn ON payload RCS/batteries) from staging and choose actions from any craft part to be used for staging sequence as every staging step can be edited as separate action group. Also adding action group as an action in the staging list (I know, action group nesting !) could allow to organise action groups on the staging list in the same way like current grouping of the items on the staging list but it could be very beneficial if some day action groups could be executed in sequence instead simultaneously, especially with timers or conditional operators. I would be interested to hear other opinions about the subject and ideas how staging and action groups interface should work and look in Your opinion.

In a way, new aerodynamics model and re-entry heating added just before 1.0 was a move to make this game a complete product which could be treated and sold as one and not early access game that shouts customers in their face that they buy not finished game. I guess that it was dictated by commercial motives as KSP "beta" was surprisingly short and more time could be used to polish and fine tune so complex feature added right after 1.0 was out but I cannot condemn this as there is a lot of games with "first day" patches that fix issues unacceptable for quality games. I had to admit that despite my wishes to keep developing KSP as long as it is possible so it would become a better, richer in content/complexity and more stable game than it is currently, KSP can be considered a complete game, a long way from the fun little game that instantly enchanted me 3 years ago. However, I am happy that SQUAD still seem to keep development of their product after decision to finish was made and it is not a beginning of the end of the KSP growth. As a owner of non-steam version of the game I never experienced issues connected to the updates as I keep the copy of the game in separate folder(s) (if you are Windows user you can use barely used Saved Games directory), if you ever don't want to have issues connected with it you can copy an backup of fresh KSP installation to be immune to the game updating itself and using multiple copies of own game to try out the mods, play with settings or just start fresh without downloading a game again, this way you can also try out new versions of KSP without removing your old instalments of the game and decide to start over with fresh and future version when the changes will be worth doing it.

Well, there may be no sounds in vacuum but you can hear any vibrations propagating trough the hull. I guess that sounds depending on the air pressure could be muffled and then gone in the outside view while there are still a lot of sounds that would be very cool in the IVA, like sounds of docking, impacting other object in space, hull creaking or groaning on different stress(it could be particularly unsettling sounds when entire craft is shaking/wobbling itself apart) and hardware like fans or such.

Precisely this.

I guess I would compare KSP replicas more to model-making, trying to recreate details with parts available require similar amount of thought and creativity as making completely new designs on your own. I didn't made much of replicas myself but I enjoyed making (bit stubby TBH) Saturn I block II back in the day.

I don't like the idea of engines overheating at all, most of them use fuel flowing trough them to cool the engine (especially NERVA's also they exhaust temperature would be lower than normal chemical rockets) or they designed to work at 100% capacity and not melt or malfunction for certain duration. I would like to see starting/restarting(with cool-down to arm again) of the engines with it's different capabilities to do so for different types of engines (from smaller orbital engines that are as easy to control as RCS up to massive behemoths(size 3 ones ?) that you can start just once unless it's their special feature) and fuels (RCS-like hypergolics vs cryo fuels). If anyone would add some balancing factor to NERVA it would be adding more gradual start/shut-down of the "nuke" engines as instant ON/OFF shut-down means stopping the coolant as well.

Kerbin is pretty small so getting to the orbit didn't take too long, especially with old drag model and lack of warp in early versions, getting to the edge of space is plain easy when compared to reaching orbit.

In a way making UI console-friendly and VR have overlapping goals, improvement of IVA and making UI more accessible with game-pad... second aspect could be even beneficial for PC version as it could possibly lead to more/easier hotkeys and manipulating with parts in VAB or using map view(maneuver nodes an perhaps maneuver/mission planner UI) with use of keyboard.