[1.6.1] RealPlume - Stock [v1.3.1 - 1/14/19] - Better Late than Never Update

[Nhawks17]

1 hour ago, gamerscircle said:

WHOA!  Really, that will be awesome.  Is this poodle fix something that might be applied to like the 909 as well?  It has been a while since I used RP, but I do recall that there was just a couple of engines that I could hear when I turned down the engine volume in the game.  Thanks for the update.

Hopefully so, yes.

1 hour ago, Phineas Freak said:

@Nhawks17 With the current system your best bet is to apply all patches as usual (:FOR[RealPlume-StockConfigs]) and after that  (:AFTER[RealPlume-StockConfigs]) to apply patches for any specific parts (like the AJE ones). But this will easily break or become obsolete if new parts are introduced.

A better way is to do what @Ser did:

@MODULE[ModuleEngines*]
{
  @name:NEEDS[!AJE] = ModuleEnginesFX
  %powerEffectName = Turbofan
  %spoolEffectName = Turbofan-Spool
}

This will set the engine module to be the FX one only if AJE is not installed. You will have to hunt down and check every part though (old or newly added) and apply the conditional check. That's why i offered the idea of decoupling the part from the plume patches. It is more work now (you have to remove the engine patches from every plume config) but you will never have to worry again for interop problems. If a new engine module type is introduced then you just add it to the global engine patcher as an exception.

Ohhh oh oh. Okay, I didn't read that well enough. I see what you guys are saying now. So, as an example, what would be necessary is to change the config for these engines from:

@PART[turboFanEngine]:FOR[RealPlume]:NEEDS[SmokeScreen] //J-X4 "Whiplash" Turbo Ramjet Engine
{
    PLUME
    {
        name = Turbojet
        transformName = thrustTransform
        localRotation = 0,0,0
        localPosition = 0,0,-2
        fixedScale = 1.8
        energy = 1
        speed = 1
    }
    @MODULE[ModuleEngines*]
    {
        @name = ModuleEnginesFX
        %powerEffectName = Turbojet
        %spoolEffectName = Turbojet-Spool
    }
}

to this?

@PART[turboFanEngine]:FOR[RealPlume]:NEEDS[SmokeScreen] //J-X4 "Whiplash" Turbo Ramjet Engine
{
    PLUME
    {
        name = Turbojet
        transformName = thrustTransform
        localRotation = 0,0,0
        localPosition = 0,0,-2
        fixedScale = 1.8
        energy = 1
        speed = 1
    }
    @MODULE[ModuleEngines*]
    {
        @name:NEEDS[!AJE] = ModuleEnginesFX
        %powerEffectName = Turbojet
        %spoolEffectName = Turbojet-Spool
    }
}

If this isn't what you're saying, I'm sorry. I really only know the basics of MM syntax  

[Phineas Freak]

25 minutes ago, Nhawks17 said:

If this isn't what you're saying, I'm sorry. I really only know the basics of MM syntax  

Yep, that's the way @Ser did it! Just an extra check so that AJE continues to function as expected.

"My" way is a bit more complicated at first but easier afterwards. You define the global patch that i showcased and then for the plume config you use:

@PART[turboFanEngine]:FOR[RealPlume]:NEEDS[SmokeScreen] //J-X4 "Whiplash" Turbo Ramjet Engine
{
    PLUME
    {
        name = Turbojet
        transformName = thrustTransform
        localRotation = 0,0,0
        localPosition = 0,0,-2
        fixedScale = 1.8
        energy = 1
        speed = 1
    }
    @MODULE[ModuleEngines*]
    {
        %powerEffectName = Turbojet
        %spoolEffectName = Turbojet-Spool
    }
}

The complicated part is to make sure that the global engine patcher works and that no one inserts a "@name = ModuleEnginesFX" inside the @MODULE[ModuleEngines*] node. The engine module patching is then taken care automatically by the global patch for all possible parts that use the AJE module.

[Nhawks17]

1 hour ago, Phineas Freak said:

Yep, that's the way @Ser did it! Just an extra check so that AJE continues to function as expected.

"My" way is a bit more complicated at first but easier afterwards. You define the global patch that i showcased and then for the plume config you use:

@PART[turboFanEngine]:FOR[RealPlume]:NEEDS[SmokeScreen] //J-X4 "Whiplash" Turbo Ramjet Engine
{
    PLUME
    {
        name = Turbojet
        transformName = thrustTransform
        localRotation = 0,0,0
        localPosition = 0,0,-2
        fixedScale = 1.8
        energy = 1
        speed = 1
    }
    @MODULE[ModuleEngines*]
    {
        %powerEffectName = Turbojet
        %spoolEffectName = Turbojet-Spool
    }
}

The complicated part is to make sure that the global engine patcher works and that no one inserts a "@name = ModuleEnginesFX" inside the @MODULE[ModuleEngines*] node. The engine module patching is then taken care automatically by the global patch for all possible parts that use the AJE module.

Ohhhhhhhh, okay okay. I totally get it now. I'm definitely going to go with the global patch because of the reason you pointed out earlier regarding any possible new engine modules. Good to know, thank you for the information!

[Akira_R]

@Nhawks17

So I have noticed something that stinks of a hardware "issue".

With the newest update with the Shuriken particles I am getting a massive drop in FPS, going from a solid 55-60 down to 16 FPS when I have the engines running, if I turn the number of particles way down (were talking like 100-200 I usually crank it up to 2000 or so) the performance starts coming back, I also get large lag spikes that feel like garbage collection doing it's thing, also this lag is only present in the atmosphere, once I leave the atmosphere it instantly jumps back up to 60 FPS, I'm using FAR and Scatterer, those are the only two things that I can think of that might cause an interaction with.

Now I go in and change all the configs back to using the old particle system (MODULE_MULTI_PARTICLE_PERSIST I believe?) and I am back to 55-60 FPS no matter how many engines and boosters and cranking the max particles up to above 2000, and the garbage collection spikes in lag are totally gone.

I have a pretty powerful system which is why I suspect it may be system/hardware difference (maybe the shuriken particles perform better on AMD or something like that), my specs are as follows:

CPU: I5 4670K @4.5Ghz

GPU: G1 Gaming GTX 980Ti OCed

RAM: 32Gb G.SKILL Sniper 1866

I am also not running any executable changes (no force_d3d11 or force_opengl)

I would be interested in knowing what system specs you are running.

[Nhawks17]

4 hours ago, Akira_R said:

@Nhawks17

So I have noticed something that stinks of a hardware "issue".

With the newest update with the Shuriken particles I am getting a massive drop in FPS, going from a solid 55-60 down to 16 FPS when I have the engines running, if I turn the number of particles way down (were talking like 100-200 I usually crank it up to 2000 or so) the performance starts coming back, I also get large lag spikes that feel like garbage collection doing it's thing, also this lag is only present in the atmosphere, once I leave the atmosphere it instantly jumps back up to 60 FPS, I'm using FAR and Scatterer, those are the only two things that I can think of that might cause an interaction with.

Now I go in and change all the configs back to using the old particle system (MODULE_MULTI_PARTICLE_PERSIST I believe?) and I am back to 55-60 FPS no matter how many engines and boosters and cranking the max particles up to above 2000, and the garbage collection spikes in lag are totally gone.

I have a pretty powerful system which is why I suspect it may be system/hardware difference (maybe the shuriken particles perform better on AMD or something like that), my specs are as follows:

CPU: I5 4670K @4.5Ghz

GPU: G1 Gaming GTX 980Ti OCed

RAM: 32Gb G.SKILL Sniper 1866

I am also not running any executable changes (no force_d3d11 or force_opengl)

I would be interested in knowing what system specs you are running.

Make sure you grab the latest update. It fixed the FPS issues.

[Ser]

23 hours ago, Phineas Freak said:

Any engine module patching should really be moved outside of the plume configs. Apart from helping avoid problems like these it makes the patching easier. Global patcher template:

@PART[*]:HAS[@MODULE[ModuleEngines*],!MODULE[ModuleEnginesRF],!MODULE[ModuleEnginesAJE*]]:AFTER[zzRealPlume]
{
    @MODULE[ModuleEngines*],*
    {
        @name = ModuleEnginesFX
    }
}

BTW, the engine patching has no place inside the plume configs. The plume configs may depend on the FX engine module but ultimately it is a plume config and not a part config. We have the same problem with the RO plume configs too.

I keep insisting that the biggest evil is this:

@MODULE[ModuleEngines*],*
    {
        @name = ModuleEnginesFX
    }

I've looked through the stock engine configs and starting to understand that this is needed, as far as I see, to make (old?) engines have ModuleEnginesFX instead of ModuleEngines. So why not target the ModuleEngines itself in the following way, without the asterisk:

@MODULE[ModuleEngines],*
    {
        @name = ModuleEnginesFX
    }

Instead of breaking everything that just starts with "ModuleEngines"? Thus you'll never need to add and maintain this part: !MODULE[ModuleEnginesRF],!MODULE[ModuleEnginesAJE*]]

Edited February 15, 2017 by Ser

[Phineas Freak]

@Ser I have been wearing the RO glasses for too long and did not realize that the case of the stock RP configs is easier to deal than the one for RO.

In any case, yes, checking only for the basic ModuleEngines is easier, better and safer.

@Nhawks17 New and updated global patcher:

@PART[*]:HAS[@MODULE[ModuleEngines]]:AFTER[zzRealPlume]
{
    @MODULE[ModuleEngines],*
    {
        @name = ModuleEnginesFX
    }
}

 

[Akira_R]

14 hours ago, Nhawks17 said:

Make sure you grab the latest update. It fixed the FPS issues.

My sincerest apologies I could have sworn I double checked and was using the latest update but you are correct I was not, I will re-download and test again once I am home.

[Nhawks17]

45 minutes ago, Akira_R said:

My sincerest apologies I could have sworn I double checked and was using the latest update but you are correct I was not, I will re-download and test again once I am home.

All good Let me know.

[Streetwind]

Right, I just spent two hours flailing at this... what's the trick to applying changes to an existing plume effect, as opposed to adding a new one? For the latter, there's plenty of examples and tutorials, but not the former...

I'm trying to resize some engines from SpaceY-Expanded. The resizing causes the plumes to be the wrong size, so I want to resize the plumes as well. In my innocence, I thought I could do something like this:

@PART[SYengine3mP1]:FINAL
{
	@rescaleFactor = 0.666667
	
	@PLUME:HAS[#name[Hydrolox-Upper]]
	{
		@localPosition = 0,0,1.5
		@fixedScale = 1.7
		@energy = 0.9
		@speed = 0.9
	}
}

But this doesn't actually do anything. I tried just @PLUME[Hydrolox-Upper], I tried @PLUME,*  ...nope, no deal. Despite this running in the FINAL pass, all I'm ever seeing are the default settings that get applied in the FOR[RealPlume] pass. I'm restarting the client, not using database reloads.

Also, I'm confused. Ingame in the Smokescreen menu, there are two plume effects and one flare. What if I want the flare to have a different localPosition offset than the plumes? The config that adds Hydrolox-Upper to this engine adds one single data structure, not three. How can I save two or three individual effect settings to a patch file?

Finally, there appear to be a Kerolox flare and plume listed for this engine in the Smokescreen menu ingame, but they don't show any visible effect graphics, not even if I manually zero out all of the hydrolox effects. As far as I understand the configs, this engine is supposed to have a kerolox plume, unless CryoEngines is present (which is true in my install), in which case it should get a hydrolox plume instead. I got the correct plume, and it is working correctly, but is it normal that the not-supposed-to-be-there kerolox plume shows up in the Smokescreen menu?

Edited February 21, 2017 by Streetwind

[DerpyFirework]

2 minutes ago, Streetwind said:

what's the trick to applying changes to an existing plume effect, as opposed to adding a new one?

Using :BEFORE[zRealPlume] should do the trick (Not tested)

[Streetwind]

18 minutes ago, DerpyFirework said:

Using :BEFORE[zRealPlume] should do the trick (Not tested)

No idea why, but this actually worked. Thanks!

 

...I don't suppose you got any untested ideas in regards to differing settings for plumes and flares too?

[DerpyFirework]

12 hours ago, Streetwind said:

...I don't suppose you got any untested ideas in regards to differing settings for plumes and flares too?

Turns out you can define flareScale, plumeScale, flarePosition, and plumePosition for this purpose (And I think I've used these myself at some point)

[Streetwind]

Neat. Does that override localPosition, or work as an offset to localPosition?

(Would try it out, but not near a KSP install right now)

Edited February 22, 2017 by Streetwind

[DerpyFirework]

2 minutes ago, Streetwind said:

Does that override localPosition, or work as an offset to localPosition?

Override. RealPlume sets them to fixedScale and localPosition if they're not defined, and it uses those values directly.

[Akira_R]

On 2/15/2017 at 11:09 AM, Nhawks17 said:

All good Let me know.

Ok so after updating to the newest version there is a marked improvement in the performance of the shuriken particles. However on my system the old particles still outperform the shuriken particles by a significant amount.

Using the same launcher and every thing and in both cases the max particles are set to 3000 (which this launcher will produce) I get 26-32 fps using the shuriken particles and 50-60 fps using the old particle system.

I mostly am letting you know in case others in the future come with complaints of poor performance, it would be nice if you could maintain two sets of configs one using shuriken particles and one using the old ones, but obviously that would add more work and headache for you and I in no way expect this. I am going to bring the issue up over in the smokescreen thread as well, maybe sarbian can figure something out.

[Nhawks17]

1 hour ago, Akira_R said:

Ok so after updating to the newest version there is a marked improvement in the performance of the shuriken particles. However on my system the old particles still outperform the shuriken particles by a significant amount.

Using the same launcher and every thing and in both cases the max particles are set to 3000 (which this launcher will produce) I get 26-32 fps using the shuriken particles and 50-60 fps using the old particle system.

I mostly am letting you know in case others in the future come with complaints of poor performance, it would be nice if you could maintain two sets of configs one using shuriken particles and one using the old ones, but obviously that would add more work and headache for you and I in no way expect this. I am going to bring the issue up over in the smokescreen thread as well, maybe sarbian can figure something out.

Okay, I'm going to be doing a mostly complete rewrite of all the configs for engines as some of the "backend" work of the stock configs portion and RealPlume has changed. If sarbian can't find a fix by the time I release the new update, hopefully the update will help. I have a computer that is similar to yours so the testing should be along the same lines.

[Nhawks17]

For anyone curious to follow development of the next update you can check out the opened issue on Github here

[Guest]

Some people talk about this adding effects to propeller engines using firespitter. Can anyone show a pic of that?

[Nhawks17]

1 hour ago, Murican_Jeb said:

Some people talk about this adding effects to propeller engines using firespitter. Can anyone show a pic of that?

I wouldn't see why you wouldn't be able to. I don't know what kind of transforms firespitter engines use but as long as it's defined correctly it should™ work.

[New Horizons]

I have Real Fuels Stockalike installed. Can I use this on top? What is the advantage?

[Guest]

@Nhawks17 But I don't see any compatibility for Firespitter on the list

[Nhawks17]

5 hours ago, New Horizons said:

I have Real Fuels Stockalike installed. Can I use this on top? What is the advantage?

Well Real Fuels effects the types of fuels in KSP. This is just a visual mod. Last time I checked it works but it could've changed as that's been awhile.

4 hours ago, Murican_Jeb said:

@Nhawks17 But I don't see any compatibility for Firespitter on the list

Because no one has made configs for them.

[StahnAileron]

Is there any reasonable way to change the sounds Real Plume uses? While the new audio is awesome for initial launching, it's very LOUD in the cold of space when I'm switching certain engines on again after having switched them off previously. I basically want stock sounds for the LFO (or non-SRB-type, I guess) engines because toggling the LFO engines back on seems VERY out of place when I'm in orbit with the throttle at zero and along comes this thunderous roar out of nowhere. I'm specifically referring to the Vector and Dart in this case (I've been testing shuttle designs lately). I imagine some other engines will have the same issue for me since Real Plume uses pre-defined configs as a baseline.

[Gordon Fecyk]

On ‎2‎/‎23‎/‎2017 at 9:21 PM, Akira_R said:

Using the same launcher and every thing and in both cases the max particles are set to 3000 (which this launcher will produce) I get 26-32 fps using the shuriken particles and 50-60 fps using the old particle system.

If this helps any, I found copying the RealPlume-Stock and RealPlume / 000_Generic_Plumes contents from my KSP 1.1.3 installation on top of my 1.2.2 installation seems to replace the MODEL_MULTI_SHURIKEN_PERSIST settings with the MODEL_MULTI_PARTICLE_PERSIST settings, and not break anything else. I also get a significant frame rate boost, going up from 24 FPS (hitting physics delta limit) to 40 FPS just with four Panthers (and 80+ other parts) on the runway. This is on top of Scatterer and ParaSci Visual Enhancements running and eating GPU time. I can wring out a few more frames by adjusting the stock aero effects setting.

That seems to work as a short-term fix, until improvements are made to the shuriken particle system or the stock configs.