Collapsing pain zone

[gopostal]

I've been kicking around the idea of a PUBG/Fortnite style gametype in UEngine. My two main issues are 1) interactive map and 2) collapsing pain zone.

In those two games you start out in a large map that gets progressively smaller, forcing the players into eventual conflict with each other. This is done via a zone that starts outside the map and slowly collapses inwards to a random point each map. The center is a circle (eye of the storm sort of) that you need to stay inside of.

I'd like to do this in a visual way where you can see the pain zone as a fog/mist/see-through texture of some type. This is what it looks like in PUBG:
[img]http://n.sinaimg.cn/97973/transform/w550h309/20171130/cuJd-fypikws9304904.jpg[/img]
This barrier can be crossed but at the penalty of the player taking damage, more the longer the game goes on.

Is there a way to do this given the toolset we have? I don't think I've ever seen a real moving zone like this. I could script the damage to be done from the centerpoint in a collapsing way but it really needs the visual element to work. I'm at a loss though on how this could be done.

[yrex .]

A quick attempt (just the visuals):

[gopostal]

This is exactly why Old Unreal will always be. You can come here with the weirdest "Can you do this?" idea and...BAM! Someone just gets it and makes the *exact* thing you really need. Yrex you are absolute legend my friend!

I hope it's ok, I made a video of your work so people could easily see it:



This works perfectly! I just need to test this at scale and make sure it will work across a map without creating UEngine weirdness. Is the shrinker your work so I can properly credit it in the code? Well, assuming you don't mind if I use it...You'd be a monster if you showed me this then go "Nope, just wanted you to see it. It's mine." I think I'd honestly cry lol.

Thank you brother. You made my evening with this.

[yrex .]

Honestly, it's like just three lines of code...

You can do whatever you want. Although please, at least modify it so it stops at some point instead of getting negative scale... e.g.:

Code: Select all

class Shrinker expands Actor;

var() vector ShrinkSpeed;
var() vector MinScale;

function Tick(float deltaTime)
{
      DrawScale3D.X = FMax(MinScale.X, DrawScale3D.X - ShrinkSpeed.X*deltaTime);
      DrawScale3D.Y = FMax(MinScale.Y, DrawScale3D.Y - ShrinkSpeed.Y*deltaTime);
      DrawScale3D.Z = FMax(MinScale.Z, DrawScale3D.Z - ShrinkSpeed.Z*deltaTime);
}

(not tested)

[gopostal]

This is the effect I wanted but it don't think it will properly scale to the size I needed. To give you an idea this is a mock up of the map I will try to build on:


It's really big but you don't get any of the HOM issues in the map because no line of sight exceeds the maximum.

Once the map starts you'll randomly be placed within the map and have to find guns, health, etc. Players will spawn with a simple melee weapon (probably a stick or something rudimentary) so the first order of business is finding a weapon. In a minute or two the engine will determine where the "center" will be and spawn the collapsing zone outside the map. It will then begin a slow, relentless collapse towards that center and force the players together to battle it out.

My concern is that anything built using static mesh will flicker and disappear because the players will not be able to always see the origin. In fact I'm not sure this is even possible at such a large scale. It may be the only way to do this would be to actually draw it on the player's HUD directly.

I can script the pain a couple of different ways so that's not the issue. I just need to work out the players being able to clearly see the approaching collapse even if it's at the edge of where they can see and they are only looking at a very small part of the mesh/effect/etc.

[Bleeder91[NL]]

Just throwing this in here, but you could try replicating the point of origin to the client, SetLocation to the player's location, then PrePivot the mesh back to the point of origin. If that works with static meshes.

[gopostal]

Oh wow...I would never have thought of that. I wonder if that will work at such a large scale? I'll test this tonight after work and see if it does. If it is a possible solution then that would address several past projects where this was a problem.

[Feralidragon]

It should work without issues, that's pretty much how the forcefield cybot in NW3 works (even when you're inside it, with your back to the origin, you still see it fully because of this).

But rendering it in the canvas also works, and maybe in this case it may be the most correct thing to do (it would be a bit more efficient actually in this specific case).

However, if this is for Unreal 227 only, you also have the bAlwaysRender property of the Actor, which if enabled, it should fix that problem as well.



EDIT: With the existence of distance fog in Unreal 227, I wonder if you could use fog for this instead, but by updating its distance in every tick depending on your distance to the edge (closer = less distance and denser) and also in your direction using the dot operator (if you look away from the edge the fog would return to "normal").
Although I am not sure if the final effect would look good enough.

[gopostal]

I'd like to use UT for it since there just wouldn't be enough people in Unreal to make it feasible, even though the toolset available for this is so much better in 227.

I really wanted the visual of the approaching pain zone but it's just not going to work right with the engine limits we have to work around. I spent today thinking about how to cheat the system and get the effect but I don't think it will work at such a huge scale and be reliable.

There's a ton of ways to punish players and keep them moving towards the random center. I could even do a HUD arrow like is in jailbreak to keep the player oriented to where they need to go. The whole point though is you learn very fast that the approaching pain zone hurts bad and so it really causes the stress level to rise if you can't find good weapons fast. If they can't easily see that approaching it just kills the vibe of the entire game.

I'll mull on this a bit more. I don't really want to give up on it. I have most everything else lined out in my head aside from the pain zone.

[Feralidragon]

Sorry, but I am not understanding (maybe I am missing something): with Unreal 227 aside, you have both the PrePivot and canvas rendering solution which should work perfectly in both UT and Unreal.
So what exactly do you mean about "it's not going to work"?

I have tested both in the past as far as I remember, especially the PrePivot one with very large meshes in CTF-Face for example (my idea was to render a huge spaceship even).

There's only a downside with the PrePivot approach, and that's only in case you want the mesh to be lit by the environment instead of being unlit: the mesh is still lit from its location, not from its PrePivot, meaning that with such meshes they will keep changing color and shading as you move. But for unlit meshes it works flawlessly, that's why I used it.

But with canvas rendering you do not have this problem, since you don't have to deal with the PrePivot that way, although making it render correctly without side-effects (especially those introduced by the render driver itself, such as D3D9 and OpenGL from Chris, with z-buffer "hacks" and such) may be a bit tricky (although this only generally affects micro-sized meshes rendered very close to the player, and not big far away meshes).

As for the actual scale, the zone shrinking (visually and damage-wise) seems to be the easiest part of this, what you have to worry about next is the number of players you want to support, and which maps you intend to use or build for it.

Generally this kind of gametype revolves around starting out with an absolutely huge outdoor area, and this engine was built mostly with indoor smaller environments in mind.
You can still cheat a bit around it by building the maps in a more dynamic way, or using a "honeycomb" approach to things (a huge map composed by fairly big outdoor areas, but all limited and joined in a "honeycomb"-like way with cliffs and such, very Unreal-style, it's hard to describe without making a small drawing or a demo).

In Unreal 227 I guess you can build a big terrain as well, and populate things with static meshes, so it would be easier that way, but if you're targeting UT, then you have indeed a bigger challenge ahead, but only mapping-wise, the rest seems to be feasible, although it will take fair amount of work to pull it off properly and it may take a couple of "tricks" like these to render meshes fully.

[gopostal]

I should have explained myself better. Last night I ran some tests to see if the absolute size would be a good fit for the ideas that I have. I don't think it's going to feel right at all. You can cross the entire plane of a wall-to-wall map in about 1:45. That's just way too fast so you'll never feel encroached by a zone. The idea of a zone is to push you towards a center but even if I slow the zone to 1/4 of player speed the rounds will end in single digit minutes max. That's not enough time to loot an area and the mechanics of the game rely on your needing to find gear in the early game. A player could easily loop the entire map in well under 10 minutes so I don't think I can prevent early interaction enough so it doesn't get frustrating if you don't have good gear yet. Not to mention I think most rounds might be over before the zone even becomes an issue.

It all boils down to the play area just not being large enough without resorting to warpzones connecting layered instances of the terrain.

I still think this is a valid idea for a gametype project but it's going to require retooling to fit the engine.

[Feralidragon]

I see, that's a valid concern.

But, on the other hand, unlike other games of the same genre (ForniteBR, PUBG, etc), you can only fit so many players here anyway, so instead of trying to making an exact clone of the game, why not give it a twist that only in Unreal/UT you can provide?

I mean, if I want to play that gametype in the same way as PUBG, I can simply go ahead and play the game itself. ForniteBR which is a huge success is free to play (atm at least), so other than maybe hardware resources, nothing stops me or anyone else from playing that one instead.
Not only that, even other games such as Robocraft will have such a gametype, which is also free to play, it's a pandemic, just like zombie games and gametypes a few years ago.


Allow me to give some suggestions in that direction:

1 - You can consider a limit of 32 players (the engine can handle at least that many for this kind of game nowadays I think);

2 - A player can transverse a big map from end to end in a few minutes at most?
No worries, take advantage on the fact that a lot of gameplay in UT is meant to be vertical, so go vertically.
Expand the map in the Z-axis, and make the death zone spherical rather than cylindrical.

3 - The zone can still shrink very slowly over time, over the span of maybe 30 minutes or an hour, or more.
The map being "smaller" than in those games will make the players to find a spot and camp a bit more, but eventually they will have to move anyway, and they may be caught off guard by it, and that's where they start running like hell.

Furthermore, the shrinking rate doesn't have to be constant, it can actually speed up as it gets smaller and smaller, starting off with a rate no one has to worry much about, but over time providing that "holy shit, I have to run" feeling you're seeking as it speeds up towards the center.

[gopostal]

I wish I could show you my idea pad, it's almost the same things you are thinking. I had sketched out an idea of a volcano-type island where the sea would rise forcing players upwards and towards each other. I'd even thought of trying to still do this PUBG style gameplay but in a very dense, urban map. TBH if it ever gets done it will likely need to be in a map where you can't easily move from A -> B.

Later today I think I'm going to download some of the really large and dense urban DM maps and see if that may be a feasible concept. I'm not interested in garish, billboard-covered cities but I am interested in seeing if you can create something dense enough and large enough to fit the bill of this project. Even adding a couple of floors worth of Z could do wonders. Be nice to have areas of town too. You could have a hospital where medical supplies are mostly, a military where higher grade weapons spawn more frequently, etc.

I really like this whole idea of gameplay in U1, it's just going to take the time to work out the implementation. I keep watching YRex's video and I just want that so bad to work.

[Feralidragon]

Rising sea also sounds like an awesome way to do it indeed.
It reminds me of Worms, where the sea keeps rising over time, and there's loot around as well (loved that game).


Now that I think about, one the most different things is that in most games nowadays, you have to press Shift to sprint/run, however in Unreal/UT it's the opposite, you're already running by default and you use Shift to walk.

So, in one hand, if you could invert this behavior and introduce something like a stamina bar, the player would forcefully take more time to transverse 2 points, but in the other this is Unreal/UT we're talking about, so players are likely to not like this.


Also, if you ever tried the AirfightUT mod (it's essentially a TC transforming UT into a game with planes, jets, etc), they got around the sizes of the maps by making everything smaller.

So, another potential way to go on about this, is to make the player maybe 4 times smaller, and you get immediately 4 times the map size.
This comes at a considerable cost though: unless you intend to create new weapons or adapt the existing ones, every single weapon effect, decal, etc, would have to be scaled down in the same proportion, and also you may get dangerously into the "quantum" zone of number precision, where the lack of precision of floats play a bigger role by being 4 times less accurate in this case.

[gopostal]

I wonder if it wouldn't just be better to script this as an add-on to normal LMS and not force a map at all. Let the people playing decide what works and what doesn't.

I'm interested in what you think about determining the eventual collapse point of a random DM map that's used in LMS. I could find it by code but I think it may be better to grab a random pickup/playerstart to use as the collapse spot. That way it doesn't end up someplace that's not accessible.

Also you and Bleeder discussed the cheating of the mesh position to always make it viewed. I understand the idea but is there someplace where this is done so I can see it in code? I looked up what I think you meant in the class "NaliFullMeshFX". Is that the example you were talking about? The NW3 code is really dense for guys like me. Can you guys reference another example too? If I can get this to work right I am going to work on an LMS mutator that brings in the PUBG style.

[Feralidragon]

Yeah, you could use playerstarts and perhaps inventory and path nodes for that, but still for best results you would need to make sure that the point is still center-ish concerning the map itself.

You could also prepare some maps in advance with an actor in them, or better yet, add the ability to set the center point for some of them manually from an ini file (a list of structs, each one with the map filename and associated center point vector, for example).

There are more ways of doing that automatically, which may yield better results overall, but they would need you to put in a lot more work for what may amount to very little gain in return, so probably is best to keep it simple and reliable at least, as you mentioned.


As for the full mesh rendering, yeah, that's the class, and the code is indeed denser and a bit more convoluted than it should be, especially since it has a few more features in it, such as the full view only being activated within a specific range, to not be rendered all the time.

The key part is this one:

Code: Select all

newOffset = (camLoc - CentralLoc) + vector(camRot)*(FMax(FMin(camActor.CollisionRadius, camActor.CollisionHeight) - 1, 1.0));
SetLocation(CentralLoc + newOffset);
PrePivot = -newOffset;

In that class, the actor which holds the mesh is responsible for updating itself, so this in the perspective of the mesh actor itself.
As for the vars:
camLoc: the current player camera location;
camRot: the current player camera rotation;
CentralLoc: the location the mesh is actually meant to be at all times, and where you want it to remain.

From there, the newOffset is calculated based on all of this, and in a way that at the end the offset is at least 1uu of distance from the camLoc.
As for the collision itself, I am not entirely sure why I did that anymore, but I think it's a way to account for sudden changes in direction or location from the camera actor (which may be the player itself or someone the player is seeing from, like a guided redeemer warhead), so perhaps a simpler version would look like this:

Code: Select all

newOffset = (camLoc - CentralLoc) + vector(camRot);
SetLocation(CentralLoc + newOffset);
PrePivot = -newOffset;

The tricky part is then to ensure the "when" this gets updated, and it must always be one of the very last things, otherwise it won't work very well, since if you're moving forward, or the actor you're seeing from, odds are that if this is updated first, that the mesh starts to lag behind and to never appear.

That's what this part is all about:

Code: Select all

//If has an updater
if (localUpdater != None && Delta != 0.5)
{
      updateDelta = Delta;
      return;
}
else if (Delta == 0.5)
      Delta = updateDelta;

//Check ViewTarget for "no-lag" updates
if (localPlayer.ViewTarget != None && localUpdater == None)
{
      if (localViewTarget == None)
      localViewTarget = localPlayer.ViewTarget;
      localUpdater = Spawn(Class'NWCorUpdaterFX');
      localUpdater.CorToUpdate = Self;
}
else if (localPlayer.ViewTarget != None && localViewTarget != localPlayer.ViewTarget && localUpdater != None)
{
      localViewTarget = localPlayer.ViewTarget;
      localUpdater.Destroy();
      localUpdater = Spawn(Class'NWCorUpdaterFX');
      localUpdater.CorToUpdate = Self;
}
else if (localPlayer.ViewTarget == None && localUpdater != None)
{
      localViewTarget = None;
      localUpdater.Destroy();
      localUpdater = None;
}

This is something used not only in this class, but some others, but essentially what I did back then is to ensure that I had an actor that was always ticked after the actor I was looking after.

This has worked pretty much flawlessly thus far in practice, although in theory any actor which manages to change the location abruptly of this ViewTarget after this actor gets ticked may still mess things up, hence perhaps the little margin using the collision, and the code overall is a bit messy and hack-ish, something I am not really proud of at all.


In other words, a potential better way of doing this would be to have a central actor/manager which could tick these kinds of actors at the very end of each tick, after every single actor has been ticked already and there's no chance of abrupt changes, which I have a feeling it may be possible to do so without a brute-force like this one, but I didn't look into it yet, so I am not sure how atm.

[gopostal]

Ah ok, got it! Now the class makes sense. I'm doing some custom actor stuff for Krullor but I'll get a prototype for the collapsing zone done this weekend. It's a holiday for us on Monday so I'll have a clear couple of days.

Conceptually do you think it's best to pick a point in this order?
If there are pathnodes, pick one of those first.
If not pick a weapon pickup.
If map is empty pick a playerstart.

Of course I'll add a proximity check to see if the area is clear. I'm aware that some games will end in not-so-desirable spots but that's also a charm in itself. At least no game will ever be such that it won't end because the zone will ensure it finishes one way or the other.

[Feralidragon]

I think you should use them all, without a specific order, and come up with a location closest to the center of the map (which could either correspond to one of those nodes).

In order to do this, you could iterate through them all, and sum their vectors in a single one and count the number of them, which then you could use to find the average location, and then find the node closest to it.

Keep in mind though that using a playerstart should really be the very last resort, to be entirely avoided if possible even if that means do some tracing around or use something else like a light actor (similarly to what Higor did in Siege), given that the proximity by which a player spawns relative to the center of the pain zone will greatly influence the chances that each player will have in surviving in the end, or at least the longest.

Ideally, players should spawn at about the same distance from the center, but as far away from it as possible and in different locations.
This is something that can be also achieved in a way, but at least the easiest algorithm for this could become very slow depending on the number of overall points to check: the complexity would be O(n x m), where "n" is the number of playerstarts and "m" the number of everything else, which means that with 32 playerstarts and maybe around 500 nodes, this would translate to 16000 iterations, although it would only be needed to be made once.

[gopostal]

I understand your philosophy but I'll tell you that having played multiple hundreds of hours of PUBG you couldn't be more wrong

I'm only joking but once you understand the dynamics of the game it can become redundant. Having circles that end at a cliff edge or even out in the water become some of the most memorable matches I've ever played. It's also a very valid playstyle to hide as long as possible. I've won a couple of chicken dinners doing this myself.

Anyway it's been my experience that the more absolute randomness of the circle placement the more that players enjoy it. For a while the circle kept falling on military base in PUBG and the players were very unhappy. Now the circle falls all over the map. I think grabbing a random nav point will do just fine. Sure, there will be times when it sucks but it's worth it that you just won't know ahead of time.

Also, I hadn't really talked this part yet but I'll end up replacing all the pickups. This will serve to force the players to have to move around to get gear enough to be offensively effective. I think I'll also look at using the tac ops military weaponry because I think it uses a reload function.

I'm curious too about something. I think I can get bots to work ok with this provided I can teach them to avoid the pain zone. What are your thoughts on that? Is it possible to have them avoid it without having to script new bot classes?

[Feralidragon]

I see... but could be that to be so simply because the map is static?

I never played PUBG myself, although I understand the gameplay somewhat, but I tried FortniteBR a while ago which seems to be similar, although in Fortnite you actually choose the area of the map you want to spawn in by jumping from a flying bus lol (not sure if they changed that in the meanwhile, it's been a while).

I understand that within the exact same map, if the zone center is always at the same place, it will make the gameplay go stale very quickly, with players employing the same strategies making it utterly boring rather quickly, so I guess that's a way for it to be more dynamic by changing the zone rather than the map.

Yeah, in that sense, it may work in UT the same way, with a random center.


As for the bots, I am almost certain that's possible.
I am not entirely sure the "how" part right now, but I think it would be along the lines of monitoring where the bots are and if they are relatively close to the edge, to tell them to just turn around, maybe even "deactivating" any nodes already in the pain zone itself.

Also, inventory in the pain zone itself would need to be "burned" to also ensure that bots do not give into temptation into trying to pick loot from the pain zone.

[gopostal]

I was thinking about that last night. As the zone progresses I think I'll have the pickups convert to some type of bot avoid spot. I might even have to address pathnodes the same way. This will likely end up with them stuck in spots but overall should keep them moving towards the center as far as that is possible.

As for the collapsing zone I'm still unsure what would be best. I've been really trying to figure out how to bring YRex's suggestion in but I don't see a feasible way. I could mimic that with an octagonal collapse of eight walls but the overlap would be ugly. Really I think your idea of a spherical zone may be the end result if this is done in UT.

Man, I wish more people played Unreal. I could do so much with what U227 has to offer. It's frustrating to have the answer right in front of you but know that it's just not what you can use.

[gopostal]

Sorry to double post but FeraliDragon has been holding my hand on this ideal of forcing a model to be visible regardless of the origin. He sent me revised and simplified code and I thought it would be helpful to share that here in case anyone else stumbles into this problem.

The revised code:

Code: Select all

var vector OriginalLocation;
var PlayerPawn LocalPlayer;

const ORIGIN_DISTANCE_FROM_PLAYER = 128.0;

simulated function PostBeginPlay()
{
local PlayerPawn PP;

     //run only in client
     if (Level.NetMode != NM_DedicatedServer) {
           //save original location
           OriginalLocation = Location;

           //get local player
           foreach AllActors(class'PlayerPawn', PP) {
                 if (Viewport(PP.Player) != None) {
                       LocalPlayer = PP;
                       break;
                 }
           }
     }

     //super
     Super.PostBeginPlay();
}

simulated function Tick(float Delta)
{
     local vector camLoc;
     local rotator camRot;
     local Actor camActor;

     //run only in client
     if (Level.NetMode != NM_DedicatedServer && LocalPlayer != None) {
           //get player camera coordinates
           LocalPlayer.PlayerCalcView(camActor, camLoc, camRot);

           //set location and pre-pivot
           PrePivot = (OriginalLocation - camLoc) - vector(camRot) * ORIGIN_DISTANCE_FROM_PLAYER;
           SetLocation(OriginalLocation - PrePivot);
     }
}
 

Thank you Ferali for this. I've run into this problem several times and never understood there was a decent solution.

Here's a demo on what I'll be trying to use this code on. I still don't know if this is going to scale up to the size I would like but I'm interested to see how far I can push it:


You can see that the mesh disappears on me even in this simple offline test map. YRex's implementation looks better but I can't see how to use a cylinder given the rudimentary drawscale adjustments I'm forced to use in UT. I went with a sphere because of this

[Feralidragon]

The "ORIGIN_DISTANCE_FROM_PLAYER" constant may have higher values, so if the mesh still disappears upon movement (the tick problem I mentioned earlier), this value can just be made higher, to something like 512 or even more.

The only thing to look out for is the LOD then.
If the mesh has LOD levels set and a LODBias set to the default value of 1.0, it may morph the polys out, given that the actor would be more distant (512uu instead of 128uu), therefore at a larger scale the LOD level of the mesh should be disabled at import (#exec MESH LODPARAMS MESH= STRENGTH=0) or the LODBias should be set to 8.0 or higher.



As for the cylinder, you can import a cylinder mesh, and in the import parameters set the Z axis scale to something huge, although I am unsure at which point will just mess it up.

Another way is to have a cylinder mesh in which this shrinkage is handled through animation, by having just a 2-key frame animation, with the first frame with the cylinder open, and the second with all of them collapsed in a single point.

I have used a similar technique to a lot of stuff, mainly things like particle effects (the growing clouds in nukes and oversurrections for example), precise trace effects (sniper trace), stretched cylinders (the guts in the gore mod for example)  and more, but it's relatively hard to set up: you either use MS3D or Blender and write a script in Python to create this animation for you for each vertex, or you use 3DStudio to set up each frame, one with the mesh open, and another with the mesh closed and export it as a single animated mesh.

Either way, it can be done, only the amount of work involved will differ depending on the approach.

[gopostal]

Well, I'm actually very surprised at the results of testing. I took the default shockwave mesh, exported with UModel and imported back, stretching it out to 8X on the Z-axis so it resembled much more of a cylinder but still would collapse down to close off any space. I then made a fully open map that stretched almost an entire plane of the editor playfield so I could see it render at max values.

I spawned the collapsing zone at drawscale 1000 (yikes) and started the round. To my great surprise it renders beautifully, collapsing just like it should. Jeez, this might just actually work.

So now question time...
1) Scaling the zone up so high makes it quite ugly for any type of wet/animated texture. Could someone suggest a way to deal with this? I would like to use anything besides a flat color but I will if I have to.
2) I'd like to start the zone out at the edge of the map instead of the edge of the map area. Is there a way to find the furthest edge from the randomly chosen zone center point? I thought about iterating the pickups to find the one with the largest difference in location and using that to compute a size but is there an easier way you know of?
3) Bonus question...is there a way to determine which actors are within the collapsing zone and which are not so I can apply damage? I can do traces to see distance and get pretty close but I wonder if there is a better way?

[Feralidragon]

1 - There are a few ways you can go about this:

1.a) Use a much higher poly mesh, something that has several lines of polys along the Z axis, squeezed in so when you scale it in that axis, they become all rather even.
Not sure how to properly explain this, but something along this:

The UV mapping in this case has to be done in such a way that every line maps to the full texture, so the texture actually appears to be seamless and repeat across them all without being stretched.

1.b) Same premise as above, but instead of a single mesh with several lines, you can use multiple instances of the same mesh, all placed on top of each other.
Although during import, if you don't take the lack of accuracy from the engine and if they are not perfectly aligned at all times, you will see the edges and it won't look great.
But this way the mesh itself is a bit easier to prepare and you could only show the lines you actually need to render instead.


2 - You can only iterate through every actor you can know a location from and then see the max distance, since there's current no way to get the vertex locations from BSP in UScript (at least in UT, not entirely sure in Unreal though).
You can also do some additional tracing in every axis from each one of those locations to try to get the utmost BSP points.


3 - You can simply use a "foreach AllActors" and check their distance from their current location to the center of the zone, and do your magic from there.
You don't need to do any tracing because the pain zone is supposed to absolute.
There's also RadiusActors, but in this case you want to know what's outside, so it wouldn't help here.