#Abort option/prompt on contested LZs
1 messages · Page 1 of 1 (latest)
There's currently no way to do that with how the chopper system works. They're entirely on pre-defined rails and nothing "dynamic" about the routing.
That's why you may have noticed that we're suddenly clipping through trees on some chopper rides in 0.4 when we didn't in 0.3 - because they changed the terrain, but didn't change the splines the choppers ride on.
Supporting this woulud require a complete ground-up rewrite of how the chopper system works.
Could be something for the longterm. Would appear that static splines are the bane of the current LZ issues?
They're just far, far more efficient from a server resources perspective than having to calculate that all the time. And those resources would have to be borrowed from other places, which I don't think we'd want to see.
Pretty much as Mike said - compute cycles allocated per instance would almost certainly spike if choppers are having to be rerouted dynamically on the fly.
Those resources would likely have to come from those allocated to the AI, which many of us think is lacking in numbers/braindead already.
If the choice is between smarter/more AI map wide, or dynamic rerouting/cancellation of in-flight helis, it's not much of an choice.
While I would personally love the ability to cancel a heli, I think the only time it makes sense is when it hasn't picked you up yet, and thus hasn't spawned in and allocated those resources yet.
I understand the limtted compute available per instance. Since the heli insertion is rather harmless from a security perspective. (What are they gonna do, hack the choppers on score roadkills?)
What about putting rerouting calculations on the client side?
Unfortunately, that doesn't solve it either - client side means it can only see it's own calculations and routing for your own heli, but you need to be able to calculate based on the other 15 helis (your factions as well as the other 2 factions) too.
Server side means it can see and calculate all flights, and allocate splines accordingly.
Sending location data for each heli to relevant clients is to heavy for the server? (proximity based?)
It can be - you're basically asking the server to send and receive 16 times the amount of data on helis (to and from each client) to 47 other people (who need to be able to see the active helis and flights as well).
That is a lot of data you're now pushing out from the server, which otherwise never had to be before.
That's even before you get to the factor of latency and lost packets of data, which may interrupt those calculations.
First off: pick better LZs. Stop landing directly next to the COP you're about to attack. I've reached level 35 (no lifer) and haven't been shot at an LZ a single time so far this patch. And that's all attributed to LZ selection.
In LRI territory these LZs are super risky and should be avoided if there's even a slight risk of players being there: Hotel 1, Foxtrot 1, Golf 3, Papa 1, Oscar 1, India 2, Juliett 2.
Secondly: Even if the technical issues could be solved (I'm sure it's doable even if non-trivial), aborting LZs has other gameplay issues.
If you can abort a landing you can use choppers to "scout" areas deep in contested areas. People will absolutely do this because there's zero risk and just a time cost. That'll tie up choppers causing them to get backed up for other players to use normally.
It doesn't actually completely solve your problem of hot LZs because you'd only know that it's hot if a player just died there (while you are in flight). Very often you'll miss that indicator and still get blasted by people locking down the LZ.
__
What I think we need is more information for players so they know what LZs are potentially dangerous. For example, a "contact report log" filter on the map that shows us a list of all contact reports in the past 12 in-game hours or so. That's a very practical thing (read: immersive) to exist because surely something as serious as gunfights would be logged by the guy who's on the radio with us.