Detecting shortest distance via QC

Discuss programming in the QuakeC language.
Post Reply
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Detecting shortest distance via QC

Post by Seven »

Hello,

I need your helping hand with this issue I have.

Torches in Quake have no hintches, so they fit on every wall (independent to its angle).
I try to bring torches with a hintch into Quake (see below screenshot).

But that needs a specific angle of the torches, so that the hintch is facing the wall.
I try to give this workload to QC. And I am stuck :|

My plan is, to detect the nearest wall via qc and set the torches angle accordingly.
So that the hintch is facing the wall.

The assumption is that the walls are always upright (which is the case in 99% in Quake) to make it easier.
In all Quake maps, the distance between torch origins and walls is approx. 10 Quake units. That is always given.
So, we need only a scan around 1 z-height (which is the torches_z origin) and not a scan in 3D.


My idea is to spread out tracelines (starting at torches origin) to see where the wall is and use the trace_endpos with the smallest length as my angle direction.
That needs either many many tracelines with only lets say 5° differences around the origin, or a smarter way to do it (maybe findradius ??)
So far so good, but I could not make it work yet....

Thank you for every hint/tip you can give.
Which method I could use to make this happen.
I am using DP.

Thank you very much.

Image
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Detecting shortest distance via QC

Post by frag.machine »

Most of time walls with torches can be found at 0, 90, 180 or 270 degrees (even if the wall angle itself is different). For every torch, fire traceline 4 times, and assume the first where trace length is smaller than 1.0f as the correct. It will be OK for more than 90% of the cases. Of course, you should first check if the torch already has angles set and honor it if true.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Detecting shortest distance via QC

Post by Cobalt »

I guess you are using the original light_small_walltorch () code and merely subbing in that new model?
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Re: Detecting shortest distance via QC

Post by Seven »

Thank you for your reply frag.machine,
But I wanted to do it right. So that the new torch model fits to every wall.
And walls are (at least in my experience) quite often other than 0, 90, 180 or 270 degrees.

Hello Cobalt,
Yes, I want the code to work with every Quake map.
Torches are spawned/called with light_small_walltorch () in maps, so this is the starting funtion to work with (to edit).

But it seems really difficult to create a 2D scan qc code which could be used, so I might have to scrap this idea...
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Detecting shortest distance via QC

Post by Cobalt »

Dont seem to hard to me. Just spawn it initially using the existing torch code - that way its partially in the wall. Assign it a .touch field, and do what you did with the dead bodies - call trace_plane_normal , but use the (z) roll element to match the walls angles....then subtract the difference between the model's
origin plane you highlited. You will need to find out first, whats the angle difference from the mounting bracket for the torch and the models angle, which you highlited in the picture, which should be a static value you can float in the code. I think the vlen (?) of that angle, would also be needed to reposition the torches origin away a certain number of origin_y values so that the bracked it flush on the wall....thats also another key float. You might get away with just getting trace_plane_normal's full vector value, and vectoangling it to the ents angles, then adding in or subtracting that difference in the angle_y....because the bracket will have to face the wall as well , no matter what the wall's angle is......give it a try.


After its set - Sub_Null () the touch, or if you wanna get fancy, assign it a hurt field like I did, then no players will like you :D

I better shut up , else you are lible to make the torch a pickup item and next video we will see the quake guy smashing monsters with it...oops, I said too much already....plus hes got an axe already.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Detecting shortest distance via QC

Post by Spike »

torches are not triggers. they have no touch functions. torches inside walls will not impact upon walls (nor would they if they were triggers), so any engine-specific trace_plane_normal-from-touch-event hacks cannot work. you'll need to explicitly call traceline yourself to determine which wall(s) are near by, and their surface angles + distances.
if its in a corner, you'll need to apply your own heuristics to average the normals or some such if they have a similar weight or whatever.
And then you can do a cross product between that normal and up, and between that result and the normal. This should ping-pong you a vector facing upwards which is perpendicular to the (averaged) surface normal. You can then use dp's vectoangles-with-up extension with something like: angles = vectoangles(averagednormal, planarup); which should give you the angles needed for a torch facing away from the wall upon which it is attached.

cross product maths supplied separately. may contain firey parts. avoid contact with eyes.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Detecting shortest distance via QC

Post by Cobalt »

I tested this a couple of weeks ago out of curiousity to learn more about trace_plane_normal....I called it in an ent's touch field, and it set the ents angles to the surface of the map area it was touching via vectoangles code added in. I also told Seven about it, and he later came up with some code to better orient corpse angles in his SMC mod.

I recently bought this up to LH in an email.... [I asked you for your email on the quake one , so I could forward it to you I guess you didnt get it.]

Essentially, he said the traceline in the touch field will set trace_plane_normal to the value of the ent being touched. He didnt say if Proquake or legacy Winquake did this or if it was DP specific. DP handles collision differently, so its possible its a DP bonus item. ...

So, Im saying make the torch model ent a trigger, and give that a try. In my experiments, the trace_plane_normal float is changed on a collision with something else that touches the ent. I have only done some rudimentary tests colliding with static / movetype_none objects, mostly the world.bsp.....LH says you will get tricky values when doing othersise, and I have confirmed fractional values which can make things kinda hairy for multiple collisions....but thats for another day.

Spike wrote:torches are not triggers. they have no touch functions. torches inside walls will not impact upon walls (nor would they if they were triggers), so any engine-specific trace_plane_normal-from-touch-event hacks cannot work. you'll need to explicitly call traceline yourself to determine which wall(s) are near by, and their surface angles + distances.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Detecting shortest distance via QC

Post by Spike »

if neither object moves, there is no point of collision and no normal for said collision for either object.
trace_plane_normal is unreliable inside touch functions because:
a) vanilla sets it only for traceline builtin calls.
b) you don't know if the other object moved into 'self' in which case the normal is part of 'self's shape, rather than a surface on 'other'.

in all seriousness, stick with traceline. it is:
a) well defined.
b) supported in all engines.
c) instant, and thus doesn't need multiple physics frames to work out the direction.
d) not framerate dependant.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Detecting shortest distance via QC

Post by Cobalt »

Played a DM map the other day that had torch holders, but they were part of the map BSP and were at 90 deg all the time.....thought of this post, how did things turn out Seven?
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Detecting shortest distance via QC

Post by Cobalt »

These were some good points Spike, thanks.

I was daydreaming the other day, would it be possible at the engine level to bring out the vector coordinates where a touch collision took place?

DP is using entirely different collision code LH has told me....and mostly it seems to work as good as the original, but I have seen a few cases where some new mods have walkmonster errors, because I believe their spawn coordinates are too close to the tolerance of the new DP collision, and I think it winds up spawning in a wall.

Theres another case on E4M8 The Nameless City where there is a triangular grating over the megahealth, and I noticed in Vanilla Quake, you can fit down that triangular opening easy, but with DP, its many times harder and you have to be lined up just right. Has anyone else noticed this?
Spike wrote:if neither object moves, there is no point of collision and no normal for said collision for either object.
trace_plane_normal is unreliable inside touch functions because:
a) vanilla sets it only for traceline builtin calls.
b) you don't know if the other object moved into 'self' in which case the normal is part of 'self's shape, rather than a surface on 'other'.

in all seriousness, stick with traceline. it is:
a) well defined.
b) supported in all engines.
c) instant, and thus doesn't need multiple physics frames to work out the direction.
d) not framerate dependant.
Post Reply