Announcement

Collapse
No announcement yet.

TrenchBroom: Entity Keys and Values

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • TrenchBroom: Entity Keys and Values

    So, on TrenchBroom you can add 'Keys' and add 'Values' to these 'Keys'.
    Can I find a list to these Keys and the Values to them?


  • #2
    This should help! CheerS!

    Comment


    • #3
      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,

      // entity effects

      float EF_BRIGHTFIELD = 1;
      float EF_MUZZLEFLASH = 2;
      float EF_BRIGHTLIGHT = 4;
      float EF_DIMLIGHT = 8;
      This is in defs.qc.

      .float effects;
      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

      open_once 1st_left 1st_down no_shoot always_shoot
      This corresponds to

      open_once "1"
      1st_left "2"
      1st_down "4"
      no_shoot "8"
      always_shoot "16"
      And this would go into "spawnflags".

      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 really quite fascinating.
      Last edited by golden_boy; 08-30-2014, 05:39 PM.
      Scout's Journey
      Rune of Earth Magic

      Comment


      • #4
        Thanks for the detailed explanation!

        Comment


        • #5
          @golden_boy

          That is a terrific explanation! Thanks for doing that! You sir, are a gentlemen and a scholar! Rep +

          Comment


          • #6
            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.
            Scout's Journey
            Rune of Earth Magic

            Comment


            • #7
              @golden_boy

              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.

              Comment


              • #8
                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.
                Scout's Journey
                Rune of Earth Magic

                Comment

                Working...
                X