GTKradiant - in-editor help via entities.def

[AEon]

I am not completely in the clear about were the different versions of GTKradiant actually save their entity help. With GTKradiant v1.2.13 it is in scripts\entities.def, and a quick test shows that v1.4 also uses that file. Though I'd have expected the v1.4 installer to install a more recent update. Anyway collecting a list of updates in this thread (as per Sock's suggestion):


gametype key for entities: I replaced all lines containing:

Code: Select all

notbot : used to make an item invisible for bot attraction.

with

Code: Select all

notbot : used to make an item invisible for bot attraction.
gametype : defines the gametype(s) that will spawn this item, valid values: "ffa", "tournament", "single", "team", "ctf", "oneflag", "obelisk", "harvester", and "teamtournament"; e.g. ffa team.

This updates the items like weapons, ammo, etc. Though it probably misses those func_ entries (i.e. doors etc.).


misc_model: Update for the misc_model section in the entries.def file (Sock's info plus my small update):

Code: Select all

/*QUAKED misc_model (1 .5 .25) (-16 -16 -16) (16 16 16) - CLIP LIGHTMAP
Generic placeholder for inserting .md3 models in game. Requires compilation of map geometry to be added to level.
-------- KEYS --------
angle: direction in which model will be oriented.
angles : X Z Y model direction for complex orientation
model : path/name of model to use (eg: models/mapobjects/teleporter/teleporter.md3).
modelscale_vec : X Y Z scale of model
_remap : retexture ALL of the model surface with a different texture, must specify full path from baseq3 folder downwards. Works with the full Q3 directory tree structure.
spawnflags : 0 or unset yields vertex lighting, 2 for vertex lighting with autoclip, 4 to lightmap model, and 6 to lightmap with autoclip.*/

It would be nifty to keep this up, adding other information missing so far, I could then make the update available for download. If an updated version of the entities.def already exists please let me know, i.e. make it available for download, I could use a "diff" tool to combine/merge info. I have a string feeling of deja vu... as if we had done this some years ago... hmm.

[MrLego]

I usually create a different .def file for new entities - "extras.def" and place it in my baseq3/scripts folder, radiant looks in the game's scripts folder for defs.

Radiant will read that file when it loads and add the new entities to the list.

This way you don't have to modify your original entities.def file.

I have never tried to modify an existing entity definition by placing it in the addon file, maybe a test would be in order to see which definition file has precedence.

[AEon]

Interesting point... I started to correct cosmetic issues in the original file though, if one wanted to "shadow" those in a separate file it would pretty much be a complete file. But the idea of using a new file is good, it would technically be a complete replacement.

Will try to test a file called entities2009.def or so.

Update: entities2009.def and extities.def are ignored, a eatities.def is loaded. So *only* the alphabetically first .def seems to be loaded. Don't think partial shadowing of the .def file works. Tested with GTKradiant v1.4.

[sock]

A new def entry which should be standard for adding portal skies.

Code: Select all

/*QUAKED _skybox (0.77 0.88 1.0) (-4 -4 -4) (4 4 4)
-------- KEYS --------
"angle" : rotation angle of the sky surfaces.
"angles" : Individual control of PITCH, YAW, and ROLL (default 0 0 0).
"_scale" : scaling factor (default 64), good values are between 50 and 300, depending on the map.
-------- SPAWNFLAGS --------
(none)
-------- NOTES --------
Compiler-only entity that specifies the origin of a skybox (a wholly contained, seperate area of the map),
similar to some games' portal skies. When compiled with Q3Map2, the skybox surfaces will be visible from any 
place where sky is normally visible. It will cast shadows on the normal parts of the map, and can be used
with cloud layers and other effects.

Update: this will allows trigger_hurt to be switchable, found this out from looking at the q3 code. To allow the trigger to be switchable set the spawnflag correctly and use the 'ENALBE_USE' option. Then simply just trigger it as you want but you got to remember the state with your own logic.

Code: Select all

/*QUAKED trigger_hurt (.5 .5 .5) ? START_OFF ENABLE_USE SILENT NO_PROTECTION SLOW
Any player that touches this will be hurt by "dmg" points of damage once per server frame (very fast). A sizzling sound is also played while the player is being hurt.
-------- KEYS --------
dmg : number of points of damage inflicted to player per server frame (default 5 - integer values only).
notfree : when set to 1, entity will not spawn in "Free for all" and "Tournament" modes.
notteam : when set to 1, entity will not spawn in "Teamplay" and "CTF" modes.
notsingle : when set to 1, entity will not spawn in Single Player mode (bot play mode).
-------- SPAWNFLAGS --------
START_OFF needs to be triggered (toggle) for damage
ENABLE_USE : Allows the trigger to be used
SILENT : supresses the sizzling sound while player is being hurt.
NO_PROTECTION : player will be hurt regardless of protection (see Notes).
SLOW : changes the damage rate to once per second.
-------- NOTES --------
The invulnerability power-up (item_enviro) does not protect the player from damage caused by this entity regardless of whether the NO_PROTECTION spawnflag is set or not. Triggering a trigger_hurt will have no effect if the START_OFF spawnflag is not set. A trigger_hurt always starts on in the game.*/

[MrLego]

Did you restert radiant?

I know that a extras.def file works for Return to Castle Wolfenstein & Enemy Territory because I use it all of the time to add Q3 entities like teleporters to RTCW & ET maps using GTK 1.4.

Maybe it only works on games that came after Q3, because all of the entities are already in the Q3 game code, just not in the entities.def file while other games that came later like RTCW & ET only included the entities that were used in those games.

[AEon]

MrLego,
Might be good to post your file. I renames a complete copy differing only in the worldspawn text naming it extras.def, as expected it comes *after* the entities.def, and thus was ignored. I quit GTKradiant and restarted it each time.

What may be working for you are the *new* entries *not* mentioned in entities.def, thus actually expanding, but not replacing/shadowing existing entries.

[AEon]

Sock,
added your additions. Some other points:

• misc_model
  Could you explain this: _remap *;textures/sockter/leave03a
  My guess is the *; means: Replace all (joker char *) textures with the one mentioned after the ;. I am guessing you may be able to replace more than one texture explicitly, e.g. via
  • _remap textures/BLAH/leaf1_old;textures/FOO/leaf1 textures/BLAH/leaf7_old;textures/FOO/leaf7
• modelscale adding this (seen in POM):

  Code: Select all

  modelscale : scale model's size (default: 1.0 = original size, 2.0 = double size, 0.5 = half size).

[sock]

As far as I am aware the editor does not read the entity def's like shaders, they are read once and then setup in an table/array. Even on older versions of GTK you have to restart the editor to make changes to the entity.def file. You can have lots of def files and the editor does read and merge them all into a big entity list.

I would have to look at the q3map2 source code to see how the _remap command is working, I always use the '*;' parameter at the front of the value field. You may even be able to replace part of the string, I am not 100% sure how it exactly works. I found if I need multiple shaders on a model, I break it down into shader parts so it is easier for the remap command.

Another update for the misc_model def:

Code: Select all

-------- KEYS --------
target: Specifies another entity (targetname key) that this model will be merged into. Useful for creating unique shapes for func objects like doors or buttons. If pointing at a func_platform entity, the platform will need to be operated by additional triggers.

There are a few generic key/value items that apply to a lot of entity types, like for example:
_lightmapscale
targetShaderName
targetShaderNewName

It is a shame you cannot specify a global block of text to be applied to a set of entities.

[MrLego]

I believe that you are correct in stating that the radiant recognizes new entities that are not in the original entity.def file but still in the game code as I posted earlier, so you probably have to directly edit your original entity.def to make your changes work.

I am only using my extras.def file in RTCW & ET because the entity definitions are already in Q3 so I don't think it will help you much.

I know that when Splashdamage made Enemy Territory they enhanced the things that you could do with scripts and entities like remapping shaders and adding the "angles" tag to entity definitions so you could access the "roll, pitch & yaw" direction of things, not just the "XYZ" - how much of those changes made it back to Q3 I couldn't tell you, but Sock is doing it so some of them must be there.

Maybe the q3map2 documentation has something - I am using version 2.5.16 for everything.

[obsidian]

I actually have a draft of a bunch of Q3Map2 and PR 1.32 entity definition updates. I'll have to compare it to the version on the SVN and add some stuff from here. I had intentionally been meaning to submit the revisions.

[AEon]

Obsidian,
that sounds very promising. Anyway here the latest version of baseq3\scripts\entities.def with most of Sock's suggestions added, plus a few cosmetic changes:

• entities_def_q3a_v1.4.4_aedit.zip @ hugelaser.com (14.8 KB)

[obsidian]

Can anyone check the source code for the existance of target_laser? It may/may not work and is undocumented. Any help on how (if) it works would be appreciated.

[sock]

The source code for target_laser certainly exists in the PR 1.32 but it is weird how it works. The start on state does not work well but the trigger state works fine. (You can switch the laser beam on and off). The routine draws a big red line from its target entity to 0,0,0

I would recommend leaving it out of the entity definition file, unless a coder who is familiar with the code base looks at the routine and says what is wrong with it.

[^misantropia^]

- 'Start on map load' works if you set 'spawnflags' to 1.
- To aim the laser, you can either use a target or set the 'angles' key (ex. '90 90 0').
- The default entities.def doesn't mention it, but the 'damage' key works for target_lasers.

One more quirky thing about target_lasers: the 'start on' variant can still be tied to a trigger. The fun part is, when triggered the laser will turn off and stay off (as in: can't be reactivated) because the entity is removed from the map altogether.

[AEon]

I read the changelog.txt for GTKradiant v1.4, here some entries that would need verification. Added them in the notes for now:

misc_model:

Code: Select all

-------- NOTES --------
From changelog.txt (needs verification): Added _lightmapscale support to misc_model entities.

light:

Code: Select all

-------- NOTES --------
From changelog.txt (needs verification): Added _anglescale to light entities for scaling angle attenuation. Use a small value (< 1.0) to lessen the angle attenuation, and a high value (> 1.0) for sharper, more faceted lighting.

[obsidian]

I've been going over my current version. Everything above has already been updated since 2004 ( ) with the exception for targeted shader swapping (targetShaderName) which has been sitting on the todo list and the new "gametype" feature. There are numerous other Q3Map2 related changes as well as a new spawnflag for portals which prevents camera wobbles.

Perhaps it should be noted that...
notfree, notteam and notsingle
...should be used if possible since it works for all versions of Q3 where gametype only works on 1.32.

I'll also have to test lasers sometime to see if they are reliable enough for use. Pewpew!


Messy notes:

Code: Select all

light : _deviance, _samples, _filter, _filterradius, _anglescale
misc_model : CLIPMODEL spawnflags 2 FORCEMETA spawnflags 4
misc_portal_camera : NOWOBBLE spawnflags 4 (Q3A Point Release 1.32)
trigger_hurt : TOGGLE spawnflags 2

_decal : *NEW
_skybox : *NEW

LIGHT:
	_sun
	fade
	scale

lightJunior : *NEW

Removal of VLIGHT KEYS

[obsidian]

Here's the latest draft. I would appreciate it if some of you could take a look at it and see if anything needs fixing.

http://www.robotrenegade.com/gtkradiant ... _draft.zip

[AEon]

I will take a look at it tomorrow, and run a diff against "my" version, where I had consolidated a few cosmetic inconsistencies. One thing I am hoping for are examples, see the _remap command usage etc.

Update: Nifty all the new info. Question on notation consistency: For some reason the original entities.def begins the explanations after a key name in lower case:

• message : text string to print on screen.

IMO, this should be and also reads better:

• message : Text string to print on screen.

If there are several sentences the next one begins with a capital letter. So that the first sentence begin lower case is weird.

If we can agree to upper case the first word after the "<key> : ", I'll fix that.

[InsaneKid]

i know, that the target_laser works very well in
"LOKI'S REVENGE CAPTURE THE FLAG".- Almost tested!

Edit: i got target_lasers in "e+Lessons"!
(in LRCTF they also make a sound!)

[AEon]

Obsidian,
updated your version, of baseq3\scripts\entities.def:

• entities_1.7.3ae.zip @ hugelaser.com (18 KB)

Changes:

• Adopted a consistent "key : <uppercase 1st descriptive word's letter>", for all entries in the file.
• Changed (fixed) the wording of a few phases.
• Cosmetic fixes, missing separator added, missing "." at end of sentences added, consistent way of presenting default values (very few cases).
• Typo: attentation attenuation x2

Possible issues:

• misc_teleporter_dest angle
  I always used multiple angles of 90° for the destination entities. I seem to recall that e.g. using a 45° angle could lead to quirky in-game behavior. Should this indeed be the case, it should be mentioned.
• target_location count : Color of the location text displayed in parentheses during team chat. Set to 0-7 for color.
  Is this key really called "count", naming seems a bit strange?
• target_delay wait : Delay in seconds from when this gets triggered to when it fires its own targets (default approx. 1).
  Approximately? Really? Not exactly 1 second?
• misc_model _remap : Used to remap textures/shaders in the model. To remap all shaders to a given shader, use "*;models/mymodel/mytexture". To remap a specific shader, use "models/mymodel/old;models/mymodel/new".
  What happens when you want to explicitly change several different textures? Just add more old/new pairs or create another _remap key/value pair?

With a good diff tool (File Compare in TotalCommander, or UltraCompare), you should be able to quickly check on my changes. Hope this helps.

[$NulL]

What happens when you want to explicitly change several different textures? Just add more old/new pairs or create another _remap key/value pair?

To remap any number of textures on a model, you'd use _remap, _remap2, _remap3 and so on.

[Bliccer]

When the target_laser exists in 1.32... does it also exist in 1.16?

[obsidian]

While one the subject of capitalization, etc. I wonder if keys should capitalize the first letter starting with the second word (e.g. "targetShaderName" instead of "targetshadername")?

I use Beyond Compare for diff comparison.

$NuLL: Thanks, I'll add a bit more detail there.

[AEon]

... (e.g. "targetShaderName" instead of "targetshadername")...

Well personally as a programmer I like that "notation". Quite common when naming variables, it sets them apart from usually all lower-case commands. Plus makes them a bit more readable (you can pick out the glued together words more easily). AFAICT the keywords in editing are not case sensitive (e.g. in the shaders), so you can capitalize those anyway you like. Some of the all upper-case keywords like SUSPENDED, seem to be capitalized to make it clear these are flags without a value.

One renaming other keys, here some candidates:

• targetname : A target_give entity can point ...
  targetShaderName : Points to the name of the original shader ...
  targetShaderNewName : Points to the name of the new shader ...
  notfree : When set to 1, entity will not spawn in "Free for all" ...
  notteam : When set to 1, entity will not spawn in "Teamplay" ...
  notsingle : When set to 1, entity will not spawn in Single Player ...
  notbot : Used to make an item invisible for bot attraction.

to

• targetName : A target_give entity can point ...
  targetShaderName : Points to the name of the original shader ...
  targetShaderNewName : Points to the name of the new shader ...
  notFree : When set to 1, entity will not spawn in "Free for all" ...
  notTeam : When set to 1, entity will not spawn in "Teamplay" ...
  notSingle : When set to 1, entity will not spawn in Single Player ...
  notBot : Used to make an item invisible for bot attraction.

Hmm... looks kinda nice. I'd adopt that naming convention and implement it, if you think that is OK. Though I have the bad feeling that some key words may actually be case sensitive, for some obscure reasons.

Update: Just to be sure the entities.def file does not let you color the text in any way? Now that would really be nifty... e.g. keys one color (blue), values another value (red), highlight color a third (orange), explicit paths a forth (e.g. to sounds/models; gray or green), section heads a firth color. I also wonder about indentation, i.e. for the examples of turning lights on/off.

[^misantropia^]

Though I have the bad feeling that some key words may actually be case sensitive, for some obscure reasons.

Yep. Camel casing looks purdier but it's not going to work.