good times.... ^_^

looking back... man, i had like no idea what i was doing. it was also the least quakey of all my maps. :P

hm... i believe nostalgia mode has been activated... 

Making mistakes is a required step of the learning process. Let this guy make his. 

don't know the exact terminology for this, but essentially, bmodels are attached to vis areas to determine whether they are visible or not. if the player can't see any of the vis areas that the bmodel it attached to, the bmodel isn't drawn.

essentially what happens is that the rotate_object is somehow linked to the vis area at the origin and not with the vis area that the bmodel is actually located in.

so you get a rotate_object that flickers in and out of existence (or just plain isn't there if the '0 0 0' vis area is never visible).

i've learned a little more since the last time this happened to me and i know that using setorigin() on an entity 'links' it back into the world visibility or some-such.

so i open up the code and add a new line to the rotate_object function:
setorigin(self, self.origin);
this should link it in.

didn't work.

the other thing that plays a part in visibility is the bbox of an entity. so i put in:
setsize( self, '-512 -512 -512', '512 512 512' );
an arbitrary, very large, bbox.

ok, so it works now. yay!

but WHY?

rotate_object already sets it's size to self.mins and self.maxs. this works for 99% of rotate_objects that are made. why is it that occasionally i need to reset the bbox to some other value to get it to work?

is this a qbsp problem maybe? how does the engine first load up things like mins/maxs? it it precomputed or does the engine figure it out the first time? 

about coding, but could this bigger setsize not be the total of the start and end position? 

Could be it has a huge bbox and touches too many vis leafs, this plagues large func_walls also. This problem has not been fixed in fitzquake yet as I don't know which numbers control that behavior. 

Could be it has a huge bbox and touches too many vis leafs, this plagues large func_walls also. This problem has not been fixed in fitzquake yet as I don't know which numbers control that behavior. 

I would suppose that in order for the object to be visible one of the two must be true:

A) The bounding box must be large enough to fit the object at every point in its rotation.
B) The original bounding box is visible from every place that you can see the rotating object

B is what happens most of the time - although what might be termed a bug in the code is present, it doesn't manifest itself. In B I'm using visible in the sense of 'being in the engine's PVS', but 'see' in the sense of it being rendered for the observer.

For example, if you create an hour hand pointing to 1:30 in it's rest pose, the bounding box might be a square running from 12 o'clock to 3 o'clock. Then imagine you load it in game and move the hand to 7 o'clock. The bounding box does not rotate, so the hand is now completely outside the box, in the opposite quadrant. However it is still likely that in most places where you can see the 7 o'clock mark of the clock face, some part of the original bounding box is in the 'potentially visible set' that the engine gets from VIS.

I'm sure that in any case where the visible object can leave the original bounding box entirely, you can construct a point on the map where you can experience the bug. However, in most circumstances the rotating object is almost off-screen itself, and so it isn't apparent. Objects where their info_rotate lies some way outside their bounding box are much more susceptible to this. It's also worth noting that rotating your viewpoint can change what the engine deems visible.

So B is basically the usual situation, the bug is there all the time but by-and-large we get away with it. Setting the bounding box to some very large size moves us into category A - the rotating object never leaves its bounding box so no rendering bug can occur. We might ask how small can we make the bounding box and avoid the bug, both to keep overdraw down and to ensure that we do catch the entire size.

If we calculate the maximum of vlen(self.maxs) and vlen(self.mins) and call that x, then set the size of the bounding box to be '-x -x -x' to 'x x x'. This is sufficient and necessary, since we've found the furthest point from the rotation origin our object could be, and then created the smallest cube which contains a sphere of that radius.

Of course, this is only as optimal as a static bounding box can get. If the engine were to recalculate bounding boxes based on rotation then we would be home free. Since the engine doesn't bother, I wouldn't want to begin considering doing it in QC... 

Can someone please explain to me how that works - I'm getting a little frustrated here. I have a shootable button in a recess on the upper part of a wall small room. Shooting rockets at walls and floor doesn't affect it. However, there's a monster in front of it which somehow transfers the rocket's splash damage to the button. Or at least doesn't block it. What do I have to consider here? 

> Could be it has a huge bbox and touches too many vis leafs, this plagues large func_walls also. This problem has not been fixed in fitzquake yet as I don't know which numbers control that behavior.

I think this is it. I'm pretty sure that was fixed in RMQ, probably DirectQ, Proquake etc. a while ago, I remember it being called the flicker fix or flickering bmodels fix. 

What do I have to consider here?

Splash damage against BSP objects is meted out based strictly on a traceline between {the midpoint of the entity's mins and maxs} and {the origin of the blast}. Monsters (strictly things with FL_MONSTER) are ignored by the traceline. If the trace_fraction equals 1 or the trace_ent is the BSP object in question then damage is inflicted.

I'm guessing that normally the centre of mass of the button can't be traced to, but that when hitting a monster the explosion gets a clean line of sight at it (ignoring the monster itself which doesn't count for these traces). 

Makes sense. Moving the button further into the wall fixed it. Maybe I just expected too much of Quake's physics. 

Oh why, oh little cuboid light fitting, oh why do you taunt me so? How can there be 300 more vertexes when you are a func_illusionary, oh why? 

Could be it has a huge bbox and touches too many vis leafs, this plagues large func_walls also. This problem has not been fixed in fitzquake yet as I don't know which numbers control that behavior.

i can confirm this has a high likely hood of being the problem as i just ran a quick test with the rmq engine that was release a few days ago and the problem isn't present.

thanks for helping clear this up for me. :)
the actual bbox dimensions that the engine was generating for the bmodel must have been even larger than 512^3. 

ditto for DirectQ. 

Check it with sv_showboxes 1 if you're curious. 

How does the static entity handling work? On mapstart things like illusionaries, ambient_ and flames are moved to the static roster and then removed from the entity list or something like that. Now how can I find out which modelindex they have, the flames for instance, without trying every single value? 

DP's "modellist" command!
(Thanks Preach 2005.) 

if you were making a custom progs, you could create a new lightstyle, let's say #12 that was the same as #0 (always on).
then, every single pointlight in the map you would set to style #12 (instead of leaving it blank).

now, set up your sunlight which would be lightstyle #0.

you could make a map/mod where you started at dusk, with sunlight and an appropriate skybox, then mid-way through the map, have your qc change lightstyle 0 to off, making your sunlight disappear and swap to a nighttime skybox, leaving you with a full dark exterior wtih only pointlights still showing.

not ground breaking or anything, but it'd be cool to see... 

is the maximum map size/grid in worldcraft/Hammer reflective of any limit in Quake itself and if not, is there any way to make the map size/grid bigger? 

not quite sure what you are asking.

the maximum map size in glquake/fq is +-4096.
you can build beyond that range, but only the visual component will be correct. entities passing beyond those ranges 'loop around' to the other side of the map like pacman.

extended engines like DP allow you to build beyond the 4096 boundary. 

the +=4096 boundary is purely a network protocol limit, not a limit in the quakec interpreter or map/bsp format. 

If your editor has the 4096 limit hardwired into it, then that sucks. Both Quest and Radiant let you build wherever you want, so I'd be amazed if an editor actually limits you to that area o_O

hack the editor?

oh wait, would need source.

RMQEngine has that limit removed, too, and is Fitz-based.

One thing to remember with engines that use floats for coordinates is that when you have something very far away from (0 0 0) you can have floating point inaccuracies, or so ISTR. But ask a real engine coder ;-) 

i don't think floating point inaccuracies will be a problem unless you are very far from the origin. Regular quake protocol precision is 1/8th of a unit. To reach precisions that low in floating point, you would need to be about 1 million units from the origin.

(reasoning: 23 bits devoted to the floating point value, 3 bits are fractional part if we want 1/8th unit precision, leaving 20 bits, 2^20 is about 1 million.) 

Would anyone know off hand why Gtkradiant wont work under Ubuntu 10.04? When I run it I get this error:

Gdk-CRITICAL **: gdk_window_get_window_type: assertion `GDK_IS_WINDOW (window)' failed

(process:1680): Gdk-CRITICAL (recursed) **: gdk_window_get_window_type: assertion `GDK_IS_WINDOW (window)' failed
aborting...
Aborted

Any ideas?

Also can anyone suggest any alternative map editors? (Ideally one that will run under Linux.)

Cheers!


This is the solution:

http://ubuntuforums.org/showpost.php?p=9919688&postcount=9

Compile Radiant manually after doing an SVN checkout.

Find the file in the sourcecode and switch these two lines around in a text editor. Then build.

There is a file COMPILING included with Radiant that lists the dependencies and tells you how to use scons to build it.

It works now (switched to ubuntu recently and had same problem).

My Radiant is hack'd anyway, so this wasn't a big problem. 

and the explanation: It seems like a problem with Gnome, possibly a Gnome update b0rked this, not Linux as a whole.