Confused Newbie needs help w basic Quake C concepts

[OneManClan]

[DISCLAIMER: If there's a site you recommend that already explains all this, please let me know.]

Hi people.

I've been reading, and reading and reading about Quake C. I can't help but use my current knowledge of C (the only language I'm familiar with) to 'grasp' Quake C, but much if the descriptions (as well as the code itself) is confusing to me. Normally, I'd look at main(), and look up the headers, and decipher what was going on that way. But here there IS no 'main' so I have no idea the order in which instructions are followed, I cant 'watch' the code execute, and so I have to 'guess' what happens and when. The tutorials help, but they still have left me confused as to HOW exactly the code works.

What's the best site which explains Quake C? I've been reading http://www.gamers.org/dEngine/quake/spe ... c-lang.htm, but the explanations just confuse me. The guy seems to be freely intermixing jargon from C around in a very confusing way.

eg: "As Quake-C stands currently, all the field definitions are definitions of entity fields." (???)

I STILL don't understand exactly what an 'entity' is. Rather than asking the question 'what is an entity' which I've read many descriptions which seem 'sloppy', please allow me to give you rough bits and pieces of my current 'understanding', which I invite people to correct, or confirm.

1. A Quake C 'Entity' = a C 'Structure', ie a collection of variables, of different types, stored as a 'record' eg 'self' contains a bunch of variables which relate to 'self'. Just like C.

2. A 'field' = 'field variable' = a member variable of an entity. eg 'self.health'. Just like C.

3. In Quake C you can't make new Entities. But you can add new variables to existing Entities (?)

4. But every time you add a variable ('field') to an Entity (Structure), ALL entities in the game get that field added to them.(?) Eg, if we're defining

.float fooamount

Does that mean that EVERY ENTITY IN THE GAME has just been assigned a new variable .fooamount? there is now a 'self.fooamount'?


5. To quote from http://www.gamers.org/dEngine/quake/spe ... tm#QC-TFLD

"Some of the fields do not store value, but instead they store the function to be executed in certain conditions. They are called the methods that can be aplied to the object."

So we're storing functions ('methods') inside entities (structures?). That sounds EXACTLY like C++. So do we call them functions, or methods?

When I started C, once I learned the language, I could (slowly) decipher what was going on, by following the 'flow' of the code. With Quake C, I'm copying and modifying bits and pieces, but without understanding wtf I'm doing, it's really easy to get stuck. It's like I'm in a foreign country with a little phrase book, and whilst I can ask for a coffee, what the time is and where the toilets are, I can't really have a proper conversation.



OneManClan

[Spike]

in c++, an entity is a class (you only get one actual class type) and a field is a member of that class.
Internally (in unmodified quake) the entities are stored in an single lump of memory with offsets counted by (fieldscount*4+internalheadersize)*entnum.

adding a new field adds that field to every entity, whatever sort of entity they are. unmodified quake has a limit of 600 entities. thus a new field takes 600*4 bytes (*12 if its a vector).

function fields (ie .void() think) would be called function pointers in any other language. treat them as member functions, but be aware that you have to assign them.

.classname is just a string that names the function that sets up the initial fields. It does nothing special other than that. The QC code uses it in a few places but other than spawning its purely an identifier for the qc code.

Every entity is identical to every other entity, except: player entities receive additional events (via named functions) and cannot be spawned/removed, a couple of builtins also accept only player entities (purely for their entity index, eg sprint/centerprint/infokey). Entity 0 (world) cannot be written to after entities have spawned, and the engine mostly ignores it.
Other than that, the only differences between entity types are the contents of their fields.

QuakeC revolves around storing stuff in entity fields. By storing function pointers in entity fields, you can change the entity how you want at a given future event.

Rockets, for instance. They have movetype FLYMISSILE so they move in a regular direction, they have a velocity so they do actually move, they have a touch function, so they know when to explode, they have a model, so they actually look like a rocket, and they have an owner, so they don't explode in the player's face. Really that's about all there is to them. I missed a few fields, but that's the general idea.

The engine does the moving/touch triggering/think processing.
All the QC does (for the most part) is set state.
Set movetype bounce and it'll fall to gravity and bounce off stuff (nades). Hopefully you get the idea.

[OneManClan]

[OneManClan]

I have SO many questions about Quake C, but I'd like to read up first, and do my homework before I bother the Gurus. Is there a proper 'manual' for Quake C? A proper 'guide'? I've found *descriptions* of the language, but no reference to what all the Entities are, how to use them, and how the code all fits together.

A Class in C++ is always defined somewhere. A Class in Quake C seems to be defined everywhere, and nowhere.

The cut and paste tutorials help, but the guys who do them don't explain HOW they figured it all out. How they knew which function did what. They all leave me thinkin "wow, how the hell did u figure that out!?".

Maybe it would be better if the Gurus *assumed* people already knew C, and geared all jargon and Quake C descriptions to people who already can program C - since there are clearly defined terms C programmers use (mostly), and already many many books on C, and there's no excuse to not understand the language. Having said that, too many use Jargon to explain Jargon. Or they explain 'how', without explaining 'what'. A rare exception was "The absolute beginners Guide to C" by Greg Perry, a joy to read, and the only programming book I know which explains jargon BEFORE it is used.

I can do 'simple adjustments' in Quake C, but when it comes to anything new or innovative, I get stuck. If I didn't have access to Gurus such as yourselves, I'd NEVER be able to figure out this stuff just by 'looking at the code'.



OneManClan

[Error]

the way I learned QC was simply staring REALLY REALLY hard at other peoples' code. this doesn't work for everyone, but that's how I did it

more complicated stuff is harder to figure out, but quake has things mapped out pretty well in QC files, I think. a bunch of the code is slightly commented too, so that helps. defs.qc is a goldmine for learning simple engine built-in functions. I learned my syntax from id1's source and admiring FrikaC's code

[Error]

best thing you can do to start. go into weapons.qc and mess around with numbers to see what they do. that's the first thing I ever did.

[Urre]

Feel free to post questions, there are lots of people here who are willing to help people who really try to learn and understand things.

A lot of QuakeC functions are called on demand by the engine, which is why there is no beginning and end to QuakeC. Say, the StartFrame function is called at the beginning of every server tick. ClientConnect happens when a player joins a server. Remember that even singleplayer games use a server in Quake, so all code has to be written with this in mind. It's a multiplayer game with just one player, when you run singleplayer.

Another good example of called on demand are .touch field functions. Those are run when an entity moves into another entity. However, if entity A stands still and entity B bumps into it, the touch function of A will not be called, only the touch function of entity B.

Imagine entities as containers of information. Certain fields give them properties which affect how they interact with other entities, or their representation in the world. A good example is the rocket entity, which has a .movetype == MOVETYPE_FLYMISSILE and a .velocity vector, which in combination will make it appear as moving in the world of Quake. Add a .touch function which makes the rocket explode on impact, and it's all set for action.

Note that there's nothing that stops you from coding all the behaviors of these read-by-engine fields yourself, and make them behave differently, or hacking their use in other ways, such as making an accelerating rocket by adding some extra speed to the .velocity vector in the .think function of the rocket, every frame.

The possibilities are endless!

[catalyst]

[OneManClan]

[catalyst]

[Lardarse]

[Lardarse]

[OneManClan]

[Lardarse]

I was more hoping that the local experts would check it for any mistakes. Glad you found it useful.