schilds

I'm on 11 and have been running with HDR, seems to work.

I just scanned the first few pages of each of the Duviri bug forums and nearly every thread going back days has been started by a different person. You can go take a look yourself. So who are these "same posters" you are saying comprise all the bug reports? Surely you're not basing your assessment off people you're debating here in general discussion? The problem is bugs! Bugs due to brittle game architecture. The solution? Fix the bugs. Fix the architecture. After 10 years, their architecture for synchronising game state over the network should be rock solid. No matter how complicated the scripts or state they throw at it, they should not break. Invalid or inconsistent states can and should be detected and corrected. Stuttering, rubber-banding, lag, disconnections etc. These are not bugs. These are connection issues, or even *expected* phenomena arising from trying to synchronise state over a network. Maybe they'll be fixed by dedicated servers, maybe they won't. Game logic that breaks is not a networking issue. It's buggy code and/or/from flawed game architecture. The game should maintain, and present to the player, consistent and valid local game state *irrespective* of network conditions. The only way that network conditions relate to this is that less favourable conditions trigger these bugs more frequently. When conditions are favourable it doesn't mean the bugs aren't there, just that they are hidden.

With arcanes that now trigger off elemental status effects (Cascadia Flare, Secondary Shiver, Conjunction Voltage, Primary Frostbite, etc) the buffs from augments like Freeze Force, Fireball Frenzy, etc have significantly more potential than before to interfere with the builds of your team mates. If they build for heat to trigger Cascadia Flare, it's can be changed to blast with Freeze Force, leaving the arcane useless. Even those that don't combine (already being a combo element like corrosive, radiation or magnetic) will have their status weighting shifted. These augments were already problematic because even without the new arcanes, players mod for specific status effects and weights. which these augments interfered with.

Every clan can get research it now.

I just realised there's another possiblity. The evolution engine probably has some kind of event system. That means what I'm imagining to be a contiguous block of code may be broken up into decoupled or loosely related blocks (because that's what events are designed for) where instead of being directly sequenced, each block is expected to trigger one after the other and in order according to their activation conditions, indirectly producing the sequence comprising each state transition (e.g. operator to frame, or frame getting stunned and then recovering). That would potentially make "interruptions" (not to mention out of order execution) and non-atomicity easier because everything is already split up. Rather than an interruption to a contiguous script, it's now an event not triggering when its supposed/assumed to. So then we have the event system, script engine, netcode, state synchronisation code, all possibly on top of threads, all interacting with each other to produce hard to find bugs. If DE are reading this they probably think I have an over-active imagination :-P.

Gen, they know about this class of issues. They've "fixed" variations of them before (infinite loading tunnels, dismounting Yareli's k-drive, broken objectives, broken cutscenes during boss fights, for example), and variations of those issues just keep coming back. Some of them might be different bugs, but some of them are almost certainly the same non-deterministic issue (or class of issues) due to different subsystems interacting poorly with each other. I bet that they've already looked at the code that deals with transference between operator and frame and there's probably nothing wrong at the surface level in *that* bit of code. Which means there's some non-obvious assumption or requirement or condition (like atomicity) for that code to execute correctly that isn't always being met. In any case, I wouldn't consider my post particularly helpful to DE. It contains nothing reproducible*, merely guesses about what's going on inside their engine. I certainly don't know more about their engine than they do. Just on objectives: Some of these do appear to have been relatively simple fixes, like preventing stuff falling off the edge or spawning underground or whatever. Some of them do appear to be related to obvious synchronisation issues over the network, e.g. when stuff doesn't happen because the host's character wasn't close enough to the client's character when they tried to initiate something. On controls breaking, what do we know for sure? You get up from being knocked down, or you transfer from operator, or you hop off your k-drive/mech/archwing, and all you can do is wasd and sprint. No weapons, no abilties, usually no jumping. You used to be able to "fix" it by jumping off the edge of the map, but the only way now seems to be to die, let yourself bleed out, and then self revive. What does that mean? It means that somewhere between disabling the controls for the initial state, and then enabling (or re-enabling) them for the subsequent state, something goes wrong: Code/script has a bug, so it doesn't get to the enabling controls bit (but if this was the case surely they would have found the problem by now). Code/script gets interrupted/cancelled (can scripts even get interrupted? I don't know). Stuff gets executed out of order (can that even happen? I don't know). Something is read before it's written. Something is written over before it can be read. Two things trying to fiddle with the same state. Heck, this could be *because* the game is trying to both maintain valid state locally, and synchronise it with remote state. Maybe the two bits of the engine that do those things can both meddle with the state at the same time, resulting in a big mess. Can that happen? I don't know. Is it even necessarily a network problem? It may not be. I'm just guessing it is because it *seems* to happen (more often) as client in a squad. If it was a simple deterministic error, surely it would be fixed already (they've had years) so the guess is there is a non-deterministic race condition, or an operation that is meant to be atomic/transactional but isn't, or something like that in there. Maybe it's not anything like that and their code is just so much spaghetti. So why all these posts? Partly because I'm venting, but mostly because *other players* keep saying that it's all network issues that DE can't possibly fix, and that just isn't true. That's not to say there are no network issues, just that they should not result in invalid state or broken game logic/scripts. That's entirely on DE and their architecture. Unreliable player connections (and their consequent phenomena such as stuttering, rubber banding, etc) might not be DE's fault, but not handling them gracefully and instead letting them affect the consistency/validity of the local simulation/state/model is. Also, people keep talking about player connections and whether they're good or bad, disregarding there is a whole network that is out of both DE's and each players' control in between. Traffic is variable. Routing is variable. Hardware inbetween is variable. The internet is *inherently* unreliable no matter how good your personal connection to your ISP may be. Software needs to account for that. We should expect DE's code to be robust to well known networking phenomena. Anything else is setting far too low a bar. That's like saying "gravity does stuff, it's not the plumber's job to take it into account". It *is* their job. There are multiple points of failure, some of them are definitely on DE's side of things, and they shouldn't be dismissed just because they often go masked. *I guess I can tell them "just play long enough transitioning between various states like operator, knockdown due to enemies, frame, etc, as a client, maybe simulate some network lag, packet, loss or something, and you'll run into it eventually".

I think there is a slight language issue here, and it's over the use of the word "reliable". From the point of view software, all network connections are unreliable. You can never be 100% certain that your local model of the universe is consistent with someone's remote model of the universe. Look up the "Two Generals" problem. All you can do is build confidence to some degree. You do that via the communication protocols and networking strategies you adopt. When I say "unreliable" I don't mean I'm experiencing massive lag, rubberbanding/teleporting halfway across the map, disconnections or anything like that. The game simply enters obviously invalid states even when the network issues are imperceptible. Indeed, the game usually appears to continue on with other players moving around normally/smoothly and with only *some* of my controls "stuck". It is because it does so during co-op missions as client more frequently than in solo missions or as host, that I *infer* (possibly incorrectly, btw) that it is the difference in reliability betwen local and distributed computation that has exposed the problem. The problem (bug) is in fact *always* there. It's just that the programmer mistake or flawed assumptions or archictecture/design errors (or whatever) are not obvious because the code is (for example) time sensitive (i.e. badly designed) and local computations happen fast enough that this assumption is ok, whereas remote computations can vary significantly in speed, making the assumption sometimes ok and sometimes not (which means, generally, not). Who wants to bet that some of DE's workarounds involve shoving guestimated delays/waits in bits of script? That is, when I say "unreliable" network connections, I mean relative to the vastly more reliable local computations. DE support are not going to diagnose my connection as any more unusually unreliable than other players. So there are two types of inconsistencies we can identify: The first is within our local model. The second is between our local model and a remote model. DE are entirely responsible for the first type - short of hardware bugs that intel or amd (or whoever) are responsible for, or computers below min spec which the player is responsible for (my computer is significantly above min spec if that's what you're wondering). DE are only responsible for doing as best they can, building as much confidence they can, with respect to the second type. And you know, it is possible to get pretty confident here, the longer a networked session goes on and the more messages are exchanged. Detecting potential divergence is possible (even if false positive) otherwise you would never know you've disconnected! So if (for example) I switch from operator to frame, and my local copy of Warframe (a) allows it and (b) shows it, then to be consistent, my controls should now be frame controls, rather than *nothing* (i.e. "stuck" controls) - actually, I can still walk, just no abilities/weapons. That's even if, due to networking issues, my local simulation has diverged from the remote one. Local consistency is DE's responsibility. Failure to maintain it is DE's bug. The first point of failure in this example is a network problem (could be a minor moment of lag on even a good connection) that has interrupted the frame to operator state transition, stopping it at a point where the state is invalid. Normally that point would be temporary. The code that handles the transition *should* recover a valid state, maybe rollback and re-attempt the transition, but that isn't happening. The second point of failure then is an incorrect assumption by DE that the entire transition is an atomic operation that always goes all the way to completion. Two (possible) points of failure contributing to the one (player observed) problem. One point DE is wholly responsible for, that is in maintaining the validity and consistency of the local state. The other point DE is only responsible for doing the best they can, that is in maintaining consistency between networked states. That's why I've been careful to use the word "expose" and why it's wrong to write off issues exposed by "unreliable" hardware as having nothing to do with DE. Btw, I can't report the bug because I can't reliably - ha! - reproduce it. It's the worst kind of bug. Non-deterministic. It's also a bug (or bugs?) they've "fixed" multiple times before.

Sorry, but this is just incoherent, rambling nonsense. While I won't accuse you of not reading what I wrote and commenting without context (so kind of you to offer such, first), you clearly haven't understood it - and that's why you're dismissing it with the pejorative "blah blah" rather than addressing the content. Perhaps your unsolicited personal assessments of other people should be directed at yourself, with a little self-reflection.

This is not correct from the point of view of the software. Things that can happen over a network include packets arriving late, out of order, corrupted, being dropped, etc. These are not bugs (or even exceptions) from the point of view of the software receiving the packets. They are all things that software should account for (not try to fix - they should be fixed as best possible in hardware). None of these should break in-game logic or leave the game in an invalid state. In Warframe, it appears they do. When stuff happens as a co-op client that doesn't happen solo or as a co-op host, the likely culprit is the netcode (though it could also be something to do with race conditions between threads, ugh ...). When that stuff isn't just lag, rubberbanding, etc. etc. (which are all phenomena arising from various strategies used to synchronise game state) but actual game logic breaking, that's a bug. not a network fault. It's a bug because the software has not accounted for the sorts of things listed above, which are known to happen even on good network connections. It is the game's responsiblity to present valid game states to the player. When it doesn't, that's a programmer error, i.e. a bug. Hence it is accurate to say that the unreliable network has exposed a software bug. There are two, separate issues. It is *not* accurate to lump it all together into "unreliable network, DE has nothing to do with it, blame the ISP, player or their cat".

Does it really though? I think the problems mostly get worked around, and then because the code is *still* buggy somewhere deep in the engine, the problems crop up again whenever DE build something new on top of it, and DE have to work around them *yet again*. Consider the current Jackal Boss fight when it was first introduced. A player skipping the cutscene during co-op would break the whole fight for everyone. So they disabled skipping the cutscene. That's a workaround, not an architectural or logic fix. The problem is that many of the phenomena players observe are hard to replicate. I can't say to DE, "oh my controls got stuck and here is exactly how you can reproduce it". I can't even replicate it on demand myself. They're a kind of heisenbug. Even if I perform exactly the same in-game action, whether or not the bug happens depends (and I'm just guessing here for the sake of argument) on something non-deterministic going on over the network. Just because the bugs are exposed by an unreliable network, does not mean they are bugs *due* to an unreliable network. We need to differentiate between two types of issues here: 1) One type of issue surfaces in phenomena such as lag, stuttering, etc. DE may have some say over exactly which type of phenomena players experience (through how they choose to deal with network problems) but they can't get rid of them alltogether. This is just what happens over a network. 2) The other type of issue surfaces in broken game logic. The game *should* present to the player *only* valid game states. If it doesn't, that's a bug. It's DE's responsibility, not the network's (or the player's or the ISP's). If a state transition gets interrupted somehow during what should be a temporary invalid state (like between disabling operator controls and re-enabling frame controls during transference) then the script/code needs to be rolled back (to a valid state) and maybe rerun. The script that performs the state transition should be made to work as an atomic transactiom and not simply assumed to be one (because that's an assumption that obviously breaks sometimes when you are not solo or the host). The bug is probably not even observable in the script itself. That code probably looks fine. The bug is likely in the assumption that the script can't be interrupted*. An assumption that is only true when solo or host, that can break over the network, and that breaks more often the less reliable the network is. * Of course I have not seen their code or their architecture, so I'm just guessing here. Nevertheless, game logic should not break due to networking issues. If the game can't synchronise state, if it can't recover to a valid state, that's a disconnect, not a "oh we'll leave you apparently still in the game but without your controls".

Whether or not we have dedicated servers, the netcode should be far more robust than it is. Some phenomena due to an unreliable network are unavoidable, such as lag, stuttering, teleporting, rubberbanding, disconnects etc. Other phenomena should not happen at all, such as broken game logic, states and transitions. In other games I also experience the former, but rarely do I experience the latter. Warframe is the exception where they occur regularly. Then of course there are the dreaded host migrations, which are always going to happen (without dedicated servers) but need to be handled far more gracefully than they are. This game is an online only, co-op game. There really is no excuse for the synchronisation of game state and logic across the network not to be rock solid. Scripts should not break. Objectives should not get stuck. Player controls should not get stuck. Player rewards should not get lost in the aether. It's also an action game. Many things may be server authoritative, but they should also be client predicted and possibly with rollback to maximise responsiveness. Network architecture in games has come a long way since 2013, but Warframe's has not. This is not just for our sake. The problems limit DE's ambitions and creativity as they shy away from presenting players with complex scenarios in part because they know they will break.