|
Post by funakichiga on Aug 5, 2006 16:54:42 GMT
Hello and im just wanting to say that the new addition to the AoE spells (no more than 1 0r 2 spells in an area) is working greatly. Especially since the buffing of these spells and making a ring on the most used AoE spell on HG, peopole are using these spells way too much. Hey but im not complaining having a mage in the party helps and we can go to tower at lvl 5......Just good job on putting a limit on the AoEs.
|
|
|
Post by FunkySwerve on Aug 5, 2006 17:56:55 GMT
Thanks. There's actually a whole nother thread on this at the moment in the drunken monk, as well. Funky
|
|
|
Post by lala on Aug 11, 2006 7:53:06 GMT
We did a test on the immortal run yesterday (involving 7 players). Setup was: - All players on run disable combat messages from log - Spawn 70% of both maps (when on them). - 22 players were on the server - 3 casters in group, also used Storm of Vengeance on a mass (to really push it). The result was no noticable server lag.
For us this is the 1st time I have ever seen lag totally removed from the Abyss, and it was really pushed by spawning most of each map.
I know we cant disable the combat messages as it is very important and critical for players at times. However I thought I should mention this as it may help provide some exta info for you.
Maybe a mechanism could be setup to help awareness of the combat message when in largish party and in high spawnrate maps.
Hope the info helps Cheers Lala
|
|
|
Post by FunkySwerve on Aug 11, 2006 23:29:58 GMT
The combat log is graphics, not server related. Disabling it takes a lot of extra work away from your graphics card. Funky
|
|
|
Post by lala on Aug 12, 2006 19:04:04 GMT
The combat log is graphics, not server related. Disabling it takes a lot of extra work away from your graphics card. Funky Sounds like they have done the design a bit whacky - ideally the mechanism should interface with server module to reduce buffer overhead and potential over-runs, leading to the cycle of an expanding cache that blows resources. The overhead in terms of communication for client-server in a delay sensitive application (such as an internet game) would be pretty high when massive amount of information is being streamed to many clients simultaneously. But then a lot of NWN is best described as rather whacky (and nifty) FYI I specialise in network-application modelling and technical architecture design in the company I work for (rather large communication manufacturer company to say the least).
|
|
|
Post by FunkySwerve on Aug 12, 2006 21:44:04 GMT
I'm not sure I understand what you are saying, but NWN is not synchronous like some games, so delays are not all that big a deal. It sends the packets, and if you don't get em, you lose em. If it waited for client response the server would crawl.
Funky
|
|
|
Post by lala on Aug 12, 2006 22:40:34 GMT
Not sure I have mentioned it before but I have respect for the work you have done with NWN; takes a lot of research and hard work and this can be seen by how stable HG is (which I think is one of the most efficient and stable out there). Regarding messages. Your right the data is transmitted in a connection-less state (no confirmation of packets receieved). However you can expect a certain level of resilience built in at the application layer otherwise you are open to security issues and really strange client-server behaviour when something goes wrong. Regarding the data stream from client to server only a finite amount of information can be transmitted if you intend to remain within a tolerance of time; The time threshold is critical for online games, if I remember correctly in general for online streaming games its around 250ms before problems start to occur. The main output queue from the server would be receiving data from various other queues such as the combat engine, chat messages, server to client commands, gfx commands,locational information, status of characters, etc. Each of the queues would have a priority to ensure critical information can be passed. Now it all depends how the messaging system works (by messaging I mean the ones you can disable) - it to may also have its own queue on the server or could be just client-side and the client processes a [censored]load of raw data (no idea but it could be identified by use of an network application analyser and that would take a lot of hours). Anyway if there is too much data and it has to be prioritised you either buffer to transmit delayed or discard, buffering would require the caches. Now the risk is that too much data from one queue would need an ever expanding cache to handle the buffering and eventually eat all the resources that can be allocated to the queue (I would hope they build in a safety discard mechanism). The downside is its a [censored]load of performance tweaking for caches (which I suspect you have done) and it depends what level the application allows you to be hands on. So personally I can see the messages system does have its own queue and it applies to all the message types you can exclude. This does not mean I am disagreeing with you as your the one with the tears of experience with NWN (more you than me I say) Hope this sort of helps with my summary about NWN being whacky in the way they may handle the disabling. Cheers Lala [edited for language]
|
|
|
Post by FunkySwerve on Aug 13, 2006 1:25:02 GMT
Not sure I have mentioned it before but I have respect for the work you have done with NWN; takes a lot of research and hard work and this can be seen by how stable HG is (which I think is one of the most efficient and stable out there). Lol, compliment me before giving me my learnin, a wise tactic, but not necessary. There is a seperate chat buffer, and while its fairly large, my understanding is that it is insignificant next to everything else going om. You can actually overload it and crash the server (no more details on that little funion, sry) There's no need for an ever-expanding cache, the data is discarded after a certain point. Play for a few hours in a large party and then scroll up, and you'll find that your login message is long gone. Of course, I'm no expert, and a few bits of this are seconhand from bioboards (namely the 'insignificant' part), but from sources I've found to be reliable. Funky
|
|
|
Post by hiryuu on Aug 13, 2006 1:31:57 GMT
The logs have a high priority with retransmission, since they need to be complete, or they're not of much use. It's hard to look back at what happened when chunks of the round are missing. Really, that applies to a lot of NWN, and RPGs and strategy games in general. That's why RTS has stayed with the synchronous state design, dropping players that can't maintain the data rate.
You seem to be saying that the log toggles should control the server state (what it sends), rather than the client state (what it displays). It is silly, but the client seems to have minimal control over the server state as a design philosophy, so it makes sense from a development perspective.
|
|