[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season

[Lisias]

9 hours ago, Jacke said:

I don't think Nyan Cat significantly affects KSP loading.  However, how smoothly it scrolls across the screen shows how well KSP is running during the startup.

It's not how Unity works. The nyan cat should being drawn on the Update callback, and every thingy you do on the Update uses time, delaying the next Update. It's the whole problem with stuttering on Flight with big crafts or clumsy input responses (as Unity uses the frame cycle to read the HMI devices).

If the nyan cat is not running smoothly, it's because the Update cycle is overloaded. If the Update cycle is overloaded, everything else on Unity relying on the Update cycle is delayed - including the KSP loading, as the assets are loaded on the Update callback! It's the whole purpose of setting the Application framerate to -1 (infinite) at first place!!

[sarbian]

It is exactly how unity works. And since KSP loads its asset in the Update loop it is not surprising that it does stutter, cats or not cats. Obviously, the stutter is a bit harder to notice with static images.

[Northstar1989]

Thanks as always for the great work Sarbian!

Hope this will still be updated as future KSP updates come out (if any), or at least once in a long while to let people know it's still active (maybe with tiny changes like cleaning up code or fixing a lingering bug).  MM is as always, essential for any Kerbalnaut, and I appreciate the dedication!

[sarbian]

if it ain't broke, don't fix it

[Flipper028]

So I am trying to get scatterer planetslist configs to load up for two planet packs, JNSQ & GPP. I have scoured the wiki and syntax pages for clues and was able to get the EVE clouds configs to load up and work properly but using the same syntax for the scatterer planetlist configs leaves JNSQ scatterer overwriting GPP scatterer. I am a bit puzzled since it works for EVE but not scatterer.

Using @Scatterer_planetsList for the JNSQ config and @Scatterer_planetsList:LAST[JNSQ] for the GPP config, but when I load the game I get no configs for the GPP planets.  Is there a way to load these two configs up together or do I need to make a third patch which includes both config's contents and load that up as FINAL? thx for the help

[Rakete]

Just a short question. Today a cat with a rainbow flag runs over my loading screen. I tracked it down to Module manager. (all other mods uninstalled)... Is this an 1st of april joke?

Does anybody else have this behavior?

[Grem]

same

[razark]

38 minutes ago, Rakete said:

Is this an 1st of april joke?

Yes

[zer0Kerbal]

On 2/28/2022 at 3:43 PM, sarbian said:

if it ain't broke, don't fix it

unless you are a Meatloaf song.

[BNSF1995]

8 hours ago, Rakete said:

Just a short question. Today a cat with a rainbow flag runs over my loading screen. I tracked it down to Module manager. (all other mods uninstalled)... Is this an 1st of april joke?

Does anybody else have this behavior?

Oh, good, it's not just me. I thought I had finally descended fully into madness.

[Jacke]

4 hours ago, BNSF1995 said:

Oh, good, it's not just me. I thought I had finally descended fully into madness.

Add the command line option " -nyan-nyan" and you can have the madness every day!

[Shoey]

I ran into 2 of the strangest arithmetic bugs while working on a greenhouse mod. 

@PART[*]
{
	test1 = 0
	@test1 -= 7.75
	@test1 += 7.65
	
	test2 = 0
	@test2 -= 3.125
	@test2 += 3.15
}

test1 will consistently be -0.0999999999999996, test2 will be 0.0249999999999999.  Probably just a floating point error, I guess? I don't imagine there are many situations where something like this matters but I got this to happen on 3 very different KSP installs so I figure it's worth reporting anyways in case it can crop up somewhere else and has just not been noticed.

More details: I would've tried another Windows 10 install before posting if I had one handy. Usage of variables outside of this don't appear to matter, I was able to get this result with or without them (I was writing a set of patches to automatically configure greenhouses for various life support mods and discovered this happening to 2 out of 6 parts). Adding/subtracting any value before and after seems to work around this, i.e. adding 0.1 before 7.65 and subtracting 0.1 after.  I can post log files if needed but I'm not sure they'd be of any help.

 

Edited April 2, 2022 by Shoey

[Gotmachine]

30 minutes ago, Shoey said:

test1 will consistently be -0.0999999999999996, test2 will be 0.0249999999999999.  Probably just a floating point error, I guess?

Yes this isn't an "error", that's just how floating point types work.

[Shoey]

49 minutes ago, Gotmachine said:

Yes this isn't an "error", that's just how floating point types work.

Well, there definitely are workarounds or better ways of doing it, as I couldn't get this error on any other calculator I tried. On top of that I ran into the exact same error again a third fourth time after I had completely changed what I was doing. To be clear, it's happened 4 times on 6 parts that have had no calculations done with more than 6 digits. It's definitely fixable, which is why I bothered posting about it, even if it may not be worth fixing. Since setting up module manager patches happen once per session at maximum, it may be worth doing higher accuracy calculations, for example.

Edited April 2, 2022 by Shoey

[Gotmachine]

30 minutes ago, Shoey said:

it may be worth doing higher accuracy calculations,

No. It doesn't matter because everything the game does has a similar level of floating-point related inaccuracy.
That FP inacurracy at the MM level is just the first one to happen, there will be tons of similar arithmetic operations (with similar level of inaccuracy) done when the game manipulate those configured values.

32 minutes ago, Shoey said:

I couldn't get this error on any other calculator I tried

https://dotnetfiddle.net/YpZzvs

Edited April 2, 2022 by Gotmachine

[Shoey]

55 minutes ago, Gotmachine said:

No. It doesn't matter because everything the game does has a similar level of floating-point related inaccuracy.
That FP inacurracy at the MM level is just the first one to happen, there will be tons of similar arithmetic operations (with similar level of inaccuracy) done when the game manipulate those configured values.

That's not strictly true either as there absolutely can be situations where a ModuleManager patch won't apply because it's expecting a value that could've been errored out like this. Maybe ModuleManager accounts for this elsewhere (i.e. every equal condition is actually +-x digit), but it wouldn't be the first time I've seen a scripting engine break from floating point inaccuracies. It's the first time I've seen it happen at 3 digits of accuracy, though.

I'm not a professional programmer by any means (not that I would call what I'm doing programming), but there are a ton of ways to mitigate this. The entire point of floating point is enhanced accuracy, and having errors at 3 digits (2 decimal) may be edge case but it's definitely not optimal.

If you wouldn't fix it, that's fine. If they don't want to fix it, that's fine. I would fix it, though, which is why I bothered to type any of this up.

Quote

https://dotnetfiddle.net/YpZzvs

Look, I get you wouldn't want to fix this. I really do. Being able to write a basic calculation function that has no error correction doesn't prove me wrong, though. Objectively speaking, it is an error, and it can be worked around. You could do as little as calculate the decimal place of both numbers involved and then round to it afterwards, in this specific case, because decimal places will never be added (past those of involved numbers) when doing addition/subtraction. Sure, it doesn't matter when it's 76499 tons vs 76500 tons, but in cases where something must equal something else to work as intended it's worth implementing basic error correction, especially when it only needs to happen for a few seconds (the time spent actually doing these calculations) out of potentially hours (playtime).

Edited April 2, 2022 by Shoey
further clarity

[Gotmachine]

2 hours ago, Shoey said:

but it wouldn't be the first time I've seen a scripting engine break from floating point inaccuracie

2 hours ago, Shoey said:

in cases where something must equal something else to work as intended

You can't expect a reliable result when comparing two previously manipulated floating point numbers for equality (or even "near equality").
That's a basic rule in programming and applies to every standard programming / scripting language, you can't implement predictable conditional logic based on FP number comparisons.

So it's not "broken", it just doesn't work like you think. And if you have logic relying on FP numbers equality in MM patches, you shouldn't.

2 hours ago, Shoey said:

The entire point of floating point is enhanced accuracy, and having errors at 3 digits (2 decimal) may be edge case but it's definitely not optimal.

Your perceived "accuracy issue" doesn't matter in the context of running the game. It's not an edge case, similar variance will always happen at runtime when FP values are manipulated, no matter how "round" your initial configured values are.
And I'm not sure where you're getting your "2 decimal" figure. The error in your example is 0.0000000000000004, which is quite close to the maximum possible precision of a 64 bit float (17 decimal places).
The only possible consequence is having the user facing values being "not round" in the UI, but even that is highly unlikely, as most values in the UI are shown with some some rounding applied.

2 hours ago, Shoey said:

Objectively speaking, it is an error, and it can be worked around

Technically, the MM parser could implement custom "exact" math for add/substract which would satisfy your examples (something like https://github.com/AdamWhiteHat/BigDecimal/blob/master/BigDecimal/BigDecimal.cs)
However, doing it for the other operators (multiply/divide/exponentiate) would be pointless, as the config format is limited to a 64 bit float string representation anyway (and that is actually also an issue for add/sustract depending on the range of your values).
So for example doing something like :

val = 1
@val /= 3.15
@val *= 3.15

Would still result in val = 0.99999999999999989 instead of 1, because the intermediate division result will have lost some precision for a round trip after the multiplication.

So in the end, anything you can do doesn't provide a general solution to your "I want exact math" issue.
KSP (and by extension MM) are backed by FP numbers. No matter what you do, the inherent limitations will always be there. Trying to hide them in a tiny subset of the application won't change anything.

Edited April 2, 2022 by Gotmachine

[Shoey]

3 hours ago, Gotmachine said:

You can't expect a reliable result when comparing two previously manipulated floating point numbers for equality (or even "near equality").
That's a basic rule in programming and applies to every standard programming / scripting language, you can't implement predictable conditional logic based on FP number comparisons.

So it's not "broken", it just doesn't work like you think. And if you have logic relying on FP numbers equality in MM patches, you shouldn't.

Your perceived "accuracy issue" doesn't matter in the context of running the game. It's not an edge case, similar variance will always happen at runtime when FP values are manipulated, no matter how "round" your initial configured values are.
And I'm not sure where you're getting your "2 decimal" figure. The error in your example is 0.0000000000000004, which is quite close to the maximum possible precision of a 64 bit float (17 decimal places).
The only possible consequence is having the user facing values being "not round" in the UI, but even that is highly unlikely, as most values in the UI are shown with some some rounding applied.

Technically, the MM parser could implement custom "exact" math for add/substract which would satisfy your examples (something like https://github.com/AdamWhiteHat/BigDecimal/blob/master/BigDecimal/BigDecimal.cs)
However, doing it for the other operators (multiply/divide/exponentiate) would be pointless, as the config format is limited to a 64 bit float string representation anyway (and that is actually also an issue for add/sustract depending on the range of your values).
So for example doing something like :

val = 1
@val /= 3.15
@val *= 3.15

Would still result in val = 0.99999999999999989 instead of 1, because the intermediate division result will have lost some precision for a round trip after the multiplication.

So in the end, anything you can do doesn't provide a general solution to your "I want exact math" issue.
KSP (and by extension MM) are backed by FP numbers. No matter what you do, the inherent limitations will always be there. Trying to hide them in a tiny subset of the application won't change anything.

 

https://dotnetfiddle.net/48IFZV

I learned the required C# and resolved this specific issue in less than 20 minutes (floating point errors in 500< of 1000 numbers with 1 digit before and 2 after the decimal, which is what I used "2 decimal" to refer to, not the very obvious floating point error) using functions solely provided by System in various revisions of .NET, fixing all of them. I did make a dumb mistake printing a value twice but it does exactly what it's supposed to. I'm willing to bet that's less time than you spent *arguing* about this. It's certainly less time than I spent typing even just this response. This can (and should) be done better, of course. Using variables to count the digits after the decimal in both numbers involved in addition and subtraction, as read off the disk, and rounding to the one with the most digits, since we know it'll never go past that thanks to elementary school mathematics (x.xx + x.xxx will never equal x.xxxx without it being a rounding error, remaining true even as you shift the decimal place, which you can correct very easily by just rounding it). Potentially optimize by "sanity checking" with known bases (i.e. 0.1 instead of 0, leading into solving it exactly like I did earlier) before rounding though the fact that it can execute 1000 times in 0.08s while printing debug information makes it kind of redundant when it'll never happen more than 100,000 times, and even if it does it'll be cached and those 8 seconds out of an hour (which it'll be far less than) won't matter so long as no module manager patches change.

As for multiplication, that one is resolvable in almost the same way as addition and subtraction, just add the relevant digits instead of using the greater. 1.8923 * x.x will never have more than 5 digits after the decimal, unless it's an error. 1.8923 * x.xx 6.

Maybe MathF.Round isn't even supported by versions relevant to KSP! It can still be resolved other ways or you can just write a rounding function yourself, though that is obviously more complicated. It's very useful whenever math is involved, even if it's not floating point.

Sure, you shouldn't do "if (float = float)" but you don't get much of a choice in ModuleManager patches sometimes. As far as I know, there is no way to round without using regular expression combined with multiple "node edits" and you can't work around having to specify variables as sp floats. But when module manager by default can not do half of "x.xx = x.xx" if math was used to get there that's a problem. Arguably a big one since a lot of numbers in KSP can wind up in that place, one way or another.

When more than a quarter of floating point operations have rounding errors, and you can fix most of them by applying the logic of mathematics and a few lines of code (literally less than 20 if you just use the logic, presumably to the 3 functions that handle parsing addition/subtraction/multiplication commands in MM patches), it's worth doing. This isn't anywhere near as impossible as you keep saying it is. I wouldn't even say this was hard, I spent more time talking about doing it than actually doing it, and I hadn't even looked at C#, C++, C anything in years.

There's any number of ways to do this. Math is logical, and errors can be accounted for. Sometimes extremely easily. There's a reason dedicated calculators can get it correct, at least far more of the time. Stop arguing in seemingly bad faith. I respect the modding work you've done but you simply aren't correct here. Sure, you can push this solution to its limit and break it but there are a significant amount of errors that can be resolved very easily this way, focusing on number ranges used very commonly in KSP (500< out of 1000 between 7.75 and 2.25, 29000< out of 100000 between -7.75 and 999.25, for addition specifically) , even if it's just making it so you can apply MathF.Round to a value present in a Module Manager patch with a command in the patch itself.

If you want to believe that floating point errors are always impossible to correct, feel free to, but don't be so adamant about it, because a lot of them can. All you needed to prove it to yourself is opening the calculator that comes with Windows.

This was literally just meant to be a simple bug report with a small desire for Module Manager side mitigation, not some "prove your work" discussion where I honestly feel more insulted than anything else since you don't seem concerned with actually reading and thinking about what I'm saying, just arguing.

Edited April 2, 2022 by Shoey

[Gotmachine]

Well, you think you're right, I think I'm right.
Your example is cute, but can't be generalized. But indeed "exact math" can be done, I said so previously. Feel free to do it.
That still is pointless for all the reasons I gave, but you won't care anyway, hey ?
Lets agree to disagree

[sarbian]

28 minutes ago, Shoey said:

you can apply MathF.Round to a value present in a Module Manager patch with a command in the patch itself.

And break any mods that needs more than 2 digits of precision. And I won't even go near the argument that using round is more accurate.

[Vanamonde]

Some comments removed. If you're that mad about how a mod is made, how about you go make a better one rather than chew out the people who offered their work to the community without compensation? 

[TheLoneOne]

3 minutes ago, Vanamonde said:

Some comments removed. If you're that mad about how a mod is made, how about you go make a better one rather than chew out the people who offered their work to the community without compensation? 

btw i like your pfp is that modern art by chance 

[Vanamonde]

More comments removed. Please just move on. 

[Watermel00n]

//Tier 1
    @RDNode:HAS[#id[start]]
    {
        @pos = -2500,1600,-1
    }
//Tier 2
    @RDNode:HAS[#id[basicRocketry]]
    {
        @pos = -2200,1800,-1
    }
    @RDNode:HAS[#id[engineering101]]
    {
        @pos = -2200,1400,-1
    }

//Tier 3
    @RDNode:HAS[#id[generalRocketry]]
    {
        @pos = -1900,2000,-1
    }
    @RDNode:HAS[#id[stability]]
    {
        @pos = -1900,1600,-1
    }
    @RDNode:HAS[#id[survivabilty]]
    {
        @pos = -1900,1400,-1
    }

Unfortunately, this code does not change the tech tree one bit. Is there any way i can fix it? Thank you.

[Aelfhe1m]

1 hour ago, Watermel00n said:

Unfortunately, this code does not change the tech tree one bit. Is there any way i can fix it? Thank you.

The RDNodes are inside a parent TechTree node so you need to include that in your patch:

Spoiler

@TechTree
{
	//Tier 1
    @RDNode:HAS[#id[start]]
    {
        @pos = -2500,1600,-1
    }
	//Tier 2
    @RDNode:HAS[#id[basicRocketry]]
    {
        @pos = -2200,1800,-1
    }
    @RDNode:HAS[#id[engineering101]]
    {
        @pos = -2200,1400,-1
    }

	//Tier 3
    @RDNode:HAS[#id[generalRocketry]]
    {
        @pos = -1900,2000,-1
    }
    @RDNode:HAS[#id[stability]]
    {
        @pos = -1900,1600,-1
    }
    @RDNode:HAS[#id[survivabilty]]
    {
        @pos = -1900,1400,-1
    }
}