Reduce multiple screen wide clear builds to 0 pls.
" The server handles calculations for moment to moment combat. Keeps track of poison stacks, calculates damage. Decides where a monster will move etc. MTX however is rendered client-side, same as stash tabs being pre-loaded when entering town. That's why racers use clean accounts with 0 MTX and extra stash tabs for best performance. The post you reference is four years old - the engine then and the engine today are not the same. " It's a tale as old as time. Someone knows a little about something, then makes up the rest. In reality, none of us have a remotely good understanding of GGG's server infrastructure. I take solace in knowing that none of this matters for how GGG will be going forward. There's no outcome where the devs would clap their hands and push a big red button labeled "Expedition 2.0" lol. The opposite of knowledge is not illiteracy, but the illusion of knowledge. Last edited by ArtCrusade#4438 on Dec 19, 2023, 10:49:26 PM
|
|
" It would help if they'd do such posts now instead of radio silence + new MTX. And yeah, that post clearly says they do drop server frames if they take too long, so individual session lags shouldn't affect other players. Last edited by Echothesis#7320 on Dec 19, 2023, 11:26:54 PM
|
|
|
I'm jealous of those 2 minute zone clear builds too, so yeah....Game performance!!!
I poop, therefore I am.
|
|
" ive been doing distributed systems for over a decade. in this field everything goes - you can pretty much setup your app in any way you wish, yet there are some rudimentary standards, esp when you are NOT major player that might dictate cooperation terms POE runs chromeless (no UI) clients that weight like 200mb each of peak allocation, language used i have no idea altho they spoke of C++ several times. it is mostly irrelevant (excluding cold start and object caching) because POE's instances are long lasting, it is not lambda type app. you can run dozens of them at the same time per 'node' (what is 'node' is a philosophical discussion, for us it is the smallest 'machine' a client can directly talk to. it is also used for billing. why it is philosophical - because there are layers and layers of virtualization, shared this and that, at some point it takes a phd to understand where the f.. actual 'node' is when your storage is in different rack and its replica in separate room. alas you can separate sessions (altho in practice there are some bits that are harder to do so - like NIC), but at a cost - now your instances are mostly fresh idle cpu cycles that you pay for yet they dont bring you money. you can do tiered sessions (idle, light, heavy etc) based on user history. you can also average it, assign fixed value and pray there are not too many outliers and if they are - there is a jitter of some form so the peaks dont collide if they do, you spin new nodes, move some sessions around (thats why you sometimes 'loose' your HO after trading). problem is - this takes time (unless you keep running pre-made instances at the ready, and even then cold start takes noticeable time) what is important - there is no practical limit on cpu power GGG can get from host datacenter. there are huge reservers. it is just a matter of money. if there is a will to pay, there wont be ANY lags (excluding issues caused by routing, big actor (very popular series on netflix == laggy games). but what people dont know - these nodes might LOOK cheap if you just briefly scroll AWS pricing, but these ADD UP like crazy. there is huge incentive to not overprovision because you really can see black once bills arrive also - most likely stash, definitely item generation and account management are separate and probably centralised (the same for ENTIRE realm, not replicated per each datacenter). it is single point of failure but GGG manages this part really well so far - i remember just few collapses, impressive result as for the calcs - DoT's are cheap. what is VERY expensive is distance calc, esp if they try to do that in circles (but in fact they cheat and that circle is kinda sum of few squares - all to keep us away from float/double arithmetic) why all that? because once you introduce a build/item/league mechanic that tries to fit into one fixed time slot more calculations that are possible (you can kinda precisely predict the upper limit) you start to briefly start cinebench on every node you have every few seconds. once it starts happening too frequently you get a sudden collapse because orchestrators start doing stupid things that are overreaction or too late or both GGG devs know this. they most likely simply assume there wont be enough such builds to cause visible problems. kinda doesnt work when people play builds that tick all the 'dangerous' boxes in a league with very tanky mobs :) oh and MTX are in fact huge part of this issue, most 'skill mtx' are in fact separate skills, mostly done in a hurry and they actually work differently (sometimes impacting gameplay - as in - MTX versions are better, GGG fixes known cases tho). all MTX needs to have to GREATLY impact performance is doing some calcs like 'mobs in radius are highlighted in different colour'. this most likely (as all other gameplay calcs) happens server-side adding up to existing calcs. then there is client-server feedback loop - when client lags, server kinda lags too, despite seemingly not needing to. you have to have some 'async' even in 'sync' setup otherwise it will all die horribly. oh and final bit - it is easy to confuse client side lag with server side lag, latency graphs are VERY misleading even for engineers because they tell you nothing more than 'symptoms', there is no 'cause' in these graphs. but if your HO latency graph look like mountain peaks while you cpu is 95% idle - yep, your instance sever-side is fighting for its life |
|
|
In absence of other contradicting evidence, inclined to agree that current lag/disconnect mess comes from overtuned/tanky league mobs in combination with a bucket of poorly tested new combat mechanics and their mtx versions. Sometimes I plain cannot return to my HO after doing trade, it keeps saying "failed to join any instances", which in my understanding means instance servers are at capacity and cannot even create HO for me.
|
|
" Thank you for the insightful post! I'm an IT worker myself but software, so getting a glimpse at this kinda stuff is very interesting. :) The opposite of knowledge is not illiteracy, but the illusion of knowledge.
|
|
" That makes no sense at all. The client knows what mobs are within your field of view, which is the only thing that matters when it comes to MTX. It's an entirely client-side problem. The only work the server has to do is in informing the client what mobs are where and what skills are where; the complete terrain map of the area is very likely transmitted at the start, not piecemeal every tick as you move around it. If the client knows what the terrain map looks like, and is updated on where everything is supposed to be within that map, it can render it however it needs, with whatever MTX it needs. Communicating what MTX is attached to what other players in the area and perhaps a timestamp for it so all clients see the same animations and hear the same sounds from it at the same time, with pet MTX maybe also having some additional position information (though even that shouldn't technically be necessary if you just have its relative position to the player play through a large loop and know the starting time for the sequence), should be all that's required. Fairgraves was a slave trafficker specialized in the kidnapping and transport of children. He was not "a good man".
|
|
|
you do not transmit 'map', you just send the seed value. both client and server know how to unwrap it into the same map, no need to transfer lots of data if you can transfer one number and have it generated on the spot. client-side resources are 'free'
as for the MTX a) you do not create exceptions if you can avoid it. new code for new case is new source of problems. you reuse as much stuff as you can. mtx included. mtx frequently are caught (and most likely even more times are not caught publicly) to behave differently. they are not simple re-skins. Ethereal Knives skin had longer range, it was NOT just visual, similar case with some other skin not that long ago (in 3.23). these things are server side b) latest mtx displays mob positions on a map. no sane developer will allow this to run client-side, it is like wall-hack but easier. it is definitely done server side and client is TOLD to disclose precisely what servers allows it to disclose. this is the reason POE struggles with load times and stutters. some resources are preloaded but at least some part of them is loaded when server tells client to load them. that prevents malicious party from reading loaded resources and determining if map is 'worth it' or not client all it does is look pretty and MAYBE does the sound. but i have zero experience with how sounds in multiplayer games are handled so wont speculate. on the other hand, i wonder what % of current gppk size is exclusively MTX, my guess is way above 50% |
|
" And this is exactly what I was saying earlier....this isn't a SECRET. These are fixes and data that GGG has released to us many many many times in the past. "blahblah mtx was causing server issues due to xyz". It is a frequent occurrence in hotfixes. |
|
" You would need at least some sort of identifier for the map area, plus the seed value to feed into your procedural map generator. Alternatively, and more flexibly because it doesn't require the client to always incorporate pretty much the entirety of your exact current version of map generation code, you would send the map information in the form of a grid of numbers indicating which tile piece to use and how to orient it, and the client would do the rest. In either case, your client is getting that information up front when loading into the instance. " A new "case", as in a new use case, necessitates new code to handle it, because a new use case, by definition, means new logical requirements. If it's just an existing use case but repackaged, that's where it helps to have separate layers to your application, like separating your business model and logic from your UI, and both of those being separate from your persistence layer. That's how you avoid repeating yourself and how, when something goes wrong, you avoid having to fix the same bug in half a dozen different places. You don't just say "well users exist, and orders exist, and products exist, so I'll just put them all in the same database table as if they're the same things, reusing the same columns for completely different semantic properties across the different entity types, and just treat them the same for all these use cases, and just hack around the differences in the UI", unless either there's some really compelling performance critical justification for it and the shared logic just so happens to work out, or you are a moron who shouldn't be writing any code, because those are semantically very different things which almost certainly require very different logic around them. " That's precisely why you separate the mechanics, which are server side, from the visuals, which are client side. You can vary them independently, so it doesn't matter what MTX the client side team comes up with, the server side just has to do the same calculations. " Then POE is pay to win. Cosmetics are supposed to be precisely that: cosmetic. If they change things mechanically, then they aren't cosmetic. " What MTX does that? Are you referring to the detect evil ability of the warlock? Because that's not MTX, that's an actual ability. If you're referring to something highlighting things on screen, or even just a bit off-screen, that's already information the client gets from the server, it needs to know about that stuff so it can render things appropriately. " Sure they will, but it's a tradeoff if we're talking about information the client doesn't normally display. By providing the client with more information than it would normally display, you potentially save on the amount of work required on the server side, but you risk some people being able to gain an unfair advantage by either modifying the client or peaking at its memory, which might then require mitigating that risk with some sort of anticheat solution. " That has nothing whatsoever to do with MTX. Haku in intervention popping up in my map is the same whether he's dressed normally or I've got some MTX on that makes him appear as a ballerina; there should be zero impact on the server for something cosmetic like that beyond perhaps some small bit of extra data sent to other clients in the instance so they know the MTX is active and maybe some simple timestamp or tick count so they can synchronize any animations or sounds for it with the mechanical information they're getting from the server. " Sounds and animations are handled the same: server provides client with where things are, what they are, and timing information to keep things consistent across different clients and sync'd up properly with the mechanics, and the clients handle converting that into the appropriate sights and sounds. " Wouldn't surprise me, and that just means the client is doing most of the work. Fairgraves was a slave trafficker specialized in the kidnapping and transport of children. He was not "a good man".
|
|
