Felger

Posted a new version of RealPlume - https://github.com/KSP-RO/RealPlume/releases, shouldn't break much, may want to check out engines that use Hypergolic-OMS-White. Marked as compatible with 1.1, so ckan should pick it up soon. Should also be backwards compatible with 1.0.x as well.

Thanks for keeping this going in my absence!

Probably better to make a new thread at this point, with everything going on on my end, I won't really have the opportunity to regularly update this one. You and @Nhawks17 should be able to merge and draft releases.

I still plan on keeping up (when I get time again) the main RealPlume mod, and @sarbian manages SmokeScreen, so that'll stay up to date. I'll see about getting you and Nhawks privileges on the repository so you can post releases and accept pull requests.

It's not dead per se, I've just not had time to work on it in the past month or so. Also 1.1 On which note, if anyone would like to take over maintenance of RealPlume Stock Configs, I'd be happy to hand the reigns over. I know @Nhawks17 and @DerpyFirework have done a lot of work with this, and are likely familiar enough with the architecture of the mod to do upkeep. I've got the pull requests on github incorporated, and released, but I'm afraid my schedule doesn't really allow for more than that at this point. Even when real life settles down a bit, I'll probably go back to spending most of my time on Realism Overhaul, so I'd love to see someone take the reigns and continue the work on the stock configs for RealPlume.

Not quite. The way the particle emitter works, it'll just release all those particles on the same frame, and they'll stay bunched. There's not a super clean way to do it, I kludged in a way into smokescreen, vRandPosOffset, which offsets the particle in the velocity direction a random amount, to help eliminate the line of dots. Example: https://github.com/KSP-RO/RealPlume/blob/cc1982fc9534be61e64d892c163893e1fd660697/GameData/RealPlume/000_Generic_Plumes/Hypergolic-OMS-Grey.cfg#L71-L76 - - - Updated - - - Also, if you get something awesome going for the core plumes, feel free to submit it as a PR and I'll add it into the core mod. Always love to see people tinkering with improvements!

On Blizzy's Toolbar, pull up the SmokeScreen button and set the particle count down. In the next version of the mod I'll add an optional patch that removes all smoke.

Don't do it per-engine, that'd be insane. Do it by the kind of plume, then set a color for each kind of plume. If you need to set a brightness, just figure some multiplier on the thrust and ISP.

The colors aren't really defined in the plumes, per se, just which particle object the plume spawns when in use. Probably the easiest way would be to do colors based on the PLUME node, something like: @PART[*]:HAS[PLUME[Kerolox*]:AFTER[RealPlume] { MODULE { name=EngineLighting ..... } } And then determining what color each plume should emit from this page: https://github.com/KSP-RO/RealPlume/wiki/PreFabbed-Plumes-and-Screenshots Which brings to my attention that a few of those are out of date. One more thing on the growing to-do list when I get some modding time.

Yes and no, it can't do multiples of the same plume, because the particle effects nodes can only be attached to one engine transform at a time. However, you can use multiple different plumes for that. I typically use something like a Kerolox-Lower and Kerolox-Upper (they're sufficiently similar) or a Kerolox-Vernier if the verniers are small. Make sure you give different powerEffectName to each ModuleEngineFX, correctly associating the right FX with the right engine node.

There should be patches for all the stock engines that adjust the plume if Ven's isn't installed, if some are still not matching up, let me know and I'll get around to fixing it. Eventually...

Eh, Novapunch is bloated, and most of the engines have terrible tankbutt syndrome. You're welcome to configure it, but it's not high on my list for my own configs. Yep, my mistake. It's fixed in 0.8.1

How did you install the mod? If you didn't install via CKAN, double check that you have all the important bits installed. Items you need in your GameData directory for this to work: SolarSailNavigator PersistentThrust ModuleManager.dll If you already have those, we'll have to come up with another troubleshooting step. Nope, requires the vessel to be in focus unfortunately.

Hmm, well, I tried it with the VASIMR from Near Future Propulsion. To be fair, I didn't try it with an engine that uses ModuleEngines. When I get some time I'll try to replicate it with some other scenarios. Module Manager is pretty necessary for this mod to function, without it, the mod won't do anything.

Yeah, you're missing this rather important part of the mod: http://forum.kerbalspaceprogram.com/threads/119579-WIP-1-0-4-SolarSailNavigator-v1-0-5-alpha

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 - - - 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.

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 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 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? 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.

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.

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. 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.

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. 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. 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? 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 for the awesome mod, this is going to be great, can't wait to fly some proper low thrust trajectories!

You know, I've often given thought to building something like STK myself, would be nice to plan the mission out in that fashion to give some nice design requirements up front. It'd be quite the undertaking, though. There's a reason that thing is so expensive.

Idea: calculate closest approach to target, then burn in a direction that minimizes the closest approach continuously. Could probably borrow Sarbian's code from mechjeb

That seems useful as I'm imagining it, do you have a tool to help determine launch windows, and delta V requirements? If so, fine tuning the rendezvous becomes much easier. You could determine launch windows for a simple transfer iteratively give the vehicle by plotting the continuous burn assuming a circular to circular transfer, using that timing to get an approximate angular separation requirement, then re-calculating the trajectory for the elliptical to elliptical transfer. It would definitely need to be on a per-vehicle basis, as twr will vary by vehicle design. Doing this would also tell you the dv for the transfer. Actually, for a full mission, you could string together a series of these, plan a burn start angle so you eject from your parent body at the right angle for the transfer, then plan the interplanetary burn, rendezvous burn. Hmm, an interesting challenge, I had a matlab script I wrote back in college that worked all this out at some point for the DAWN mission, I think. Got pretty close to their transfer time and trajectory IIRC. Now, you've probably thought of all this before, I'll have to give some thought to how this would translate to an in-game tool the player could actually use to make transfers.

Wow, this looks awesome! Definitely giving this a go. Do you know if it's possible to spawn a stock orbit at the end point of your predicted continuous thrust trajectory to provide a rendezvous visualization in game? Perhaps something like a pseudo maneuver node. In trying to fix a typo, looks like I deleted my post. Well done, ksp forum mobile interface. Above is what I remember from that post.