Time for KSP 2.0

[DunaManiac]

3 hours ago, Sharpy said:

Did you per chance do this while KSP still didn't have the Tutorials option available? 

  

I started with the .18 demo. I actually didn't know about the turtorials back then. I had the demo for 2 years, but never reached the mun until I got the full version.

5 hours ago, klgraham1013 said:

Muddy ground textures are not cartoonish, they're muddy ground textures.  I wouldn't mind if KSP embraced it's cartoonish visuals as long as they did it of a high and consistent quality.

I agree. all I really want is a bit smoother ground ( I agree with sharpy about that ) and a few clouds on kerbin and eve and laythe. Not really super duper HD graphics.

[Piatzin]

6 hours ago, qzgy said:

I would assume that's because the pool of people potentially interested in the game and joining the forum have mostly joined by then or something along those lines. The community won't expand at a certain rate forever. 

True, and people will also continuously leave or stop playing. But there's a constant flow of kids growing up - people who are potentially interested in this type of game. That pool of potential customers won't ever be exhausted so long as people continue to be born and reach the age of KSP playingdomsomewhatist called

3 hours ago, KerbolExplorer said:

How long until that?.....Id say the current development trayectory of squad gives this game 2 more years

I doubt it's that little

[Sharpy]

2 hours ago, DunaManiac said:

I agree. all I really want is a bit smoother ground ( I agree with sharpy about that ) and a few clouds on kerbin and eve and laythe. Not really super duper HD graphics.

...but that still leaves realistic rovers useless, and speedy rovers unrewarding. My point is less about "looks" and more about having planets "higher resolution" conceptually - make things differ meaningfully on scale of meters, not kilometers. For Mun to have craters that can barely fit a kerbal, and return a different science data than if you climb out of such a crater.

[DunaManiac]

1 hour ago, Sharpy said:

..but that still leaves realistic rovers useless, and speedy rovers unrewarding

Why do you want slow rovers? I appreciate your need for realism but having rovers that drive around in one place and really slowly would make rovers completely unnecessary plus being extremely tedious. I like speedy rovers. Because driving like real life rovers isn't very fun unless you seriously want a curiousity replica mission. (this is only my opinion others may differ)

 

1 hour ago, Sharpy said:

For Mun to have craters that can barely fit a kerbal, and return a different science data than if you climb out of such a crater.

I would like little craters but i'm not sure about different science data.

[Sharpy]

17 hours ago, DunaManiac said:

Why do we have slow rovers? I appreciate your need for realism but having rovers that drive around in one place and really slowly makes rovers completely unnecessary plus is extremely tedious.

Fixed that for you. Let me remind you of these parts:

RoveMax Model S2

Max speed 12m/s, about never practically achievable. Fragile as heck. If you luckily land at the border of two biomes, an hour of driving can double your science reward once you reach the other biome. Otherwise, useless.

 

RoveMax Model M1

Decent speed, will break as soon as you start utilizing it. Drive 15m/s max if you want the rover to live longer than a couple minutes.

 

RoveMax Model XL3

Rugged, heavy and SLOW. 15.5m/s max speed, realistically a little less. Useful if you want a reconfigurable base. Not useful if you want to go anywhere..

 

The only reasonably useful rover building part is the ruggedized wheel, which allows both for a reasonable payload and a reasonable speed... so within 2-3 hours you may cover 3-4 biomes. The remaining three are written for the type of gameplay that simply doesn't exist in KSP. They  only make sense for aesthetics and fun, they serve no purpose for the gameplay mechanics - everything they can do, a rocket-based biome hopper (in case of M1 and XL3), or a dumb non-restartable static lander (in case of S2) does better.

[DunaManiac]

14 minutes ago, Sharpy said:

Decent speed, will break as soon as you start utilizing it. Drive 15m/s max if you want the rover to live longer than a couple minutes.

I never said Why do we have slow rovers. I said why do you want slow rovers. Besides, those rover wheels do have a purpose for small rovers that don't fit the ruggedized wheel.

 

21 minutes ago, Sharpy said:

They  only make sense for aesthetics and fun, they serve no purpose for the gameplay mechanics

That's my point. If you want to drive like real life rovers you can. But, it actually being part of the gameplay is not likely.

[Sharpy]

21 minutes ago, DunaManiac said:

. Besides, those rover wheels do have a purpose for small rovers that don't fit the ruggedized wheel.

 

What is the purpose for small rovers that don't fit the ruggedized wheel?

[DunaManiac]

1 minute ago, Sharpy said:

What is the purpose for small rovers that don't fit the ruggedized wheel?

well, aesthetics and fun. Their for those who want to create realistically looking curiosity/opportunity/ Apollo Rover missions and drive them around. For those who want to land rovers on duna or mun or minmus before they've unlocked the ruggedized wheel. A small rover for their mun base. You can create infinite different rovers for asthetics and fun, and realism.

[Sharpy]

1 minute ago, DunaManiac said:

well, aesthetics and fun. Their for those who want to create realistically looking curiosity/opportunity/ Apollo Rover missions and drive them around. For those who want to land rovers on duna or mun or minmus before they've unlocked the ruggedized wheel. A small rover for their mun base. You can create infinite different rovers for asthetics and fun, and realism.

For spaceplanes, there's at least the alternate use as less practical rockets. Rovers... as less practical landers?

I think expanding the game mechanics so that a family of parts, and a family of associated crafts actually begins serving a purpose, especially one that is mirrored in real life, would be a worthy endeavor.

Especially, that we already have micro-biomes in the game. All around KSC. You can test your Opportunity and make full use of its capabilities, driving it around KSC. But wherever else you fly it, it will be a lousy lander that can move slowly  around for no good reason.

 

[DunaManiac]

18 minutes ago, Sharpy said:

For spaceplanes, there's at least the alternate use as less practical rockets. Rovers... as less practical landers?

I think expanding the game mechanics so that a family of parts, and a family of associated crafts actually begins serving a purpose, especially one that is mirrored in real life, would be a worthy endeavor.

Especially, that we already have micro-biomes in the game. All around KSC. You can test your Opportunity and make full use of its capabilities, driving it around KSC. But wherever else you fly it, it will be a lousy lander that can move slowly  around for no good reason. 

 

I suppose I can agree with you there. But in order for  this to happen is for us to get a new surface sampler, like a drill that gives you science. Because having all the expirements apply for micro biomes on duna is just too much coding everywhere.

[Tyko]

20 minutes ago, Sharpy said:

For spaceplanes, there's at least the alternate use as less practical rockets. Rovers... as less practical landers?

I think expanding the game mechanics so that a family of parts, and a family of associated crafts actually begins serving a purpose, especially one that is mirrored in real life, would be a worthy endeavor.

Especially, that we already have micro-biomes in the game. All around KSC. You can test your Opportunity and make full use of its capabilities, driving it around KSC. But wherever else you fly it, it will be a lousy lander that can move slowly  around for no good reason.

 

Except real life rovers don't go far or fast...Curiosity has only traveled 18km in 6 years...

[Sharpy]

1 minute ago, DunaManiac said:

I suppose I can agree with you there. But in order for  this to happen is for us to get a new surface sampler, like a drill that gives you science. Because having all the expirements apply for micro biomes on duna is just too much coding everywhere.

I'd say "some experiments are per macrobiome, some are per microbiome", temperature, pressure and atmosphere composition won't be much different 15 meters away, but the goo might react differently, and metal content from a meteorite may throw a magnetometer off, a ground sampler will definitely find something new.

Plus that wouldn't be an infinite number of microbiomes. Maybe same number as general biomes on a planet, maybe a little more; no biome would contain every kind of microbiome of a planet either, so multiple landers, hoppers or long-range rovers would still make sense. But landing a small, slow rover would yield about 2-3 times the reward of landing an inert one; you get 1x the biome-specific science (as with a lander), and can expect to find 3-4 microbiomes within range, gaining 3x-4x microbiome-specific science, for about 2x total. Maybe in more exotic biomes, more microbiomes. In more generic ones - just 2 or even the single, global one - say, Minmus Flats would be flat, uniform and featureless, but Slopes could contain quite a variety of exposed goods - simultaneously making a robust rover and precise landing more rewarding.

[DunaManiac]

Just now, Sharpy said:

t 15 meters away, but the goo might react differently, and metal content from a meteorite may throw a magnetometer off, a ground sampler will definitely find something new. 

That's just what I'm saying!

1 minute ago, Sharpy said:

Slopes could contain quite a variety of exposed goods -

The problem with that is that is that most rovers can't drive on slopes like that. Believe me, I've sen't rovers to the mun  and even there the gravity is punishing.

[Tyko]

4 minutes ago, Sharpy said:

I'd say "some experiments are per macrobiome, some are per microbiome", temperature, pressure and atmosphere composition won't be much different 15 meters away, but the goo might react differently, and metal content from a meteorite may throw a magnetometer off, a ground sampler will definitely find something new.

Plus that wouldn't be an infinite number of microbiomes. Maybe same number as general biomes on a planet, maybe a little more; no biome would contain every kind of microbiome of a planet either, so multiple landers, hoppers or long-range rovers would still make sense. But landing a small, slow rover would yield about 2-3 times the reward of landing an inert one; you get 1x the biome-specific science (as with a lander), and can expect to find 3-4 microbiomes within range, gaining 3x-4x microbiome-specific science, for about 2x total. Maybe in more exotic biomes, more microbiomes. In more generic ones - just 2 or even the single, global one - say, Minmus Flats would be flat, uniform and featureless, but Slopes could contain quite a variety of exposed goods - simultaneously making a robust rover and precise landing more rewarding.

Yeah, the idea that you'd have hundreds of kilometers of featureless plain and then hit a cliff or crater that contained multiple biomes would be very realistic and make a lot of sense. Like NASA does today you'd have to survey to find the best places to drop your rover, but if you did it right you wouldn't have to drive too far.

That said, "too far" is a relative term. At semi-realistic speeds you're still talking months of driving. you'd need some sort of autopilot to let you set a goal and then time warp.

This mod exists, but I've never tried it:

 

Edited August 31, 2018 by Tyko

[DunaManiac]

1 minute ago, Tyko said:

Yeah, the idea that you'd have hundreds of kilometers of featureless plain and then hit a cliff or crater that contained multiple biomes would be very realistic and make a lot of sense.

I would kind of like that as well, but I really wish if rovers were extremely slow, it could be turned off in  the settings.

[Sharpy]

9 minutes ago, DunaManiac said:

The problem with that is that is that most rovers can't drive on slopes like that. Believe me, I've sen't rovers to the mun  and even there the gravity is punishing.

But some can. Using Ant to help uphill, copious use of brakes, fine-tuning wheel parameters... Challenge and reward. Want easy 1x, land on the Flats. Want 5x? Make something that can climb the slopes!

 

3 minutes ago, DunaManiac said:

I would kind of like that as well, but I really wish if rovers were extremely slow, it could be turned off in  the settings.

They don't need to be slower than they are now - or maybe at worst a little slower. There could be a phys-warp higher than 4x to reduce the travel time... but that would need physics engine overhaul again, 'cause 4x is unreliable enough.

 

[Tyko]

5 minutes ago, DunaManiac said:

I would kind of like that as well, but I really wish if rovers were extremely slow, it could be turned off in  the settings.

Just something to consider - 12 m/s is almost 27 miles per hour (43 km/h). Driving that fast over open ground (other than a salt / sand flat) on earth is going to have you bouncing all over the place. The only reason you're not completely out of control is you have 1G pulling you down so you can build a bouncy suspension to with lot of travel. If you attempted those same speeds at 1/3G or 1/6G you will have a very difficult time controlling it.

You can test that in the game now. Just build a rover with TR-2L (max speed 58 m/s) and go for a drive on the Mun or Duna at high speed.

[Sharpy]

2 minutes ago, Tyko said:

Just something to consider - 12 m/s is almost 27 miles per hour (43 km/h). Driving that fast over open ground (other than a salt / sand flat) on earth is going to have you bouncing all over the place. The only reason you're not completely out of control is you have 1G pulling you down so you can build a bouncy suspension to with lot of travel. If you attempted those same speeds at 1/3G or 1/6G you will have a very difficult time controlling it.

You can test that in the game now. Just build a rover with TR-2L (max speed 58 m/s) and go for a drive on the Mun or Duna at high speed.

Without a reaction wheel?

I had a sweet Mun rover based on these, the entire volume was framed by the four wheels, so no matter how it would tumble, it would land on its wheels anyway. Although the wheels upside-down don't work... but still absorb the shock, and the reaction wheel could flip it back up. I could utilize the entire 50m/s or so (180 km/h).

Within an hour I managed to reach 3 nearby biomes. Another 3 hours for one more biome, and I ran out of patience. And yes, it was flying most of the time, touching the ground was brief and rare between the jumps, and it would be pointless without the reaction wheel.

And that's why I feel biomes should be places you reach by rocket propulsion or on wings, with only rare cases where you have access to 2-3 biomes in close vicinity; microbiomes should be a rover thing. So that you could reach 3-4 within less than an hour of driving a small,  fragile, slow rover - as these built on Rovemax S2 (the tiny wheels) as they are currently.

As for time/range... Lunokhod top speed was 2km/h. And within these 2km you should find all microbiomes given biome has to offer. With terrain being more varied you'd need to pay attention to driving more too, so it won't be as boring as driving a 2km/h rover would be currently.

 

[Tyko]

7 minutes ago, Sharpy said:

Without a reaction wheel?

I had a sweet Mun rover based on these, the entire volume was framed by the four wheels, so no matter how it would tumble, it would land on its wheels anyway. Although the wheels upside-down don't work... but still absorb the shock, and the reaction wheel could flip it back up. I could utilize the entire 50m/s or so (180 km/h).

Within an hour I managed to reach 3 nearby biomes. Another 3 hours for one more biome, and I ran out of patience. And yes, it was flying most of the time, touching the ground was brief and rare between the jumps, and it would be pointless without the reaction wheel.

And that's why I feel biomes should be places you reach by rocket propulsion or on wings, with only rare cases where you have access to 2-3 biomes in close vicinity; microbiomes should be a rover thing. So that you could reach 3-4 within less than an hour of driving a small,  fragile, slow rover - as these built on Rovemax S2 (the tiny wheels) as they are currently.

As for time/range... Lunokhod top speed was 2km/h. And within these 2km you should find all microbiomes given biome has to offer. With terrain being more varied you'd need to pay attention to driving more too, so it won't be as boring as driving a 2km/h rover would be currently.

 

All true     IF the game had microbiomes and IF the game's terrain detail and surface scatter was detailed enough it could be really fun to drop near a crater and figure out how to make your way down into it and run tests on various layers of the crater sides. THEN I would a agree that driving slowly could really be fun.

Since this thread is about KSP 2.0 I'd say that new gameplay like this would help to justify a full new game release. KSP 1 is really about launching rockets, everything else is just decoration really and it shows in the surface detail, aerodynamics, career mode, science mode, etc....If KSP 2 was designed from the ground up to be about exploration and discovery it could be a really cool and different game.

[Sharpy]

Now as I think of it, what would really make 2.0 a real 2.0, would be introduction of a programming language. Capabilities of KOS, but much more kid-friendly syntax - most probably, "connect blocks" graphical style. Inputs from sensors, arrows connecting to processing blocks and output to actuators or just flight parameters. Tutorials for PID, pathfinding, etc. And craft run on their own following the script. Autonomous rovers, autonomous probes, swarms, self-synchronizing constellations, and so on, and so forth. Plus recording, so that you could replay how it ran. That way it would provide the autopilot for the slow rovers, let us have actual orbit decay with automated station-keeping, low-thrust engines that won't suck, life support. base maintenance, with enforcing sustainability through scheduled automated tasks, and generally all kinds of wonders... as soon as you write them.

More advanced, more "high level" commands could be unlocked with science like parts, so instead of writing your own maneuver-executing autopilot command you can purchase the block; more advanced cores would provide more space for the programs and so on.

[Dunbaratu]

2 hours ago, Sharpy said:

And craft run on their own following the script. Autonomous rovers, autonomous probes, swarms, self-synchronizing constellations, and so on, and so forth. Plus recording, so that you could replay how it ran. That way it would provide the autopilot for the slow rovers,

That's a LOT harder than you might think.  The reason the current KSP game doesn't allow things to happen "off camera" was that the entire physics system breaks down and invokes the Kraken when using large magnitude numbers that aren't as precise as low magnitude numbers when dealing with floating point values.  The solution was to only fully invoke all the physics interactions when the ship is "near" the origin point, and to move the origin point with the active vessel.  Most people think that cutoff point is 2.5 km or so.  It's actually even tighter than THAT - the real cutoff point is at about 300 meters.  You can *see* vessels within 2.5km but they're still "packed" meaning not all the PartModules fully work yet, until they get "unpacked" which is really at 300 meters.

To make a script able to actually run things on the vessel while the vessel isn't nearby, would require somehow solving this problem first in the new KSP 2.0.  And I suspect *THAT* would be the harder problem - much harder than actually implementing the automation itself once that's solved.

I'm not sure how I'd feel about the programming system being done with graphical bits like that - it usually ironically makes things *harder* to do them that way.  There's a reason flowchart graphical programming languages never really caught on despite how many times people have tried to do them.  Also, there's my fear it would turn out like the finite state machine used in the Making History DLC, where there is ZERO retention of information whatsoever so you can't do anything variable with it.

[Sharpy]

2 hours ago, Steven Mading said:

To make a script able to actually run things on the vessel while the vessel isn't nearby, would require somehow solving this problem first in the new KSP 2.0.

Lots of instances of the physics engine,

 

origins, all working in the background whenever needed. Probably a bunch of optimizations of the engine, e.g. deep, flexible integration of the 'welding' mod concept where the inactive craft becomes a single rigid body instead of a collection of parts bound by flexible physics engine joints.

Would also require more RAM and good CPU, definitely make use of many cores... the PC did move ahead from where it was when KSP came out though.

2 hours ago, Steven Mading said:

I'm not sure how I'd feel about the programming system being done with graphical bits like that - it usually ironically makes things *harder* to do them that way.  There's a reason flowchart graphical programming languages never really caught on despite how many times people have tried to do them. 

You never programmed a PLC? Ladder languages are still common with these. The graphical/flowchart has a very friendly learning curve. Give it good subdivision interface (subroutine/function blocks) and it isn't that horrible. And it could always compile to a text script, and they could leave the scripting layer accessible/editable, like advanced tweakables. Besides, it should be easier than programming in Minecraft Redstone, Factorio or SpaceChem. Try "Automate" for Android, a very useful graphical scripting tool for controlling your Android device - and while yes, writing anything harder isn't all that nice, it really has a very friendly learning curve.

 

Designing it so that's simultaneously powerful, friendly and fun would be difficult, but I think possible and worth it.

[FungusForge]

3 hours ago, Sharpy said:

e.g. deep, flexible integration of the 'welding' mod concept where the inactive craft becomes a single rigid body instead of a collection of parts bound by flexible physics engine joints.

The game already does exactly this. Within 300m an inactive vessels physics are loaded because they are relevant for interactions with the active vessel. Outside 300 meters they are physics-less props, no different from a construction within the editor. Outside 2.5km, this prop ceases to be rendered altogether, and is reduced to just a point riding its orbit "rail". Also

 

3 hours ago, Sharpy said:

You never programmed a PLC? Ladder languages are still common with these. The graphical/flowchart has a very friendly learning curve. Give it good subdivision interface (subroutine/function blocks) and it isn't that horrible. And it could always compile to a text script, and they could leave the scripting layer accessible/editable, like advanced tweakables.

This, in an extremely crude sense, exists within the Making History mission builder. You can make it stage, or activate action groups based on various inputs (speed, mass, mission time, if a specific stage has fired). Crude as I said, but with some more inputs, as well as some actual control focused outputs (roll angle, heading, attitude, throttle), I imagine even somebody like me could actually hammer out a rough program to get a rocket to Mun orbit. I believe Scott Manley (or was it someone else?) actually got a rocket to orbit only using the Mission Builder commands as an "auto-pilot", although its repeatedly mentioned crudeness provided a challenge all its own.

This still would be limited to the active vessel, but it could conceivably be done. Even if they made a KSP2 I have doubts they'd make stuff like this run in the background, because optimizations or no, having a bunch of things running in the background will bog down active play. 

[Sharpy]

6 hours ago, FungusForge said:

This still would be limited to the active vessel, but it could conceivably be done. Even if they made a KSP2 I have doubts they'd make stuff like this run in the background, because optimizations or no, having a bunch of things running in the background will bog down active play. 

The idea is that it would NOT be limited to current vessel. And with sufficient optimization, it could run dozens, maybe hundreds vessels simultaneously. Take your average CRPG like Skyrim... and it does run hundreds of scripts simultaneously. Look at the gameplay trailer for Cyberbunk 2077, each of hundreds of NPCs runs a script. This IS doable. Applying physics like a planet surface vs wheels would be trickier, but again, not so much it couldn't be done. And there's a lot of room for optimization.

[RealKerbal3x]

On 8/25/2018 at 12:37 PM, Gidreess said:

 

• Optimization is the thing we all want.
• KIS and KAS in stock game.
• Life Support that we can disable if we want.
• Real Solar System (If you are creating new save it should be an option to use Kerbal system or RSS).
• OPM and other planet mods, so you can enable or disable planets from these mods in stock.
• Manned planet exploration is a bit boring, but what about caves? What about geysers so you can get electricity on your base?
• Included USI, Near Future, Color Coded Canisters, Community Tech Tree, Unmanned Before Manned, Engine Lighting, Planet Shine and also more Graphic mods.
• Graphics in the stock are bad. Very bad. What about simple atmosphere and water? Simple version of Scatterer will be enough, but stock clouds will be even better.
• Kerbin not to look like lifeless planet with only our buildings.
• Parts with reflection (Also graphics, but that will look good).
• "Portrait stats" in the stock.
• SCANsat.
• "TakeCommand" to launch kerbals in the seats.
• "Trajectories" in stock. If something in carrier is upgraded, maybe add an option to predict landing place and aerobraking at atmosphere?
• Transfer Window Planner.
• "Precise Maneuver" mod?
• "Time Control" mod with all it's features.
• A bit more antennas for really far travelling.
• SSPXr and colonization. You can make it into DLC, still with life support will be awesome.
• Aerodynamics, of course based on real ones.

At least one of the things you want in KSP is coming in the next update— IIRC the latest KSP weekly confirmed that 1.5 will let you launch kerbals in command seats.

I agree with most of your suggestions, but unfortunately most of them will likely never make it into the game or its successor (if they ever make one).