Quake3World

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.

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

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.

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

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: 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 \".

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.

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

^ this

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.

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.

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?

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.

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

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

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?

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.

Looking into what the GtkRadiant v1.6.x does with the angles vs. angle key, I noted that: 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.

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.

obsidian wrote: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.

Floating point accumulation errors are fun stuff.

Who needs math when you have computers, eh?

^misantropia^ wrote: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.

There shouldn't even be negative values, really.

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.

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.