ok, todays class is about Worldcraft's FGD file first off, FGD stands for Forge Game Data...Ben ended up calling it Worldcraft because of a copyright conflict with someone elses product an FGD entry breaks down into a fairly simple formula: @ClassType base([, ...]) size(x y z, x y z) color(RRR GGG BBB) = : "" [ key(var-type) : "" : default value ] The @ClassType can be one of three things: BaseClass, PointClass or SolidClass PointClass and BaseClass both define the actual entities for use in Quak e :) More on those after First, the BaseClass, which is quite important if you plan to create many entities BaseClasses are used to define building blocks for entities The following example, for instance: @BaseClass = Appearflags [ spawnflags(Flags) = [ 256 : "Not in Easy" : 0 512 : "Not in Normal" : 0 1024 : "Not in Hard" : 0 2048 : "Not in Deathmatch" : 0 ] ] @BaseClass base(Appearflags) size(-16 -16 -32, 16 16 32) color(0 255 0) = PlayerClass [] @PointClass base(PlayerClass) = info_player_start : "Player 1 start" [] ...covers almost everything in the FGD format, although in a rather simple method The first entry, for Appearflags, defines itself as a BaseClass. Appearflags will be used to make other entities have the ability to only appear at certain skill levels. The second entrPlayerClass becomes a descendant of Appearflags, and gains all its properties. PlayerClass becomes a descendant of Appearflags, and gains all its properties. doh..one sec The second entry, which is also a BaseClass, creates PlayerClass. By specifying the base(Appearflags), PlayerClass becomes a descendant of Appearflags, and gains all its properties. Also, the size() and color() parts of the definition will let Worldcraft know how to display the entity when you are making a level. The third entry finally defines an entity, info_player_start, which is a PointClass. It is a descendant of PlayerClass, and therefore has the properties defined in both PlayerClass and Appearflags. If you were to write this entity out by itself, you would write: @PointClass size(-16 -16 -32, 16 16 32) color(0 255 0) = info_player_start : "Player 1 start" [ spawnflags(Flags) = [ 256 : "Not in Easy" : 0 512 : "Not in Normal" : 0 1024 : "Not in Hard" : 0 2048 : "Not in Deathmatch" : 0 ] ] thats only 10 lines of code...thats not soooo bad...right? but by defining the two BaseClasses above, it also allows you to define the following... @PointClass base(PlayerClass) = info_player_start : "Player 1 start" [] @PointClass base(PlayerClass) = info_player_deathmatch : "Player deathmatch start" [] @PointClass base(PlayerClass) = info_player_coop : "Player cooperative start" [] @PointClass base(PlayerClass) = info_player_start2 : "Player episode return point" [] @PointClass base(PlayerClass, Targetname) = info_teleport_destination : "Teleport destination" [] ...in 5 lines of code, instead of the 50 lines it would otherwise require to define each entity separately. fifth entity there, info_teleport_destination, also includes the BaseClass Targetname, which inserts a Name field in Worldcraft's SmartEdit properties for that entity, and a "targetname" key in the .MAP. ok, the next part of that formula i'll cover is base([, ...]), size(x y z, x y z), color(RRR GGG BBB) the base() part is used to include the BaseClass names as covered above you can include a bunch of BaseClasses by going base(Target, Targetname, Appearflags, Whatever, Else, You, Want) there isnt really a limit a base entry is not required tho, and an entity will work perfectly fine with no base() declarations The BaseClasses in the standard Worldcraft quake.fgd file are: Appearflags, Target, Targetname, PlayerClass, Ammo, Weapon, Monster, Light, Door, and Trigger. The size() declaration controls how big the bounding box of the entity will appear in Worldcraft You only need to specify a size for pointclass entities. SolidClass entities are those entities that have to be attached to a brush The reason for the two sets of values in size(x y z, x y z), instead of just giving one width, height, and depth, is that some entities are not "centered" at their middle point. An example of this is the entry for the monster_army entity. It has a size defined as size(-16 -16 -24, 16 16 40), so its center is not in the middle, but 24 units above the bottom of its bounding box. the color(rrr ggg bbb) declaration is quite simple - you dont need it. :) Worldcraft defaults to using the standard magenta (?) color for entities if no color is specified But, if you think that your custom entity deserves to have some flashy color, say...tangerine...you can specify color(255 136 17), which would be the red/green/blue color values for a bright orange. Custom color values can be found with a number of paint programs (I used Paint Shop Pro to get this example). The = : "" part of the entry defines the actual entity name for use in worldcraft and the Quake .MAP. the "description" i have found no use for...anyone else? ok, now for the part that can be a pain in the ass keys and flags and stuff :) anything that is individual about the object must be entered between the [ and the ] all keys follow the format key(var-type) : default value er....actually key(var-type) : "SmarEdit description" : default value the key is the .MAP variable thing...."wait", "delay", "target", etc There are five types of variables that can be used with the keys: integer, string, choices, Flags, and target_source. Of the 5, Flags and target_source types seem to be the most specialized. Flags may only be used with the spawnflags() key. Its values typically ascend in powers of 2 (1, 2, 4, 8, 16, 32, etc.). The appropriate values for these can almost always be found in the .qc files, if they are handy. The flags define what will appear in the entities Flag section when you are looking at its properties An example from above had the following: spawnflags(Flags) = [ 256 : "Not in Easy" : 0 512 : "Not in Normal" : 0 1024 : "Not in Hard" : 0 2048 : "Not in Deathmatch" : 0 ] 256 is the value for the spawnflags key, "Not in Easy" will appear ni Worldcraft as the description for that flag, and 0 tells worldcraft to have that as off for a default You will not have to add these flags to any of your entities, as the BaseClass Appearflags is already defined. But there are other things which will require flags. An example: the Light entity will start either on or off, depending on the value of its flag, "initially dark" The target_source is used 8 times within the standard quake.fgd, and is restricted to use in target, targetname, and killtarget keys. I have seen no problems with using the string variable in place of a target_source variable, however. The integer variable type is self explanatory, but the string is a little misleading. You can use a string for characters (of course) or for rational numbers ("1.1", "1.2", etc) The choices variable type is best used when a key has several values that correspond to different things. A good example is the sound key. Each number stands for a different sound, but just having a choice of 1 to 4 is not very intuitive, so by adding this to the definition… sounds(choices) : "Sounds" : 1 = [ 1 : "secret" 2 : "beep beep" 3 : "large switch" 4 : "Set message to text string" ] …you can just select from the list the appropriate sound, which is then translated to the numeric value for the .MAP. ok the next stuff is from The Forge Add-ons section, and deals with some errors you might encounter from worldcraft when you play around with the fgd since they are text (Doh..you all knew that right? :) you can go in and change stuff to suit yourself better but, Worldcraft isnt very forgiving when you screw up Currently, Worldcraft does not like it when an entity is declared twice. When this happens, Worldcraft will pop up a messages window when you start up, and the following error will occur: (this is only an example) error parsing quake.fgd, line 1055: redefinition of class 'func_bobbingwater' This is quite easy to fix...just take out the damn entity...er...you may run into this a bit if you copy the Hipnotic fgd patch onto the end of the standard quake.fgd when you remove the offending entity, be sure to get the first line AND everything between the [ and ]...this seems to be a problem, judging by my email error parsing quake.fgd, line 1052: expected @ error parsing quake.fgd, line 1052: unrecognized section in name base These will occur when you neglect to put a '@' before you start to define an entity, starting a definition with SolidClass, as opposed to @SolidClass. error parsing quake.fgd, line 1052: expecting '(', but found ':' This will happen when you don't place a '=' character in the entity definition's first line (@SolidClass base(Appearflags) func_bobbingwater : "Bobbing Water") error parsing quake.fgd, line 1052: expecting '=', but found ':' This will happen when you entirely leave out the entity's name (@SolidClass base(Appearflags) : "Bobbing Water") error parsing quake.fgd, line 1054: expecting string This occurs when you do not properly add the quotations around a string. This is most commonly done when, by mistake, you are setting up a default value for a string, and enter something like 4, as opposed to "4". This last error tends to...um....crash worldcraft. When i wrote the hipnotic.fgd, i didnt do any testing while i was writing it. After many hours, i ran it and it locked up wc... i wanted to cry... turns out i'd missed one measly little quotation mark...so dont do that this has been fixed in the newest verison of Worldcraft (1.3) so i've been told well...that about wraps it up