Talk:FGD

Anyone feel like making a nice FGD editor?

Anyone feel like making a nice FGD editor? :) - Chris Bokitch 16:58, 7 Jul 2005 (PDT)

Gulp. . .um, I could do that, 32bit MS OSes.

Almost afraid to ask but how did you invision that working? i.e. Informational support from Valve, updates, testing, validation, etc. [1] --wisemx 06:19, 8 Jul 2005 (PDT)

Well, I guess I was just thinking of a visual environment for creating and managing the FGD. Thinking of each "block" (entity, comment, baseclass, etc) as an object that can be inserted and moved around. Managing references (base references), inserting/removing the helper attributes (color, etc). Chris Bokitch 11:26, 11 Jul 2005 (PDT)

Why not... ;) In about a week I´ve finished my exams, so I have time for this --King2500 15:11, 11 Jul 2005 (PDT)

Meanwhile, seven years in the future --Nacimota ^{Talk | Contributions} 13:15, 31 May 2012 (PDT)

That would be nice to have around. - Shens 15:15, 11 Jul 2005 (PDT)

do npcclass & pointentityclass actually work?—Ts2do 22:58, 23 Sep 2005 (PDT)

I'm not planning to make an editor, but I've got a formal grammar for ANTLR working pretty well right now. Reading it is the harder part anyway, because there's more variation... --Terr 11:36, 11 December 2009 (UTC)

You could consider using SublimeText to edit FGD files, I wrote syntax highlighting available here: https://github.com/Crowbar-Sledgehammer/forge-game-data-language

Connecting spawnflags in the .FGD with code in the .DLL

Does anyone know how the values of each spawnflag (like 65536, 131072, and so on) are chosen? I realize their binary representations set a single bit to one, but other than that how are the values in the fgd correlated to the values in the .dll?

each flag is 1, 2, 4, 8, 16, 32, 64, 128...this is how they're defined in the dll—ts2do ^(Talk | @) 23:35, 24 Nov 2005 (PST)

Additional Variable Types

I'm currently writing a mod with many entities that reference external script files. It would be a godsend if a new variable type was allowed in FGD files, so that you could browse for ANY file type - much the same as the current implementation of the "scene" variable type, only for generic files. An alternative would be to allow browsing for any .txt files, though as many people may use script files with their own file extensions that might not be quite as useful.

As it stands, I need to type in every file path manually, which is quite a chore when dealing with hundreds of entities! It would also be really handy if hammer then had an "open" button underneath properties of this variable type, so you could launch the default program to open the file you had browsed for. I'm just using .txt files as my scripts, so it would be a really useful feature to be able to open them with notepad from hammer, rather than fiddling around in folders trying to hunt them down.--ReNo 22:15, 4 Apr 2006 (PDT)

What are you trying to accomplish with scripts and have you considered alternatives?—ts2do 22:18, 4 Apr 2006 (PDT)

I'm creating an AI system for background characters - think of it as a more elaborate take on the actbusy system. The scripts DO contain data that could easily be used as entity properties instead (eg. min_time, ideal_population, etc...), but they also contain others that are not so suited. For example, each activity point (a point entity at which NPCs can do a set of activities) links up to a script that defines all of the activities available at that location, and each of the listed activities can have a variable number of "tags" (which are a generic strings used to encourage order to the selection of behaviours). Keeping everything in scripts rather than splitting the data between scripts and entity properties means that things are easily reusable and maintainable. --ReNo 08:19, 5 Apr 2006 (PDT)

I know it would be easiest to use scripts then...but consider using the approach like ai_actbusy_tags with up to 20 tags (how many you need)...and reference those using nodes...then if you need to reuse them later, just make prefabs—ts2do 13:49, 5 Apr 2006 (PDT)

I had considered doing that but never thought of the prefabs idea for reusability. I think I'm gonna stick to using scripts for now, as the system allows for some other neat features (eg. each script can use a #include style system, meaning you can include common base activity scripts and add specialised tags on top of them, etc...), but thanks a lot for your suggestion. This mod is being developed as my uni honours project, and so the use of the Source engine is more to provide me with a solid base of features rather than for me to compliment the engine, so I'm trying to compromise the engine to work with my system rather than compromise my system to work best with the engine. I just feel that scripts are a useful thing to be able to reference from the editor - at least browsing for them, and even better being able to launch/edit them - so if any Valve bods come across this, give it a thought guys ;) I'm sure I'm not the only one who'd find it useful.--ReNo 16:14, 5 Apr 2006 (PDT)

Have you thought of designing a script browser/list?—ts2do 17:45, 5 Apr 2006 (PDT)

Its something I've considered, but the real benefit I am looking for is being able to choose and edit the script for an entity from Hammer for the sake of ease of use. Notepad is a fine editor for such simple scripts, and the directory structure I'm using is easy enough to navigate, so I don't really see much benefit in a seperate editor/frontend for the scripts with my current implementation. I've spent some time these evening changing the script loaders to search the correct paths and fill in missed out file extensions automatically so that in hammer I now only have to enter the actual filename of the script, and that has gone some way to simplifying the level editing step.--ReNo 18:11, 5 Apr 2006 (PDT)

Conditionals

Is there any way to add conditionals to the FGD so different keys can be shown/hidden depending on others? AFAIK theres not (haven't ever seen anythin like it before), so would anyone support the idea for Valve to implement? Wraiyth 02:27, 15 Aug 2006 (PDT)

There's no way to do this currently but you could split what you want into different entity names, link them to the same class and use string comparison to see if a certain entity is chosen. You could also just add a note that a certain keyvalue is only used for a certain setting. Or you could just disregard hiding anything and pick from them in code.—ts2do 10:02, 15 Aug 2006 (PDT)

HL2ep1 fgd update: installation instructions

1. Copy the new fgd updates ("base_Geardev.fgg" and "halflife2_Geardev_ep1.fgd") into "\steamapps\<username>\sourcesdk\bin" folder.
2. Use GCFscape [2] to load "episode 1 shared.gcf" and (right click on "episodic" in the right-hand pane) to extract the goodies into "\steamapps\<username>\half-life 2 episode 1".
3. Restart Steam.

Unfortunately "Sourcesdk -> Current Game" selector still does not list HL2 ep1, and modelviewer cannot find any new resources ... what else do I need to do ? Beeswax 14:20, 12 Oct 2007 (PDT)

Hmm it should pop up okay and should always have ep1, try re-installing the sdk. Also make sure you extract models and textures to source sdk content folder to the hl2 folder. Yeah also you make a mod and put the models and textures in there.--Gear 17:55, 12 Oct 2007 (PDT)

Editing auto-visgroup

Did someone find a way to make it work? --ArmageddonSnipe 12:04, 10 July 2012 (PDT)

Spawnflags disappear under certain circumstances

If a class replaces spawnflags that were inherited from another class, then all spawnflags that appear below the replaced one(s) will be deleted, based on order in the FGD, not the integer. This behaviour is different from regular keyvalues. Ex:

@BaseClass = Example
[
	spawnflags(flags) =
	[
		2 : "baseflag 2" : 0
		16: "baseflag 16" : 0
		4 : "baseflag 4" : 0 //this gets deleted
		8 : "baseflag 8" : 0
		32: "baseflag 32" : 0 //this gets deleted
	]
]

@PointClass base(Example) = PointClass
[
	spawnflags(flags) =
	[
		1  : "pointflag 1" : 0
		8  : "pointflag 8" : 0
		16 : "pointflag 16" : 0
		256: "pointflag 256" : 0
	]
]

Would result every spawnflag in the BaseClass under 16 getting deleted, since that's the first flag that is listed. In this case it results in flags 8 and 16 getting overwritten as per usual, but 4 and 32 get completely deleted.

The spawnflags of PointClass would look like:

• pointflag 1
• pointflag 8
• pointflag 16
• pointflag 256
• baseflag 2

A fix for this is to either move the spawnflags that get overwritten to the bottom of the BaseClass, or adding all desired spawnflags to the PointClass.
--Sirhephaestus (talk) 10:29, 30 November 2024 (PST)

This sounds like an editor-specific bug. Which editor?
— SirYodaJedi (talk) 10:41, 30 November 2024 (PST)

Hammer++ but just checked and it's in regular hammer too, for CSS. --Sirhephaestus (talk) 13:27, 30 November 2024 (PST)