76 réponses à ce sujet

[Jenna WSI]

I have an area that's quite laggy, and I'm not sure why. I thought only the animated plcs caused much lag, out of the CEP stuff.

[Jackal_GB]

All placeables can cause lag if you use too many of them. Check out Red's "Jungle Village" prefab on the vault to demonstrate lag vs placeables.

[Jenna WSI]

Do any create more lag than average?

[Jackal_GB]

Placeables and creatures with high poly counts can cause the most. In other words, the highly detailed models require a lesser number to cause lag.

Modifié par Jackal_GB, 19 décembre 2010 - 05:37 .

[Fester Pot]

Avoid using some of the new trees added to 1.69. They cause nasty hiccups, like horses do, due to their high poly count.



FP!

[Jenna WSI]

I didn't use 1.69 plcs, just CEP. The CEP trees may be the issue though.

[Frith5]

It's been recommended that one avoids putting down placeables on grid lines, as this causes lag too. So, if you can avoid crossing a grid line with your placeables, do so.



Regards,

JFK

[Frith5]

oops, double posted.

Modifié par Frith5, 19 décembre 2010 - 04:04 .

[TheSpiritedLass]

From the 1.69 Lexicon tutorial done by Funky called "How to Make Your Server Run More Smoothly" Basically what has already been said in this thread with a little more detail.



"5. Review Placeable Use in Your Areas



Aside from massively bulking up the size of your area files, using lots of placeables can come with other risks. Most importantly, you do not want to place placeables with walkmeshes across tile boundaries. A placeable with a walkmesh is one that characters cannot freely move over - think furniture, not carpet. The reason for this is that the pathing system uses these tile boundaries, and blocking access to them with placeables generates blocked pathing calls, which are enormously expensive. So, you can break this rule when spawns will not be crossing the space in question. We also break it in order to allow our PCs to summon walls via spells, but it is very pricey to do so. Pathing lag is entirely server lag. Another issue to be aware of is that putting many placeables together in an area can generate both massive graphics and server lag. Graphics lag, because more places mean more polys for the client to render, and server lag, because the server loads the description of all non-static placeables when they enter PC perception. Piling a few hundred placeables into a small space can cause enormous load, especially if players are repeatedly moving in and out of perceptual range."

[Eradrain]

Setting placeables to static functionally makes them part of the tileset, as far as the game is concerned, which drastically cuts down on lag. You should be setting every placeable you don't directly want the player to interact with, to static.



Also avoid putting placeables on the red lines where tiles meet, because the game thinks it has to load them twice (or four times, if you put it at the intersection of four tiles).

[TSMDude]

Eradrain wrote...
Also avoid putting placeables on the red lines where tiles meet, because the game thinks it has to load them twice (or four times, if you put it at the intersection of four tiles).

I completly agree on the first thing you posted but am not sure on this as I have heard it more than a few times and think this might be false. This was even pounded into me years ago by another builder but in very generic testing I do not think this is true....

(Not attacking just asking if anyone knows if this is indeed true as I think not crossing the grid lines is more due to pathfinding than anything else.)

[Fester Pot]

It's not false.



BioWare was the one who mentioned this to the builder community on the old nwn.bioware.com forum. From what I recall, it has to do with how the placeable itself is processed by the area/engine. If it's off the grid line, it's processed once. If it sits on a line, it's processed twice. If it sits on a +, it's processed four times. Pathfinding becomes confused and generates a hiccup as it calculates how to get around it, in terms, lag for the player.



FP!

[Eradrain]

TSMDude wrote...

I completly agree on the first thing you posted but am not sure on this as I have heard it more than a few times and think this might be false. This was even pounded into me years ago by another builder but in very generic testing I do not think this is true....

(Not attacking just asking if anyone knows if this is indeed true as I think not crossing the grid lines is more due to pathfinding than anything else.)

It's worth bearing in mind that isn't a gamebreaking concern, it's an issue of efficiency.  The difference between 1 placeable and 2 isn't that great.  Even the difference between 1 and 4 is only three placeables, and when an area can (on my computer at least) load comfortably with half a thousand placeables in use, that doesn't make much of a difference.

It begins to become an issue when a builder who doesn't realize this ends up placing dozens, maybe even a hundred placeables, along grid points.  Suddenly your game is mistaking that half-a-thousand-placeable area it's trying to load for one with 800 placeables, and that's too much, and the game crashes, or shudders to a near-halt.

So it's not surprising if people have deliberately tried testing this and found that there wasn't any change in performance.  Placing 2-15 placeables along grid lines isn't gonna tax your system any more than having 4-30 placeables placed correctly.  It becomes an issue when you vastly increase scale.

[FunkySwerve]

Eradrain wrote...

So it's not surprising if people have deliberately tried testing this and found that there wasn't any change in performance.  Placing 2-15 placeables along grid lines isn't gonna tax your system any more than having 4-30 placeables placed correctly.  It becomes an issue when you vastly increase scale.

For load times, thatmay well be true - I know little about that. For pathing, it's a different story. There used to be a running joke on HG that you could tell when someone was in the drow areas (with atrocious placeable placement) because of the noticeably poorer server performance. Frankly, it had never occured to me that placing across gridlines would increase loadtimes - I guess I never noticed, after factors like area size and placeable count in area, which, so far as I've ever noticed, have a far greater impact on load times (that is to say, an impact I HAVE noticed  ). Anyway, we still get away with some atrocious placements (especially with our epic wall spell), but the performance hit from it is very noticeable, even on a small scale (10 critters scrambling against some 30-40 spawned in blocks is ugly). As servers improve their performance, though, this is becoming less of an issue.

Funky

[_six]

Also bear in mind that on certain video cards introducing a texture onto a placeable that is greater than 512x512 in size will cause quite large framerate drops if there are more than one in the scene. Not sure why, but it does so on my graphics card quite nastily when having larger textures on placeables even though I can get away with 1024x1024 or greater on creatures, items or tiles quite happily.

[FunkySwerve]

_six wrote...

Also bear in mind that on certain video cards introducing a texture onto a placeable that is greater than 512x512 in size will cause quite large framerate drops if there are more than one in the scene. Not sure why, but it does so on my graphics card quite nastily when having larger textures on placeables even though I can get away with 1024x1024 or greater on creatures, items or tiles quite happily.

Interesting. I'd never heard about this relating to textures, only overall model size. Here's the relevant blurb from the same tutorial:

Avoid Using Lots of High-Polygon-Count Models

Some placeable and creature models in the toolset are composed of a high
number of polygons. This means that it requires more effort for graphics cards
to render them, and that they take up a larger chunk of NWN-cached graphics.
Some, like horses, are so large, that they practically render NWN’s caching
ineffective, and result in a great deal of graphics lag for players. A typical
horse model is around 14 megs, and the entire default cache is only 16M. Players
can increase their caching to 32M or even 64M in their .ini files, but only very
high end computers are improved by the 64M setting, meaning that for most
players, using horse models eats up roughly half their entire useful graphics
cache or more (most don’t even know to edit their .ini past 16, in our
experience). Other models are not quite as high-poly, but should still be used
sparingly. The CEP has a number of models of this type. You can judge the
relative sizes of different models by looking in the haks/bifs at the .mdl
files. The lag resulting from using too many high-poly models is, of course,
graphics lag.

I'd be curious to learn anything you might know on the subject beyond what you posted already. Perhaps the correlation is simply that the texture size is increasing the overall model size?

If anyone is interested in how to increase their caching, there are instructions here, under Configuration Tweaks/Cache Size:
Click Me!

Funky

[Eradrain]

FunkySwerve wrote...
 after factors like area size and placeable count in area, which, so far as I've ever noticed, have a far greater impact on load times (that is to say, an impact I HAVE noticed  ). Anyway, we still get away with some atrocious placements (especially with our epic wall spell), but the performance hit from it is very noticeable, even on a small scale (10 critters scrambling against some 30-40 spawned in blocks is ugly). As servers improve their performance, though, this is becoming less of an issue.

Funky

It's worth noting that area size creates more lag BY FAR than anything else talked about in this thread.  You will create more loading- and game-lag with one disgustingly big, placeable-free 32x32 area than you will with a small area loaded with a thousand poorly located placeables.

The number of polys in a given model, by comparison, really won't effect your performance at all if you're using a computer made anytime in the last, say, four years (Unless you really go overboard and use tons of them, of course).  I don't know for certain since I don't know the source, but I'd be willing to bet that the tutorial FunkySwerve quoted up there is probably pretty old - at least older than the technology we're working with today.  You shouldn't avoid good-looking models simply as a matter of principle; I think that hurts more than it helps because your server will be uglier, and NWN players will have lower expectations for what's good, and misguided conceptions of what affects server performance most.

Modifié par Eradrain, 20 décembre 2010 - 12:09 .

[FunkySwerve]

Eradrain wrote...
It's worth noting that area size creates more lag BY FAR than anything else talked about in this thread.  You will create more loading- and game-lag with one disgustingly big, placeable-free 32x32 area than you will with a small area loaded with a thousand poorly located placeables.

No, again, that's only true of area load times. Large areas have otherwise no real impact on server performance by simple virtue of their size- a common myth with roots, I suspect, in the absurd load times they DO have. By contrast, one small area packed with a thousand places could bring a server to a standstill, IF those places were nonstatic (because of players moving in and out of perception of them).

The number of polys in a given model, by comparison, really won't effect your performance at all if you're using a computer made anytime in the last, say, four years (Unless you really go overboard and use tons of them, of course). 

Not true at all. We avoid the horses with high polys for this very reason. They create huge hiccups as the model loads, and displace tons of other models in the cache.

I don't know for certain since I don't know the source, but I'd be willing to bet that the tutorial FunkySwerve quoted up there is probably pretty old - at least older than the technology we're working with today. 

Fraid not. I WROTE that tutorial for the 1.69 lexicon (as Lass mentioned above).   HG runs on very modern servers (we just transferred off of Amazon EC2 to a better setup, in fact, one devised by a professional in the field (acaos)), and caters to gamers with high-end computers as well as those with old clunkers.

You shouldn't avoid good-looking models simply as a matter of principle; I think that hurts more than it helps because your server will be uglier, and NWN players will have lower expectations for what's good, and misguided conceptions of what affects server performance most.

That's not what that tutorial advocates - it simply suggests using high-poly models sparingly, because they can easily crush performance. You can easily make lower-poly models that look good, and can still use higher-poly models - you should just be aware of the result. This has been playtested to the point of simple fact on our servers by players with all kinds of setups, new and old, over a period of years. Heck, a lot of the newest graphics cards perform worse with NWN than older ones because they're no longer optimized for what NWN uses. The cutoff for NVIDIA was the 7900 series, though players have been reporting improved performance with newer cards (400s, etc) when using CQ and/or NWSHADER - though I've yet to investigate the specific reasons for/truth of that as of yet.

Funky

Modifié par FunkySwerve, 20 décembre 2010 - 12:31 .

[Frith5]

Funky, I thought it was the animation data on those horses, and not the mesh itself, that caused the hiccups. Is that wrong? (I'm not contesting the 'cost' of higher poly models though; just if its more the animation on the horses or the actual polygons)



JFK

[_six]

FunkySwerve wrote...

_six wrote...

Also bear in mind that on certain video cards introducing a texture onto a placeable that is greater than 512x512 in size will cause quite large framerate drops if there are more than one in the scene. Not sure why, but it does so on my graphics card quite nastily when having larger textures on placeables even though I can get away with 1024x1024 or greater on creatures, items or tiles quite happily.

Interesting. I'd never heard about this relating to textures, only overall model size. Here's the relevant blurb from the same tutorial:

In my experience increasing texture size is more likely to bring you lag than increasing polygons - most NWN custom content doesn't even touch the tip of the iceberg in terms of what NWN can handle with poly counts. Rendering models is all about manipulating relatively small amounts of (admittedly complex) geometrical data, but the textures are almost always much larger files to begin with. That said, given that the problem I mentioned only seems to affect placeables to a noticeable degree I'd say its more likely NWN just has something very strange going on beneath the surface - and from chatting to peachykeen I get the impression the rendering engine is indeed far more convoluted than it should be.

Regarding the horses I'm fairly sure the animation is the primary issue, with the high number of bones on that skinmesh (NWN was never truly designed for skinmesh in the first place) and the fact that its essentially two full creatures being loaded at once. Something like the Q balor model is actually rather higher poly than the horses as I recall, yet I haven't had a single hiccup using it in the game so far, whilst horses drop my framerate from about 90 to a modest-but-useable 25 or so.

Incidentally, area size might be rather more of an issue than you might think. Using the standard Bioware tilesets you probably wouldn't notice a difference, but with more detailed sets upping the area size is dramatically increasing the amount of data needing to be processed each time the scene is rendered. Admittedly camera angle might have an impact, as well as fog (though don't forget that the models themselves are rendered a considerably greater distance further than the fog overlay's clipping distance), but it shouldn't be discounted as a factor. Plus big areas tend to become kinda generic and boring, as they often lose any sense of a focal point.

Modifié par _six, 20 décembre 2010 - 03:56 .

[FunkySwerve]

Frith5 wrote...

Funky, I thought it was the animation data on those horses, and not the mesh itself, that caused the hiccups. Is that wrong? (I'm not contesting the 'cost' of higher poly models though; just if its more the animation on the horses or the actual polygons)

JFK

Simple answer - I'm not an animator, and don't know. I've done over a thousand placeable models for CEP, but they were all ripped from bioware tilesets.  I've been told it's the size of the model cached that matters  - which would include anims and textures - that's why I asked six what I did.

What I do know is that those horses are atrocious in actual use - we had to turn down player requests to use them, unfortunately. I also know that I've seen similar issues with other high poly models wiht no animations to speak of, as mentioned by others in this thread. I had originally used the largest size of worm's lovely trees for our Rowan tree model in town, but had to downgrade due to player complaints. Yes, I still use high poly models, just sparingly (and in the rowan tree case acaos was the one who removed it, not me, at some protest on my part - the thing looks awesome).

Funky

[FunkySwerve]

_six wrote...


Regarding the horses I'm fairly sure the animation is the primary issue, with the high number of bones on that skinmesh (NWN was never truly designed for skinmesh in the first place) and the fact that its essentially two full creatures being loaded at once. Something like the Q balor model is actually rather higher poly than the horses as I recall, yet I haven't had a single hiccup using it in the game so far, whilst horses drop my framerate from about 90 to a modest-but-useable 25 or so.

I suspect your knowledge exceeds mine on this. The only thing that comes to mind that makes me question the relative import of anims versus polys is my experience with worm's trees - though I suspect they are big textures, by the look (no idea how the alpha would play into consideration). I don't recall them moving at all, so I don't think they have anims, though I haven't had the opportunity to place one in over a year, so I could be wrong. How does the poly count on one of those compare to the Q balor? The horse?

On the other side of the equation, we do use the Death God's Vault and a palace, both from NWN2, in one area, though one is far out of the bounds of the area. I seem to recall hearing a 50k poly count on one or both of those, which would be FAR above anything else, and I haven't noticed any real hiccups in that area. I don't know what the model size is on those, though I assume it uses a ton of textures (but no animations, I think).

Incidentally, area size might be rather more of an issue than you might
think. Using the standard Bioware tilesets you probably wouldn't notice a
difference, but with more detailed sets upping the area size is
dramatically increasing the amount of data needing to be processed each
time the scene is rendered. Admittedly camera angle might have an
impact, as well as fog (though don't forget that the models themselves
are rendered a considerably greater distance further than the fog
overlay's clipping distance), but it shouldn't be discounted as a
factor. Plus big areas tend to become kinda generic and boring, as they
often lose any sense of a focal point.

Interesting. I've little experience with nonstandard sets, though acaos did some extensive mods on ours that diverged from the cep's. I used to be a big believer in keeping areas small too, some years back, based on a bunch of stuff I'd read. It was actually acaos who pointed out to me that they had no impact on mod performance, so long as no one was in the area, which is, I think,  a common misconception. When players enter, of course the server is going to have to stream them the areas data, but I've yet to see that ever cause a hiccup, even when 10 players move into a 20x20 area near-simultaneously. It DOES take a while for the load screen, but seems to matter little to the server at large.

Anyway, after he told me that area size wasn't such a big deal on its own, I loosened my old restrictions on area size considerably - I used to try to keep to no more than 60-70 tiles, or around 8x8. We've seen no detectable performance hit from this loosening, though many areas wound up being close to twice as large (120 tiles is not uncommon). Granted, this has been over a long period, so a gradual hit would be hard to detect, but, at least with bioware/cep sets, there's no noticeable hit at all, either during load, or during play in these areas (and we're talking a LOT of areas). I have no experience with other, larger/custom, sets though, so I'll bow to yours there.

Using larger areas actually allowed me much more creative freedom. I know what you mean about big areas being able to become generic and boring, especially if the builder doesn't need the space or spend time filling it. Still, though, when you really WANT the space to pull something off, the result is amazing. My favorite area in our mod is Pelor's palace in Elysium, which came in at 17x15 despite my best efforts to keep it down:



Then there's the Elemental Plane of Air, three areas at 16x16:



And the top of Demogorgon's fortress Abysm, featuring a bone bridge and weighing in at 8 x 22 (and I would've added another 6 to both dimensions to hide the corners, if I could've made myself, but that just seemed like too much space for the gain):



And, while I'm sharing, here's the good 'ole Pillar of Skulls in Avernus, which is a fairly normal-sized area by comparison, but it's the source/root cause of our knowledge on the effects of placeables (it used to be around 10x11). The pillar was spawned in on entry using gaoneng's EXCELLENT vfx scriptset, and would use a lot more places if we could've gotten away with it. As it is, we had to push the pillar out an extra 4 tiles or so and make it spawn ondeath, because players were moving in and out of perceptual range of it during the Tiamat bossfight, which was crippling server performance. Here's the code for the Pillar, should you be curious:

    /* create the Pillar of Skulls */
    if (GetResRef(oArea) != "avernus003" || GetLocalInt(oArea, "skullpillar"))
        return;

    SetLocalInt(oArea, "skullpillar", 1);

    location lLoc = GetLocation(GetWaypointByTag("SkullPillarSpawn"));
    vector vPos = GetPosition(GetWaypointByTag("SkullPillarSpawn"));
    float fClean = 0.5;

    for (i = 0; i < 60; i++) {
        nRand = Random(9) - 4;
        fRand = IntToFloat(nRand) / 100.0;
        f = IntToFloat(i);
        lLoc = Location(oArea, vPos + Vector(0.0, 0.0, (f * 0.15) + fRand), 0.0);

        if (i % 3) {
            AssignCommand(oArea, DelayCommand(
                fClean + f * 0.01, PlaceCircle("plc_pileskulls", lLoc, 0.3, 3, 1.0, 1.0, f * (8.57 * (10 * fRand)), "z", 0, -1, 0.0, 1.0, 0.0)));
        } else {
            AssignCommand(oArea, DelayCommand(
                fClean + f * 0.01, PlaceCircle("plc_bones", lLoc, 0.3, 3, 1.0, 1.0, f * (8.57 * (10 * fRand)), "z", 0, -1, 0.0, 1.0, 0.0)));
        }
    }

And the screenie:



Funky

Modifié par FunkySwerve, 20 décembre 2010 - 05:33 .

[Calvinthesneak]

This is a very interesting read. I'm currently trying to patch up an old module and I didn't know the hit of static vs non-static plc's.



I'll keep it in mind and Funky, those screenshots are awesome.

[Eradrain]

FunkySwerve wrote...

Eradrain wrote...
It's worth noting that area size creates more lag BY FAR than anything else talked about in this thread.  You will create more loading- and game-lag with one disgustingly big, placeable-free 32x32 area than you will with a small area loaded with a thousand poorly located placeables.

No, again, that's only true of area load times.

I was talking about load times.  This thread is about client-side lag, right?

Loading times, graphical lag from the player's end, that's the kind of issue we're talking about here, right?  Getting the areas to run smoothly in the player's client?

You keep bringing up how modern your server is, but I really don't see the relevance.  As far as I'm aware, the lion's share of lag issues occur client-side, not server-side.  You don't need a particularly impressive server to run a stable NWN game, and getting the same kind of server that professional MMOs get just strikes me as overkill when you're never gonna have more than 60-75 people online at once, if even half that.  And even then, wouldn't the real bottleneck be your connection, moreso than the server itself?  There's a roleplay server I play on with an average of 20 folks online that's being run out of someone's old laptop, and it runs smoother than some PWs I've tried with professional servers, some with bigger populations, some with quite smaller ones.  That being the case, the lag has to come from client-side issues (Loading/processing bad placeable use or bad area size) or a shoddy internet connection, the server just seems like the icing on the cake.  It's nice to have, but you can have a cake without icing and still call it a cake.

Modifié par Eradrain, 20 décembre 2010 - 06:10 .

[FunkySwerve]

Eradrain wrote...

FunkySwerve wrote...

Eradrain wrote...
It's worth noting that area size creates more lag BY FAR than anything else talked about in this thread.  You will create more loading- and game-lag with one disgustingly big, placeable-free 32x32 area than you will with a small area loaded with a thousand poorly located placeables.

No, again, that's only true of area load times.

I was talking about load times.  This thread is about client-side lag, right?

Not really, no. There are three kinds of 'lag' discussed in that tutorial (graphics, connection, and server). Placeable lag, the topic of this thread, can be of both server- and client-side varieties (and each of those three kinds relates to both, though graphics lag is largely client-side, other than the serverside steps you can take to reduce it). The issue with the pillar of skulls mentioned above is server-side lag - it sends the client updated placeable description info every time a place enters their perception, making an enormous amount of work for the server. The tutorial is very careful to make this distinction, as it IS particularly confusing, especially given the loose usage of the term 'lag' among players. I humbly suggest you read the whole thing, but here's the relevant chunk:

Lag - What is it?:

More properly, lag refers to a delay in information exchanged between client
and server, resulting in a hang with breaks immersion and can result in loss of
control of one's character, with often unpleasant consequences. Players,
however, tend to use the term 'lag' much more broadly, to refer to anything that
causes a hang or break in play experience. Decoding their meaning is critical to
understanding the problem that they're experiencing, and to fixing it, if indeed
there's anything you can do - sometimes there isn't. So, for the remainder of
this tutorial, we’re going to use the term 'lag' in this broader sense, and
label actual lag 'connection lag'. Before we can discuss ways to prevent lag, we
need to familiarize ourselves with the various types of issues that can give
rise to interference with game play. Below is a rough listing.

• Connection Lag:
  
  Connection Lag, is also called network lag. Connection Lag arises from a
  problem with the connection between the player’s computer and the server. It can
  have a number of causes, including active programs on the player's computer, the
  player’s router, the server's router or the server’s active programs, or
  somewhere in between. Connection lag can be detected by pinging the server, and
  checking ping times. A network trace or trace route (tracert command in Windows
  DOS) will show where, roughly, the problem lies. Often there will be nothing you
  can do about this sort of lag, other than to assist the player in
  troubleshooting their system, or waiting for network issues to be resolved. If a
  ping results in an unusually high number, or the tracert fails at a certain
  jump, the problem is connection lag.
  
• Graphics Lag:
  
  This is one of the most common types of lag, and the one most mistaken by
  players as network lag, or as some other sort of problem external to their
  system. Graphics 'lag' occurs when the player's computer is overwhelmed with the
  graphical data it is getting, and fails to render graphics smoothly, resulting
  in poor frame rate, lockups, and occasionally more exotic issues. It is LARGELY
  a client-side issue, and the player will need to take steps to fix it. Fixing
  the problem may require steps, such as, changing their graphics settings or
  getting a different graphics card. There are, however, some things that a server
  administrator can and should do to prevent this sort of thing, which we will
  discuss below. If the 'lag' a player experiences is intermittent and coincides
  with times when a lot is happening on their screen, and other players on the
  server do not experience it when they do, the problem is likely graphics lag.
  Graphics lag can often also be detected by having the player hit the tilde (~)
  key, type ‘fps’, and hit enter while playing, which displays the Frames Per
  Second they are seeing displayed. The higher the number, the better the
  framerate; the lower, the choppier (‘laggier’) things will appear.
  
• Server Lag:
  
  This is the final type of 'lag', and the one you have the most direct control
  over. It arises when the server is trying to do too much at once. The game
  engine begins to run on the hairy edge, and it stops doing certain things, based
  on priorities in the engine. This often is caused by a lot of players on a
  server, poorly written scripts, poorly built areas, or some combination of the
  above. Other times, there may be some technical issue at work, like a crippled
  game server, an out-of-control process, or insufficient RAM. Server lag is often
  the trickiest to detect, and can be diagnosed by ruling out both connection and
  graphics lag. In more extreme cases, however, it is not at all hard to detect,
  as low-priority processes cease. These include the updating of the game clock,
  resulting in the game being stuck permanently at a certain time, arresting the
  day/night cycle. There are other low-priority processes as well. These low
  priority processes may fail with even a couple players on a well-built server
  and module, so they are not of much help when diagnosing a problem. Some
  examples of low priority processes include persistent area of effect heartbeat
  scripts and spawned-in-placeable heartbeat scripts. These scripts often will not
  fire, even on a healthy server.

Loading times, graphical lag from the player's end, that's the kind of issue we're talking about here, right?  Getting the areas to run smoothly in the player's client?

No, there's more issues than just that, and load times are a distinct issue from graphical/rendering 'lag'.

You keep bringing up how modern your server is, but I really don't see the relevance.  As far as I'm aware, the lion's share of lag issues occur client-side, not server-side.  You don't need a particularly impressive server to run a stable NWN game, and getting the same kind of server that professional MMOs get just strikes me as overkill when you're never gonna have more than 60-75 people online at once, if even half that. 

The power of the server is very relevant to server lag. And no, client-side issues are just one slice of the pie, not the lion's share. We used to host 6 servers capped out at 32 players each, in the hayday of NWN, before NWN2 dropped, and they would be full with people waiting to get in at peak hours. Now, we typically have on 70-75 people at once during peak times at night (in UTC-5), though that's been increasing of late, probably mostly due to the holiday season. I can assure you that a professional grade server is anything BUT overkill - acaos specifically set up one with 32 G of RAM when he decided to host us (we host 13 mod instances with that - a dev server, a roleply server, three hub servers, and 9 'party' servers linked to the hubs).

And even then, wouldn't the real bottleneck be your connection, moreso than the server itself?  There's a roleplay server I play on with an average of 20 folks online that's being run out of someone's old laptop, and it runs smoother than some PWs I've tried with professional servers, some with bigger populations, some with quite smaller ones.

That depends. Either can be the bottleneck. In our case, acaos has an absurdly good connection - T3 - which is one reason we were able to make the switch from Amazon (which also has an excellent connection, obviously). At Amazon, cost was an issue, but server power was bottlenecking us as well (we were paying for 1 small and 2 medium VMs, if any of you are familiar with their setup). Paying 300 bucks a month on donations alone was getting difficult (but yes, we run purely on player donations). I have experience with everything from:
1) Hosting myself on Win with no nwnx
2) Hosting myself on Win with nwnx
3) Hosting myself on a unix VM with nwnx
4) Hosting on a friend's 'normal' computer remotely, in the UK, with nwnx
5) Hosting on a professional service without nwnx (Dungeon Server, which was awful)
6) Hosting on a professional service with nwnx (Fragism, who were fantastic, and kept us on long after they shut down the business)
7) Hosting on a network service we had to set up ourselves (Amazon) with nwnx
8) Hosting on a friend's professional setup with nwnx (most recently)

Where the bottleneck is has varied from setup to setup - when hosting myself, it was always my crappy cable modem connection, also true with my friend's 'normal' setup (#4). When hosting at the other places, other than #8, the bottleneck was typically server power, as services are generally hosted at datacenters with nice connections. It's still not clear where our bottleneck is at #8, since we've yet to hit one. HG's instances are using 8k Mhz out of 18k, and 11 G ram of 32, but other things are running on that system as well, pushing use up to 11k Mhz and 18 G ram with 75 players on. Likely connection will be the limiter, if we ever have 150 players on again (unlikely, but then, this setup was designed to be our final home).

That being the case, the lag has to come from client-side issues (Loading/processing bad placeable use or bad area size) or a shoddy internet connection, the server just seems like the icing on the cake.  It's nice to have, but you can have a cake without icing and still call it a cake.

No, we are always on guard against server-loading issues, and area sizing would be a server-side as well as client-side issue. I still don't plan to add anything to the pillar of skulls at our new home, as I'm quite confident we could still crush even our newest server. Again, I strongly recommend giving that tutorial a read.

Funky

Modifié par FunkySwerve, 20 décembre 2010 - 09:44 .