But the server itself is still flooded with hundreds of retainers at once. So, no, unless they break it up into completely separate servers, it doesn't help.Curving or augmenting the area will help, you are not looking at the problem rationally to understand that. Retainers could be placed behind stalls if being freely placed is some sort of issue. It solves scalability and stability because the server isn't flooding your client with hundreds of retainers at once, as players and retainers a few sections away don't get sent.
I think we might be talking about two different things and that's where our confusion comes from.
The server itself will having hundreds if not thousands of objects that it handles, where each object is a retainer, player or something. If you are writing smart code then all these objects get grouped based on their position.
So, let's say, the Mason Wards are broken now into ten sections. Each section can handle 50 retainers allowing up to 500 retainers for that entire area. But the client tells the server, "Hey, I'm in area 1", and the server now knows that 450 of those retainers are not relevant to you, only those 50 in the same area that you're in. Now the server doesn't have to work quite as hard.
And if you want to handle 1000 retainers in one ward, add another ten sections.
But the server is still f'ed in the a'. . . Even if it doesn't send the info, it still has to track it.I think we might be talking about two different things and that's where our confusion comes from.
The server itself will having hundreds if not thousands of objects that it handles, where each object is a retainer, player or something. If you are writing smart code then all these objects get grouped based on their position.
So, let's say, the Mason Wards are broken now into ten sections. Each section can handle 50 retainers allowing up to 500 retainers for that entire area. But the client tells the server, "Hey, I'm in area 1", and the server now knows that 450 of those retainers are not relevant to you, only those 50 in the same area that you're in. Now the server doesn't have to work quite as hard.
And if you want to handle 1000 retainers in one ward, add another ten sections.
ETA: Oh, and it's presently all saved on one physical server, so your idea doesn't help the server at all, unfortunately.
Also, this is assuming SE writes 'smart' code, which given their excuses about why they can't change X or implement Y (or even alter existing code in a timely manner) would be a very bad assumption to make...I think we might be talking about two different things and that's where our confusion comes from.
The server itself will having hundreds if not thousands of objects that it handles, where each object is a retainer, player or something. If you are writing smart code then all these objects get grouped based on their position.
So, let's say, the Mason Wards are broken now into ten sections. Each section can handle 50 retainers allowing up to 500 retainers for that entire area. But the client tells the server, "Hey, I'm in area 1", and the server now knows that 450 of those retainers are not relevant to you, only those 50 in the same area that you're in. Now the server doesn't have to work quite as hard.
And if you want to handle 1000 retainers in one ward, add another ten sections.
I don't think you quite understand how server-client communication and programming works. The current method that's available now, where only the retainers next to your character are rendered, is exactly what you're suggesting. It doesn't help, because your client isn't the only user that the server needs to handle requests from and because all that information STILL needs to be processed. You're increasing the amount of data transfer between server and client hundredfold when you have to start rendering things and when you're moving your character through a zone.I think we might be talking about two different things and that's where our confusion comes from.
The server itself will having hundreds if not thousands of objects that it handles, where each object is a retainer, player or something. If you are writing smart code then all these objects get grouped based on their position.
So, let's say, the Mason Wards are broken now into ten sections. Each section can handle 50 retainers allowing up to 500 retainers for that entire area. But the client tells the server, "Hey, I'm in area 1", and the server now knows that 450 of those retainers are not relevant to you, only those 50 in the same area that you're in. Now the server doesn't have to work quite as hard.
And if you want to handle 1000 retainers in one ward, add another ten sections.
Adding the amount of zones that are available in the market wards means one of two things: they add more servers or they increase the load on available servers. The former costs a lot of money, becomes harder to maintain and recover in case of outage, and becomes harder to develop for (spreading out a service over multiple machines increases its complexity in terms of software design). The latter is what we have now.
A server that has to process graphics, players, and item transactions can handle a few hundred concurrent users. A server that only has to process item transactions can handle tens of thousands. There is only so much "smart code" can do (and rendering retainers is not smart code in any way, shape or form).
|
![]() |
![]() |
![]() |
|
Cookie Policy
This website uses cookies. If you do not wish us to set cookies on your device, please do not use the website. Please read the Square Enix cookies policy for more information. Your use of the website is also subject to the terms in the Square Enix website terms of use and privacy policy and by using the website you are accepting those terms. The Square Enix terms of use, privacy policy and cookies policy can also be found through links at the bottom of the page.