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.

I guess that IVA's designed for kerbals eye level is essential for good cockpit experience with VR. It could be solved by right positioning of front windows in relation to seats or get rid of the (like in size 2 capsule) front facing windows and use periscope(like in Soyuz or just move IVA end of the window lower so it mimics using mirrors window) or camera-screen glass cockpit.

I think that the best thing about KSP is the fact that failures can be fun to watch and encourage you to try again and again ... and again, until sweet success !

I think that radar altimeter part would be interesting as the placement of the RADAR antenna would matter(distance from ground in straight line from the direction of the antenna).

I like the mun accessibility (easy to make multiple mun missions in short time after returning to game) and it's terrain... I guess that landing on the mun never got old for me still.

Probably the most omitted fact about SRB's is that the fuel layer burns on the inner surface of the empty chamber drilled trough the middle. If the fuel and diameter is the same for each SRB then every each of them would work for (almost) same amount of time and thrust would be bigger proportionally to it's length.

Actually my suggestion was implying exactly what you said, hollow and solid fairing(so procedural like current fairings) enclosed from both sides with ring parts (one initial part (A) like with current fairings and one (B) which spawn on the other end of it) so the fairing walls act as structural support, engines or payloads could be attached to nodes inside so it would allow to make Apollo style LM fairing with service module above it. Current engine fairings are pretty much useless for many applications as they aren't bearing any load.

I think that 2 units should be used, cubic meters (m^3) for fuel tank volume and kilograms for mass of current fuel load. Displaying current fuel mass would be very useful during mission and design process.

It was the same thing I was thinking about myself, and with current fairings available it wouldn't be that much of problem to implement. Inter-stage decoupler could be made in similar way like fairings, but they would end with another structural plate(also it need to transfer fuel trough the plate to attach engines and other objects under it ,but not transfer fuel on the other end of the fairing). This is great workaround(no need for building rod thought the ship while using clustering) as unlike current engine fairings they would provide structural support and remove the need of stacking the previous stage directly to the engines. However it's important that such hollow part would be a solid object and not shatter after being jettison like current fairings, also there should be option in VAB to switch from which end of the faring we want to decouple or disable jettison option altogether to have hollow hull similar to cargo bays. At the end, I like to add that It's important that such part shouldn't be thick or massive so it could be used for short decouplers and hull parts as well as longer inter-stages.

I think that fully customizable atmospheric settings are the right way to go, it both allows to play with the configuration files for our own amusement as well as it may lead to find more realistic settings by community due to it's size and collective time spend on actual playing, which is far exceeding the time available for developers and testers... I'm optimistic !

I see new small SRB as a nice payload motor in late game, so not that obsolete for me !