Converting OXCE to rapidyaml

[Delian]

I'd want to see those "nested rulesets" that are causing the loss of error messages first.

Static is a no-go, because it breaks my multi-threading

[Yankes]

I'd want to see those "nested rulesets" that are causing the loss of error messages first.

Static is a no-go, because it breaks my multi-threading

Where I used "static" variables that could be problem here? Only static is `YamlErrorHandler` that is stateless.
And all `tree` objects get its own "handler" as global is only fallback if not overridden.


And code that crash without info look like:

Code: [Select]


    reinforcements:
      - type: firstwave
        minTurn: 1
        maxTurn: 1
        maxRuns: 1
        mapBlockFilterType: 1
        spawnZLevels: [7]
        randomizeZLevels: falsee #crash here without info where it is
this is code related to `AlienDeployment`, any `tryRead` will break line info as we call functions like

Code: [Select]

bool read(ryml::ConstNodeRef const& n, ReinforcementsData* val)
as now there is no `root` in sight. as alterative would be refactor all calls to propagate one pointer.
but as `yml::Callbacks` already need have pointer that we control, we could easy store here our `root`.

[Delian]

Hmm, nevermind that. So you're storing root in the callbacks...

Actually this looks good. It's probably a normal way to use Callbacks, and not a hack at all.

Yes, with that we can get rid of the _root reference from the YamlNodeReader/Writer and we can probably remove the global callbacks that I've set up as well.

[Delian]

Rapid YAML 0.8.0 has been released.

It fixes most of the stuff we've reported, such as problems with trailing whitespace, and UTF-8 BOM.

[Meridian]

Good news.

I'll release OXCE 8.1 with the current ryml version still, because it is tested.

Later we can check if upgrading is worth it.

[Meridian]

@Delian: can you please merge these 2 commits into OXCE?

https://github.com/OpenXcom/OpenXcom/commit/b6ec154611339938f5b643e411285764818a22d4
https://github.com/OpenXcom/OpenXcom/commit/0f3978894548ddf9fe6ee9c245b2253787a94702

[Delian]

Does it matter if non-existent options are put at the end of options.cfg, or do they need to be correctly sorted together with the rest of normal options?

[Meridian]

Does it matter if non-existent options are put at the end of options.cfg, or do they need to be correctly sorted together with the rest of normal options?

They don't need to be sorted IMO, can be at the end.

[Delian]

https://github.com/Delian0/OpenXcom/commit/1888c52bcac470f46f68fdaaa9e9be672456813d

[Meridian]

https://github.com/Delian0/OpenXcom/commit/1888c52bcac470f46f68fdaaa9e9be672456813d

Merged. Thank you.