If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
The keys correspond to entity fields in the QC (progs.dat.)
So if a QC entity has a field "self.effects" you could put a key "effects" on the entity in the map editor.
Actually once a .field is defined in QC (fields are marked by a period in front) then ALL entities have that field. So you could give "effects" to an ogre and make him glow...
The entitiy fields are defined in the QC source. For example,
This as well. It means that all entities have a field called "effects". So in the map editor (any map editor) you could add
"effects" "8"
to any entity to make that entity glow.
There are some fields that make more sense than others to add in a map editor, for example "health" or "angle" make more sense than "effects".
Now there is a subset of entity fields that are usually contained in so-called "entity definition" files so they appear inside the map editor (like in your example.) These are the fields that are listed in the QC source in a special way:
/*QUAKED func_door_secret (0 .5 . ? open_once 1st_left 1st_down no_shoot always_shoot
Basic secret door. Slides back, then to the side. Angle determines direction.
wait = # of seconds before coming back
1st_left = 1st move is left of arrow
1st_down = 1st move is down from arrow
always_shoot = even if targeted, keep shootable
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)
If a secret door has a targetname, it will only be opened by it's botton or trigger, not by damage.
"sounds"
1) medieval
2) metal
3) base*/
Anything in the code that has such a /* QUAKED */ entry is traditionally in an editor .def file (or .fgd if you're using worldcraft.) The fields / keys listed there usually are the most common and make the most sense.
A special type of field is called a "bitfield". Examples are .spawnflags or .items in the code. A bitfield contains many fields because it uses bitwise math. In the code, that usually looks like:
self.items = self.items | IT_SOMETHING;
where IT_SOMETHING is a power of 2. A single bitfield can contain many such powers of 2, and thus you get many fields rolled into one. This is why "spawnflags" can only be 1, 2, 4, 8... or a sum of those.
This is also why, when you give an entity spawnflag 1 and spawnflag 8, the result will be "spawnflags" "9". It's a bitfield.
You can glean the spawnflags of an entity from the QUAKED entries; in the case of func_door_secret. the code says
So to get the most common keys and values, you must read the .def file (or .ent file) of your editor. To get to know *all* possible keys and values, you must read the QC source code.
Edit:
And to make it clear, something like func_door_secret() is called a spawn function. Spawn functions appear to never be actually called from anywhere else in the code and seem orphaned... but they are called eventually.
First the engine loads the gamecode (progs.dat) in order to know about all those entities. Then it loads the map, and while it does that, it calls all the spawn functions. First for the map itself (this spawn function is called worldspawn() in world.qc, which is why a level has something called "worldspawn" and "worldspawn keys") and then for each entity in the level. (The actual geometry of the level, for example, belongs to the entity called "world".)
And while it spawns these entities according to their spawn functions, it fills in those entity fields that were defined in the map editor... and among those are, chiefly, "origin" (which is actually filled in by the map editor when you place something) and "angle" (which is translated to self.angles.)
Those two place and orient the entity in the world (see setorigin() etc. in every spawn function.) The spawn functions will also kickstart the entity's thinking and touching, as well as its animation if it has those things, thus going deeper into the gamecode. And then it spawns the player (if you wonder why the player appears to have no spawn function, this is done via PutClientInServer() in client.qc), which is an entity too...
and then, eventually, the entire thing is updated every frame. Prime examples for such constantly running functions are PlayerPreThink() and PlayerPostThink() (also in client.qc)...
It's just that I would generally like more people to do creative things in this world, so I help where I can.
Some of the hardest parts to understand about Quake modding are
a) how mapping interacts with the gamecode
b) how the gamecode interacts with the engine.
These border areas are cross-discipline, so that may be where the difficulty lies.
And I got most of my knowledge from people like Spike, MH and Lord Havoc, who really understand the entire process (maps, models, gamecode, engine, hardware and everything in between.) They are just far more busy or less inclined to ramble than I am.
All the same I really appreciate it! I think it would be a good idea to get a good beginners guide together for the Quakeone.com community. I understand they have Inside3d and others but I currently don't frequent those and I really thought it would be nice to see some of that stuff here! Maybe even revive those older, rusty Tutorials and revive and redo some of them. Especially some more darkplaces tuts. It would be nice to get guys like yourself, Seven, Rook, etc together and collaborate on such a project for the community. Just my two cents. Again, thanks for your detailed and well explained posts.
A good beginners guide is unfortunately missing from the entire community :-s
Picking up mapping isn't that hard, it's more mapping WELL that is the problem. All you've got to know in the beginning (apart from how to set up the map editor / how to compile) is: seal your map, use stairs that are 16 units or less, avoid long view axes / block your vis, don't use CSG Carve etc. That is pretty manageable. (A bonus one is: don't try to kill the player, just give them something to do.)
With QC, it is probably the other way around - learning basic C (definition, variable, function...) is manageable, and even ugly code might work well enough, but you don't get an idea of how it all works together (entities? spawn functions? precaches? builtins? fields? bitfields? think? touch? function fields? time? ltime? ctime? tempstrings? vectors? angles? animation macros? "game edge functions"? main() function that isn't actually used? bodyqueue? movetypes? networking? O.M.G.) until pretty late in the process. That's because the basics are already in place and people don't look into those unless they positively have to...
Alas, I know veeeery little about Darkplaces. I mean yeah, it is an engine with per pixel lighting, Q3bsp/shader/MD3 support and other niceties, and a lot of QC extensions. But it is different from FTE in some very mind-bending ways. Gamecode actually needs to be "ported" between these engines.
What's most needed is probably a *good* QC primer and an explanation of how it actually works with the engine and with the levels. That would be an epic undertaking though.
Comment