Problems

- Providing direct access to equipment info through get_equipment() means that LMR gets tied into more of the game code (EquipSet). This one is acceptable I think, since it makes the model scripts much clearer, and in doing this work I've tried to isolate EquipSet and ShipType further from the rest of the code (same for LuaConstants).

-- I think that's reasonable. We do change model things based on game state, so its reasonable that they're hooked together somewhat. And as you've shown with the intro screen, EquipSet is reasonably isolated and can be built ad-hoc if necessary.

- I don't like the "animationNamespace" thing in LmrObjParams. It seems bug-prone (animationNamespace has to match up with the actual animation slots that you're using). It was a fix I put in when I realised that I had added animation with an "animation slot" system but didn't have a universally available set of animation slots... could be improved but possibly only by making LmrObjParams more complicated.

-- It should be fine to leave it for the moment. We can take it in either direction as it becomes clearer what variations we might have, that is either rip it out and hardcode "ShipAnimation" or .. do something more complicated, whatever that may be.

- No replacement for the general argStrings[]. The only one that's currently used by the model scripts themselves is argStrings[0], which comes through as the label value. However, other argStrings are *set* in src/SpaceStation.cpp:786-789 -- it picks some random advert models and puts their names into argStrings[4..7] for the space station models to use. Not sure if we should just scrap these since no models use them or keep get_arg_string() or what.

-- Scrap them. We can easily write a random ad model selector based on registration or tags or whatever in the future, probably from right inside Lua.

- *Enums.h is ugly and irritating. I don't like pulling those lists out of the code, particularly for the small enums that only have one or two values. You can't grep for them because the names in the *Enums headers miss whatever prefix is being used, and you can't see them at a glance from the place you'd expect. Unfortunately I don't know of any better solution for this problem in C++ (except to use a completely separate source preprocessor tool to reflect enums and generate the enum name tables, which I would probably be in favour of except for having to keep 3 build systems in sync)

-- We're discussing this in IRC. A script to be run as necessary to regenerate things is the current popular answer.

- Some model scripts do things like get_arg(ARG_SHIP_EQUIP_LASER0) > Equip.PULSECANNON_DUAL_1MW, which doesn't work with string constants. One option for this is for the relevant model scripts to keep a table of valid laser types and just check for valid_laser[get_equipment('LASER',1)]. Another option is if LuaConstants provides a mapping table to the scripts then they could map back from equipment name to a numeric ID again and do the relative comparison.

-- I'm wary of adding any kind of numeric values to LuaConstants - it was originally added to get away from that. I think it should be left to the individual model to do weird things if it wants to present different models for different specific equipment types. Otherwise "do I have a laser" should be enough.

- Some model scripts have code like this: local scale = (get_arg(ARG_SHIP_EQUIP_LASER0)-Equip.PULSECANNON_DUAL_1MW)*.1 which they use to scale their laser model according to the laser type (stronger guns are bigger guns!). I don't really like this anyway so I'm inclined to say this should just become a mapping table in the model of equipment constant (string) -> scale value.

-- Yep, per model again. Its doing something weird.

- Maybe others that I've forgotten...