[Logspam] Error messages in KSP.log when performing arithmetic on keys initialized to well-formed numbers

[Monniasza]

Hi. When you run the Ultimate Part Converter, you'll get error messages like in the attached KSP.log.
Here's the excerpt that causes this issue, taken from https://github.com/Monniasza/SSTO-Project/blob/master/SSTOLPG/ConverterLPG.cfg:

//Data collection - tanks
@PART[*]:FOR[1LPG]{
	lpgLF = 0
	lpg = false
}
@PART[*]:HAS[@RESOURCE[LiquidFuel]]:FOR[1LPG]{
	@lpg = true
	%lpgTank = true
	@lpgLF += #$RESOURCE[LiquidFuel]/maxAmount$
}
@PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer]]:FOR[1LPG]{
	@lpg = true
	%lpgRocket = true
	@lpgLF += #$RESOURCE[Oxidizer]/maxAmount$
}

Solution

To solve this, check if incoming values to arithmetic are string, if yes then convert them to numbers first.
It sems that calculations work fine, but errors are reported wrongly and don't contribute to error count on the loading screen.

Attachments

KSP.log

[Lisias]

This also happens with Forum Module Manager

---

Answering my own question: YES.

[Lisias]

HUMMM.. Found this.

Error - Failed to do a maths replacement: @PART[*]:HAS[@RESOURCE[LiquidFuel]] : original value="0" operator=Add mod value="#$RESOURCE[LiquidFuel]/amount#"

This means that someone shoved a string into a numeric field. Ideally, the root problem (someone screwing with numeric values) should be fixed instead of patching workarounds everywhere to mask the problem.

At the very least, this will impact somewhat the performance - parsing numbers is probably the most used code on MM - so I would need to check if the string is convertible to a number, or protect the parser with a try-catch. Both are probably a order of magnitude slower than just using he number.

IMHO, the error message should pinpoint the exact node where the problem happened, what would make our lives way easier as would allow us to fix the root cause at first place.

I will check the code to see how exactly is does these things.

[Lisias]

First impressions: the code that does math is not exactly efficient, everything is already a string on a textual representation of a (recursive) Dictionary anyway.

The problem is that the code is not being able to parse the string into a number. I'm guessing there're quotes in the key's value.

So, the solution would be to create a new numeric parser, or to shove string replacements in the hopes we would fix the string into a valid number.

I really think we should purse fixing whoever screwed the patches at first place by writing the values with quotes (or whatever is on the Node, I don't know).

@Monniasza , can you please remove this problematic patch from your rig, finish the KSP boot, and then send me the ConfigCache so at least I can be sure about what and where the problem is?

[Lisias]

On a side node: if KSP accepts the value as they are presented, so MM should do it too - no matter what I think about. :/

Time to do some empirical testings.