Stop "fixing" the MW scrap it

[normalforce]

No, a solution that fixes scalability, stability and usability. This has nothing to do with my feelings. Stop pulling red herring fallacies.

Curving the area won't help, because the server still needs to maintain and process all of the information needed for rendering the retainers (as well as player character movements and actions). Retainers are also still freely placed in the wards. So this solution wouldn't address scalability or stability; and fix some usability issues while simultaneously introducing other usability problems.

Buying directly from the menu would be the ultimate usability problem solver, but again, it will do nothing for stability and scalability.

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.

[Viridiana]

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.

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.

[normalforce]

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.

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.

[Viridiana]

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.

ETA: Oh, and it's presently all saved on one physical server, so your idea doesn't help the server at all, unfortunately.

[Kiroh]

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.

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...

[Wolfie]

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.

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).

[Wolfie]

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.

The client is not the issue here, it's the server. Servers are not bottomless pits of storage and processing power; it's why wards are limited at just a few hundred retainers, and it's why they have massive stability issues. Scalability and stability issues are server related, not client related. Curving the areas does NOTHING to alleviate the load on the servers, only the load placed on clients by limiting the amount of graphical information that's being processed at any given time.

Which, by the way, doesn't really matter because they already have a very good policy in place to curb client side issues with this. Retainers that aren't in the immediate vicinity of your character are not rendered (but the server still needs to process that information).