[1.5.1] Engine Lighting (1.5.1) Little Config Update (13 October)

[jlcarneiro]

 

25 minutes ago, StahnAileron said:

Ahaha! I'm stupid. The reason why they don't work is because I used a close curly brace "}" in them here instead of a square close bracket "]" near the end. And since I copied-pasted the first to make the second, it would invalidate both. The first version works in my install of KSP, so I was wondering why it didn't work for you. So yeah, dumb typo. Sorry for that.

[...]

Oh, didn't notice that either! I'll try it then, thanks!

But... What about the R.A.P.I.E.R., the Whiplash (turbo mode) and the Panther (wet mode) engines? Will they get lightning effects?

28 minutes ago, StahnAileron said:

[...]

And I'm really starting to think the FOR[EngineLight] should be a NEEDS[EngineLight] instead...

Sorry to bother, but what is the difference between them?

[Drew Kerman]

3 hours ago, StahnAileron said:

And I'm really starting to think the FOR[EngineLight] should be a NEEDS[EngineLight] instead...

Good catch, you're correct

2 hours ago, jlcarneiro said:

Sorry to bother, but what is the difference between them?

when you use FOR, MM assumes the mod is actually there, so it's what is used by the mod authors themselves for patches they write for their mods. NEEDS actually checks to see if the mod exists or not in your GameData before applying the patch

[jlcarneiro]

On 16/03/2017 at 8:13 PM, jlcarneiro said:

[...]

But... What about the R.A.P.I.E.R., the Whiplash (turbo mode) and the Panther (wet mode) engines? Will they get lightning effects?

[...]

 

@StahnAileron, @blowfish, @Rhedd and @dtrauma can you, please, enlighten me?

I'm still getting lightning effects from air-breathing (airplane) engines... Some of them (R.A.P.I.E.R., Whiplash on turbo mode and Panther on wet mode) are ok, but how could I disable lightning effects on the others?

[dtrauma]

On 15.3.2017 at 2:20 AM, jlcarneiro said:

Tried with the boolean expressions and it did NOT work... 

ETA1: Actually, neither worked...

ETA2: It seems the following patch works, though...

@PART[*]:HAS[@MODULE[ModuleEngines*],!PROPELLANT[IntakeAir],!PROPELLANT[IntakeAtm],!PROPELLANT[FanIntakeAir]]:FOR[EngineLight] {

 

This is the incorrect form, without the nesting needed.

13 hours ago, jlcarneiro said:

@StahnAileron, @blowfish, @Rhedd and @dtrauma can you, please, enlighten me?

I'm still getting lightning effects from air-breathing (airplane) engines... Some of them (R.A.P.I.E.R., Whiplash on turbo mode and Panther on wet mode) are ok, but how could I disable lightning effects on the others?

The problem is that engines with multiple modes all share just the one EngineLightEffect. So you either get no light in both modes or incorrect light in air breathing mode if the other mode doesn't use air. The comment inside the config file is wrong actually, RAPIERS are not excluded because they have one mode of operation that doesn't use IntakeAir. This results in them getting two EngineLightEffect nodes. One fix is to put the rapier config at the top, and change the general config to:

@PART[*]:HAS[!MODULE[EngineLightEffect],@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir],!PROPELLANT[IntakeAtm],!PROPELLANT[FanIntakeAir]]]:FOR[EngineLight] {

The !MODULE[EngineLightEffect] prevents it from applying to nodes that already have a config, so engine mod authors and third parties can include their own configs without getting duplicate nodes.

I guess it would be a feature request to make per-mode configuration possible.

On 13.3.2017 at 10:09 AM, StahnAileron said:

I'm just adding to the above really, but for overview, the (corrected) exception list should look for:

• IntakeAir (Typical LF Jets)
• IntakeAtm (Non-oxygen jets & many fans)
• FanIntakeAir (Other fans)

In the end, I'm guessing it'd be:

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir]|!PROPELLANT[IntakeAtm]|!PROPELLANT[FanIntakeAir]}]:FOR[EngineLight]

Dunno, if the !PROPELLANT[] can take Boolean expressions. If it can, then you could shrink it to:

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir|IntakeAtm|FanIntakeAir]}]:FOR[EngineLight]

BTW, are all the FORs necessary? I can't tell if you're trying to tell KSP all the changes are meant to be part of  a mod called EngineLight (which is what FOR actually does and MM assumes via a mod's main folder name or dll name) or if you're trying to make sure the configs take place only if EngineLight is installed/loaded first (which FOR sounds like it does), but that's actually NEEDS. At least, this is my understanding of how FOR and NEEDS work for MM from the references I read.

In the first example, you are testing for engines that don't use resource a OR don't use resource b OR don't use resource c. In other words, every engine that doesn't simultaneously use all three. You want AND, which you can specify using "," in module manager.

The second isn't valid syntax according to the module manager docs.

[jlcarneiro]

2 hours ago, dtrauma said:

[...]

The problem is that engines with multiple modes all share just the one EngineLightEffect. So you either get no light in both modes or incorrect light in air breathing mode if the other mode doesn't use air. The comment inside the config file is wrong actually, RAPIERS are not excluded because they have one mode of operation that doesn't use IntakeAir. This results in them getting two EngineLightEffect nodes. One fix is to put the rapier config at the top, and change the general config to:

@PART[*]:HAS[!MODULE[EngineLightEffect],@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir],!PROPELLANT[IntakeAtm],!PROPELLANT[FanIntakeAir]]]:FOR[EngineLight] {

[...]

Thanks for this explanation! If I got it correctly, I should move R.A.P.I.E.R.'s config to the top and change the general config (now the second to appear) to the following?

@PART[*]:HAS[!MODULE[EngineLightEffect],@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir],!PROPELLANT[IntakeAtm],!PROPELLANT[FanIntakeAir]]]:FOR[EngineLight] {

If so, great! What about the other exception air-breathing engines (Whiplash and Panther)? Couldn't they be treated the same way (individual configs at the top), since they both have two modes?

[StahnAileron]

7 hours ago, dtrauma said:

In the first example, you are testing for engines that don't use resource a OR don't use resource b OR don't use resource c. In other words, every engine that doesn't simultaneously use all three. You want AND, which you can specify using "," in module manager.

Crap... Now I realize my problem. I forget I'm trying to exclude them via negation. My logic was backwards. I was thinking, "Match any of these first, then exclude them (i.e. NOT {A OR B OR C})" rather then, "Include things that don't have these (i.e. {NOT A} AND {NOT B} AND {NOT C}). I completely forgot that with the syntax MM uses and allows, I need to use a Boolean equivalent of my thoughts rather than use it directly.

Thanks for catching that. I feel stupid now...

BTW, for that (correct!) change you mention: perhaps it's best to also add a :FINAL instead of changing the order so it runs after any changes other mods do first if the mods already have EngineLight support built-in. It's a general change (PART[*]), so I usually make those run last. It ensures built-in mod support is done first and the generic change doesn't overwrite it/append to it.

EDIT: On second thought... After browsing the config again, I realize the stock-specific changes just EDIT the changes applied by the generic. EVERY part would need a :FINAL or a complete implementation (rather than just edits) if I wanted to make the patch file run last after other mods... I'm starting to dislike how this config was made (especially with all the FORs instead of NEEDS...) I mean it does make sense, but only in a narrow cases (stock-only or the mod names come after EngineLight alphabetically). Once you add other mods, you could run into problems, technically.

@jlcarneiro Technically it wouldn't matter for those two since the changes in modes are just statistical (fuel consumption, ISP, thrust curves) and not what fuels they consume (it's still air and LF.)

Edited March 19, 2017 by StahnAileron

[jlcarneiro]

8 hours ago, StahnAileron said:

[...]

@jlcarneiro Technically it wouldn't matter for those two since the changes in modes are just statistical (fuel consumption, ISP, thrust curves) and not what fuels they consume (it's still air and LF.)

Got it, but that means these two can't get different effects bases on the mode they're currently using, right?

[StahnAileron]

1 hour ago, jlcarneiro said:

Got it, but that means these two can't get different effects bases on the mode they're currently using, right?

With EngineLight, yeah, given it's current limitations according to @dtrauma. On the flip side, I think they already do have different effects under stock. I believe the Panther afterburner mode has emissive lighting (it actually has visible exhaust) versus none in its dry mode (there's nothing to see). I admit, it might only be really evident if you looking for it in daylight or are paying attention at night. I haven't used the Whiplash anytime recently, so I can't comment on it.

...Or this is an effect from me using RealPlume, though I'm pretty sure I didn't have it installed the last time I checked the Panther. I could be wrong though... (The effects were nice, but I disliked how it change the audio for certain engines when you toggle them off/on.)

[jlcarneiro]

Thanks, folks!

One last question (I hope!): is there a (simple) way of correcting this by using an MM patch or only by editing the mod's .cfg? Because I'd like to avoid overwriting when the mod updates...

 

 

[StahnAileron]

Technically, you could let the EngineLight MM cfg run, then run a second, custom MM cfg that checks for engines that use whatever air as a propellant and remove the EngineLight module. Personally, I prefer avoiding that and have no qualms about modding the included MM cfg if it's a simple(ish) edit I'm doing. It's a roundabout way to get the results I want. Plus it may have some effect on KSP start up since MM needs to parse and apply all those changes. If you have enough parts, it eventually adds up.

At one point, my MM changes totaled about 4k on start-up. I added a few more mods after that and updated others. It suddenly bloated up to around 8k. Eventually, I started cleaning out optional MM cfg I don't use/care for and got rid of a couple of mods I was having issues with/didn't care enough for. Got it back down to around 5k changes, which is more in line with what I was expecting. Couldn;t tell if it loaded any better since I've gotten into a habit of playing a game of Freecell or two while KSP loads. (Or otherwise doing something else while I wait.)

Still, I do understand wanting to keep a custom MM cfg you don't have to worry about overwriting by accident during updates. The best thing would be to have the mod adopt the changes we discussed. Otherwise you'd have to make a reverse cfg that deletes the module on air-breathers after the fact. Personally, I just edited the mod's config.

[dtrauma]

18 hours ago, StahnAileron said:

BTW, for that (correct!) change you mention: perhaps it's best to also add a :FINAL instead of changing the order so it runs after any changes other mods do first if the mods already have EngineLight support built-in. It's a general change (PART[*]), so I usually make those run last. It ensures built-in mod support is done first and the generic change doesn't overwrite it/append to it.

No, final should be reserved for user overrides IIRC. There is :AFTER and :BEFORE to make sure a patch applies before or after a mod loads, and for this to work correctly the mod has to use FOR. You'd use BEFORE for configs you don't want EL to touch (after the change mentioned to ignore parts already configured) or AFTER if you just want to patch a few values from the default config. Also IIRC you can combine NEEDS and BEFORE/AFTER to make sure it only runs when EL is actually there. A NEEDS check from inside the EL folder doesn't really make sense as of course the folder is there if Module Manager sees the config file.

That's my understanding of Module Manager at least, feel free to check the docs to make sure.

4 hours ago, jlcarneiro said:

One last question (I hope!): is there a (simple) way of correcting this by using an MM patch or only by editing the mod's .cfg? Because I'd like to avoid overwriting when the mod updates...

I hope that the next release includes the changes discussed here, and it will probably only happen when KSP 1.3 hits. You could do everything from your own MM patch file and leave the EL one alone, but it would be more involved. The ! and @ operators (delete/edit) are your friends in that case.

[StahnAileron]

I sometimes just want to give up on MM *sigh* Do you have a link to recent documentation? I've been using the wiki docs on its github page. I think those are pretty old and a bit rough. But as they're on the MM github page, they're official, so I use them, even if they do seem a bit sparse to me. Is there any other source of info/docs, or is that it?

[dtrauma]

On 19.3.2017 at 9:29 PM, StahnAileron said:

I sometimes just want to give up on MM *sigh* Do you have a link to recent documentation? I've been using the wiki docs on its github page. I think those are pretty old and a bit rough. But as they're on the MM github page, they're official, so I use them, even if they do seem a bit sparse to me. Is there any other source of info/docs, or is that it?

I cobbled what I know together from the forum post / MM release thread. MM syntax is byzantine and unusual at first, because it builds on top of KSP's equally NIH cfg syntax, but once you get going it's not that bad, particularly with "modern" extensions like nested operators and variables.

[VladP53]

That's quite nice mod. Thanks @tajampi.

Though I see a lot of NRE exceptions comes from `tjs_DecouplerLight.cs` and I'd like to fix them but recent release dll file doesn't match source published at https://github.com/tatjam/KSP-EngineLight/.

Could you please point me where latest sources for plugin could be found. I'd create pull-request with fixes.

[tajampi]

@VladP53 Sorry for late reply!

 

The source code at my github is from before ToXiKyogHurt's update, I have not update my repo with his changes as they are hosted here: https://github.com/ToXik-yogHurt/EngineLightUnofficial

 

I will update the repo with Toxikyoghurt's changes! (Also set a link to his repo at the main post)

Edited April 30, 2017 by tajampi

[Iamsodarncool]

are there plans to update this to 1.3?

[Rocket In My Pocket]

6 minutes ago, Iamsodarncool said:

are there plans to update this to 1.3?

I'm using it in 1.3 seems to work just fine as is.

[Iamsodarncool]

@Rocket In My Pocket ...so it does. Thanks.

[Nightside]

My Kerbals' faces get illuminated in the cockpit (other end of rocket from the burning engines), is this a known issue?

[PmThay]

On 2017-6-2 at 4:06 PM, Nightside said:

My Kerbals' faces get illuminated in the cockpit (other end of rocket from the burning engines), is this a known issue?

I also noticed that, but it only happens during ignition, as soon as the craft starts to rise the light fades away.

other than that it seems to be working fine in KSP 1.3

so, i can live with that.

 

Edited June 6, 2017 by PmThay

[Nightside]

27 minutes ago, PmThay said:

I also noticed that, but it only happens during ignition, as soon as the craft starts to rise the light fades away.

other than that it seems to be working fine in KSP 1.3

so, i can live with that.

 

I'll just imagine the kerbals are watching the launch on screens in the pods

[Errol]

Ive noticed the face lighting as well. Also the light source appears to stay on after the engine is shutdown or other otherwise no longer producing thrust. Any one else observe this? KSP 1.3

[PmThay]

@Errol strange, that doesn't happens to me. The face lighting only happens when i fire the engines but if I stop then the light stops and when I release the ship and it rises the light fades away. another thing was when pressed "return to launch" the lighting effect doesn't happen.

[cyberKerb]

For whatever reason, I keep getting an ERR in the log file regarding one of the MM changes this mod makes to the stock Ion engine.

[LOG 20:25:02.369] PartLoader: Compiling Part 'Squad/Parts/Engine/ionEngine/ionEngine/ionEngine'
[ERR 20:25:02.384] Invalid float value! Field lightPower, value 0; on object of type EngineLight.EngineLightEffect

There are two points the engine-configs.cfg file has a 0 value in the "lightpower" field are as below:

@PART[*]:HAS[%MODULE[ModuleEngines*]:HAS[@PROPELLANT[XenonGas]]]:FOR[EngineLight]
{
	@MODULE[EngineLightEffect]
	{
		%lightPower = 0.0; // ions use _only_ emissive light

...
<snipped code>
...

@PART[ionEngine]:FOR[EngineLight]
{
	@MODULE[EngineLightEffect]
	{
		%lightPower = 0.0; // ions use _only_ emissive light

Are there any changes to the MM code so this can be corrected?
I would of thought that the 1st patch would of changed the stock Ion anyway, seeing as a stock engine does have a [ModuleEnginesFX] module, which in turn has a propellant of XenonGas. I tested it by commenting out the second change and it doesn't hit the Stock ion engine.

Is the idea that with a 0 lightpower, that the light won't change with throttle changes? it's either on or off or have I misunderstood that?

EDIT: After mucking around with the settings and reloaded KSP 30-odd times, I found the issue of the log error to be the semi-colon after the 0.0 figure. It loads without an error when that is removed.

With regards to the Kerbal face lighting - I get it too. If it helps, I noticed it changes depending on what part is the Root part. I rerooted a mocked up ship with multiple cockpits and the light changes depending on where the root is.


 

Edited June 17, 2017 by wile1411

[Beetlecat]

Just trying this in 1.3 -- on a small aircraft with four junos. As soon as I activate the engines, the light source switches on, seemingly indifferent to whether there's active thrust, or not. I'll try out some different craft/engine combinations.

So, yeah, it "works."