5 years on, can really only assume that this is somehow considered a feature. You can check it out yourself - steps to reproduce (works for my squad for years now): 1. Spawn an infiltrator. Stalker works best for trying to reproduce the bug. 2. Get into a queue to wait on a continent. Can be in sanctuary, or anywhere really. 3. Turn invisible and wait. *Poof*! When you warp to your new continent, you're visible, and you can't turn invisible. You can't re-up, change gear, respawn, change continents, etc. - you have to restart the client to get it to work again. Here's to another 4 years of occasionally getting screwed by the feature the devs don't care about, alt-f4'ing, and seeing what else to play that night! Woooooo!!!!
So for 5 years you've know about this and you still sit around cloaked until you warp? Stop doing that. Why are you cloaked when warping to another continent? Are you trying to hide from someone and not let them get you before the continent shift? What kinda chicken !!$# is this? It's a super minor bug (what devs often refer as a "corner case") that has a known workaround. I'm sure it's on the list but it's a long list and given the minor nature and available workaround it's going to be near the the bottom. How about they fix the bug where you can fire while still cloaked on the other screen. How about that one. Infiltrators, I swear... chicken !@#$ mfers.
it is one of those bugs that should have been squashed long ago, like if you die in the middle of throwing ammo or using aegis shield you can't do ANYTHING until you relog.
It's been a bug so long, it might as well be a feature. I feel like a single script would resolve this one, the throwing ammo one and the Aegis shield bug as all of them put the player in the same 'state'.
It can be caused with all abilities. Usually though it's mostly a problem of throwing ammo, dropping a barrier or shield regen tool and dying/redeploying as you place it. Thing is stuck on cooldown until you log off. It's quite annoying.
Bugs having birthdays seems to be a feature. Vehicles causing me to redeploy when I exit them wasn't new when I submitted the bug report, and that report is more than a year old.
You don't really need to worry about that. You can scroll on by if you don't understand why it's a problem. The short answer is, if we're waiting in the queue and I'm 17 of 43, instead of standing around Skanktuary, we might go to one of the other continents and play a bit while we're in the queue. And that's when it happens. Nobody sits around cloaked waiting to warp. Nice troll attempt, though, lol!
Speaking of longstanding bugs. The bug that kills your weapon sounds after 3 hours of play seems to have shortened to 1-2 hours of play.
* related to the implementation of DX11. Its not gear in the hardware term, it's an api (software) set that's been kept updated since it's launch. We're not using the version of it at launch, it's frequently updated kind of like windows on your computer. Basically it's last update was April 2, 2021, so it's pretty new. Issue is more likely cause by some bug DBG added during it's implementation.
I'm familiar with it being an API (I'm a software developer for ~20 years now, been a dotNet dev for years). It's a known bug with DX11, but not everyone has it - it also has a lot to do with execution times across older hardware. If the guy has Great New Stuff™, then that's fine - Serious Gamers get Serious Gear. Most times, however, if a problem is associated solely with a software implementation (API, lib, whatever), the bug will manifest everywhere, for everyone. Otherwise, it's usually a combination of software implementation and the hardware it's running on. What he described sounds very like a timing issue associated with client events happening asynchronously with what the server thinks is going on; still very likely a poor connection, server lag (which seems to hover around 55ms-70ms lately), or local execution on his hardware not completing or at least disagreeing with what the server has decided happened, re: player locations, hitboxes, etc. There are a lot of problems like this, unfortunately. DBG could likely benefit from looking at the Quakeworld source - Id did a great job addressing these sorts of issues 20 years ago. Valve took it and ran with it here: Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization
yeah exactly this is what seems to be going on here. It's something that's affecting everyone all the time, which is what lead to that conclusion. I think it was acknowledged on reddit somewhere but I'm not 100% sure.
That's an awesome article, can't believe it's already been 10 years since I first read it. The solution implementation is going to be wildly different in planetside. Server can do network compensation for 10-40 man deathmatches. It's going to buckle if it has to do 200+ in a zone. The infiltrators firing while cloaked isn't directly related to the game doing well or poorly at latency compensation. It's a separate beast because it requires an atomic operation. Two different events must remain related to each other in a correct way. As best we can tell in other discussions there is an "I wish to decloak" outbound client packet followed by a return packet either ACKing the request, or sending a broader status update indicating "you are coming out of cloak". After this packet arrives the client is free to fire (it puts a built in delay client side before it lets the user do this) There is a separate packet that appears independent that indicates when the client fires and that packet will also indicate the hit (client side hit detection). Server verifies of course and sends on a "you are hit" or "you are dead" for this event. The server sends on the tick. (like every 15-18ms if I remember). The "enemy is decloaked" and "you are hit/dead" should not go on the same tick but can. Problem manifests in two parts: 1. If there is jitter (latency doesn't explicitly matter here... 200ms acts same as 50ms) from the client or it's network then the two packets can GO OUT simultaneously on the same tick or possibly even out of order. 2. If there is jitter on the receiving client then packets could COME IN out of order. (Regarding hardware: if it were a graphics rendering issue someone would have to get 0.01 FPS to have the entire decloak elapse before the hit packet arrives. I'm running an Intel 8086k at 5ghz on all cores, 4ghz memory and a rtx2070 and I experience the issue fairly regularly) I'm not sure of a way to solve #2 outside of moving some portion of hit detection over to the receiving client. A terrible idea for a thousand reasons and likely impossible to implement without rebuilding the whole thing. #1 though is where the "bug" is. Not sure if a bug so much as a design defect. The DX11 patch seemed to just exacerbate things. A ham-handed fix would be add to the delay. A more elegant fix would be server side. Simply add a "decloak completed" event in addition to the "you are beginning to decloak" and do not allow the client to fire until it arrives.