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.
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.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.
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).
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).
Why is everyone circling around the fact that many players LEFT because there is no AH?
does it really matter what the system is named to you?!
Just think of what kind of marketing tool it would be if SE could announce that now we finally have an AH!
There's not that many things SE can do to win those players back especially since creating one dungeon takes 7 months.
The potential of an AH is far greater than just what happens in the game.
no MW, no MW, AH please. XD
Sounds like the hymn of the French Revolution.
"Forward, children of the Auction house, it's time to overthrow the decadent retainer bourgeoisie!"
Been singing that for months now. Time to burn some witches.
Ah, sweet golden memories...If you were very quick you might be able to dodge the whole mess by running like mad from one end to the other and by the time the server caught up you were through the congestion, but hesitate a moment and you would get pinned in the mob.
Last edited by Rinsui; 06-20-2011 at 06:32 PM. Reason: Typo
Add an auction house just like in FFXI, and remove the AH purchase history for all items.
its worked in World of Warcraft for many many years and it still works perfectly.
Items are sold based upon the time it takes to farm them and supply and demand.
LOOK SE! I JUST SAVED THE ECOMONY!
i'll never understand what they were thinking putting in a history in a virtual economy full of undercutters, what did they think was gonna happen? lol
|
![]() |
![]() |
![]() |
|
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.