[WIP] Day of Defeat: Source entities and other TF2 Branch fixes

[SirYodaJedi]

I'm almost done with my updated Day of Defeat: Source FGD, so I figured I'd attempt to add the DoD:S entities to this project. I've also bundled some related edits that affect all first-party TF2 Branch games (HL2DM, CSS, TF2, DODS, HLDMS).

This adds a few extra tags:

• HLDMS - Half-Life Deathmatch: Source (has everything HL:S has, plus more, because it runs on TF2's engine version)
• HL2DM - Half-Life 2: Deathmatch (surprised this wasn't here already?)
• PROPLM - supports lightmapped static props
• 2025MP - runs on same engine version as TF2 currently does (as of Feb 2025 update) and shares codebase for DLL code. Name suggested by @vrad-exe.
• MPONLY - no singleplayer mode; used to hide newunit in multiplayer-only games

Todo

• Editor assets - Done except for comp_team_wall.
• Update code mentions of TF2 such as this one to apply to all 2025MP games:

  HammerAddons/src/hammeraddons/bsp_transform/globals.py

  Line 68 in 506d542

  in_tf2 = 'TF2' in ctx.tags

• Test FGD in Hammer
• Verify comp_team_wall.py loads
• Any glaring oversights, as well as Suggestions and recommendations from this repo's maintainers

Entities

Checkmarked ones are implemented in this PR. Unchecked ones exist in DoD:S, but seem to not be useful for neither Hammer nor the postcompiler.

Comp entities

• ✔ comp_team_wall - gets renamed to func_team_wall. This allows both @PointClass and @SolidClass versions to coexist, as func_team_wall is intended to be usable as both.

Point entities

• ✔ dod_bomb_target
• ✔ dod_control_point
• ✔ dod_location
• ✔ holiday_gift - also added the L4D2 and CS:S versions, which use different models
• ✔ info_player_allies
• ✔ info_player_axis
• ✔ weapon_30cal
• ✔ weapon_amerknife
• ✔ weapon_bar
• ✔ weapon_basebomb - distributed via dod_bomb_dispenser; perhaps could still be useful for point_template
• ✔ weapon_bazooka
• ✔ weapon_c96
• ✔ weapon_colt
• ✔ weapon_frag_ger
• ✔ weapon_frag_ger_live
• ✔ weapon_frag_us
• ✔ weapon_frag_us_live
• ✔ weapon_garand
• ✔ weapon_k98
• ✔ weapon_k98_scoped
• ✔ weapon_m1carbine
• ✔ weapon_mg42
• ✔ weapon_mp40
• ✔ weapon_mp44
• ✔ weapon_p38
• ✔ weapon_pschreck
• ✔ weapon_riflegren_ger
• ✔ weapon_riflegren_ger_live
• ✔ weapon_riflegren_us
• ✔ weapon_riflegren_us_live
• ✔ weapon_smoke_ger
• ✔ weapon_smoke_us
• ✔ weapon_spade
• ✔ weapon_spring
• ✔ weapon_thompson

Brush entities

• ✔ dod_bomb_dispenser
• ✔ dod_capture_area
• ✔ func_team_wall
• ✔ func_teamblocker

Logical entities

• ✔ dod_control_point_master
• ✔ dod_scoring
• ✔ info_doddetect

Code-managed entities and C++ baseclasses

• ✔ base_rocket
• ✔ dod_ammo_box - doesn't seem to work when spawned from point_template; IDK about via VScript
• ✔ dod_bomb_dispenser_icon - spawned at center of dod_bomb_dispenser's bbox; need testing if parenting updates icon location.
• ✔ dod_gamerules
• ❌ dod_objective_resource
• ❌ dod_player_manager
• ❌ dod_ragdoll
• ✔ dod_round_timer - this entity is managed via dod_control_point_master, and can't be controlled directly
• ❌ dod_team_allies
• ❌ dod_team_axis
• ❌ dod_team_manager
• ❌ dod_viewmodel
• ❌ env_grenadetrail - all relevant assets are precached by weapon_basedodgrenade
• ✔ grenade_frag_ger
• ✔ grenade_frag_us
• ✔ grenade_riflegren_ger
• ✔ grenade_riflegren_us
• ✔ grenade_smoke
• ✔ grenade_smoke_ger
• ✔ grenade_smoke_us
• ❌ player - handling via info_player_allies/_axis to avoid complications with other games
• ✔ rocket_bazooka
• ✔ rocket_pschreck
• ✔ weapon_basedodgrenade
• ✔ weapon_dod_base
• ✔ weapon_dod_base_gun
• ✔ weapon_dod_base_melee
• ✔ weapon_dodbaserpg

[TeamSpen210]

Thanks for this! For base classes, you'll want one the BaseEntity* classes - I reorganised them this way to better match how entities are actually defined. Stuff like angles/parenting always exists for instance. For autovisgroups, there's a single config file with all of them, so it's easy to see the big picture. If you've not seen it, I do have docs for the syntax changes.

@resources is a custom bit of syntax, it indicates what resources this entity loads itself (other than stuff directly mentioned in the FGD. Might be overkill, but it's useful in some cases. If you don't know leave it out so we know it's still to be done. For choices, the extra engine tag is used to indicate what the actual data type is once ingame, so we can apply instance transforms, pack resources, etc.

[SirYodaJedi]

@resources is a custom bit of syntax, it indicates what resources this entity loads itself (other than stuff directly mentioned in the FGD. Might be overkill, but it's useful in some cases.

Is it possible to have resources be conditional based upon the entity's KVs, or do I just list everything? info_doddetect has a specific set of soundscripts that it choses from.

[TeamSpen210]

It can be conditional yes, but it's a bit more work I'll probably need to do. You define func somefunc, then those are implemented as Python code in the srctools library. Probably easier to list everything, main place that's useful is if stuff is built up out of multiple keyvalues or something. Also, for the unchecked ents, internal ones go in engine/, and can be referenced by an entity some_ent resource to indicate it's getting spawned. Up to you if you want to go to that detail though. It's obviously not necessary for the FGDs, but provides information for the postcompiler and other tools.

[vrad-exe]

You should really rename TF2BRANCH to 2013MP, since that's really what branch it is internally, the VDC is kind of misleading listing it as separate

[SirYodaJedi]

You should really rename TF2BRANCH to 2013MP, since that's really what branch it is internally, the VDC is kind of misleading listing it as separate

It's a continuation, but very different from the 2013MP prior to the update. It's not an actual "branch", no, but it is a distinctly different (and semi-incompatible) engine version; that's why Hammer++ had different TF2 and SDK2013MP versions. The 2025 SDK update should've been a separate new SDK, not pushed as an update to SDK 2013.

[vrad-exe]

Perhaps 2025MP would be better then if you want to keep it separate, I don't feel like it really makes sense to refer to it with TF2 though since it's used for a bunch of other games too

[SirYodaJedi]

That works; keeps it future-proof in case there's another major update.

[TeamSpen210]

Yeah aurovis() isn't, I need to remove that. Originally I had normal @AutoVisgroup blocks, then made the autovis() shorthand, then realised the amount of visgroups were inconsistent and excessive. So I had it dump out the full list into the config file we have, deactivated autovis() and adjusted the config.

[TeamSpen210]

Oh also noticed you mentioned Mapbase's ent sprite font - I do have another option, a script in the repo root that assembles those.

[SirYodaJedi]

Ah, spritefont.py; I see that now. That simplifies things; wish I noticed it sooner.

[SirYodaJedi]

Okay, I tried to run the build scripts locally, but command prompt crashes (without the FGD being made). I don't want to mark this as ready for review until I can test it locally.

[TeamSpen210]

What error do you get? What version of Python are you using?

[SirYodaJedi]

What error do you get?

Okay, I had to open command prompt from within command prompt to get it to not "crash", because the exit commands from within the build.bat file would close the command prompt instance (which I perceived as a "crash"). I see now that I need to install srctools (perhaps there should be a brief section on the wiki for building prereqs?)

What version of Python are you using?

I recently changed the version on my %path% to 3.13.3.

[SirYodaJedi]

I installed srctools via pip and ran build.bat, but it seemed to put every single entity in each FGD (regardless of if I chose all or dods), so I'm still not sure I did it correctly.
built_fgds.tar.gz