Trenchbroom: When user tries to add a duplicate key in the attribute grid, add a "#1" (or "#2" etc) suffix instead of replacing

[TheRektafire]

So a few months ago I was learning half life mapping with trenchbroom and I was following some tutorials on TWHL and VDC but I hit a bit of a snag when it came to the monster spawner tutorial https://developer.valvesoftware.com/wiki/Alien_Teleport_Effect_(HL1) , the setup from the tutorial doesnt work correctly in trenchbroom currently since it uses a multi_manager to trigger the teleport sprites multiple times (once for on, once for off). The way multi_manager works is the key is the targetname of the entity you want to trigger, and the value is the delay time of the trigger, the problem is in the tutorial there are several entities that are triggered multiple times from the same manager meaning you need to add duplicate keys to it, unfortunately in the current versions of trenchbroom you cant do that, you will just get an error saying that key already exists and asking you if you want to overwrite it instead, it would be nice if there could be an option, perhaps at the game config level since this only applies to certain games, to allow you to specify the same key multiple times for an entity, it would make setups like this much easier

[ericwa]

We discussed on discord a bit and I did some tests in JACK. JACK doesn't actually let you create duplicate keys either, when you try to create a second "tele_light" key, it creates "tele_light#1"

Also I wondered whether the order matters, like whether the key/values are executed by the game as a list of commands from top to bottom, but apparently the order doesn't matter, so we're fine on that side.

So this request is, as far as I understand, asking for us to append a "#N" suffix when you try to create a second key, instead of overwriting the existing key as we currently do. I don't want to have custom behaviour for Half-Life here as the attribute grid UI code is already somewhat complex, and whenever there is game-specific UI code it adds a dev/testing burden.

[TheRektafire]

@ericwa well it wouldn't need to be specific to half life, it could be an option added to the game config like I said, so if the option is enabled/added in the cfg TB will append the #N and if it isn't then it would use the current behavior where it asks if you want to overwrite, that shouldn't require any game specific changes or UI changes

[eGax]

Where would be this be useful besides halflife?

[TheRektafire]

Where would be this be useful besides halflife?

I dont know since I havent mapped for any goldsrc/idtech2 based games beside quake and half life yet ;) But if it's there then someone may decide to use it in the future for their game and I imagine it wouldn't be too difficult to add to TB since some of the logic is already there (checking for 2 keys that are the same), the only thing that would need to be added is to add a game config option to check against and to automatically append the #N if it is enabled, though to be fair I havent checked the game config parsing code so idk how hard that would be to add. The name for it could be something like "IncrementDuplicateKeys" or something like that since its adding 1 to the name of the key every time you make a new copy

[eGax]

OK. I didn't know of any, just curious if you did.

[kduske]

Isn't there already something similar going on with Quake where we can have numbered entity properties? I don't think we support automatic property management there either, but in the very least we should support the different format that uses # to separate key name and number.

I suppose that if we can make both Quake's and GoldSrc's approach easier to use, then it could be worth doing it. But I think it requires quite a bit of refactoring to make this work safely.

[ericwa]

Isn't there already something similar going on with Quake where we can have numbered entity properties? I don't think we support automatic property management there either, but in the very least we should support the different format that uses # to separate key name and number.

Yeah - we draw entity links for "target2". This example with the multi_manager doesn't involve multiple targets, I don't know if you can do "target#1" in HL.

But I think it requires quite a bit of refactoring to make this work safely.

This is not worth any sort of overhaul or attempt to unify IMO.

[kduske]

Maybe I'm misunderstanding, but aren't they both just different ways to get multi values properties?

[TheRektafire]

Not really, normally when you do something like target1, target 2 etc you are referring to different entities, but in this case you are trying to refer to the same one multiple times

[kduske]

Ok, then this is way too specific to add special support to TB for.

[kduske]

I vote to close this -- @ericwa what do you think?

[TheRektafire]

Ok, I guess since you can add the #n manually it wouldn't be too bad, I just wish it would be able to autocomplete like how JACK and hammer do it

[ericwa]

We can reconsider implementing what JACK does if more people find it a problem, it's such a small thing though (saving typing 2 extra characters) I don't think it's worth spending dev time on right now.