Converting std::initializer_list to const std::vector& on every call to the various SlObject methods doesn't really seem better than converting constant data to std::vector once at static init.
At the moment it looks like a new std::vector is being created, with memory allocated, memcpy called and memory deallocated on every loop iteration (i.e. each individually saved/loaded item) in most of the chunks. This seems likely to be bad for performance.
It would seem better to take a std::span instead, but unfortunately this is C++20. Some other equivalent wrapper type which holds begin and end pointers/iterators, or begin and length could be used instead.
In general const std::vector& tends to not be a good function signature.

At the moment it looks like a new std::vector is being created, with memory allocated, memcpy called and memory deallocated on every loop iteration (i.e. each individually saved/loaded item) in most of the chunks. This seems likely to be bad for performance.

I was really hoping compilers would do the right thing, but clearly it does not. Which is a bit sad :P I now solved it in a slightly different way by just templating both variants. Godbolt at least tells me that it is doing the right thing now.

In general const std::vector& tends to not be a good function signature.

Sadly, as C-programmer, these kind of statements don't really help me. I do need some container that is dynamic, and people tell me to use std::vector for it. So I see no other way then to use const std::vector & as function signature in those cases. If you have other suggestions, I am more than happy to hear, as I would love to learn this a bit more. But I need a bit more guidance here :)

Sadly, as C-programmer, these kind of statements don't really help me. I do need some container that is dynamic, and people tell me to use std::vector for it. So I see no other way then to use const std::vector & as function signature in those cases. If you have other suggestions, I am more than happy to hear, as I would love to learn this a bit more. But I need a bit more guidance here :)

The contents of a container is not the same things as the container itself.
The real purpose of std::vector is to automatically manage memory. Each std::vector with non-zero capacity has it's own exclusively owned memory allocation. std::vector cannot be used as an aliased view over some other existing slice of memory, you need something like std::span, std::string_view or just a pointer/iterator for that.
In this case SlObject and other such functions do not need to do any std::vector memory management operations and so do not need a std::vector. A const std::vector& argument implies that the function needs a pointer to a std::vector container with all the memory management operations that that implies, in particular it's own exclusively owned memory allocation. However the function promises not to do any actual std::vector memory management operations on it because it is const.

Both std::initializer_list and std::vector are abstractions which return a contiguous array, so you can just pass the contiguous array directly without needing any allocations, copies or templates.

Underneath all the C++ syntactic sugar, what you really want is either:
SlObject(void *object, const SaveLoad *begin, const SaveLoad *end)
or
SlObject(void *object, const SaveLoad *begin, size_t length)

For the sake of convenience/prettiness, you can combine the begin and end, or begin and length, into a single type.
Which of these you use and what you call the type is entirely arbitrary and doesn't actually matter.
std::span is an implementation of the latter.
There are various other similar implementations such as gsl::span, boost::range.
It is trivial enough that rolling your own version and putting it in src/core/ would make sense. I could perhaps look at that later in the week.

You are awesome, tnx for this; I seriously appreciate it :) Now I get what you mean ;) And yes, it makes sense. I just want something over which I can iterate :P And I really do not care what that "something" is :D

Right, I spend some time reading up on std::span and how to put your story in perspective. I ended up copying parts of gsl-lite into OpenTTD to give us a std::span-lite. I tried to minimize the code as much as possible, to make it as readable as possible. I am sure I forgot things or did silly stuff .. but for that we have reviews :)

It is a lite variant, as I did not implement all the functions. Mostly as I don't think we need them, but it is easy enough to add them all if we really want to.

Alternatively, we could add gsl-lite to our 3rdparty folder, or .. switch to C++20. Sky it the limit :D

Tnx again for the explanation @JGRennison , it helped a lot in figuring out what this all is doing .. and I learnt a lot today :D

After some talk on IRC, decided to remove std::initializer_list, as it is kinda odd to have to use that. Turns out C-style arrays works fine, as long as we also have span<> to track the length as soon as we need it. So I changed this PR into that :)