 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
- entity name
- description of entity - bbox extents - spawnflags - keys (and the valid range of values) - is it meant to be a point entity or a trigger/bmodel (not always obvious) - anything else I forgot How many times do I have to link http://kell.quaddicted.com/quoth/quoth_tutorial.html in this thread... Apart from the handful of entities I listed in my last post, this information is there for all the new entities. The quoth naming convention is that anything that's a bmodel gets trigger_ or func_ in front of it, anything else is a point entity(the point sized triggers are a exception to this for obvious reasons). The size of monsters can be grabbed from in game if it's needed, but as a general guide things are either shambler sized or enforcer sized - the vermis is the only real exception to my knowledge. you actually sent round emails containing descriptions of most of the new stuff when developing quoth 2. I can probably fish out all the info and post it in this thread when I get home tonight if that's ok.
As I said, I know the bulk of the documentation is done. I know where it is. Thank you. :)
Why not decompile the progs so you can put together a working Why don't you try to dig your way to China with a spoon? Look, as I've said, I appreciate the effort that has gone into Quoth/2. I understand that this is a project done in people's spare time and I would neither expect nor demand anything more. I would simply rather wait to have the complete info before I start making This is not just laziness talking - given that I wanted to make a If that makes me sound like an ungrateful bastard, so be it. I'm not in a hurry though, and I don't have a Quoth/2 map on the go, so I have the luxury of waiting. If the docs are never completed, obviously I'll deal with it in one way or another, but you won't hear me bitching about it. p.s. thanks for the extra info, Preach. :) "'Till you're blue in the face Preach, 'till you're blue in the face"
I tried pointing my editor at that web page but it didn't seem to parse correctly. I didn't have any real problems implementing the wider range of features Quoth2 has to offer into my last map! The tutorial at kell.quaddicted.com was very informative, and with a little savvy and common sense I was able to use the new stuff with no major problems, all of the gameplay added to the map in just a couple of good sessions (before playtesting that is). The map sources were very usefull, and I found the map source for the breakables to be highly usefull too, a real good way of getting the right effect for whatever situation you require.
I've never used a def file in my life, so I can't comment on that. after I have finished the current rmx map I am working on I will be returning to Quoth straight away, with the intention of making a small episode, probably in no particular rush. I am getting busier all of the time, crikey, I've been mapping for about 11 months, and have made 10 maps and am currently working on an 11th. I was delighted to discover Quoth during the construction of the 1st release, I know that there is much more I can still do with it...
I dont see me kicking this habit of making Quake maps any time soon, but I will probably slow down some, the next project will be made slowly at my leisure, as a relaxing way to disconnect from my daily schedules... There's heaps of info on the web pages. More than I would have expected - very informative.
The def file isn't really any different to a FGD file (it's the same thing really, it's just in a different format). Here's the point though, since it seems like it still isn't clear: It is impossible to create a complete There's certainly enough info to make a map. There's not quite enough info to create a comprehensive If a job is worth doing, it's worth doing properly. If I'm going to make a That is all. How about starting on it, taking it as far as you can with the info available, then getting Preach to fill in the gaps...
(I should have been a politician) Then it's done, innit! Don't oppress me with your common sense and logic!
(Real answer: because I'm lazy ;) I could put most of it together this weekend I suppose. *grumble* 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.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |