stratasource/fgd

The FGD + Hammer resource files for games built on Strata Source.

fgd's Issues

Add custom icon for `info_portal_gamerules`

info_portal_gamerules is use info_target icon currently.

Default `prop_dynamic_base` key value `animateeveryframe` to 1

The above KV should default to Yes rather than No as that is the state that most mappers will want their animated props to be in. This KV being set to no results in issues such as the following video:
https://cdn.discordapp.com/attachments/654321545044426762/1059599402689363989/Desktop_2023.01.02_-_18.28.57.01.mp4

The performance impact of this should be considered before simply making the change, since this may result in unexpectedly large numbers of props all being updated every frame unnecessarily.

https://github.com/ChaosInitiative/Chaos-FGD/blob/master/fgd/bases/prop_dynamic_base.fgd#L24

Light falloff shouldn't be in BaseLight

The light falloff parameters only apply to light and light_spot, not light_directional or light_environment. Should we have a new base light for these two?

Falloff parameters:

_zero_percent_distance
_fifty_percent_distance
_hardfalloff
_constant_attn
_linear_attn
_quadratic_attn
_distance

Remove `npc_houndeye`

In dev build npc_houndeye is cuted, so, it's should be removed also from .fgd.

Add OnFizzled output to BaseAnimating

OnFizzled is actually a CBaseAnimating output, not specific to prop_weighted_cube like the default FGD would imply. Currently P2CE's FGD only has it for weighted cubes still.

Add custom chaos-FGD readme file

[GitHub Actions] Manual Release Artifact Upload should just use created game ZIP files

Currently the artifact uploader processes all 1600 files instead of running after the the game ZIP commands. A simplification can be to make the two ZIPs and upload those as artifacts, cutting it down to just 2 already-compressed files.

Missing light parameters _castentityshadow and _shadoworiginoffset

We're missing two parameters from BaseLight (although these don't seem to apply to light_directional).
_castentityshadow : a 1 or 0 boolean with a defaulted of 1
_shadoworiginoffset : a three float vector with a default of 0 0 0

These were added in L4D and are documented on the VDC as "not be available in some FGDs".
https://developer.valvesoftware.com/wiki/Light

Put Portal-related entities exposed in codebase behind USE_PORTALS switch

Stuff like linked_portal_door so games that USE_PORTALS can use em

info_player_start has a doubled model helper

info_player_start has both studio and studioprop helpers, resulting in it having two hitbox outlines, and rotating it with the handles causes it to rotate by twice the amount. It should only have studio (since the hitbox is supposed to be a fixed size representing the player).

Consider adding a separate keyvalue for naming `light` entities

Adding a name to light entities causes VRAD to treat them differently in the compiling process, though some people may want to name lights for organizational purposes and might not want them to be grouped together by VRAD. To fix this, we should consider adding another dummy keyvalue for lights that people can use for names. Or, adding a new keyvalue for VRAD and making 'name' be ignored by VRAD. Or, adding some sort of entity flag that does a similar thing. I personally like option number 1 the most.

Suggested by corny in the p2ce discord

`info_player_start` transform conflict

The semi-recent changes to add a custom player_start model have caused the transforms to the entity to be performed twice

Removing studio() fixes this, but I'm unaware of the repercussions, if any.

Default `game_text` location to somewhere other than the center of the screen

By default the location of a new game_text entity is -1, -1 which centers the text both horizontally and vertically. If a mapper forgets to change this, this places the text right over the player's crosshair which can be very frustrating. A more acceptable default would be x = -1 and y = 0.7. See below comparison. Obviously this won't affect existing maps but it should prevent more in the future from making this mistake.

Change func_button default flags for momentum mod

In momentum it makes the most sense for func_button entities to have the "damage activates" flag enabled by default and the "use activates" flag disabled by default, as that more closely matches what mappers typically use buttons for. This is probably not a change p2ce wants.

Clarify use of OnSoundFinished in ambient_generic

We fixed some issues with OnSoundFinished output on ambient_generic, and disabled it for looping sounds.

Add func_slick FGD definition

Create a func_slick FGD definition. This brush entity has no properties and makes the player slide when standing on it.

[Momentum] mom_df_weaponspawner entity

Added recently to momentum, this entity spawns defrag weapons.

vgui_movie_display uses .bik presets

With Smart Edit on, when selecting our movie to display in the Movie to display keyvalue, the preset options will point to the respective .bik files, instead of the recently implemented .webm videos.

math_counter_advanced icon is lost

Describe the bug

math_counter_advanced icon is lost.

To Reproduce

1. Open Hammer.
2. Place entity math_counter_advanced.
3. Pay attention that icon use error texture.

Issue Map

None of maps in game, lol. Only in Hammer.

Expected Behavior

User should see icon from Mapbase or see icon created by P2CE Team.

Operating System

Any.

Update Momentum's CmdSeqDefault.wc file to have Zonmaker called before VBSP

Last step of momentum-mod/game#1331 moved here.

Add USE_VEHICLES tag

Some ents (like the jeep) are behind USE_VEHICLES feature switch in the engine. It'd be good to add the tag to this repo so the vehicle entities arent exposed through the FGD for a game when they're compiled out.

Update from latest upstream

Not precisely everything but the base FGD fixes along with the texture touchups would be great.

Add GitHub action that builds latest Hammer content

So the files can (not always, nor recommended!) be obtained outside of requiring the push via Steam.

Also to help verify PRs don't break anything!

Try to pull latest HammerAddons commits down

they have some useful changes that we'd like, just need to solve lots of merge conflicts in the process

A small scripting language embedded into the fgd

Trenchbroom currently has this, I believe it's main use there is setting models depends on the keyvalue because quake-like games don't do that automatically like source hammer does for the model keyvalue.

That ability would be nice to have here too, for example the defrag weapon spawner could change its visual model depending on the keyvalue. However what I believe is most useful would be hiding other keyvalues depending on the value of another. For example in trigger_push, it has a keyvalue called reorient_landmark that only applies when the mode is set to 4. reorient_landmark should be hidden until mode is set to 4, as it is unneeded in all other cases. Another use case would to manually set another keyvalue based on the value of another, but I can't think of a use case of this off the top of my head right now.

Unify FGD script duplicates "i" parameter for both import and export

The unify FGD script specifies i as an alias for both import and export, which appears to now cause an error on Python 3.11 or otherwise after some update.

Traceback (most recent call last):
  File "C:\Users\Luke\Git\Chaos-FGD\unify_fgd.py", line 1323, in <module>
    main(sys.argv[1:])
  File "C:\Users\Luke\Git\Chaos-FGD\unify_fgd.py", line 1218, in main
    parser_imp = subparsers.add_parser(
                 ^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Luke\AppData\Local\Programs\Python\Python311\Lib\argparse.py", line 1188, in add_parser
    raise ArgumentError(
argparse.ArgumentError: argument mode: conflicting subparser alias: i

HammerAddons fixed this already

Automatically enable "Clients" flag for teleport triggers

Mappers in Momentum (and in general) prefer to make teleport triggers that teleport the player. It seems like if the player doesn't want to be teleported should be an opt-out thing, but if P2CE doesn't desire that, can be game specific flag defaults.

Per-game gameconfig defaults

Currently, P2CE's default gameconfig includes momentum & vice versa. Makes little sense as hammer wont even work in those situations (wont find FGD, etc).

Programmatically find FGD omissions using game code/executable

Entity classes, key fields, inputs, and outputs are defined in the game in a way that can be gathered programmatically. This could be used to find at least some definitions that are missing from an FGD file, or find FGD definitions not actually present in game. This could unfortunately not be used to generate the entire FGD, as some things would still require manual effort (spawnflags, and all entity/field descriptions, to name a few).

Update trigger_teleport with the changes from momentum

Base Chaos' trigger_teleport has been merged with momentum's, so we can remove the jank surrounding it in the FGD.

Show coordinates of point entities such as info_teleport_destination in the entity properties

Originally requested from Bocuma:

Brush entities have their origin coordinates listed here but point entities don't, which means I have to open the vmf in a text editor to find it.

Bug: env_projectedtexture Light World option is set to no by default.

Describe the bug

In hammer when you create a new env_projectedtexture the Light World option is set to no by default, however in normal Portal 2's hammer this option is set to yes by default.

To Reproduce

1. Make a blank map in hammer, doesn't need to be compiled.
2. Place down a new env_projectedtexture entity.
3. Check it's options and see that the light world option is by default set to no.

If you want to double check this then copy the exact same steps in normal Portal 2's hammer except this time you'll see the light world option is by default set to yes.

Expected Behavior

Light world option should be set to yes by default, as this can be annoying when creating new projected textures and the shadows don't appear.

Operating System

Windows

Entity icons for new momentum mod entities

Currently from what I see the entities that need their own icons are: filter_momentum_campaign_progress, filter_momentum_collectibles, filter_momentum_player_state, filter_momentum_progress, filter_momentum_track_number, filter_velocity, env_surface_teleport, and momentum_df_weaponspawner

Add USE_NAV_MESH feature switch

Change "Name" property in Entity filter_activator_name to "targetname"

As requested from pretzl:

For ease of understanding, the "name" property in the entity filter_activator_name should be changed to "targetname" since this is really what it is. Triggers use this name to call to the filter entity with the convention "targetname ", but as-is can be confusing at times.

Make sure to do this in game code as well!

Add SJ bounce trigger

Move boolean choices to just use boolean

Quite a few fields declared with the choices type are really booleans, restricting choices to yes/no:

The boolean type already does this though, so just use that:

The reason they aren't using it already is that it was added later, so I don't think SDK2013 has support for it.

Include HL2 global states in env_global default choices for P2CE

Since P2CE supports most of the HL2 global states, they should be provided in the default dropdown instead of needing to be typed in manually. "Spawn without portalgun" should also be removed, since it doesn't function as far as I'm aware.

Consolidate build scripts to take game as parameter

Right now they're in their own files and could be consolidated with a simple menu if one is not provided to the script.

"all" should build all applicable.

Recent defrag changes

Remove `item_longjump`

P2CE have no item_longjump, but it's still in .fgd.

trigger_overbounce -> func_overbounce

Overbounce triggers for momentum were changed to be func_overbounce

Remove `trigger_momentum_slide`

Related to momentum-mod/docs#287 , remove the old trigger_momentum_slide entity and any references to it. we will be solely recommending people use func_slide in their future maps

Deprecate *_prop entities

The entities dynamic_prop, physics_prop, and static_prop should all be deprecated. These entities only lead to mapper and programmer confusion, with mappers not knowing if there is a difference and programmers not realizing the *_prop entities exist. We’re stuck supporting these on the engine for compatibility, but we can deprecate them in Hammer. We should either outright delete their entries or extend FGD to add some type of deprecated tag. Making a deprecated tag could be useful for some of the other legacy entities as well.

https://github.com/StrataSource/FGD/blob/master/fgd/engine/dynamic_prop.fgd
https://github.com/StrataSource/FGD/blob/master/fgd/engine/physics_prop.fgd
https://github.com/StrataSource/FGD/blob/master/fgd/engine/static_prop.fgd

add prop_portal to momentum fgd

prop_portal exists in momentum but is obsolete in momentum hammer ;)

Make linked_portal_door StartActive "yes" by default

I don't know if p2ce likes it better this way with how maps use portals, if so consider game-locking this

Suggested by touny

trigger_momentum_catapult changed to trigger_catapult

The above entity was renamed but the fgd (at least my local one, maybe steam didn't update it) still has the former which means if you place one in-game it will do nothing because that name doesn't exist. Should be a very easy fix.

`func_illusionary` should not contain `solid` keyvalue

func_illusionary should not contain the solid keyvalue as this entity can not be solid in any way

Add Trigger* FGD definitions

A few triggers found without definitions in P2CE:

trigger_callback
trigger_survival_playarea
trigger_portal
trigger_super_armor
trigger_momentum_reversespeed
trigger_momentum_setspeed
trigger_momentum_teleport
trigger_momentum_userinput
trigger_fog
trigger

Note: Some of this are probably partially/non functional. In which case they should be put in engine category to hide from FGD users, or taken out of the game completely if possible.

Add "solidbsp" keyvalue to doors & buttons

It was added as part of the Momentum import, but used for all doors, buttons, and prop doors. Should just be in Door.fgd