This breaks all save file compatibility, but I don't care.
Because of the dynamic nature of the end result I have in
mind, there's no sane way to maintain save file compatibility.
The group file code looks a bit more complex to untangle, so
that will come in another commit.
The way to save this information in the "pluggable module" form
will be to just export large JSON tables of the masks.
This reverts commit dd54bd09b7.
Conflicts:
sc2/src/uqm/Makeinfo
This is because when I did this, it seems that I didn't do it with
accounting for the state file. This makes a second new-game crash.
(It may also cause crashes on other solar system loads?)
The replacement isn't too much better... But it's a
wrapper around C++ `std::list`, which means C++ code
can start to peer into it without needing to make
widespread changes to the C code that still works with it.
Over time, I can modernize all of the C code into C++ code
at whatever pace is needed.
The core of it was in the byte array, but...
Much of it was in some global task-specific C structs. I'll
wind up making the macro mess a bit worse, just to get everything
into the JSON fold... then I can go make a pass that makes things
C++ and reduces the complexity down.
(I should probably make this check runtime-sticky... with
huge dynamical games it might get a bit noticable that
we slow down for each solar system load event.)
Frankly I don't care to try to support a wide variety of
"older" stuff. I don't have the time, and I don't think
it's sensible to promote being able to play the
modified form of this game (using my dynamic system) on
toasters and coffee makers. Most systems with the capacity
to handle what I'll wind up demanding will probably
support C++23 already.
It seems that each Melnorme is distinct at each
system. In my play-testing here, they stay dead if
killed. Which is, well, sensible.
I don't remember if this was the behaviour in the original game.
I changed it to use string lookups. This permits
hardcoded strings in the table, which defeats a bit
of static checking -- but the goal is to permit those
strings also at runtime so folks can define their
own generators as plugins.
Further, the decoupling means that there's less
tight coupling between how the generator works
and how the map is defined -- fewer forward
decls and constants for each race, etc.
The VUX, Utwig, Melnorme and others all have branching paths
on the actual `XXX_DEFINED` enum value. This is an ersatz
parameter. I'll provide an extra string parameter for all
generators, that lives in the `SolarSystem` type (for now).
The table can now just mention the static string which
indicates the kind of variation to build. (Eventually,
this will become more dynamic, once I have support for
runtime-insertion of stars.)
It's a bunch of hacky things I threw together. Some accurate,
some not. Mostly just to play with the algorithms which
generate stuff -- I want the generation to be unaltered if I
slip in new stuff between planets. To do this, I have to
understand when RNG gets updated, how, and what other constants
affect the generation computations.
The original code is miserly with bits for planet data, which
made sense for a game for that generation of hardware. I'm
fine with dozens of KB per planet... Even with tens of thousands
of planets; modern systems won't even be stressed by the memory
usage. A few hundred megabytes to a gigabyte are available easily
on most platforms that I care about.
Hello, gas bags! Somehow, it seems fitting that they're the first...
they did, after all, mess up the code/settings on the probes
to wreak havoc!
Hopefully I haven't! :-)
I think I can simplify things a lot from here...
adam
