Jump to content

0.25 Discussion thread


EnderSpace

Recommended Posts

This idea that modeling something realistic is impossible in Unity is one of the greatest cop-outs this community has. I don't know where it started or why people keep repeating it. It's the worst attempt to defend non-realistic gameplay, because your argument falls apart completely the very second someone proves that it can be done, especially because it implicitly assumes that the only reason for not doing it is because you can't do it. You know, I'd bet money that if FAR didn't exist, everyone would say the same thing to excuse the stock aerodynamics system.

There are reasons to argue against realism on the basis that it is unfun, but don't sit there and say that such things can't be done as the reasoning. Most of what you're talking about can already be done in sims like Orbiter and X-plane, and they already had to tackle the same challenges that KSP would in implementing those levels of features. Code is code; it doesn't decide to melt if you combine it with a certain engine.

:) two thoughts:

- why people would assume kerbal's universe is ruled by the exact same rules as ours ? Who said it was the case ? The fact is players wants to keep their marks wherever they virtually go and makes every "sci-fi" games ruled by the physics laws humans have discovered for now.

It's a huge discomfort to move into unknown territories, left old habits behind, "think different" (but very different than one brand with an apple :P)

Why it couldn't be admitted that's bodies in kerbal's universes are stuck where they are and not submitted to gravity at all ?

Why the star should be warm at all ?

Why thrust can't be produced in apparent violation of the (in)famous 3rd law of thermodynamic ?

Kerbal's universe is not ours and don't have to be limited by our current understanding of the universe IMHO.

- the main problem which rise from studying one thing always the same way as others, from scientists to teachers to students, act as a blindfold. That's may explain why some geniuses comes from time to time to completely change the vision and the knowledge, they don't just follow the path the others are onto, they go where people taught them not to go, never, because it's too dangerous, because it could be considered "heretic". The same applied to game programming, if one people who work with unity (or any other engine) say one day "you just can't do that, period", people who follow the lead and do their own games moves and stop themselves to the invisible wall they have learn to believe it was just there, but it was not, and they don't know that, they even can't imagine they can go further, just one step ahead, and never move... until someone who have not learn the same way (self learner mostly) just cross the imaginary wall and shows it was in fact possible and the former people was wrong.

It's like people in the early days claiming human would never fly in the sky (something like "nothing heavier than air can fly, not a chance"), or for cars in the beginning of the 20thcentury: going faster than 40 km/h can't be achieve due to human biology. Some others don't care or keep their mind open... and did it !

Link to comment
Share on other sites

Performance. Fact that something is done in a mod, doesn't mean it works well on a fully deployed game.

I believe that that's exactly what devs mentioned as a reasoning for why n-body physics will never be in KSP.

And that performance limitation is directly a problem with the engine - Unity 5 seems to migrate it (multi-core physics) though we don't know when or if at all KSP will be ported to Unity 5.

Nope, not true.

In high school I once coded a very simple N-body system just for fun. It was 2D, but it was using 3D vectors anyway with the z component set to 0, and it could run smoothly with 100+ objects on screen. The real problem with N body gravity is that it is HARD, and that would be definitely way beyond a simple game's scope and in simulator's territory.

But it's not a performance issue, with less than 20 bodies in the system you are definitely not going to cause performance issues, and even there you could just limit it to the 3 or 4 most influential bodies.

EDIT: also, let's say that it does cause a performance issue. In that case, we could maybe accept to have fixed orbits for the celestial bodies and in that case the complexity goes from O(n^2) to O(n), which means it's basically free when you have so few elements to account for.

It's true however that for the number of bodies we are speaking of, O(n^2) is still very cheap. If FAR doesn't cause performance problems, I don't see why N body gravity would.

That being said, I'm not sure it would be a good addition to stock unless it can be turned off, because seriously, at that point the learning curve would be really steep, much more than with RSS. I'm still planning to use principia when it comes out though.

Edited by Ippo
Link to comment
Share on other sites

Nope, not true.

In high school I once coded a very simple N-body system just for fun. It was 2D, but it was using 3D vectors anyway with the z component set to 0, and it could run smoothly with 100+ objects on screen. The real problem with N body gravity is that it is HARD, and that would be definitely way beyond a simple game's scope and in simulator's territory.

But it's not a performance issue, with less than 20 bodies in the system you are definitely not going to cause performance issues, and even there you could just limit it to the 3 or 4 most influential bodies.

EDIT: also, let's say that it does cause a performance issue. In that case, we could maybe accept to have fixed orbits for the celestial bodies and in that case the complexity goes from O(n^2) to O(n), which means it's basically free when you have so few elements to account for.

It's true however that for the number of bodies we are speaking of, O(n^2) is still very cheap. If FAR doesn't cause performance problems, I don't see why N body gravity would.

That being said, I'm not sure it would be a good addition to stock unless it can be turned off, because seriously, at that point the learning curve would be really steep, much more than with RSS. I'm still planning to use principia when it comes out though.

If it were possible to integrate, N body gravity would be a very cool "hardmode" :D

Link to comment
Share on other sites

Nope, not true.

In high school I once coded a very simple N-body system just for fun. It was 2D, but it was using 3D vectors anyway

So you say that performance isn't a problem based on your high school experience?

Come on Ippo, you can do better than that.

KSP already has a performance issues with a single body physics. Look: First random large space station. And you argue with me that adding N-body physics wouldn't cause any performance issues. Oh come on....

Link to comment
Share on other sites

If the Kerbal "universe" is not to share the same physics as our universe, the game should be called Kerbal Ether Program, or something. Where will "lift wood" be in the tech tree, I wonder?

Most of us (all I've seen so far, but I've not been here that long) wanting "realism" are not demanding Orbiter, just getting the physics as good as is practicable for the stock game. I have seen anti-realism people on countless game forums over the years somehow equate "realism" with "unfun" and "hard." Realism and fun (for the large majority of players) are not mutually exclusive. Realism and "hard" are not mutually exclusive. Easy vs hard has at least as much (or more) to do with the tools provided (UI, etc) than the physics (a nod to the devs, BTW, that their user interface is actually really good, IMO, and makes things that might be daunting for some players make a lot of sense). Trying to keep the physics in line with the real universe is good because we know that the real universe makes sense. In doing science fiction, it's best to try and keep some grip on reality so unexpected consequences and inconsistencies don't break everything.

If you want to track your astronauts through careers, and their stupidity/courage is to matter, for example, then presumably there needs to be a way to actually kill them (deadly reentry, for example), something I've not managed to do yet (playing only a couple weeks now). As it is, the idea of anything making the game too hard seems fanciful to me. The first night after I downloaded the game, I successfully landed on the moon twice in science career (the first managed to leave the surface, but I had wasted so much fuel accidentally over thrusting and having to shoot the landing a few times that I could not make it home and Jeb was stuck in orbit (a terrible, retrograde, inclined munar orbit into the bargain), the 2d was a return trip). A couple nights after that, I rescued Jeb (wanted RCS first). I've not gone everywhere yet, but honestly, I will have run out of unplayed stock game in a couple weeks more of play (all done after the kids go to bed with a glass of wine or beer in one hand). It can likely bear some replay, but I have already DLed the first mods I plan on installing (FAR, life support, deadly reentry, etc).

Edited by tater
clarification
Link to comment
Share on other sites

Perhaps I am too late, but I would urge caution against turing this into an all-or-nothing argument. Realism is a continuous scale, and we all fall on different places along it. I myself have tried RSS and found it unenjoyable, but I happily play with NEAR and DRE, and I think they should be stock.

Link to comment
Share on other sites

So you say that performance isn't a problem based on your high school experience?

Come on Ippo, you can do better than that.

KSP already has a performance issues with a single body physics. Look: First random large space station. And you argue with me that adding N-body physics wouldn't cause any performance issues. Oh come on....

You are wrong: KSP is struggling to resolve contact forces between multiple bodies attached one to the other, which is objectively a hard task. The effects of gravity are instead a breeze, even in N body gravity.

Basically, what happens right now is that only the gravity due to the main body is computed. Instead, you could compute the gravity vector for all the 7 main bodies in the system (sun + 6 planets)*, sum them together, and then proceed as usual. You don't need to include the gravity from other parts (it would be absurd) and you can safely neglect asteroids too.

It is actually a very quick computation: if I have the time tonight, I'll code a proof of concept to show you.

*EDIT: and also moons, but you could just put a distance threshold to avoid wasting time computing the effect of gilly on something that is orbiting jool

Link to comment
Share on other sites

Wow, the hypeplane has sure taken a turn towards super-stall over the last couple of days. Maybe we should discuss everyone’s subjective demands for KSP in a new thread (name it “Devs be hearing my self-righteous rant of justice†or something :kiss:), and discuss here what might be added in 0.25 as the title and OP of this thread imply.

Back OT, the recent devnotes have shed more light on the features that are added in 0.25, including a difficulty options panel, crew transfer without EVA and vessel/kerbal flight logs. DanRosas mentions approximately 10% of 64 aesthetically congruent assets have been modeled so far.

Maxmaps mentions in the recent Kerbal Podcast that: “The admin building [makes] your play style way more customizable and [adds] a lot more interaction between the three currencies [i.e credits, tech and rep].†He also mentions: “there’s two more systems going in [to 0.25] that are going to modify how you play, one of them we’re gonna talk about next week and the other is gonna have to wait until QA, because it’s something that no mod has done to this point. [it] doesn’t affect gameplay that much, if you play really well you’ll never run into it. [This same] system includes about 90% of the framework necessary for the system we’re gonna drop into 0.26, that is really really huge and game changing, it’s as big as contracts at least.â€Â

When asked about how SQUAD sees KSP 1.0 Maxmaps says: â€ÂThere is a design document we have and then there’s a roadmap we have for scope completion, but we did our best to leave a good chunk of wiggle room for each object. For example, every update has about 6 to 7 features, the roadmap usually has 2 or 3, so we leave room for things that come up as we develop or what the fan base has shown us the game really needs [Max exemplifies with enhanced navball and menu for crew transfer for 0.25 and discusses plans for a fuel-transfer update].â€Â

Any idea what features will be implemented in 0.25 and what the big feature for 0.26 may encompass? Let the speculation continue!

Edited by Yakuzi
Link to comment
Share on other sites

You are wrong: KSP is struggling to resolve contact forces between multiple bodies attached one to the other, which is objectively a hard task(...) Basically, what happens right now is that only the gravity due to the main body is computed.

OK, fair enough. Somehow I always though that KSP calculates full physics for objects, not just a simplified point body. In that case - in deed adding n-body physics shouldn't be any problem performance-wise.

Link to comment
Share on other sites

OK, fair enough. Somehow I always though that KSP calculates full physics for objects, not just a simplified point body. In that case - in deed adding n-body physics shouldn't be any problem performance-wise.

It calculates gravity for individual parts for vessels within the 2.5km physics bubble, with each individual part being a rigidbody. On rails objects are treated as a single point following a predefined orbital path; as I understand it this is much less computationally intense than calculating gravity and trajectory continuously even if it's treated as a single point mass, as would be required for n-body.

The real performance bottleneck as I understand it is the interaction of parts within a given ship, this sort of chained rigidbody problem involves a lot of calculation dependent on the results of other calculations, so it's not easily multithreadable even if the engine supports multithreading. At best, a thread for each vessel in physics range could be done, so being near a staion wouldn't necessarily start lag like it does now. Once they dock or otherwise make contact, it's back to one thread though.

Oh look, 4000 posts! #NoLife #NeedsToGetOutMore #WishIHadAQuarterForEveryPost

Link to comment
Share on other sites

N-body gravity is the easy bit. The hard bit in my expectation is making map mode work with it. That requires the game to calculate not just the next time step, but every timestep for potentially years in advance in order to plot the orbit, and recalculate it for any ship when thrusting ideally every frame and certainly often enough to not annoy the player with laggy map updates.

You could duck the issue by still using patched conics for the map mode, but then it won't show the effects of n-body gravity and the paths it makes possible, meaning players will not have the tools to assist them in taking advantage of it and bringing into question why to even have it in the first place.

Link to comment
Share on other sites

N-body gravity is the easy bit. The hard bit in my expectation is making map mode work with it. That requires the game to calculate not just the next time step, but every timestep for potentially years in advance in order to plot the orbit, and recalculate it for any ship when thrusting ideally every frame and certainly often enough to not annoy the player with laggy map updates.

You could duck the issue by still using patched conics for the map mode, but then it won't show the effects of n-body gravity and the paths it makes possible, meaning players will not have the tools to assist them in taking advantage of it and bringing into question why to even have it in the first place.

Check out the Principia thread, it has some wicked orbit plots. Besides, it show that this performance bottleneck is not really significant (again, check out that thread: it's a pretty awesome read).

Red Iron Crown: IIRC, KSP doesn't actually compute gravity between parts, and not even for single parts. IIRC, it only calculates the gravity in the CoM of the vessel and applies it to every part of the ship, and that's the reason why there is no torque due to gravity differentials in the game. I might be wrong though.

Link to comment
Share on other sites

As a few have pointed out in the Principia thread, the ability to deal with forces while in "on the rails" time compression or higher compression "physics warp" is what would actually matter most because things like ion engines would actually work properly (constant acceleration trajectories).

Link to comment
Share on other sites

Red Iron Crown: IIRC, KSP doesn't actually compute gravity between parts, and not even for single parts. IIRC, it only calculates the gravity in the CoM of the vessel and applies it to every part of the ship, and that's the reason why there is no torque due to gravity differentials in the game. I might be wrong though.

That is what I meant, though you expressed it more clearly. :)

Link to comment
Share on other sites

Listen to the latest Kerbalcast, MaxMaps if I remember correctly will talk about the main implementations in .25. Here's da link: http://kerbalpodcast.libsyn.com/ You can also go to the latest DevNote and find the link in MaxMap's section and listen to it there. I won't ruin anything for you so if you want to find out just listen to the beginning minutes "first 10-ish if you want the most info and then there's a bit more at random moments throughout" but if not then no need to listen.

Link to comment
Share on other sites

Anyone mind to post a summary from that ^ ? I refuse wasting* an hour for something that probably can be cut to few positions on a bulleted list. >_>

* beware subjective opinion

Receive, and ye shall ask. Posted only a page before:

Wow, the hypeplane has sure taken a turn towards super-stall over the last couple of days. Maybe we should discuss everyone’s subjective demands for KSP in a new thread (name it “Devs be hearing my self-righteous rant of justice†or something :kiss:), and discuss here what might be added in 0.25 as the title and OP of this thread imply.

Back OT, the recent devnotes have shed more light on the features that are added in 0.25, including a difficulty options panel, crew transfer without EVA and vessel/kerbal flight logs. DanRosas mentions approximately 10% of 64 aesthetically congruent assets have been modeled so far.

Maxmaps mentions in the recent Kerbal Podcast that: “The admin building [makes] your play style way more customizable and [adds] a lot more interaction between the three currencies [i.e credits, tech and rep].†He also mentions: “there’s two more systems going in [to 0.25] that are going to modify how you play, one of them we’re gonna talk about next week and the other is gonna have to wait until QA, because it’s something that no mod has done to this point. [it] doesn’t affect gameplay that much, if you play really well you’ll never run into it. [This same] system includes about 90% of the framework necessary for the system we’re gonna drop into 0.26, that is really really huge and game changing, it’s as big as contracts at least.â€Â

When asked about how SQUAD sees KSP 1.0 Maxmaps says: â€ÂThere is a design document we have and then there’s a roadmap we have for scope completion, but we did our best to leave a good chunk of wiggle room for each object. For example, every update has about 6 to 7 features, the roadmap usually has 2 or 3, so we leave room for things that come up as we develop or what the fan base has shown us the game really needs [Max exemplifies with enhanced navball and menu for crew transfer for 0.25 and discusses plans for a fuel-transfer update].â€Â

Any idea what features will be implemented in 0.25 and what the big feature for 0.26 may encompass? Let the speculation continue!

Link to comment
Share on other sites

Anyone mind to post a summary from that ^ ? I refuse wasting* an hour for something that probably can be cut to few positions on a bulleted list. >_>

* beware subjective opinion

I listened to it while doing some plastering at home today. The dev said that aside from spaceplane plus, the focus of 0.25 was the new admin building, and how it would make more sense of career modes by factoring in money, reputation and science. Admin building makes play style more customizable and adds "interaction" between the three currencies (money/rep/science).

That was all in the first 5 minutes, and I switched to a ww1 history podcast for the remainder of my plastering after the podcast went off from 0.25 :)

Link to comment
Share on other sites

Receive, and ye shall ask. Posted only a page before:

Thanks for the repost monophonic.

For the sake of all that is Kraken, please stay on topic!!! (I'd use caps but Gregrox was told off earlier)

Edited by Yakuzi
Link to comment
Share on other sites

I'm confused by something in the podcast. He said that there's a secret system they're adding that will hardly affect gameplay, and if you play well you might never notice it. But then he says that same system is laying 90% of the groundwork for a huge, game-changing thing to come in .26. Do I have that correct? How is that even possible? How will 90% of a game-changing system hardly affect gameplay? And no modder has done anything like it? What could it be?!?!

Link to comment
Share on other sites

I'm confused by something in the podcast. He said that there's a secret system they're adding that will hardly affect gameplay, and if you play well you might never notice it. But then he says that same system is laying 90% of the groundwork for a huge, game-changing thing to come in .26. Do I have that correct? How is that even possible? How will 90% of a game-changing system hardly affect gameplay? And no modder has done anything like it? What could it be?!?!

My guess is that this system will have something to do with going bankrupt, or failing too many contracts, or something. I would bet that if you end up failing too many missions, or run out of funds, that an 'auto-pilot' mode will activate. In this mode (coming in 0.26), you will only have to worry about managing your contracts and funds, hiring Kerbals, and other 'Administration' stuff. You can leave the technical stuff like flying to space or landing on the Mun for the Kerbals to handle themselves.

Link to comment
Share on other sites

^^^ This will be disastrous!

I do not want to be too offensive, but losing is earning experience. Player must not be protected from losing. It is like pushing your D&D character slightly behind the death point and master says "OK, I think he has survived, and will be carried to the nearest town by your party". WHY? I am responsible for his actions. I want a heroic death, not another variation of all that disney stories...

The point is: If player loses all money, has no rep, and out of science - let's be fair, something went awfully wrong. We'd better allow him to "reclaim" leftovers of previous space program (Dwarf Fortress reference), by flying special "reclaim missions", which will put his control codes into spaceships left by other space programs. But we should never say "Hey, look, you failed, let's give you the 23rd chance. Press continue in nearest 10 seconds to continue... 9... 8... 7..."

I personally think that it can be some preparations for either aerodynamics overhaul, or some preparations for more planets, which were announced long time ago.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...