Open IdleSol opened 6 months ago
/Confirmed
I've seen it a fair bit for quite some time.
Debugging catches it in item.cpp operation item::get_var, where end
is either expected to point a the end of the string to be parsed, or else point to a ',' character intended to be interpreted as the fraction separator.
However, for whatever reason, the strtod
operation instead leaves it pointing to '.' after a successful(?, hard to tell if a double with a value of 0.0 has parsed the string or just the integer part) call.
Someone who think they understand how the stupid C string parsing macros work and don't work will have to take it from here (and I don't care if the macros have a fancy name like "lambda", it's still a stupid macro debuggers don't understand). I wouldn't be completely surprised if local settings come into play anyway, such that the macro somehow uses the local convention rather than the US one of '.', so might reject '.' in such cases.
I didn't understand anything.
Isn't this similar to https://github.com/CleverRaven/Cataclysm-DDA/issues/71635#issuecomment-1935743602? Something about using ,
as a decimal separator instead of .
?
It's probably similar, but probably not identical. I don't know how the macro is supposed to work, and thus don't know if the macro isn't working as expected or if the code using it is incorrect.
So far I've treated these reports as the usual garbage cluttering start of saves (complaints about the old guard quest "reward" no longer being a valid item, a pile of overmap identifier not being valid (due to improper migration), hair color not being recognized (again due to improper/missing migration) etc.
Describe the bug
It happened a couple moves before the save.
Attach save file
Госпорт-trimmed.tar.gz
Steps to reproduce
N/A
Expected behavior
N/A
Screenshots
No response
Versions and configuration
Additional context
Loading from a save, doesn't cause an error.