TR catalogs: rename objects from number to description when applicable

[Joey79100]

Context

Object names are sometimes suffixed with a number, generally for these 2 reasons:

1. Usually, it's just multiple slots that have the exact same behavior, no matter the number. For example, DOOR_TYPE1, DOOR_TYPE2, or ANIMATING1, ANIMATING2, etc.
2. Sometimes, it actually implies a different behavior. For example, UNDERWATER_SWITCH1 is a wall level switch, and UNDERWATER_SWITCH2 is a ceiling lever. BADDY1 has ammo and a normal sword, BADDY2 starts with no ammo and has a special sword. Etc.

The second case makes it confusing especially for newcomers:

• You don't know what slot to look for when you're looking for a specific object (think of questions like "How do I setup a SEARCH_OBJECT so it behaves like a cabinet?")
• You risk accidentally copying to the wrong slot ("I imported the shoot switch from City of the dead into SWITCH_TYPE1 but it won't work!")
• Even when simply building your level, you're not sure of what is what (imagine wanting to put your TR4 flash grenades on your map - especially if you're colorblind - the only difference is the number and the color)

Also, this info is usually not documented: you either deduce it from seeing the actual object (when its appearance differs), or you ask other builders, hoping they know.

Proposal

Such cases should be renamed, so that numbers only denote different slots sharing the exact same behavior.
This would help builders instantly identify what an object is for, whether it's making objects, transferring slots, or

This would also allow adding extra slots to allow builders having multiple appearances (for engines that are still being expanded).
I believe all engines should be affected as needed, for consistency, not just the newer ones.

• Changes should be minimal and only replace the number, not change the entire slot name to avoid losing existing builders.
• The change should reflect the difference in behavior if possible, instead of just its "original appearance" or context (because this is level-specific, unlike the behavior). This way, looking at the name is enough to know what it does.

Suggestions

Here's a list with suggestions. It shall be completed and amended as needed.
If this change is agreed, I believe we should all agree on the new names before proceeding.

Original name	Proposed name	Comment
FLAME	DEATH	This object is not an actual flame, it just insta-kills Lara with fire when triggered.
FLAME_EMITTER1	FLAME_EMITTER_BIG	For flame emitters, the OCB may give very different results, which aren't really related to what the non-OCB slot looks like (Core probably just squeezed their needs wherever it could fit). I don't think they should be considered in the name.
FLAME_EMITTER2	FLAME_EMITTER_TORCH
FLAME_EMITTER3	FLAME_EMITTER_PUFFS
KEY_ITEM1	KEY_ITEM1_JEEP_KEY (TR4 only)	Specific case: in most cases, this is just a regular key, so the number should remain. But in TR4, it is also used as the jeep key.
KEY_ITEM12	KEY_PERMANENT_ITEM1 (TR4 only?)	This key stays the inventory after being used, so it's a kind of separate type of key
PUZZLE_ITEM1	PUZZLE_ITEM1_NITRO (TR4 only)	Specific case: in most cases, this is just a regular key, so the number should remain. But in TR4, it is also used as the nitro you add to the sidecar.
SWITCH_TYPE7	SHOOT_SWITCH1
SWITCH_TYPE8	SHOOT_SWITCH2
SHOTGUN_AMMO1_ITEM	SHOTGUN_AMMO_NORMAL_ITEM
SHOTGUN_AMMO2_ITEM	SHOTGUN_AMMO_WIDESPREAD_ITEM
CROSSBOW_AMMO1_ITEM	CROSSBOW_AMMO_NORMAL_ITEM
CROSSBOW_AMMO2_ITEM	CROSSBOW_AMMO_POISON_ITEM	(please double-check if I didn't mess up the order)
CROSSBOW_AMMO3_ITEM	CROSSBOW_AMMO_EXPLOSIVE_ITEM
GRENADE_GUN_AMMO1_ITEM	GRENADE_GUN_AMMO_NORMAL_ITEM
GRENADE_GUN_AMMO2_ITEM	GRENADE_GUN_AMMO_SUPER_ITEM	(please double-check if I didn't mess up the order)
GRENADE_GUN_AMMO3_ITEM	GRENADE_GUN_AMMO_FLASH_ITEM
UNDERWATER_SWITCH1	UNDERWATER_SWITCH_WALL
UNDERWATER_SWITCH2	UNDERWATER_SWITCH_CEILING
SEARCH_OBJECT1	SEARCH_OBJECT_CABINET
SEARCH_OBJECT2	SEARCH_OBJECT_DRAWER
SEARCH_OBJECT3	SEARCH_OBJECT_SHELF
SEARCH_OBJECT4	SEARCH_OBJECT_CHEST
BRIDGE_TILT1	BRIDGE_TILT_1CLICK	The goal is allowing slot names like BRIDGE_TILT_1CLICK_1, BRIDGE_TILT_1CLICK_2 etc
BRIDGE_TILT2	BRIDGE_TILT_2CLICK	For consistency, I would either not add an S to "clickS", or add it even for 1 click. I think grammar matters less in this case.
BRIDGE_TILT3	BRIDGE_TILT_3CLICK
BRIDGE_TILT4	BRIDGE_TILT_4CLICK
WRAITH1	WRAITH_FIRE
WRAITH2	WRAITH_ICE
WRAITH3	WRAITH_AIR
WRAITH4	?	WRAITH4 is actually unused in TR4. But looking at its decompilation, it looks like it will share the appearance of WRAITH_AIR (no flickering), but it lacks some of its behavior. I would avoid WRAITH_UNUSED, unless the game doesn't trigger it at all.
ANIMATING10	ANIMATING10_WRAITH_TRAP (TR4 only)	Specific case: in most cases, this is just a regular animating, so the number should remain. But in TR4, it is also used as the wraith trap (TEN has its own WRAITH_TRAP slot).
DEMIGOD1	DEMIGOD_HAMMER
DEMIGOD2	?	Not sure what the difference is with 3?
DEMIGOD3	?	Not sure what the difference is with 2?

Considerations

TRLE has been around for a long time, and we have a big legacy of tutorials and other online resources, which refer to the TR4-TR5-TRNG names.
Renaming, while it has clear benefits, will also have consequences (which is why it should remain minimal):

• Let's say a new builder downloads a WAD on TRSearch, containing a TR1 object that was ported into an existing TR4 slot: the readme tells them to import all objects into their WAD, and then tells them to place OBJECT2 on the map. If OBJECT2 was renamed OBJECT_HAMMER, they will not know what to do.
• TRNG scripts allow directly referencing a slot, by writing it in full letters. A builder might see OBJECT_HAMMER and try to type OBJECT_HAMMER into their script, only to get NG Center/TombIDE refusing the change. They may check NG Center/TombIDE's reference, but only find OBJECT2 and not OBJECT_HAMMER. They will not know what they're meant to use.
  Maybe NG Center/TombIDE could have their files edited to match the new names, but this would break compatibility with old scripts, so it's not a good idea.
  A workaround could be comparing the slot ID itself.

Maybe there could be an "oldName" parameter in the catalogs, for moveables. TE and/or WT could show the old name in parenthesis next to the current name, when there is one. For example "DEMIGOD_HAMMER (DEMIGOD2)".
This could be optional for people who don't want their UI cluttered, but on by default so newcomers (which don't know about that change) know.

Careful

When renaming a slot, the change needs to be reflected on all catalogs referencing that slot for the remapping to keep working.