 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Yeah, I acknowledge you can't complete the fgd yet. But I can assure you that anything listed there, eg func_breakable, is fully documented, we shouldn't be adding anything more to that entity when the documents are updated. I didn't realise you'd be able to knock something out within a weekend, I figured it would take you longer to write it than it will for Kell to update. I had also been planning to post the playtester info Than mentioned in this thread to tide people over(I can't update Kell's website). Than, if you've got it all gathered together I'd love to see it here.
It's pretty simple, it's just a text document with an entity definition something like this (see below). All that really matters is the first line, which defines the entity name, bounding box extents (or ? if it's a bmodel), and spawnflags.
The rest is basically just information for the mapper (a desription of the entity and the list of keys). It's optional, even the key list, since in Radiant you have to manually add your keys every time regardless of whether that info is there or not (it's just helpful for the mapper to have that info, of course!) /*QUAKED func_door_secret (0 Basic secret door. Slides back, then to the side. Angle determines direction. Flags: "open_once" - stays open when triggered "1st_left" - 1st move is left of arrow "1st_down" - 1st move is down from arrow "no_shoot" - only opened by trigger "always_shoot" - even if targeted, keep shootable Keys: "target" - all matching targets will be used "killtarget" - all matching entities will be removed "wait" - # of seconds before coming back "delay" - waits # seconds before firing its targets "t_width" - override Width to move back (or height if going down) "t_length" - override Length to move sideways "dmg" - damage to inflict when blocked (2 default) "message" - prints message when touched "sounds" 1 = medieval 2 = metal 3 = base NOTES: If a secret door has a targetname, it will only be opened by it's button or trigger, not by damage. */ Again, all that matters is the first line (preceded by QUAKED), though you should note that func_msgboard wrapped the text in the post above.
The rest is purely optional information and can be in any format or order you wish. The text will appear in the entity dialogue in Radiant regardless of how it is written. As you can see, most of the "work" involved in creating the Quoth2.def file will be a simple copy/paste job from the web page. Posting this just in case anyone wants to know exactly how the
The structure is basically this: /*QUAKED entity_name (colour) (bbox extents) spawnflag1 spawnflag2 Optional info... */ The colour is just an RGB (0-1) colour for Radiant: it will only affect how it is displayed in the editor. If the entity has an associated brush model, the bbox info will be replaced with a ? Here's 2 examples, a point entity and a bmodel, which will demonstrate this: /*QUAKED item_spikes (0 25 ammo points (spikes) for Perforator and Super Perforator. Flags: "big" gives 50 instead of 25 */ /*QUAKED func_episodegate (0 This bmodel will appear if the episode has already been completed, so players can't reenter it. */ I use Worldcraft and have written a few
Looks to be the same tedious task, but in a different format. it has come up a few times before, and may be useful for Worldcrafters to know. When you see 't1', 't2', 't3', etc, as target names in source maps, that is the result of Radiant filling in the name field when you are too lazy to name the entities yourself. Radiant links the hunter entity to its target entity with a line in the editor window so it isn't difficult to keep it organized while mapping.
Quick question on the Sentinel monster. Here's what the web page says:
classname: monster_sentinel health: 150 size: small ranged: lasers/nails melee: none special: flying The above indicates that it can fire lasers, nails, or both. What controls this? Is it set by spawnflags or keys, is it implied by the worldtype in worldspawn, or does the code just choose and/or switch at runtime? Here's some info on the omitted entries, tide people over until the official writeup:
Commands: info_command trigger_command These two entities send a command to a client's console and execute it. The info_command is a point entity which sends the command when triggered, and the trigger_command is a brush based trigger which sends it when touched. Set the "message" key to the commands that you wish to send to the player, followed by the newline escape code: "\n". For example, "message" "fog 0.1 0.2 0.2 0.4\n" will set the fog level in engines that support fog. If spawnflag 2 is set on these entities, then the command will only be sent to the player who triggers or touches the entity when this event is triggered in coop games. Otherwise, the command will be sent to all the clients on the server. A trigger_command behaves like a trigger_multiple in all respects but message, so use wait to control how frequently the command can be sent, add a target to trigger other events, and so on. info_command_server info_command_server works in the same way as info_command except that the command is sent to the server rather than the client. In single player games the client and the server are all on one machine, so there is little difference in sending a command to the server or the client. In multiplayer games the distinction becomes important, because on a dedicated server even sending a command to all the clients will not send it to the server. You may have to experiment to find out exactly where a command should be sent. As a general guideline, commands that affect rendering such as fog and bf, commands prefixed r_ and gl_, or commands that affect client input, prefixed cl_, should be sent to the client. Commands prefixed sv_ or host_, which affect physics and similar, should be sent to the server. trigger_command_contact This is a more specialised entity for sending a command once to a client each time they touch it, but not again until they leave and enter the trigger again. As with trigger_command, put the desired command into the "message" key. Since sending commands like this over the network can be bandwidth intensive, it is recommended that this trigger be used to set effects for regions of maps. For example, setting fog in one half of your map can be accomplished by placing a trigger_command_contact with the desired fog level as its message over that half of the map, and a trigger_command_contact with "fog 0 0 0 0" as the message over the other half. If the regions you want the commands cannot be covered simply by one trigger, it is enough to cover each entrance to the area with a pair of triggers, one for the way in and one for the way out. The most important caveat for this entity is that you must ensure it is not possible to touch two trigger_command_contact entities simultaneously. If you do, then both commands get sent every frame, which is bad for performance, and might be noticable to the player in the case of commands like "bf". If you have multiple commands to issue at once, combine them into a single message with each command seperated by semicolons. In the case described above where you have a pair of triggers to toggle some setting, make sure they are separated by more than 32 units so that the player can only touch one at a time. Updates
func_train The sounds a func_train makes can now be customised. Set "noise" to the path of the desired sound the train will make while in motion. This should be a looping sound file. Similarly set "noise1" to the sound the train should make when motion ends. Rather than set the speed at which the train should move, you may instead set the "duration" key, which will move the train at the speed required to make the journey take "duration" seconds between each path corner. If you need to specify the duration of each journey from path corner to path corner, see the path_corner entry below. The "count" key allows you to create clones of the func_train. Each one will start at the next free path corner until "count" clones have been created(in addition to the original) or until each path corner of the circuit has a train. spawnflags: TRAIN_SMOOTH = 1 TRAIN_BLOCKABLE = 2 if TRAIN_SMOOTH is set, will not pause (unless wait is set) on path_corners. It will not apply damage either when blocked, you must use the TRAIN_BLOCKABLE flag to make it cause damage when blocked. path_corner Set "duration" on a path_corner and any func_train which visits this corner will inherit the value of "duration" set. This means it will take "duration" seconds to travel between path_corners from that point onwards. By having each path_corner set duration, you can control the lengths of each stage of the train's journey. The train will use the duration or speed it is given initially for it's first journey between path corners, it will not inherit the duration of it's starting target. The "event" key can be used to trigger an event when a func_train leaves this corner. Set "event" to the targetname which you wish to trigger. This doesn't trigger if the train arrives and stops with a "wait". setting "wait" will cause monsters to pause for that number of seconds on the path_corner. while they are waiting, they will turn to face whatever angle the path_corner has set. if "wait" is set to -1, monsters will stop there forever, and turn to face whatever angle the path_corner has set. info_screenshake info_screenshake now shakes ALL player's screens (not just the one who triggered it) in a radius around it's origin. The entity is the same as before, except you now can use the "height" key to specify how large a radius to affect player's screens. "noise" specifies the looping sound to be played while the entity is active and "noise1" specifies the sound played when it ends. Set both to misc/null.wav to make the effect silent. func_togglewall noise noise1 wait dmg This is basically an invisble func_wall that can be toggled on and off indefinitely. The "noise" key is used to specify the sound effect played when the wall is triggered and "noise1" is for the sound played while the wall is actually blocking the player's movement. "noise2" is the sound to play when a player touches/takes damage from the wall. Add these in the format "weapons/lhit.wav" ( the "/sound/" bit is automatically added by the engine ). The wall can also be set to inflict damage on the player every "wait" seconds, with "dmg" specifying how much damage per hit. Default values are 0.5 and 0 respectively. Spawnflag 1 means that the wall begins non solid, and will become solid once triggered. Spawnflag 2 turns on the particle effect, making this into a forcefield. While the func_togglewall is solid, a particle effect will scroll across it. The "worldtype" key takes values from 0 to 5 specifying the direction the effect scrolls;up, down, east, west, north or south,. The "colour" key should be a quake palette index specifying the colour of the particles. "speed" specifies the speed at which the wave should travel. "style" specifies the number of particles that should be generated per second. Take care that style is not set too high, or the player will be flooded with particle messages, causing lag in network games. If the wall does not have a particle effect, spawnflag 4 will change the type of solid object that the func_togglewall is. By default a func_togglewall blocks line of sight to monsters and has a shape matching the brushes it is built from. With spawnflag 4 it does not block line of sight and has a bounding box shape like a trigger, so it is a cuboid aligned to the axes of the world large enough to cover the whole extent of the brushes it is made from. If you are using this spawnflag, construct the object from a single, unrotated cuboid brush to see the shape of it correctly. That begs the question though, what are the other spawnflags then?
So far I have only included spawnflag 1 as "ambush" which I assume is used here in the same way as the standard monsters. If spawnflag 4 is used to turn the Sentinel into a nail guy, what are the other spawnflags used for? Are there any other new spawnflags for any of the other monsters? The Quoth web page does not specify any new spawnflags for any of the monsters as far as I can see. I just realised I didn't even have the complete range of spawnflags for the standard stuff, let alone the new ones. (The whole easy/medium/hard/not in dm)
I never noticed since I haven't done an SP map in Radiant! (Or at all..) So yeah, anyone got a list of all the spawnflags (new and old? ;) There are the general flags added to all monsters here:
http://kell.quaddicted.com/quoth/quoth_tutorial.html#spawning I don't think any individual monsters have new spawnflags. Also all the coop/not in skill level/not in dm apply, but those get applied to every entity. The monsters in quoth1 tended to have their own keys rather than spawnflags, like the dangle key for vorelings. Spawnflag 2 was skipped because that is also ambush. The ID people screwed up and made spawnflag 1 crucified for zombies, so to make an ambush zombie you give it the second spawnflag. This will in fact work on any monster, both in original quake and quoth. Fribbles, here's what I have for those standard flags:
SF_NotInEasy = 256, SF_NotInNormal = 512, SF_NotInHardNightmare = 1024, I think "DM only" is all of those combined (so, not in any skill level - only DM). It's not a real spawnflag, just a side effect (I think). Or, obviously, not setting any of them will also let the entity appear in DM which is why your DM maps worked. Not in deathmatch is 2048, it's a different flag. Quoth adds
coop only = 4096 not in coop = 8192 which are the next two flags. The quoth coop flags don't work quite as efficiently as the built in ones, mostly with regard to precaching things. If all the shamblers in your map had not_in_easy, then the shambler models wouldn't get precached in easy skill. The same can't be said for the coop flags, as it's done by the qc code, not the engine. Hopefully other than that the effects are the same. Details for the info_trap entity, which is quite complex:
info_trap This entity allows you to create highly customisable shooters along the lines of the spikeshooter in regular Quake. targetname if set, will not start until triggered. Will also turn off when triggered again. target info_notnull to shoot towards. Theoretically, you could target monsters or func_trains... This is only the initial direction. If "tracking" is set, projectiles will eventually curve toward the activator. wait delay between shots delay delay for first shot speed determines the speed of the projectile tracking 0 = None, 1 = Vore style, 2 = Death Lord/Rocketeer style style 0 = Flying, 1 = Ballistic (Explode on Impact), 2 = Bounce (noise2 sets bounce sound, duration sets fuse time) mindamage Defaults to 1. This is the least amount of damage the projectile will cause maxdamage If set, damage will be between 'mindamage' and 'maxdamage'. Maxdamage is at least mindamage dmg Makes this projectile explode. Higher values increase radius and damage. (Player rockets are 120 for reference) noise Sets the sound to play when firing noise1 Sets the sound to play when hitting noise2 Sets the sound to play when bouncing (only applicable with style=2) duration How long the fuse should burn before exploding multiplier This is how much damage will be multiplied when the shooter hits func_breakables. This is so shooters can break func_breakables fast, without needed to be overpowering strong and kill the player in one shot. flashlight Whether projectile should glow, 0 = Don't glow, 1 = glow deathtype String for obituary message, "was zapped by a trap" outputs "Player was zapped by a trap" preset Various preset values for common projectile settings. Preset settings simply replace default settings. Can be overridden selectively. 0 - No preset 1 - Player Rockets 2 - Player Grenades 3 - Player Plasma 4 - Player Nails 5 - Player Super Nails It's a regular func_button except that it can be attached to a door, so that the pair of them move together. This is basically for making lifts with attached buttons. While the door is in motion the attached button and any other buttons which target the door are disabled.
bind Set this key to the targetname of the door you wish to attach the button to. If you require several doors, each with their own attached buttons but all of them affected by by the same trigger, then give them a unique targetname and use targetname2 to give all the doors a single name to trigger them with. In all respects besides this key, the func_door_button is identical to a regular button, and the usual keys of wait, delay, target apply. So why does Quoth2's ambient_generalpurpose precache that one machine sound instead of drip1.wav as specified? Placing a regular ambient_drip entity somewhere in the map seems to fix it though.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |