Rewriting the "on Rails" code?

[Sathurn]

How hard would it be to rewrite the "on rails" code so that ship's equipment is ran say every 100 sec, 200 sec or some other time frame.

This would allow scientific equipment to add science to their on board count, and subtract electricity.

This would allow solar panel to calculate weather or not to add electricity.

This would allow space junk to de-obrit, if it's pe is low enough.

This would allow mapping sat (mod, or added) to map while on rails.

This would up the demands on the computer.

Would it be worth it?

[Sirrobert]

I would love for a way to adjust this in the settings. More detailed behavoir of your on rails stuf at the cost of more performance

[Kasuha]

I don't think the "on rails" code needs rewriting. It needs some improvements but its basis is good.

It might (and I think it should) evaluate when the trajectory crosses important regions - when it crosses a SOI boundary, when it crosses atmosphere boundary, when it crosses planet shadow boundary etc. The timestamp of the nearest upcoming event would be stored with the ship. During time warp the game would evaluate which of existing ships has the nearest event and whether it is before the current warp step or not. And when an event comes first, it would step only to that event and perform all necessary adjustments, then evaluate when the next event comes and continue executing the warp step. With that, many things like above would be possible without any significant slowdowns of time warp. Even higher time warps would be possible, too.

[boomerdog2000]

How hard would it be to rewrite the "on rails" code so that ship's equipment is ran say every 100 sec, 200 sec or some other time frame.

This would allow scientific equipment to add science to their on board count, and subtract electricity.

This would allow solar panel to calculate weather or not to add electricity.

This would allow space junk to de-obrit, if it's pe is low enough.

This would allow mapping sat (mod, or added) to map while on rails.

This would up the demands on the computer.

Would it be worth it?

Pretty sure this would lead to a lag spike every(whatever interval you go with) since at that moment the game would have to simulate the physics of every part of every ship in your save file.

[Sathurn]

Pretty sure this would lead to a lag spike every(whatever interval you go with) since at that moment the game would have to simulate the physics of every part of every ship in your save file.

If you tried to due every object at the same time, you bet it would cause a lag spike. How ever if spread at the calculations over the entire period it might be doable. As the other guy said, having events trigger a recalculation would probably work better.

[boomerdog2000]

If you tried to due every object at the same time, you bet it would cause a lag spike. How ever if spread at the calculations over the entire period it might be doable. As the other guy said, having events trigger a recalculation would probably work better.

Then the entire game would become laggy all the time. Having the events trigger recalculation would still run into the problem of calculating the physics of multiple crafts at once.

[vexx32]

All things considered, I don't think this is the tidiest solution. I think it would be much better if the on-rails simply did simple maths to account for all these things. If you work out the surface area of a vessel at its current angle of attack, you can get a reasonable trajectory prediction for it falling through the atmosphere. It isn't as accurate as simulating all the physics on it, but it's accurate enough that it should not cause any undue errors. The maths for all the other stuff -- science, solar panels, etc. -- is even simpler.

[allmhuran]

The physics side of rails is deterministic and seems to work OK (with the exception of inaccurate calculations on SOI changes, but there are easy ways to fix that which have been presented in other threads)

What we are really talking about is for the most part, other functionality that will not have any effect on the physical characteristics (speed, mass, etc) of the craft, and therefore will have no impact on the deterministic physics calculations. This would exclude de-orbiting, but I think that's a small price to pay.

As such, timer events to do a satellite scan, energy drain, etc, should not cause too much of a problem.

[giltirn]

I just want them to improve SOI transitions such that you don't have to do correction burns every time you change SOI.

[TMS]

This is what needs tweaking: http://forum.kerbalspaceprogram.com/threads/53667-SOI-transitions-introduce-trajectory-errors-depending-on-warp-factor?p=710149&viewfull=1#post710149

[Kasuha]

I just want them to improve SOI transitions such that you don't have to do correction burns every time you change SOI.

You don't have to do them - or you can minimize them - if you always make sure to cross the SOI at x5 time warp.

[vexx32]

The trajectory errors are -- at my best guess -- the result of the game not attempting to predict when the SOI crossover happens, and simply breezing past the actual SOI intersection because of the warp speed before actually noticing a SOI change. There should be a clause in the rails code that checks for an SOI change in between the steps it takes at that speed​, so that it won't miss it.