Non-number-based indexing

[aaronfreed]

As far as I’m aware, all indices in the engine are currently numbers. This is fine for many of them, but it poses a massive problem for something like shapes patches. If multiple patches want to patch the same collection, which one do you apply first, and how do you tell Lua scripts which patch was applied first? I don’t even know if Aleph One allows multiple shapes patches to affect the same collection for this reason, and if it does, it would be a massive pain in the ass both:

• on C++’s end, to keep track of:
  • which bitmap in the shapes patch should be renumbered to which bitmap in the shapes file
  • which frame in the shapes patch should be renumbered to which frame in the shapes file, and
  • which sequence in the shapes patch should be renumbered to which sequence in the shapes file; and
• on the Lua script’s end. (I don’t even believe it’s currently possible to be absolutely certain that an associated shapes patch will be given the expected sequences.)

Not to mention that I don’t even know if shapes patches work if the existing collection doesn’t match the exact original contents of the shapes file used as the base of the patch – and if they do, they probably can’t have different numbers of sequences, bitmaps, or frames.

The solution to this is a massive pain in the ass in its own right, but ultimately a much lesser one: string-based indexing. This will very likely require an entirely new shapes format, an entirely new editor, and entirely new Lua accessors, but it’ll allow shapes patches to operate independently of one another, and thus any script that depends on a particular shapes patch can know that the correct indices will be there (unless someone, purely out of spite, decides to use exactly the same strings – which could in turn be prevented by also giving each shapes patch its own unique identifier of some sort).

I focused on shapes patches here, but there are very likely other benefits as well – I’m just too tired to think of any at the moment :V

[SolraBizna]

I've been referring to this under the name "Indexpocalypse". Internally, at runtime, the engine would still use integer indices. The change would be at load time, where it would amass mappings between string-based indices and the currently-in-effect integer indices. These mappings would be retained for subsequent use by Lua accessors and embedding in save files. Inconveniently, this means that the surface area of the change in the engine is relatively small, and we would "only" have to make enormous changes to literally all the tools instead...