CleverRaven
typified item.h + cpp
Summary
None
Purpose of change
Changed untyped coordinates in operations to typed ones. Focusing on item.h/cpp this time. A by-catch was the discovery of an untyped bubble coordinate sent into an untyped absolute coordinate operation (map_field.cpp operation field_processor_fd_fire, where the bubble coordinate was sent into get_local_windpower). The bug fix was to convert the bubble coordinate to an absolute coordinate using the appropriate conversion rather than a cast.
Describe the solution
Change operations from using untyped coordinates to using typed ones and adjusting users accordingly.
Describe alternatives you've considered
Testing
Apart from the bug, which I don't know how to test, no functionality was changed. Thus the test is a general one. Loaded save, walked up ramp, jumped into car, drove through hay bales, ran over zombie corpse with inventory, ran over turkey, smashed into stationary vehicle. Nothing odd seen.
Additional context
The bug is to use bubble coordinate when getting weather, which expects absolute coordinates. This means the wrong wind info was used when processing fires. Since this hasn't been detected before it's probably not very important, and there shouldn't be any tests (failing to) test this. Basically, fire would be fanned by winds taken from a different location, and so spread in the wrong direction, possibly with the wrong speed, if that's a factor.
They weren't there when I checked this morning... I'll get to it.
Edit: OK, that should take care of it. It would have been easier if MSVC hadn't insisted on crashing on half of the files when trying to resolve conflicts, but manual editing worked as a fallback (but there may be resulting garbage: one file still had an include for the removed file). Still, it compiles and it's possible to load a save.
Also, I appreciate the heads up. It's a bummer you're spammed with half a dozen messages about cancelled runs when pushing an update, but not a word when a conflict sneaks up on you (and lurking beneath the run status stuff, to ensure you don't happen to detect it when you're looking for posted changes).
It's happened again, vehicle stuff tests serial failures in an unrelated PR (General build matrix / Basic Build and Test (Clang 10, Ubuntu, Curses) (pull_request)). Is there a way to repeat the failures under a debugger so they can be tracked down by somehow making use of the randomness seed printed in the error report ("1733050048")?
Edit: Another run, another unrelated failure: General build matrix / Basic Build and Test (Clang 10, Ubuntu, Curses) (pull_request) with seed "1733060005", this time testing fake parts.
Is there a way to repeat the failures under a debugger so they can be tracked down by somehow making use of the randomness seed printed in the error report ("1733050048")?
Sometimes you can run the tests with the exact same arguments and get the same outcome, but it's the seed for the whole rng so it's not super stable, a single operation being different will cascade to everything afterwards being different.
Thanks. How do I try to repeat it? Would the RNG seed be some kind of a command line parameter?
Yes though I don't recall what it is offhand, it does support cata_test --help to dump the cli options.
Failed to repeat the errors locally, but it was still worth a try, even though the chances were slim.