Collapsing pain zone

[gopostal]

1) I've been experimenting with different animated textures to try to find something that works without making some very heavy poly-ed model. I'll let you know what I end up getting with results from that. Honestly Blender intimidates the crap out of me and doing correct edits on an existing model is above what I can currently do (though I will learn it if this requires model work). I hadn't considered multiple instances of the mesh and this might be a good fit. I can use layers at high drawscale and reduce them as the need lessens and the mesh is at a lower draw.

2) I took a look at a set of random DM maps and I think running through the pickups/spawnpoints will give me a really good start point for the zone size. I figure whatever it returns I can fudge upwards 10% and that will be in the ballpark. Can I trouble you later as I start to try to work through the math? That's where I'm pretty weak. Once it gets to middle-level algebra I'm lost quick. Wish I could have went to college.
EDIT: OK, It boils down to choosing either running a Pythagorean calculation using the coords or doing a trace from location to location. What do you think is faster and/or better?

3) Will a foreach return distance even if that crosses empty space/multiple hits on BSP?

Thanks for hanging in here with me. I'd like to get the gameplay fairly set before I work on weapons and pickups.

[Feralidragon]

2 - Yeah, no problem.

3 - A "foreach" generally only iterates through actors, and from there it may only do something more depending on the used iterator.
For instance, only VisibleActors and VisibleCollidingActors take visibility into account (hence the names), while TraceActors does tracing, and so on.

An AllActors iterator does really only do just that, iterate through all the existent actors within the map, as long they belong to the class or a subclass that you specify, so there's no tracing involved whatsoever.

Therefore, from there, to know the distance you only need to do a "VSize(A.Location - CenterLocation)", where A.Location is the iterated actor location and the CenterLocation is the actual center location of the pain zone.

Code: Select all

local Actor A;

foreach AllActors(class'Actor', A) {
      //check if is within the pain zone
      if (VSize(A.Location - CenterLocation) >= CurrentPainZoneRadius) {
      
            //do damage, inflict pain, destroy stuff, etc...
            
      }
}

From here, you may want to only affect classes like Inventory and Pawn, at which point, depending on how many classes of actors you want to affect, you may want to write a separate foreach for each, or filtering them within a single one (the rule of thumb is: if you have very few main classes to deal with, use multiple foreach statements, it will be more efficient even although in terms of time complexity it shouldn't be, but it cannot be helped given that UScript is 20x slower than C++ iirc).

[gopostal]

Ugh, I wish I had a cookie for every time I try to say something and it comes out not what I meant. It makes me look so retarded.

I understand about the actor iteration. I didn't fully explain myself, I was trying to do too much at once. I should have said it as "Will a foreach give me actors I can return distance trace even if that crosses empty space/multiple hits on BSP?" Luckily for me you also can read minds.

*Edited my post after testing tonight*...

Thanks for your help. Using your trace example I was able to script checks for the farthest playerstart from the zone's spawn point. I'm converting those distances to drawscale now and I think it should all be good. There's still a lot to work out like how fast to collapse and such but it's nice to know the core is good thanks to you.

[Feralidragon]

I will be honest: I also found it weird that you would make that kind of question concerning a "foreach", but I opted to just reply to it rather than questioning it.


On your 2) edit: on the off-chance I am misunderstanding you, what exactly do you mean by "trace from location to location"?
I am asking this because a Pythagorean calculation as you said (which is what VSize does) is the only viable way to know the distance from location A to location B, therefore coordinates are the only things you need to know how big something is, you don't need to know or trace anything in BSP itself or anything else.

The only tracing you could do would be to check the surroundings around each location, so you could get a better insight on how big the map actually is, but you already said that you would just add 10% to the distance, which sounds very reasonable and a good way of doing things, so I guess this is not what you meant.


PS: This discussion made me install and check out FortniteBR again.
Been having a blast with it ever since.
(although I didn't win a single match yet, but at least managed to be at 6th place thus far, out of 100)

But the pain zone mechanics there seem to differ a bit from what you described from PUBG: it's spawned at random locations, but not just 1 single location.
Instead, it starts out with no pain zone at all, then the center is somewhere random in the map, but not too random since the initial radius is big and has to be contained within the map, then each 2-3 minutes it shrinks a bit, stops, then a new point within the current radius is chosen, and only starts shrinking again after a few minutes.

By the end of the game it gets faster, changes more frequently, and the damage it gives is much higher.

[gopostal]

Yeah, it's a little frantic. TBH I prefer PUBG over Fortnite simply because I'm not good enough to use the building mechanics well as part of the game strategy. For me (and for this old of an engine) the simpler play is just better because there is less to track all the time.

I had never done a trace across empty space between open BSP and I did not know if it would return proper values. I didn't know that's what VSize actually did. Turns out it works like a charm. I figured out the ratio last night and it's a bit surprising:

If you take a mesh about the size a player could fit inside of, this compared to the player's default size, then to reach just past a marker 2048uu away you need to inflate the mesh drawscale 73.25 times. This is linear too and works all the way up to 805.75X, which is roughly going from the center of the usable field out to near the edge of the usable field (diameter). In testing it seems the engine does not care if the mesh renders out of bounds so long as the origin remains in the map play area. This is a visual of my testing map if that helps you see. The pic is very large, that's why I'm not embedding it:

Today I'll work out the pain zone part of this and test in some various DM maps. If it's all good then I'll probably work on the weapons and replacement mutator parts of the mod. I've been using the CS 1.6 weapons and it seems a good fit. Forced reload will slow things down some and allow the hit player a chance to run and bandage up.

I'm glad you played a bit of Fortnite. Hopefully you see the draw of this game mechanic and hopefully it could bring some interest into regular DM play.

Edit: Got finished with the implementation of the zone, here's a demo video. The mutator is finding a random playerstart and the distance to the farthest other start. It then computes the correct drawscale and spawns the zone. I sped this zone collapse way up so it won't waste any of your time. There will be steps along the way where the zone will pause and it will stop in an area small enough for two people to face off in before finally collapsing totally. I want to give the final two an option to knife fight for the win if they want


I tried your code to force the mesh to exist but it didn't seem to help. If you aren't facing the origin the mesh will blink out Man, it's frustrating to be this close and still not there...hahaha

[[]KAOS[]Casey]

re: mesh problems

are the polys flagged two sided in umodel?

[gopostal]

No they were not. Before I imported it into the mod I used UnrealFX to set them all to two-sided. I think I'm going to have to go back into Blender though and divide the model down more so it has a higher poly count. In fact I've been toying with the idea of using multiple models and replacing it as the drawscale decreases with lesser poly versions. I'm just concerned how that will look in-game.

[[]KAOS[]Casey]

I wonder if you could trick the LOD settings to decrease polys as it gets closer?

[Feralidragon]

Yeah, you could, by setting the location of the mesh actor much farther away, and tweak the PrePivot in the same proportion.
The only problem here is that you have next to no control on which polys are going to disappear and how exactly it is going to morph...

Either way, I don't believe that to be an issue in this case, since I don't really see the number of polys to be so massive as to introduce a performance problem, and gopostal seems to going with the multiple meshes approach, which already make way for similar optimizations to take place if he wishes to pursue in that direction.


In other cases where full mesh rendering is required, the full rendering could be activated only as long as you're within the bounding box or bounding sphere of the mesh, since this is the only situation where the disappearing mesh is a problem.

That's exactly what I did in NW3 for example, if you're inside a cybot shield the full mesh rendering is activated, however if you're outside it renders normally with all the optimizations the engine already does, and the transition is absolutely seamless, you never notice a difference (I used a bounding sphere though, which is easier and faster to calculate, and even matched more closely the kind of meshes I applied this to).

[gopostal]

It's not really a game killer problem, I just would like the mesh to look better when it is blown up so hugely. I wanted ideally to use an electric field looking texture but I switched over to the UDamage one in unrealshare for now and it looks ok-ish even at very extreme sizes. I'm going to revisit it when I go back and polish things though because it for sure needs more poly at larger drawscales. I'm still incredibly surprised it even works at all when you approach 1000X scale but the engine doesn't seem to mind at all.