Best way to pre-test a spawn area for adequate room

[gopostal]

In my mod I will randomly spawn an "airdrop" on the map during the game. It's essentially a crate under a parachute that drops straight down. When it touches ground it deletes the chute and spawns red smoke to mark it's location. Players can then destroy the crate and get higher-tier weapons.

The location is randomly chosen by finding a pathnode and then tracing upwards to see if the area above is sufficiently clear:

Code: Select all

        if (NodeCount == NavPoint)
         {
                         // Do a trace to find the hit location of the ceiling
                        endVector = NP.Location + 448 * vect(0,0,1);
                        hitActor = Trace( hitLocation, hitNormal, endVector , NP.Location, false );
                        log("Hit Actor :" $hitActor);
                          if(!hitActor.isA('LevelInfo'))
                          {
                              log("Failure, hit :" $hitActor);

If there is enough height then it attempts to spawn the airdrop. However in testing I'm going to need to do an additional circular trace to see if there is enough room for the box to land.

My question is this: would it be more efficient to just create an invisible mesh and attempt to spawn it to see if there is room or is using the tracing function better?

[Bleeder91[NL]]

Code: Select all

hitActor = Trace( hitLocation, hitNormal, endVector , NP.Location, false, vect(10,10,0)/*10 unit radius.*/);

[gopostal]

Ok, if you'll allow me the time can you explain it out slightly more? I get that "vect(10,10,0)" gives me a flat diameter of 10 in a circle around location. So given that does "vect(10,10,10)" now constitute a sort of sphere? Can I expand that into a column and use "vect(10,10,1000)" and that would return hits on anything in that column of space above? It appears to me that I can't do that and that I'll need to check in two passes, the first for height and the seconds for immediate area. That's why I was curious if attempting to spawn a cylinder that matched the dimensions of the area I wanted to check was a more efficient solution.

[Bleeder91[NL]]

the 10x10 basically makes the trace (in this situation) a cubic(?) trace straight up. You could add the Z axis but that doesn't do much in this case.

You could spawn a cylinder, though I don't know how you'd check if it spawned successfully since stuff usually spawns just fine as long as their origin is in-world.

If only the landing area matters, you could consider doing a FastTrace in 8 directions (or just 4, starting at one end to the other).

Another option would be to have the box spawn down there first, then teleport it back up if it succeeded so it can fall down.

[gopostal]

Ah ok, I understand it all now. Thank you B. I've worked it out and I'm posting an update video in my thread. The airdrop spawns correctly but now that I understand it fully I'll refine the check trace to prevent any issues.

[[]KAOS[]Casey]

I have an [glow=yellow,2,300]extreme[/glow] hackjob code that uses spawn, static functions, and default.collisionheight, default.collision radius to determine if something can fit in an area. its also like, 12-15 years old. And i know the code is dirty as fuck and probably hackjobbing in ways so extreme that it shouldn't work... but it does.

From what I remember, it abuses "spawn" to try to use the ULevel's native function to attempt to fit something in a place by picking semi-random offsets. I also pick a few random offsets using some code I jacked from deus ex's spawn mass.

It works pretty well, and I can rip some of the code out into a zip if you want, but really... yeah the code is fucking awful. I know it is because i hated writing it back then, cant imagine how i'd feel now lol

[gopostal]

You have never steered me wrong, I'd be very happy to see how you attacked this problem. Once I started looking at a selection of random DM maps and where the pathnodes are it doesn't take long to realize I'd better make sure I have the room to do what I'm wanting. The airdrop mesh is 128 wide (roughly circular) and 180 tall so it needs a little space to work. Because this will happen in a very large variety of maps I'd like to make it as good as possible.

[Feralidragon]

Since the trace extent subject was touched, I will go ahead and ask this as well: is the trace extent relative to the direction, or is it absolute?

I mean, if it's relative to the direction, and given that the default direction is always in the X axis, shouldn't the other 2 axis be tweaked instead to make the trace wider?
Something like vect(0,10,10) instead?

There's literally next to no documentation on this, and even at the BU wiki there is some minor discussion around this without any proper confirmation.

Sorry for the slight hijack, but I also feel that a proper understanding of this parameter may also help gopostal into deciding the best approach, not only for this, but even other things in the future, so it would be a 2 in 1.

[gopostal]

Yeah, I did my due diligence on this before asking and you are right. I can find very little in the way of good explanation and like so much I just try to figure it out by looking at source code. My hardest issue with this is that I'm just not nearly as bright as you guys and that makes progress slow and hard earned.

You mention making the trace wider. I didn't know that was possible, and it could solve my problem. Just so I'm clear can I ask if this is correct? Using (0,0,10) means a single point trace in the z axis upwards, essentially a ray. If I change that to (0,10,10) then it becomes a 10uu line on the ground that extends upwards creating a 10uu squared (circled?) shape that will be checked. Adding the final (10,10,10) now creates a box (sphere?).

If that is correct then something like (20,20,1000) creates a column?

Thank you for taking the time with me on this you guys.

[[]KAOS[]Casey]

You have never steered me wrong, I'd be very happy to see how you attacked this problem. Once I started looking at a selection of random DM maps and where the pathnodes are it doesn't take long to realize I'd better make sure I have the room to do what I'm wanting. The airdrop mesh is 128 wide (roughly circular) and 180 tall so it needs a little space to work. Because this will happen in a very large variety of maps I'd like to make it as good as possible.

http://www.klankaos.com/kaosspawner.u

Look for the "KCollisonCheck" class and how I use it. the class "KaosSpawner" under info uses it. the "omglol" function alters the default collision radius/height of "kcollisioncheck" before it can spawn.

this code is awful so please dont hate me

[gopostal]

I learn way more seeing ugly stuff. I get to kinda peek into the process you used to get where you were going and that's way cool*.

Thank you for sharing with me. I'm legit excited to get this done correctly.

*-unless it's Bob's code. My OCD goes into overdrive when I see his (cough)...formatting. 

EDIT: Just following up. Casey was spot on. He's right, it's a weird way of doing the spawn checks but it works great even though I'm dynamically altering the height of the drop depending on the restrictions of the map. If he allows it I'm going to post the check as a stand-alone bit of code since this nicely addresses a problem that will often be encountered when spawning things. I wish I'd have had this years ago.