Custom Gamemode Entity - A proposal for Valve

[Zeus]

Many of us that have tried to go off the beaten path with gamemodes in TF2 have run into issues where we basically need to "hack" or override existing logic to make our gamemode work. I'd like to start a discussion about a new entity that would be able to solve this problem for us and unlock a lot of potential for creative new custom modes.


My proposal to Valve:

The thing all these custom gamemodes have in common is that we want to override parts of the HUD or the entire HUD and make things update on it.

A new entity called "tf_logic_hud_driver".

• Simliar to the pd logic, takes a .res file that defines the gamemodes HUD
• Takes inputs to drive values defined in the .res file
• My assumption is that there is enough existing generalized logic entities (e.g. math_counter, logic_compare, etc) to be able to manage the state for most custom gamemodes. This entity has always been the missing piece

Spoiler: Example

        "DeathCounter"
        {
            "ControlName"     "CExLabel"
            "fieldName"       "DeathCounter"
            "xpos"            "52"
            "ypos"            "72"
            "zpos"            "4"
            "wide"            "25"
            "tall"            "15"
            "visible"         "1"
            "enabled"         "1"
            "textAlignment"   "center"
            "labelText"       "%deathcount%"
            "font"            "HudFontSmallBold"
            "fgcolor"         "TanLight"
        }

How might the inputs work?

• Set a string. Could be something like a goal string, or help or instruction text
• Set / increment / decrement an integer. Could be something like health of an entity you want to protect (see Generator Defense)
• Drive a progress bar (like the PD score count or Payload progress) by modifying the width of a hud element based on an integer.
• Turn certain hud elements on and off. Set a variable that controls visbility of a particular element. (e.g. Seige, show a progress bar for the cap but replace it with a payload hud for the payload part)

Custom Gamemode Examples:

Siege: https://tf2maps.net/threads/siege_grove.43069/
Generator Defense: https://tf2maps.net/downloads/gd_powerbreak.8350/
Casual Arena: https://tf2maps.net/downloads/lumberyard-event.10884/
Object Destruction: https://tf2maps.net/downloads/od_canary.9156/
CTF Enhanced: https://tf2maps.net/downloads/ctf-with-a-gateswitch-cp.1148/
King of TC: https://tf2maps.net/downloads/king-of-territorial-control-prefab.10312/
Tug of War: https://tf2maps.net/threads/longboy.38876/
Mutli Payload: https://tf2maps.net/threads/resource-mpl_-game-type-setups-coding.24979/#post-334252

Open Questions:

• Would we be able to have this entity work in tandem with existing payload logic and cp's?
• It would be nice to be able to also drive a payload track, could func_tracktrains be able to expose a "progress" output so one could more smoothly drive a payload track
• Could this entity simply override a hud file. (e.g. You want remove the pointer things from the CTF hud, could just comment those out in the .res file and load it into the map with this entity)
• Are we concerned with players having their own custom huds for things, and this causing certain maps to look a bit off? Should we only support the idea that everyone is running the default hud?

What gamemodes have you tried to implement? I'd like to hear about other potential use cases of this kind of entity.

 

[pont]

i'd love this. i've got a payload-esque mvm map and some tug of war logic i've not done much with yet, both with no way to express progress on the HUD completely.

 

[Kill_the_Bug]

Oh boy - not sure how to comment on this one.

IMHO Valve completely f'd up the payload coding for the HUD < it pulls in information from various files to create is, and that there is your problem. If you need some light reading, these are the HUD issues I ran into when trying to code the HUD for my multiple payload mode.

I mean I love the idea of just making the hud into whatever format you want/need but I'm not sure how you can do it without having to reformat the way that it's currently set up in the file systems but then again maybe it's time for valve to show us content creators some love, attention and make our coding lives a little easier.

 

[Yaki]

I'm all for it.

I think the code already kind of exists, considering that the tf_base_minigame can set .res files, it only makes sense to expand the capabilities through another entity.

I would even be OK if they merged it with the already existing entity tf_gamerules (which can set HUD type). Of course, this comes with serious limitations from what you're proposing.

Maybe there could be a mix? The new entity tf_logic_hud_driver pulls from tf_gamerules to set the security and restrictions on what to add and modify, but also lets you add the new parameters based on restrictions (or "features") it is limited to?

(I also believe (but don't know for sure) that the MvM HUD is hard-coded to MvM. So if a tf_logic_hud_driver entity wasn't able to be used for MvM, I'd be ok with that. MvM would just be a bonus)

 

[Zeus]

IMHO Valve completely f'd up the payload coding for the HUD < it pulls in information from various files to create is, and that there is your problem. If you need some light reading, these are the HUD issues I ran into when trying to code the HUD for my multiple payload mode.

Yeah one of my questions is like, how tightly integrated is various other hud elements into the game. Like being able to create ad-hoc payload displays would be very nice. Even if we didn't get first class support for payload itself, it would still be better than me constructing a payload using an env screenoverlay.

 

[Zeus]

I would even be OK if they merged it with the already existing entity tf_gamerules (which can set HUD type). Of course, this comes with serious limitations from what you're proposing.

Maybe there could be a mix? The new entity tf_logic_hud_driver pulls from tf_gamerules to set the security and restrictions on what to add and modify, but also lets you add the new parameters based on restrictions (or "features") it is limited to?

(I also believe (but don't know for sure) that the MvM HUD is hard-coded to MvM. So if a tf_logic_hud_driver entity wasn't able to be used for MvM, I'd be ok with that. MvM would just be a bonus)

What do you think would be the value in mixing it with tf_gamerules?

Assuming you load it just like you would the PD logic / hud, then i dont think you'd need to do anything with the gamerules.
And yeah this kind of thing is def possible, multiple entites allow one to load a res file; the missing peice is being able to drive values on that HUD with entity inputs

 

[pont]

hell, i'd be happy if we could even stack screenoverlays.

 

[Kill_the_Bug]

For example, last night I tried to modify the resource/ui/objectivestatusescort.res file (so you know which file to look at) to try and customize my HUD for my tug of war map. I then tried to pack it in with my test map and it didn't work. This file is for payload and there's coding in it for hills/no hills (or something weird like that - going by mermory don't have it open) but that seems to be for another style of gameplay. The same goes for the multiple escorts .res file. If I remember correctly (been a REAL long time) both files act together to create the HUD. It also seems to contain coding for CTF game mode.

 

[Zeus]

For example, last night I tried to modify the resource/ui/objectivestatusescort.res file (so you know which file to look at) to try and customize my HUD for my tug of war map. I then tried to pack it in with my test map and it didn't work. This file is for payload and there's coding in it for hills/no hills (or something weird like that - going by mermory don't have it open) but that seems to be for another style of gameplay. The same goes for the multiple escorts .res file. If I remember correctly (been a REAL long time) both files act together to create the HUD. It also seems to contain coding for CTF game mode.

Yeah so it's a bit unclear.to me how easy it.would be to be able to reuse hud elements from other game modes like payload or cp. From the things I've seen it's prob gonna be tough, but at least with this entity suggestion, you'd unlock still a lot of functionality

 

[Yaki]

What do you think would be the value in mixing it with tf_gamerules?

Assuming you load it just like you would the PD logic / hud, then i dont think you'd need to do anything with the gamerules.
And yeah this kind of thing is def possible, multiple entites allow one to load a res file; the missing peice is being able to drive values on that HUD with entity inputs

I thought it would be more for security reasons. That way players wouldn't be able to add elements but rather modify ones that are allowed by tf_gamerules and tf_logic_hud_driver.

I might be overthinking this. I don't know for sure how the .res files make are chosen in the game's code, so... yeah there's that.

 

[Zeus]

I thought it would be more for security reasons. That way players wouldn't be able to add elements but rather modify ones that are allowed by tf_gamerules and tf_logic_hud_driver.

I might be overthinking this. I don't know for sure how the .res files make are chosen in the game's code, so... yeah there's that.

Currently theres nothing in the PD hud logic that prevents you from adding new things to it. you can add as many images, text fields and such as you want

 

[Yaki]

Currently theres nothing in the PD hud logic that prevents you from adding new things to it. you can add as many images, text fields and such as you want

Wait, really. I had no idea! That's wonderful news to me.

Never mind what I said, then. This seems more plausible than I initially thought.

 

[Zeus]

Wait, really. I had no idea! That's wonderful news to me.

Never mind what I said, then. This seems more plausible than I initially thought.

Well the issue is that while you can add stuff to it, you cant make them do anything. So if its purely for display purposes then it's pretty easy to add but making it dynamic is the hard part

Foir siege mode, im currently hacking the PD logic to act as a % progress bar based on PD score, and i remove all the other hud elements not related to that

 

[Yrr]

Would love this kind of thing, up there with tf_zombie_generic in terms of useful entities I want.

Having trouble with a map I desperately want to display a named player's health in atm, I imagine this wouldn't be able to solve that but more readable outputs is def smth to consider with this.

 

[henke37]

The thing is that this would be limited to basic number and string huds. You need custom code to do things such as the payload bar. The trainwatcher actually iterates over the path nodes that make up the track and counts the distance between them.

 

[Pocket]

This might not work as well as you're hoping. Some of the existing stock game modes have been hacked together by overriding the default behavior of some of the relevant entities so they behave completely differently under specific conditions. For example, I once looked into the possibility of making a tug-of-war palyoad mode that worked like in Splatoon, where you have to capture the cart like a control point to change which team is allowed to push it. Turned out it can't be done because the push zone trigger is literally just the capture point entity parented to a train.

 

[Zeus]

This might not work as well as you're hoping. Some of the existing stock game modes have been hacked together by overriding the default behavior of some of the relevant entities so they behave completely differently under specific conditions. For example, I once looked into the possibility of making a tug-of-war palyoad mode that worked like in Splatoon, where you have to capture the cart like a control point to change which team is allowed to push it. Turned out it can't be done because the push zone trigger is literally just the capture point entity parented to a train.

Ive been able to hack this together: https://tf2maps.net/threads/siege_grove.43069/
Works basically how you described; but I do agree and am not sure how feesiable it would be to be able to reuse other logic like payloads and cp hud elements