mrsolarsail

[WIP][1.3] PersistentThrust v1.0.9

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

Share this post


Link to post
Share on other sites

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

Edited by FreeThinker

Share this post


Link to post
Share on other sites

This is exciting, I look forward to seeing this develop! Congrats!

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
Will this work with any engine, or just the solar sail and stock ion engine?

I've included a ModuleManager patch to the ion engine with the plugin, but it should work with any engine.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

I posted a new version, v1.0.3, with a very minor change: the "averageDensity" field is now public, for use by SolarSailNavigator's mass prediction calculations.

Share this post


Link to post
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!

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

I'm using the "Dawn" ion engine. The stock one. I do, however, have non-stock parts on my ship(and non-stock ion engines available in the VAB); could that have anything to do with it?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.