Jump to content

[WIP][1.3] PersistentThrust v1.0.9


mrsolarsail

Recommended Posts

PersistentThrust is a plugin that allows propulsion systems to operate during timewarp. The plugin includes a new solar sail part and module that allows a spacecraft to be propelled only by sunlight. It also adds a module with a patch to the stock ion engine that allows engines to thrust during timewarp. This plugin was previously a part of SolarSailNavigator, which allows you to plan maneuvers with solar sails or long duration engine burns. Development discussions specific to this module will take place here instead of in the SolarSailNavigator thread.

The source code is available on Github: https://github.com/bld/PersistentThrust

The plugin can be downloaded from Github: https://github.com/bld/PersistentThrust/releases

Features:

 

  • Animated solar sail part from KSP Interstellar by SasquatchMarmalade
  • Solar sail module modified from the original in KSP Interstellar
  • Persistent Engine module for operating engines during timewarp
  • Patch to the stock ion engine using ModuleManager with realistic thrust (0.25 N) at the same power level. Use as an example to patch your own engines.
  • Operate any combination of engines and solar sails
  • Consumes any number of engine propellants with mass from the vehicle during timewarp
  • Virtual methods for calculating deltaV, resource consumption, and applying resource consumption

 

Known issues:

 

  • Disabled during timewarp on a suborbital trajectory due to a bug in perturbing the suborbital orbit
  • Consumption of massless resources during timewarp disabled (e.g. ElectricCharge) due to a bug in how KSP requests resources at high timewarp
  • When the thrust of a persistent engine is too high (above ~5 kN), KSP won't allow switching to timewarp (need to check if this is still an issue in v1.0.8)

 

Changelog: see https://github.com/bld/PersistentThrust/releases

Thank you to FreeThinker and Felger for reviewing the code. Thanks to OctarineNoise for the fix to address physics lag.

03C1CBC559D46A9A1DB1C6D4159A83E3E74BE29D

Edited by mrsolarsail
Updated to work with KSP 1.3
Link to comment
Share on other sites

Thanks all. Make sure to check out SolarSailNavigator to see where your ion engines and sails are going.

- - - Updated - - -

Good to see you created a sperate Mod for this, I will integrate additional fixes into the Persistant thrust engines code

Thanks for all the feedback. See the v1.0.2 branch for the latest changes: https://github.com/bld/PersistentThrust/tree/v1.0.2

I'm making OnFixedUpdate more modular with methods to calculate & apply deltaV and resource consumption.

Edited by mrsolarsail
Link to comment
Share on other sites

does this work in realism overhaul? even if it doesn't this is awesome!

Thank you. I haven't tried RO, though my ModuleManager patch to the ion engine reduces the thrust to 0.25 N (while keeping the ElectricCharge usage the same), which is how much thrust a state-of-the-art NASA ion engine produces. That low thrust level is effectively useless with KSP's stock maneuver planning tool, which assumes short duration high thrust burns. So, that's why I wrote SolarSailNavigator.

Link to comment
Share on other sites

From a comment on the SolarSailNavigator thread:

Excellent, looking forward to it!

In the more near term, did some tinkering last night, and have a couple of questions. For some context, I'm hoping to deploy this as one of our recommended mods for Realism Overhaul.

Great! I hope I can make it work for you.

One thing that's going to present some difficulty is the custom engine module you use, especially since we're already juggling a few other types. I believe near future propulsion uses one, and real fuels uses one as well, though that's less important overall, since this use case trumps the real fuels use case IMO. However, I'll have to talk to NathanKell about adding support for Persistent Engines to RealFuels engine configs, so we can have multiple fuel configs for our ion engines.

So far, no feature requests! We're doing well!

The next thing on my list is compatibility with near future's custom engine modules. To replicate some realistic engine behaviors, he coded up some adjustable-on-the-fly engine modules, which is very cool, but breaks compatibility with persistent thrust. In the near term, we can just force those to use persistent engine, but long term I'd love to either see that supported, or somehow change the engine modules around.

Would it help if PersistentEngine was added to an engine part as a separate module instead of inheriting and replacing the engine module?

Finally, I'm having a terrible time getting consistent power draw from my engines. Probably me doing something dumb, but in the VAB it claims a draw of 2.3 (modelling NSTAR) , in orbit it claims 3.9, and in time warp it was claiming something like 0.6. Is there an easy way to quantify power draw that you're aware of?

Well, resource consumption isn't entirely working right now. Propellant mass is working. But, when I tried to fly a solar electric spacecraft, at high timewarp the batteries were depleted, even though the solar arrays should have generated more than enough power for the ion engines and recharging the batteries. So, at the moment, massless propellants (0 density like ElectricCharge) are not being consumed.

Finally finally, if you like I can polish off your CKAN install files, I built most of the install files for realism overhaul and it's associated mods, so I can say I have a little experience.

Thanks, I could use some help there. PersistentThrust needs ModuleManager, and SolarSailNavigator will need PersistentThrust (once it's added to CKAN). I was also considering pulling the files from my Github releases.

Thanks for the awesome mod, this is going to be great, can't wait to fly some proper low thrust trajectories!

Let me know how it goes!

Link to comment
Share on other sites

...

Would it help if PersistentEngine was added to an engine part as a separate module instead of inheriting and replacing the engine module?

It'd certainly be the cleanest option. I'd be happy to help figure out how to do that, I've done a bit of c# myself, so I can pitch in on that if you want. Chatted with NathanKell, as long as PersistentEngines is derived from the ModuleEngines class, it should be compatible with RealFuels, however if it's custom and doesn't fork the class at all, then it'd be a bit more complicated. In the end, for compatibility, it's probably easiest to just use the stats from whatever ModuleEngines* is used on the part.

That does leave the question of how to change particle spawning during time warp. I believe ModuleEnginesFX nixes that, but it'd be nifty to have engine effects still active while the engines are active. Guess it's a "cross-that-bridge-when-we-come-to-it" sort of thing, although I think the old OrbitManipulator mod that used something similar, but utilized ModuleEngineFX (source here) and could spawn particles at a reasonable rate during time warp.

Took a look through Nertea's source (source here) for Near Future Propulsion, and it appears he modifies ModuleEngineFX on the fly for both of his modules. That lends further credence to the idea using the stock engine modules, and who knows, maybe it'll fix the electricity consumption bug!

I tested the NearFuture Engines in game, and you can access and adjust the parameters during time warp, so it'll likely be necessary to re-access the engine parameters frequently, though probably not on every time-step to minimize the performance hit.

Well, resource consumption isn't entirely working right now. Propellant mass is working. But, when I tried to fly a solar electric spacecraft, at high timewarp the batteries were depleted, even though the solar arrays should have generated more than enough power for the ion engines and recharging the batteries. So, at the moment, massless propellants (0 density like ElectricCharge) are not being consumed.

That's exactly what I just spent half an hour diagnosing, haha, I'm a genius! I suspect making use of the stock engine modules, or grabbing whatever ModuleEngines* is currently on the part would be sufficient.

Thanks, I could use some help there. PersistentThrust needs ModuleManager, and SolarSailNavigator will need PersistentThrust (once it's added to CKAN). I was also considering pulling the files from my Github releases.

Let me know how it goes!

Will do! Would you prefer to have CKAN reference KerbalStuff or Github? Both are equally easy.

Link to comment
Share on other sites

Put together the updates to the NETKANs to redirect CKAN to look at Github, unfortunately CKAN doesn't recognize pre-releases, so it won't be able to download from Git unless you mark the latest two as regular releases.

As a workaround I marked the netkans as "development" rather than "stable", so users are still informed about the potential for bugs and instability.

Link to comment
Share on other sites

Put together the updates to the NETKANs to redirect CKAN to look at Github, unfortunately CKAN doesn't recognize pre-releases, so it won't be able to download from Git unless you mark the latest two as regular releases.

As a workaround I marked the netkans as "development" rather than "stable", so users are still informed about the potential for bugs and instability.

Ok. I unchecked "pre-release" in the Github releases.

Link to comment
Share on other sites

It'd certainly be the cleanest option. I'd be happy to help figure out how to do that, I've done a bit of c# myself, so I can pitch in on that if you want. Chatted with NathanKell, as long as PersistentEngines is derived from the ModuleEngines class, it should be compatible with RealFuels, however if it's custom and doesn't fork the class at all, then it'd be a bit more complicated. In the end, for compatibility, it's probably easiest to just use the stats from whatever ModuleEngines* is used on the part.

I can take a stab at it. I'm learning C# with this project. PersistentEngine currently inherits ModuleEnginesFX, so it is a derivative. But, I can change it to an additional part module that uses whatever ModuleEngines* is on the part. Would that let the other custom engine modules do their thing?

That does leave the question of how to change particle spawning during time warp. I believe ModuleEnginesFX nixes that, but it'd be nifty to have engine effects still active while the engines are active. Guess it's a "cross-that-bridge-when-we-come-to-it" sort of thing, although I think the old OrbitManipulator mod that used something similar, but utilized ModuleEngineFX (source here) and could spawn particles at a reasonable rate during time warp.

Yeah, that would be pretty cool. At least the ion engines glow blue during timewarp. I haven't tried it with a rocket yet. We could work on it.

Took a look through Nertea's source (source here) for Near Future Propulsion, and it appears he modifies ModuleEngineFX on the fly for both of his modules. That lends further credence to the idea using the stock engine modules, and who knows, maybe it'll fix the electricity consumption bug!

I'll test if making the change fixes things. I'm using "Part.RequestResource" on the propellants during timewarp. It works for the massive ones.

I tested the NearFuture Engines in game, and you can access and adjust the parameters during time warp, so it'll likely be necessary to re-access the engine parameters frequently, though probably not on every time-step to minimize the performance hit.

I'm currently saving throttle, thrust, and Isp during realtime and using the saved values during timewarp. SolarSailNavigator updates those saved thrust/throttle/isp values itself from the maneuver commands, so I think it's pretty efficient. When it switches back to realtime mode, the throttle is updated from the saved one.

That's exactly what I just spent half an hour diagnosing, haha, I'm a genius! I suspect making use of the stock engine modules, or grabbing whatever ModuleEngines* is currently on the part would be sufficient.

Will do! Would you prefer to have CKAN reference KerbalStuff or Github? Both are equally easy.

Link to comment
Share on other sites

I can take a stab at it. I'm learning C# with this project. PersistentEngine currently inherits ModuleEnginesFX, so it is a derivative. But, I can change it to an additional part module that uses whatever ModuleEngines* is on the part. Would that let the other custom engine modules do their thing?

Yeah, did some testing with everything as-is, and while (as expected) if I patch the near future engines to use PersistentEngine they function normally (drawing double expected power aside), changing the ISP/Thrust mode doesn't function. Could be one of two things, either PersistentEngine doesn't reload the changes, or NFP is looking explicitly for ModuleEnginesFX and attempting to modify it.

In the long run though, swapping to using the existing ModuleEnginesFX or ModuleEngines nodes and just reading their state should be a much more compatibility-friendly method. Looking through how HoneyFox implemented that, it doesn't look too hard to replicate. The pertinent code is here:

https://github.com/HoneyFox/NBody/blob/master/WarpableEngine.cs#L186-L273

Yeah, that would be pretty cool. At least the ion engines glow blue during timewarp. I haven't tried it with a rocket yet. We could work on it.

Agreed, and it might even be pretty easy. Looking through HoneyFox's code from the now-defunct Orbit Manipulator, it only took a few lines to handle the FX generation during time warp (I believe the stock game terminates FX generation during time warp by default).

I'll test if making the change fixes things. I'm using "Part.RequestResource" on the propellants during timewarp. It works for the massive ones.

I suspect the stock modules do the same thing. I wonder if your request for the time step is higher than the total charge on the part, that's the source of the behavior. Even if the EC production is high enough. Maybe if you check to see if the EC available is less than what you need, then split it into smaller requests that all are less than the total available?

I'm currently saving throttle, thrust, and Isp during realtime and using the saved values during timewarp. SolarSailNavigator updates those saved thrust/throttle/isp values itself from the maneuver commands, so I think it's pretty efficient. When it switches back to realtime mode, the throttle is updated from the saved one.

Yeah, the NearFutureProp modules adjust thrust and ISP on the fly, so whatever the plugin does, it needs to catch those changes, or we could ask Nertea to lock that down during time warp. In all likelihood, you're not going to want to change it in the middle of a burn, you'll really only want to use the high-thrust low-isp mode for insertions and whatnot.

However, it looks like it updates the engine object when it does (and it identifies the engine object by its partmodule name, it does look for ModuleEnginesFX directly). So we catch engine updates by simply using the engine object in every frame to grab Isp and Thrust.

- - - Updated - - -

Oh, and I got the update to the Netkans done, PersistentThrust and SolarSailNavigator are on CKAN, and install from Github. Will need to update KSP version compatibility when KSP updates, or set it up to draw from a .VERSION file in the download.

Link to comment
Share on other sites

Yeah, did some testing with everything as-is, and while (as expected) if I patch the near future engines to use PersistentEngine they function normally (drawing double expected power aside), changing the ISP/Thrust mode doesn't function. Could be one of two things, either PersistentEngine doesn't reload the changes, or NFP is looking explicitly for ModuleEnginesFX and attempting to modify it.

In the long run though, swapping to using the existing ModuleEnginesFX or ModuleEngines nodes and just reading their state should be a much more compatibility-friendly method. Looking through how HoneyFox implemented that, it doesn't look too hard to replicate. The pertinent code is here:

https://github.com/HoneyFox/NBody/blob/master/WarpableEngine.cs#L186-L273

Ok, I modified PersistentThrust to add PersistentEngine to a part with ModuleEngines. I put it in a pre-release to try out. This breaks a couple things in SolarSailNavigator, but I'll make those updates in the next release of both. See: https://github.com/bld/PersistentThrust/releases/tag/v1.0.4dev0

The code for this branch is at: https://github.com/bld/PersistentThrust/tree/v1.0.4

Link to comment
Share on other sites

  • 2 weeks later...

For some reason, this mod isn't working at all for me(I'm trying to use ion engines.) Any idea why?

Using KSP v1.0.4 and PersistentThrust v1.0.3. Using MechJeb, Nuclear Pulse Mod(Orion), HyperEdit(warning: made for v1.0.2), and RLA Stockalike. Ship I'm trying to use it on has stock, MechJeb, and RLA Stockalike parts.

Edited by TotallyNotSatan
Link to comment
Share on other sites

Ok, I modified PersistentThrust to add PersistentEngine to a part with ModuleEngines. I put it in a pre-release to try out. This breaks a couple things in SolarSailNavigator, but I'll make those updates in the next release of both. See: https://github.com/bld/PersistentThrust/releases/tag/v1.0.4dev0

The code for this branch is at: https://github.com/bld/PersistentThrust/tree/v1.0.4

Huh, I didn't get an email notification for this post. Weird.

Anyway, did some testing, it seems to work great, catches the mode switches and everything! The only hangup is that throttling up seems to kill timewarp for ModuleEnginesFX-using engines. You might have to use a separate throttle from the game throttle, since I'll bet that's a feature of the stock engine modules.

- - - Updated - - -

For some reason, this mod isn't working at all for me(I'm trying to use ion engines.) Any idea why?

Using KSP v1.0.4 and PersistentThrust v1.0.3. Using MechJeb, Nuclear Pulse Mod(Orion), HyperEdit(warning: made for v1.0.2), and RLA Stockalike. Ship I'm trying to use it on has stock, MechJeb, and RLA Stockalike parts.

I suspect you're not using the stock ion engine? I believe mrsolarsail only has a patch for the stock ion, everything else is unsupported at this point.

Link to comment
Share on other sites

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