Did you remove /oos or fix desync?

"

genericacc wrote:

Projectiles don't need constant updates. A projectile with constant velocity only needs a (t_0, x_0, y_0, z_0, v_x, v_y, v_z) tuple to dictate its position across all of time in 3-space, actually, which will take 28 bytes or so per projectile using 32-bit floats. Of course, you also need a word or so to specify what the projectile type is, putting us at ... another two bytes. Nothing could possibly handle that network load.

You seem to have some knowledge on this, I certainly don't, so that is why I ask this. Is that last bit sarcasm?

I always figured with the vast amount of ways to customize attacks, that the netcode has a lot of thing to worry about. Does it really just worry about position of a projectile? What about all the ways to modify that projectile with support gems? (GMP-LMP/fork/chin/piercing/damage conversion/etc)

Again, I don't know anything, I'm going off what a dev posted once. They mentioned the reason they didn't do a certain thing was because of server load and how much the server has to think about when you modify so many skills in so many ways at once (could be misremembering that).

This whole thing may a bit off topic but it's interesting to me.

I haven't read the whole thread but was the reason for this change the fact that spamming /oos would effectively make your whole party unable to move?

"

njon16 wrote:

I would love to know Chris, Damien and other GGG members what do your work hours look like and how much sleep are you actually getting during this stressful beta time. I'm running a small landscape contracting company pulling 70 hours a week between work and paperwork and I cannot even fathom what you guys are doing.

I haven't slept since Thursday night (it's Saturday morning now) and Mike on the support crew was with me all of last night having had only two hours sleep which is pretty indicative of our hours of late.

I know Chris pulled a 30 hour shift or two recently and support staff has been extremely stretched with non-support staff and siblings even being pulled in to help during the 9pm to 12am shift. I've done a few all nighters and ended up in hospital for high blood pressure and overexhaustion haha - I went straight in the next day because I really wanted to get the skill fx microtransaction vids out the door and hey, I love my job!

But yes, we're stretched in some senses but also enjoying what we're doing and really loving the opportunity of having the game out in the wild for people to play.

@F2Pelerin2010 - I am - for some reason they wouldn't cast me as the witch! ; )

""If we don't have good sync improvements in the very near future we'll put a rate limited version of /oos back in.""


I very hope you will because spamming /0OS to have a good gameplay experience is a very lame mechanic :(

"

Damien_GGG wrote:

siblings even being pulled in to help during the 9pm to 12am shift.

How cool is that ? :)

i guess these are the solutions they are looking at. this is for fps but i guess it works (roughly speaking) the same..

Do nothing

doing nothing does have the advantage of giving players the truest possible picture of what is happening to their input.
With variable latency this may be frustrating even under ideal conditions; with higher latency and random player movement it can make playing virtually impossible. For example, if a remote player passes by a window in a period shorter than the client's latency it will be impossible for the local player to hit them even if they fire immediately.

Rewind time

Another way to address the issue is to store past game states for a certain length of time, then rewind player locations when processing a command.
The server uses the latency of the player (including any inherent delay due to interpolation; see above) to rewind time by an appropriate amount in order to determine what the shooting client saw at the time the shot was fired.
In the worst case a player will be so far behind that the server runs out of historic data and they have to start leading their targets.

This is a WYSIWYG solution that allows players to aim directly at what they are seeing. But the price is an aggravation of the effects of latency when a player is under fire: not only does their own latency play a part, but their attacker's too. In many situations this is not noticeable, but players who have just taken cover will notice that they carry on receiving damage/death messages from the server for longer than their own latency can justify. This can lead more often to the (false) impression that they were shot through cover and the (not entirely inaccurate) impression of "laggy hitboxes".[2]

Make clients extrapolate

A third lag solution is to do nothing on the server and to have each client extrapolate to cover its latency.[3] This produces incorrect results unless remote players maintain a constant velocity, granting an advantage to those who dodge back and forth or simply start/stop moving.

Extended extrapolation also results in remote players becoming visible (though not vulnerable) when they should not be: for example if a remote player sprints up to a corner then stops abruptly at the edge, other clients will render them sprinting onward, into the open, for the duration of their own latency. On the other side of this problem, clients have to give remote players who just started moving an extra burst of speed in order to push them into a theoretically-accurate predicted location.

Design

It is possible to reduce the perception of lag through game design. Techniques include playing client-side animations as if the action took place immediately, reducing/removing built-in timers on the host machine, and using camera transitions to hide warping.[4]

"

Jcap wrote:

I apologize if i come off as harsh. I'm just passionately disagreeing. If you guys had made a crappy game i wouldn't care, so please take this as evidence that I enjoy it and appreciate the work you've put into it. but please please prioritize desyncing, I genuinely feel that it is worse than you think it is.

Thanks Jcap - this is the sort of post that I'm more than happy to directly address - at least, if I have something useful to offer (which, as far as the desync goes, is very limited from a technical perspective but I can offer some input on points you've made until Chris addresses this issue fully).

As Chris said, we are rapidly approaching a place where we can be free to address the desync issue. I understand what you're saying about being willing to have the servers down for a day or two but if you can understand from our perspective - the numbers that are complaining about desync, I think it's quite safe to say, will utterly pale beside the numbers who will complain - a lot more vocally - if we took the servers offline for a significant period of time.

Before anyone takes what I've said out of context I will reiterate that the number of desync complaints has no impact on our prioritisation of the issue - it is of primary importance no matter how many or how few complain about it, so please be assured that we are giving it as high a priority as it is sensible and within our capability to do so. (Naysayers can nitpick my choice of words here but I mean no more or less than what I've said - I can't vouch for all of Chris' plans - I'm just the video and voice guy! - and our plans are necessarily fluid to adapt to other issues that are bound to arise - hence "sensible" and "capable".)

As for the desync issue being worse than we think it is, I can only tell you that your voices are heard in the many forum posts to date and we are not trivializing the issue in any way.

Chris is the final authority on this issue and I've said too much about an issue that isn't in my purview already so please look forward to his forthcoming post on desync!

Really really looking forward to that desync post then. This game is way more fun than D3 mainly because of its superior gameplay mechanics, but the desyncs keep me from further leveling up and I just can't continue this way.

Anyways, being a developer myself, I just wish you good luck and great success. I know how hard it can be setting up a fully functional network architecture in a small company.

"

Chris wrote:

If we don't have good sync improvements in the very near future we'll put a rate limited version of /oos back in.

As I mentioned before I'm writing up an explanation of how the system works, what it's for and what we can improve.

Alright, that's very good to hear.

"

Attack wrote:

various methods

I seem to remember rewinding time being fairly popular?

K BACK TO POINTLESS BICKERING

"

anubite wrote:

I play the game @ 300 ms perfectly fine.

How do you avoid dying to screens full of cobras on Merciless? >_>

"

tl;dr about how projectiles aren't always linear

If they're deterministic then you just need to send the appropriate information to generate the deterministic projectiles, is my point. That is, generally, not very much. Note that PRNGs are still deterministic.

I agree that you do need to keep track of the "missing" of the target, which relies on the server-side positions of things, which are frequently quite different from their apparent positions. So, we go back to the original problem here.

"

tl;dr about poll loops and auras

It doesn't have to check for gem removal every frame because removal triggers an event. Nobody does poll loops for that sort of thing, I hope.

Testing whether something is in a radius around a point is just (x-x_0)^2 + ... <= r^2, it's not like you're solving a PDE. This is not a practical issue for runtime unless you're doing it a lot or to very high precision.

"

Projectiles aren't the only thing that can grow very complex. Six summoners in a party ... against six summoners in an enemy party ... each with max minion counts? That's easily something like 250 minions and 12 players duking it out.

[/quote]

250 minions is annoying, yes. I am fine having sync issues due to amount of bandwidth required as there start being large numbers of mobs, that's expected. That is not the issue when I am fighting five monkeys near a wall.

"

POE instances are not capped at 6 players. You can have 2 groups of 6 players in cut-throat.

All the "instance full" messages I see beg to differ, it's 6 in normal play. 12 is still not going to kill performance unless you try really hard (see your previous example).

"

POE is not a game where there are hit-scan attacks like an FPS. Networking a game like POE is non-trivial, despite your attempts to paint it as such.

Ground slam is pretty much hitscan. It still doesn't work perfectly. It is, however, the only skill I use anymore, since it's quite predictable and large enough to give a healthy margin of error (click back, groundslam forward, almost certainly hit). There are also many FPS weapons which are not hitscan, like rocket launchers in every DM game ever.

I'm not saying networking syncing is trivial. I'm saying it's a problem that's been solved in a fashion most people find acceptable in many other games already, many of which are quite similar to this game (D2) and many of which have tighter sync and latency constraints (FPSes). Having a product with sync issues this major at de-facto release is quite irritating, even though the underlying game is good.

Since we're promised a post with actual information soon, augury isn't needed anymore at least, so we can postpone the rest of this until we have further information, yes?