I've spent half a day hunting a bug. Usually if I'm systematic enough I can isolate the problem and find and understand the culprit (usually PEBKAC, naturally). This time though, I've isolated the bug as much as I can, but I'm still really confused. I'm not even 100% if it's a bug, though it's weird, whatever it is. Partly because it seems to rely on at least 3 different factors, any two of which seem to cause no problems on their own until the addition of the third.
I suppose the practical upshot of it is simple: don't omit items in INI groups. But because the circumstances to produce this bug seem so specific and so peculiar it's hard to know what's really going on, and it makes me wonder how else (if at all) similar bugs might surface. I'd be really grateful if @Yves or @Anders or some other person smarter than me could help me understand what's happening so I can try and stay clear of any such trouble in the future. It's hard to explain what the bug is, but I'll do my best. I've attached an MFA that shows it as clearly as I could muster. In a nutshell, it seems that:
if you try use the Ini++ object to set an altVal to the value of a non-existent item in an INI file, Fusion will just make the altVal zero.....except if you are using Anders' Easing Object and you reference that altVal in your easing parameters and you happen to use a certain combination of other numbers and/or operators in those parameters then - though Fusion will still claim that the altVal is 0 - the easing object will end up making unexpected calculations that wildly misposition the object. In the attached MFA, you can see that when an object is told to ease to [altVal+0] it moves to X=0, but when it is told to ease to [altVal+1] it moves about a billion (!) pixels too far.
So, obviously a part of the problem is that you shouldn't try and read information from an INI by referencing an item that isn't in there. I thought you could, but I was obviously wrong. That part's easy. But something else seems to be not quite right here in a number of places. A bunch of questions spring to mind:
-Perhaps it's INI++'s fault for not converting [non-existent value] into a plain 0? But perhaps that's not INI++'s responsibility?
-But the easing object never spoke to INI++ directly. It got the [non-existent value] from Fusion via an altVal, which got it from INI++. So at what point did this weird phantom [zero that doesn't seem to be a zero] materialise? INI++? in the altVal? In Easing Object? A combination?
-When Fusion got the [non-existent value] from INI++, it claimed to output 0. You can see in the MFA that the altVals in question are all, according to the string object, 0. Yet Fusion clearly passed on [something not quite the same as 0] to the easing object. Could Fusion perhaps be patched to forcibly clean up a [something not quite the same as 0] and store it as a 'pure zero' in the future?
-What is the [something not quite the same as 0] that Fusion gave to the easing object, and why did the easing object do such strange things with it...but only when other simple numbers in the equation were changed?
-Why does this crap always happen to me?