Ryandor.com

You?re lagging the client with static items?...

Pretty hard to do, I?d imagine, given the state of modern computers running such a primitive application.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Enough items in the same location - like for instance a huge 5 story building with lots of decorations and lights - will slow the client down, especially on computers that aren't "top notch" - and curiously enough there still seems to be quite a lot of people who don't follow the latest trends/spend all their cash on the latest and greatest at any given time

_________________
-= Ho Eyo He Hum =-

I think most of those people are the ones without jobs. Everybody else has at least a 1ghz now days!

I suppose you could argue that a large percentage of the UO emu population are those whom do not have jobs, though?

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Sydius: believe me you can lag even the newest OSI client very easily with a 5 store building and i am talking only basic decorations , no animated tiles (with animated tiles you will be hardly able to move).
The first version of Avalon we had it with animated water.. needless to say it was a disaster.. so we had to delete it and replace it with static one. Even so the lag is quite noticeable even on 2Ghz+ machines.. and especially in the upper floors..
The LAG on the building sphere is another story.. you can move with speed of 1 tile per about 5 seconds

Also Light and Animated tiles seem to LAG the client very easily , we had only a one store building with lots of lighted tiles (lava tiles as a floor) and it lagged pretty much until we changed those lava tiles with normal floor (not radiating light).

P.S. Why i can't edit my posts? I have to post few times to add something

Have you tried with an older 2D client? They were a lot less lazy about optimizations years back.

Then again, it was never meant for things like that, anyway.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Yes of course , our main client is a modification of a 2.0.0 2D client, we don't support 3D at all. Mainly the newer clients are faster though..

Hrm? What video card?

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Id have to agree. Animated tiles and very large buildings just lag. We have a great pc running our shard. But you throw in a 5 story building and you will lag some. Even when we played on OSI if you were on 56k and you ran up to a large tower you usu. froze up. Its not just the machine its being ran on but the people connecting to the shard. You may beable to run up to a 5 story building with water flowing from all windows and not miss a beat. But a player may run up and freeze to where you have to pull them away. We have started keeping buildings under 3 story if at all possible. And animation.. usually we mix a little with non animated tiles and so far so good.

Lady: No, when you run on a tower on OSI , it is filled with items that are on the server.. Meaning in order for the client to show them, it needs to download the items from the server first (that?s why it matters if you are on a 56K connection) and then also show them.. Not to mention there are surely other variables that add to the Lag (as when building on the sphere it lags way to much and locks the client if you teleport to a place with a lot of server side items).
Now the LAG because of client side items (those in statics) is experienced purely according to the user machine.. Its all the same if he is running on 14.4Kbs modem or T3 connection , as the communication with the server is minimal (that is to assume all the decorations are in the statics).. That goes to say also that it doesn?t matter what PC the server is running on, as far as it won?t lag in the open , it will never add to the LAG inside huge buildings.
The graphics card has no effect whatsoever or to be more specific a very small negligent effect, as the client does not use any advanced features of the card.
Either way , the main rule in building maps is to never build more than 3 floors.. At best only 1 floor if it is a dungeon and you plan to have a lot of people fighting NPCs at the given place.. and never build anything with lots of animated tiles, even 100 (which is a 10x10 square) animated water tiles on a 1story area LAGed the client pretty bad.
As I saw someone saying on this board OSI had a better britain at first.. My guess would be they cut it down mainly due to client LAG (in those days most people hardly had Pentium 1).. So even an extra basement would LAG the hell out of them.

That is not entirely accurate. UO does take advantage of hardware acceleration, and having a video card with more RAM will dramatically decrease the kind of lag you are referring to. Basically, all the graphics have to be sent from regular RAM to video RAM before they can be displayed? but if they are already there (in other words, there is enough RAM for them to stay there), it saves the VERY costly transfer.

Probably any modern card has more than enough RAM to ?overkill? that problem, though. I remember upgrading to a video card with 32 megs greatly decreased my lag, however.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Yes thats why , of course if we are speaking about very old cards then there is a difference (the best you can see trying to run UO without graphics drivers installed). What i meant was that it doesn't matter if you have a GF2 (which is the bare minimum of anyone who plays any kind of games) or ATI 9800.

Not necessarily, I still have my old Voodoo card in my personal computer. It will not play The Sims 2, but it will work just fine for most any other game in which I am interested. Like I said before, though, many UO players, and especially those working on emulators, are poor and have old machines.

I have never personally experienced a lag such as that you speak of, but then, I suppose it is possible for me to have never been in a situation such as that. I do wonder, though, about the 4-story mutli towers? Why do they not lag, except during the transfer of the dynamic items over the network? Would an equivalent building in the static file cause more or less lag? I would have thought less, but I know I have never had a problem with much overloaded towers since I got a cable modem.

Perhaps multis have some built in optimizations since they knew they would be so common. On the other hand, perhaps, it is simply a matter of the offset and lookup? much faster to look up an item in a multi file than in the main static file.

Somebody should test this ? place a multi tower and cram in a thousand items, and then do the same thing, but static, and see which lags the client more (removing network lag, of course).

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Its no problem to lag klient with building in statics. Client doesnt like many items and especially floors, try to make something with five floors and base 40*40 and you will lag even on 1ghz + machine. Add some decorations or animated tiles, add lighting sources and 2,4ghz machine will lag.
UO client is very bad programmed (according to our top programmer, who disasembled it, becase we wanted some special features) and no cpu cant save that. And grafic card makes no difference, uo client is not designed to use them. Even the newest clients are not friendly to huge buildings.
I think, on our shard we pushed client graffic limitations to the maximum. But price fot that is that you need at least 1ghz machine, to have smooth most of locations. People with junk like 300mhz have troubles.


If you dont beelive, log on Endor and try Avalon:

http://screens.endor.cz/gallery/screenshot066.html
http://screens.endor.cz/gallery/screenshot067.html
http://screens.endor.cz/gallery/screenshot071.html
http://screens.endor.cz/gallery/screenshot068.html

Cpu, on which Avalon running smoothly doesnt exist

_________________
Endor Team leader, visit our web site:
http://www.endor.cz/index-en.php

One appendix. If you make something like i described above, direct on the server from tiles and not freeze into statics, you will lag 50x more. Even 100mbit bandwich can save that, its how client handle with statics and "free" tiles.

_________________
Endor Team leader, visit our web site:
http://www.endor.cz/index-en.php

2sydius: already tested

Slowest are buildings/decorations on the server builded from tiles.
Faster mul houses.
The fastest are items in statics. Unfortunately its not enough.


PS: I would realy appreciate edit function

_________________
Endor Team leader, visit our web site:
http://www.endor.cz/index-en.php

Sydius: There is no way a tower (multi one) filled with server side items can lag less than a statics counter part.
The tower itself is considered as one server item (lets say you have a lot of items spread on its floors.. lets say you even have 10x10 items on the floors.. that still makes about 100 items per floor -> about 500 items TOPS per tower.. which is still in the range of non problematic (even on server side)..

500 is very easily reached with a 20x20 building of just one floor , with no decorations whatsoever (400 items below , 400 items for the ceiling , and some 60 items for the walls). You see it is not the decorations that make the lags... but the skeleton of the building itself... so it doesn't really help reducing much decorations (other than carpets.. those are killers as well) .. decorations usually make a mere 5-10% of the item count.. even though they apear to be much more.. so it is safe to add the decorations as server side items in one to two story buildings... again with the exclusion of carpets.. those should be in statics.

Demostenes: You completely misunderstood me, and your top programmer should be fired if he is making assumptions such as that based solely on disassembled assembly. I am definitely not defending their programming, but you cannot judge a cow by what it looks like when you put it through a grinder and then spread the entrails out on the floor. It may not be fast, but it may be well coded, for all we know.

TheChosen: I was not implying that decorations are what lag the client. I was simply stating that the tower should be filled with items to simulate a higher item count. Take each tile that makes up the 4-story multi tower + 1000 more items inside. In one test, make the whole thing static (rebuild the tower one tile at a time, and then freeze it), in the other, use the multi and leave the items inside dynamic. Test both on a local server, to eliminate network lag. See which one loads more quickly.

I have a sneaking suspicion that multi buildings may indeed be faster client-side, since loading them and displaying them is technically less jumping around for the client. Slightly more math, though? Hard to say, but I bet it is close.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Hmm , you may be right at the 'loading time' of the tower.. since it is faster to the client to read from the HD the tower whose items are stored one after another in some file.. but slightly less to read anything else from the verdata.. however once this is loaded (and usually in a radius of about 1.5x screens).. the main LAG experienced is due to the items per screen , not their loading from the files.
So my assumption would be that multis will behave exactly the same as statics (as multi is basicly all statics but the one server item telling the client to show a specific set of statics).
More to this, from experience running around multis has always lagged me way more than running around buildings of similar item count in the statics... eitherway server side items means a lot more LAG.. (with this i don't mean the multis.. they are one item only and practicly it does not make a difference if they are in statics or not).

But to summarize.. i don't really see a practical difference to all this. The map is most beautiful when it is built of unique items , and building it from multis while maintaining uniqueness would mean a LOT of multis. We do use a lot of multis (about 150) .. but as sold homes for players.

The only conclusion i have is simple .. build as much as possible into the statics (decorations too).. make minimum on server side.

My reason for that question is simply this: I have frequently been around some much over-filled towers in my time, and never experienced any such lag. By ?over-filled?, I mean every tile of every floor with at least one and often up to four or five items on it. Back then, it was popular to carpet your floor with dyed cloth. Since I never experienced any lag (other than the initial network traffic), I was wondering if perhaps there might be a difference.

Another consideration could be server-side collision detection. Do you lag no matter what you do (such as opening your spell book), or only when you move while in those areas? If it is primarily happening when you try to move, it may very well be the collision detection.

I know from personal experience that many UO emulators (if not all), must load and look at all the tiles in a radius around the player, including all floors. This is a very slow process? the bane of many server-writers (since people walk more than anything). Network flow might be fine, but if the server has to load and check many items every time you move, that might be some of the problem.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Sydius: The server collision is out of question

1) it would most likely lag the whole server
2) it would mean the lag is the same in first floor and 6th floor... which is by no means the same. In 1st floor in avalon i move with no problems, in6th i move with speed of 3 tiles per second.

As to why you have experienced no lags close to filled towers? I think even a full packed tower is not filled enough.. not nearly enough with the number of items that it takes for a statics to lag.. Not to say that from experience i even think the client handles worse the multi than the statics.. there is some kind of a LAGy feeling when around multis..

True. I suppose you're right -- rendering lag. Still hard to believe, though.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Back in the day you would not lag while running past towers with millions of items it them for the simple reason that the original UO designers set it to were the items did not load till you hit the front door step, then you payed the price.

The z elevation thing if "VERY" true and the higher you go the worse it gets because the client has to draw every single z level even if its not being used by a tile. So a 36 x 36 screen size lets say would with one single tile at 15z elevation the client would draw every single layer of 36 x 36, 15 times to stack all the items correctly. Thats why it gets laggier the higher you go.

Take a boat ride across the map at 20z then another at 70z and you will see what I mean. It increases exponentionally with each layer.

I currently use 1 gig of memory with a ATI 128 all in wonder and still have video lag in the newest client because now they load everything as you appear on screen except for items in chest which are loaded after hitting the steps.

It takes about 2 seconds to load my house after recalling into the front lawn in the real online UO. Its a 4 story 18x16 packed to the gills.

There have been custom towers in swamp areas with those stupid "Ice Staff's" stacked up glowing every where that have actually crashed my client before. 10,000 staves stacked in one location in addition to all the other garbage normally found in a home can do some damage.

Dev

_________________
"So...if crazy people don't know their crazy...does that mean your only sane if your know your crazy?"

"Guess she knows nothing." Even though Ive been building for 5 yrs.

Guess I can say.. you got lag thats your problem. Ill just keep my mouth shut from now on

who says its a problem? we got lag in 0.0001% of the map (which server no other purpose but show we took the map building seriously).. 0.001% of the time (we got a dual proc server).. just theoreticizing for future builders in case they want to avoid lag in their maps.