GTKradiant - in-editor help via entities.def

[obsidian]

If it won't take a long time to do, that would be great! Thanks! (Please include instructions on running the script). Also no hurry.

[obsidian]

Caught a major bug where the wonky GtkRadiant 1.5 XML format was ignoring the last 1/3 of the entities.ent file!

Fixed. Update if you're using GtkRadiant 1.5. GtkRadiant 1.4 and older and 1.6 users aren't affected.

http://robotrenegade.com/gtkradiant/dow ... as_0.1.zip

[AEon]

Hmmm... entities.ent changes for v1.5:

• target_laser

  Code: Select all

  -------- KEYS -------- 
  was replaced by
  ******** KEYS ********
  and
  -------- SPAWNFLAGS --------
  by
  ******** SPAWNFLAGS ********

  making the section headings that all use "--------" inconsistent.
  

  Code: Select all

  <angles key="angles" name="Pitch Yaw Roll">Alternate "pitch, yaw, roll" angles method of aiming laser (default 0 0 0)</angles>

  Is missing the "." at the end of the sentence.

[obsidian]

The "--------" was causing the problem of the missing bottom 1/3 of the entities. I'd rather live with a little inconsistency.

[AEon]

I suspect that something else is causing the problem... I checked the number of ", and they come out even, good. But the number of < is 22 less than the number of >. The reason for this are lines like:

Code: Select all

 > 1 = cast shadows on entities with ...

Since < > are command delimiters, you would normally expect a < or > would need to be "escaped" in-text. In HTML that would be < and > ... could this be messing up the XML?

I also suspected in-text usage of ", but that is never a problem in HTML, in C you'd have to escape those with \".

[obsidian]

I meant to fix the greater-than issue but forgot. I just replaced " > " with " > ".

However, that doesn't fix the problem. I suspect the "--------" is somehow affecting the "<-- ... -->" comments.

If I completely remove target_laser or uncomment it, it works. Or if I replace the "-------" with some other character.

[^misantropia^]

I suspect the "--------" is somehow affecting the "<-- ... -->" comments.

^ this

[AEon]

Just noted that you actually commented *out* the target_laser block, i.e. surrounded it with a <!-- and a -->. Is that actually intended? This only also occurs for info_spectator_start. The latter uses a "======== KEYS ========" separator not "-------- KEYS --------", BTW.

It may be that commenting out otherwise "working" info (actually point) blocks is not properly supported.

[AEon]

Well, I found the problem... remove the comment out for the above mentioned two point blocks (target_laser, info_spectator_start) and the file loads without a problem. I.e. you *cannot* comment out complete point blocks. (The KEYS sections now all can use "------" again).

It seems - if you want to remove a "valid" section - you have to delete it from the file, to avoid messing up the rest of the file.

Update: This has been said before, but be very careful with the files you place in the GtkRadiant 1.5\q3.game\baseq3\ folder. I had several - renamed - versions of the entities.ent file there with the result the actual file was being shadowed (i.e. not used). If you have several versions, place them in some newly created *subfolder* to avoid such confusion.

[Bliccer]

I've just seen that idsoftware used entities called first or second place in their maps. What are these for?

@obsidian: Could you please fix the links to the zip files?

[InsaneKid]

u also changed the boundaries of the items, didnt u?-
i think, thats not good ...
the items could be placed easier in a perfect position before:
if the RL has the same bounds as GL,
it will be placed too tight at a wall.

[obsidian]

Whoops... (you can browse to it from my signature)

Direct link:
http://robotrenegade.com/radiant/downlo ... as_0.1.zip

[AEon]

Something I have been wondering about for some time now is why was the misc_teleporter_dest entity sized 64ux64u, whereas the player's footprint info_player_deathmatch is only 32ux32u...

Is this to ensure that a player does not get stuck at the TP destination?

[obsidian]

Yeah, it's extra clearance room so the player doesn't get snagged on anything on his way out. Just good practice to have that much extra room anyway.

[AEon]

Looking into what the GtkRadiant v1.6.x does with the angles vs. angle key, I noted that:

Code: Select all

/*QUAKED info_player_intermission (1 0 1) (-16 -16 -16) (16 16 16)
...
-------- KEYS --------
angles : Alternate "pitch, yaw, roll" angles method of aiming intermission camera (default 0 0 0).

info_player_intermission is missing an entry for the angle key. I have been using only the angle key for years now, and that worked.

I am still testing how the editor and probably more importantly the q3map2 actually reacts when *both* keys are present. Most infos in the entities.def mark the angles as q3map only!

Update: In v1.6.x the angle/angles key that is further up (loaded first) seems to be use, if both keys are set. IMO, there should be a warning in the entities.def telling mappers to avoid using both keys.

Update II: It turns out that v1.5 does NOT tolerate both keys, it will choose the appropriate one when you rotate the entity that uses them. Nifty.

[obsidian]

Oddly enough, rotating a model in 1.5 with the 90-degree rotates works until you rotate it back to 0-degrees. It doesn't become 0, but 2.50448e-006.

[AEon]

Oddly enough, rotating a model in 1.5 with the 90-degree rotates works until you rotate it back to 0-degrees. It doesn't become 0, but 2.50448e-006.

Just tested this... really weird.

[^misantropia^]

Floating point accumulation errors are fun stuff.

[obsidian]

Who needs math when you have computers, eh?

[AEon]

Floating point accumulation errors are fun stuff.

Bit OT, but the really weird thing about "x-axis Rotate" are the angles... its 0, -90, -180, 90, 2.50448e-006... it's almost like an explicit array of values and not simply a "-= 90", what I'd expect.

[obsidian]

There shouldn't even be negative values, really.

[^misantropia^]

Or zeroes, for that matter. The Romans didn't need it so why should we?

@AEon: It happens because many decimal numbers can't accurately be represented in binary. 90 becomes something like 89.99999. Multiply or add it a few times and you get a build-up of rounding errors.

In reality there are also things like unit vectors involved but the above is the essence of the problem.

[obsidian]

I was referring to the angles since -90 degrees is he same as 270 degrees. So if you ever rotate counterclockwise or type in a negative degree, it should just get converted over. The last bit of this thread should be moved to the GtkRadiant 1.6 thread.