Burn in time warp with RO ion engines (new feature suggestions)

[Kerbinator-Fras]

As in reality,ion engines has a very poor thrust (0.092N Vac in 1.6.1 RO as of NSTAR) ,so burn will last for hundreds of days which is really annoying but quite realistion(Dawn burnt for 270 days as 1 burn).As principia make high physics warp in BetterTimeWarp extreme laggy(and the burn will still last for a computer's whole day if use 100x physics warp maximum)so it must be executed in on-rail high time warp.I know principia has a good prediction under thrust so I hope to change this into a executor (spaceship will follow the prediction with thrust,and it's relatively easy since Principia use forces during timewarp on gravity) on and drain required resources (for example xenon(or Argon) gas and electricityfor RO NSTAR ion engine ,but tweakable depending on engine) from resources,and timewarp will be forced to stop if one resource is drained and time warp will stop and warning text will be shown.(pls prevent game crashing!)
Why I have to submit this issue is because KSPI and DSEV`s plugin work only for stock patched conics orbit system (completely disabled by Principia) and they force orbit parameters to change during time warp.(KSPI is completely uselsss,while DSEV drain resources but does not bring any velocity change)But as a RO user I hate to use stock ion engine which violated energy conservation by 1k times.
Hoping to see improvement next moon and tell us how to use this API in cfg files,and thus it will be applied to RO ion Engines,and fusion torches with Mm/s level burn in KSPI&DSEV,and Photon sails in KSPI.
(@sswelm and @Angel-125 for KSPI&DSEV support)
Anyway,again hoping to see improvement next moon.

[sswelm]

I would love to add this but Eggrobin sais it cannot be done

for a more detailed answer see:
https://forum.kerbalspaceprogram.com/index.php?/topic/162200-wip151-161-17x-principia%E2%80%94version-fibonacci-released-2019-09-28%E2%80%94n-body-and-extended-body-gravitation-axial-tilt/&do=findComment&comment=3656533

[sswelm]

The problem is that there is no way to accelerate a vessel during timewarp with Principa installed.

[Kerbinator-Fras]

Well,the solution may be insert your powered flight plan integration method into prediction.That's to say,well cruise control setting could be setting use a node(then node may appear to have resource-binded infos to prevent over-dv-burns),then a flight-plan-type powered extremely long node will be auto created and insert into prediction line and then during timewarp resource check(especially for ion engine electricity draining which does not ) will be binded with ever integration step.Then if prediction end time doesn't reach end of line and resource deduction plugin goes normal,it goes on and then follow into next loop.
Also this can also grow into a hacking tool,by removing the resource draining plugin's bindings completely ant it will be eve more useful for debugging time when we need to check a part of flight(a more advanced orbit hyperedit tool!)--for debugs only,NOT CHEATING
Also I'm contacting RF authors to get a proper resource draining plugin instead of DSEV's plugin in conflict with RF.Note again that principia should be optimised for RO than stock.
And one more things is that I think the mulit-body core is even nearly enough since Cramer 1.2.2(except for inablity of milti-node planning),so I think Ferrari is good enough in CORE.
(frame is still WIP,thinking for better coding guidance which you could place code blocks)

[Kerbinator-Fras]

Well now I'm using 1000x physics warp as a bare solution.I'm still wondering why your flight planner can manipulate orbit but the flight calculation cannot.(Maybe a static model is simpler?)

[lamont-granquist]

You can integrate the rocket equation and update position and velocity and decrement propellant in time warp. That is the easy part.

What is the control for the direction the vessel is pointing and what guidance law are you using, and what is the UX/UI for the user to input properties of that guidance law?

Pointing in a single direction is going to be garbage. Following an impulsive KSP maneuver node is going to be hot garbage. Starting and stopping the time warp in order to halfway get some precision with the burn is going to be very difficult for human users.

There do exist low thrust guidance laws, like the Lawden Spiral, but you not only need to program that kind of guidance law, but you need a trajectory optimizer so that it calculates a maneuver to its conclusion that results in arriving at least very near the destination. That is the actual hard part here.

Because if someone builds the capability to have low thrust burns without solving that problem, you're going to suddenly realize how bad that feature is to use.

I expect if I go looking at the various abandoned persistent thrust mods throughout the years that the common theme I'm going to find is that the authors solved the basic problem of persistent thrust, but then without a trajectory optimizer and guidance law on top of that it turned into an unusable mess.

[sswelm]

perhaps you didn't notice but KSPIE peristant thrust does support active navigation locking meaing it will adjust its directly exacly as you would do follow a navigation burn in real time.

[Kerbinator-Fras]

I think is it able to restrict usage to make things clearer; if this is just moving the plan integrator to flight, then restricting usage will simplify other works to get it implemented (in official RO wiki on GitHub, it was said that Orbit Manipulator that old mod could have implemented this, which featured same as Principia)
Start the burn with if both electric-thruster and SAS exist(no matter how weak, because thrust sufficiently low), and lock position to a same point (inertial or relative to velocity)
Also, the goal is to directly implement this as a principia feature, not to make outer mod(for example, persistent thrust) work in principia. However, it may be just a consistent force port of Principia (resource draining can be done by other mods to save coding amount)

[Kerbinator-Fras]

Now starting to find usables and difficulties
Usable No.1: Code of Persistent Thrust mod to take over interaction of KSP
Difficulty No.1: Prediction definition (complete curve of inertial cruise? complete curve of persistent thrust? cutdown at a fixed time? this will leave it undefined, need additional UI to restrict the definition of prediction line.

[Kerbinator-Fras]

egg — 16:36 2021.12.29 UTC, at KSP-RO discord
come to think of it, now that we have rotation and thus that Principia has its own copy of the mass of every part, resource consumption is even more complicated than it already is, we would need to update the masses in our data (and then to do so in a way that is consistent with the laws of physics, so figuring out where the angular momentum goes, and whether jet damping is a thing), so resource consumption is even harder than it is for Kerbalism.
https://discord.com/channels/319857228905447436/480397772248580098/925789455816749087

[Kerbinator-Fras]

current status: a temporary solution is reached, by Charon_S. and me, with a fairly OK accuracy with acceptable time efficiency.
firstly, the result is, 500x physics warp is actually useful, for principia which make persistent thrust not working. This enables the use of principia with low thrust vessels (for example, RO ion engines, etc.)
The trick here is to disable quicksaves by editing settings.cfg: set autosave interval to 300000000s(300mil). this will disable autosave. principia autosave is known to be very laggy due to require of storing numerical data (large size and compression process issues), and autosave of KSP is affected by physics warp, if you use default 300s, it will be 0.6s per save and lag to death. but beware that you need to save manually once you finish the burn, and any time according to your need (such as important process points), and if you quite KSP by crashing the exe or taskkill your progress will be lost, this is a caution.
--------
for accuracy and performance:
with default settings your physics warp rate may not exceed 500x. otherwise the apparent Isp will increase significantly. error of impulse is no greater than 0.1% even at 1200x physics warp thanks to stable c++ core of principia. but fuel deduction can go wrong, you'll have less fuel deducted than it should be, either because physic frame begin to lose, or a physics frame have a maximum length of 10s (this is implied by KSP's default 0.02s physics delta settings. 0.02x500=10)
this require some at least medium-level PCs, and best at winter. if you are using laptop, low-voltage CPU is probably not quite useful, for gaming laptops you need to make sure intel turbo on so that you don't lag too severely. by the way, part count doesn't matter much (only framerate will be really low for 100+ parts. still, less parts = better performance.)
https://www.youtube.com/watch?v=bQLjdoeZUS8 main video of Haumea mission
https://www.youtube.com/watch?v=-Fp3RbVlpgs Haumea orbit insertion footage (a year-long node, 6 segments, 30h real time)
initially developed by Kerbinator 2022.1, and proved by Charon_S. in 2023.10-11.