Control distance extended or tweakable?

[liko2k]

Hello Kerbonauts!

I haven't found this topic on the banned or planned list. I couldn't find it through search either. So, my question is:

Due to the fact that the parts recovery has been implemented in the career mode, can the control distance be extended to, say 10-20km? Right now, if one wants to recover parts of spaceship such as boosters after they have been detached, it is not possible if the main spaceship moves further than 2.5km from the boosters. If the control distance was to be increased (even by individual tweaking) such recovery would become possible.

If I'm duplicating some post, please feel free to move or delete this one, but please point me to the main discussion about this problem

Thank you!

Edited July 30, 2014 by liko2k

[iStickyDuck]

I support this because even if I detach a stage that has parachutes on it, as soon as it hits the atmosphere when it's beyond 2.5km, it vanishes and becomes unrecoverrable

[vexx32]

This would cause a hell of a lot of lag, especially if you've got more than a few pieces flying off in different directions (e.g., in the case of spontaneous unplanned craft disassembly). If you want to give it a shot anyway, I'd recommend you give Romfarer's Lazor System a try -- that is one of its many features.

Edited July 30, 2014 by vexx32

[liko2k]

This would cause a hell of a lot of lag, especially if you've got more than a few pieces flying off in different directions (e.g., in the case of spontaneous unplanned craft disassembly). If you want to give it a shot anyway, I'd recommend you give Romfarer's Lazor System a try -- that is one of its many features.

Thanks for answer!

Do you think that now, when we are running 64bits version of the KSP and have large amounts of memory at hand, this would still cause a lot of lag? Do you know what is the control radius in the Lazor mod?

Besides, what is the difference of falling apart on the launchpad and falling apart in the atmosphere? Once landed, the parts can be uncontrollable as, for example, planted flags (and recovered at the end of the mission).

[M3tal_Warrior]

Do you think that now, when we are running 64bits version of the KSP and have large amounts of memory at hand, this would still cause a lot of lag?

You don't get the point of both what he said and what 64bit does.

64bit enables a computer to allocate more than 3.x GB of RAM, thus loading times decrease for most stuff can be kept in a sufficiently large instant-access-memory (that's what a RAM is). It does NOT increase the CPU performance, and since physics is solely a matter of CPU performance (or, if possible by game and GPU, a matter of the second graphic card), 64bit gains you nothing at all there.

What vexx32 tried to tell you is that the bigger the bubble of physics is, the more ships and parts will eventually fit in there -> more parts having to be physically processed -> more load on the CPU/GPU -> less FPS -> more lag.

[liko2k]

All right, it makes sense. I thought that memory IS used in larger quantities in more power-hungry computations. Nevertheless, it is still a bubble. When you are lifting from launchpad, radius on the ground gets smaller and smaller, eventually getting out of range of simulation. There would be enough time for parts to land. And again, if your computer is capable to calculate all parts during the spontaneous disassembly, it will be able to calculate them until you order a cleanup and recovery of all surviving parts for cash.

Besides, it would be good to let people with more powerful machines to decide about this radius by themselves.

[M3tal_Warrior]

Well, technically more calculation do need more memory, but that's just a relatively small amount compared to graphics and planets and the rocket itself. And yes, the radius gets smaller, but after you reached 2564m, the radius equals zero and no calculations will be done for impact and other physics - and most of us reach 2.5km pretty fast.

Side note: It would be possible to adjust the size of the bubble on the fly based on the idle process usage of the system. A similar shot was made around 2000 with the game 'Sacrifice', which calculated graphic enhancement, polygons and other eye candy solely on your available GPU time and the distance between camera/sorcerer and object/landscape. This way there were almost no graphic settings ingame, it all was done by the game itself. AFAIK this was a unique feature and wasn't continued in other games, much to my regrets.

[liko2k]

Well, technically more calculation do need more memory, but that's just a relatively small amount compared to graphics and planets and the rocket itself. And yes, the radius gets smaller, but after you reached 2564m, the radius equals zero and no calculations will be done for impact and other physics - and most of us reach 2.5km pretty fast.

Side note: It would be possible to adjust the size of the bubble on the fly based on the idle process usage of the system. A similar shot was made around 2000 with the game 'Sacrifice', which calculated graphic enhancement, polygons and other eye candy solely on your available GPU time and the distance between camera/sorcerer and object/landscape. This way there were almost no graphic settings ingame, it all was done by the game itself. AFAIK this was a unique feature and wasn't continued in other games, much to my regrets.

It would be enough to have a slider to adjust the radius by yourself, or introduce auto-tuning option based on your example. The first is much simpler to implement though... IDK if this version is fully using all thread/cores in modern CPUs - if it does there is plenty of power on our disposal. Especially that the game is being developed for a long time now and a lot of advances were seen in the CPU world (especially in Intel's processors). What about openCL?

[Sky_walker]

This would cause a hell of a lot of lag

Depends on a hardware you have.

It might cause hell of a lag for you - but for me it'll most likely be perfectly playable.

[vexx32]

Go right ahead and try it, then. I personally don't think this is a useful solution to the problem you really want to address -- recoverability of craft. There are other abstractions you could use to simply perform a much more concise calculation to determine if a dropped section would reach the ground (and approximately where it would reach the ground, if necessary) along with which parts are likely to survive the landing (taking into account parachutes and so forth). It would be a simplified simulation, but I feel it would suffice for the purposes that OP seems concerned about.

[liko2k]

Depends on a hardware you have.

It might cause hell of a lag for you - but for me it'll most likely be perfectly playable.

Mine should be also capable of running it smoothly.

Go right ahead and try it, then. I personally don't think this is a useful solution to the problem you really want to address -- recoverability of craft. There are other abstractions you could use to simply perform a much more concise calculation to determine if a dropped section would reach the ground (and approximately where it would reach the ground, if necessary) along with which parts are likely to survive the landing (taking into account parachutes and so forth). It would be a simplified simulation, but I feel it would suffice for the purposes that OP seems concerned about.

You mean using LAZOR, right? I will try although I don't know how does the control limit works in that mod.

Currently there is no way to recover any part of a multiple-stage to orbit craft (except of course the lander itself) short of installing probe capsules on each boosters and trying to trace it down to earth... With the mods reproducing USA shuttles program for example it becomes even more important to be able to tweak this value.

[RenevB]

May I direct you to this thread which is 13 pages (which I did not all read) of discussion about much the same subject.