xp_bugfix - nwn2server bugfixes

[Skywing]

New release 1.0.18 posted.

Issues addressed in xp_bugfix 1.0.18 for nwn2server 1.0.23.1763 / 1.0.23.1765:

- Added support for rewriting the client's claimed UDP port so that two players behind the same public IP address do not cause various incorrect server-side behavior. This option, controlled by the new RewriteClientUdpPort ini setting, is on by default.

- Added support for disabling verbose messages like the invalid object deletion message. This option, controlled by the new VerboseLogging ini setting, is configured to disable verbose messages by default.

[Rasael]

*CHeers!* No more router troubles!

[Skywing]

Version 1.0.20 released. Please help pass the word about this version.

http://www.nynaeve.net/Skywing/nwn2/01231763/xp_bugfix_1_0_20.zip

This release includes a server-side component that is designed to replace the loss of GameSpy for NWN2. When xp_bugfix 1.0.20 or later is run, servers will check in with nw2master.bioware.com, as usual, and also with a server that I maintain, nwn2.mst.valhallalegends.com. The master server maintained by me will be used to support a web-based list of all active PWs, and (in the future) native CE integration to display the active server list for clients using the CE.

However, only PWs that install the updated xp_bugfix version will list themselves.

The same information that is sent to the BioWare master server today is sent to the master server I maintain. Additional details available here: http://nwnx.org/phpBB2/viewforum.php?f=1

[bsb5652]

Hi,

I installed the latest xp_bugfix.dll in response to the NWN2 master server list going down and worked perfectly, however, I am still having the issue of clients behind the same router causing havoc on the server ( ghost slots and the like ) afterwards. From the release notes, I was under the impression that this was fixed in the previous patch. I checked my xp_bugfix.dll and it does have the setting RewriteClientUdpPort = 1

I was wondering if there is anything else that needs done that I may be missing to take advantage of this new setting. Any help would be appreciated greatly. Not sure if it matters or not, but we run on port 6551.

Thanks again,
Brian
_________________
Brian S. Bloom
Creator of NWN2 PW Realms of Trinity

[bsb5652]

I actually answered my own question per a suggestion of the lead scripter at Tales of Amn. Changing the game to run on the standard port of 5121 actually solved the issue. Worked like a champ!

[erikbreau]

Installed the 2 updates and 2 required files, Europa II is back on the server lists after a delay of several months. Hope to see more players now...

Great work with the plugins!

Come see us at https://plus.google.com/communities/106885469303644155125

Erik
_________________
"Europa is coming, and there isn't anything you can do to stop it!..."
http://nwn-europa.blogspot.com/
Europa Pic Gallery: http://picasaweb.google.ca/erikbreau/EuropaPics

[Skywing]

The xp_bugfix 1.0.22 release incorporates substantial reliability and performance improvements. Note that some new performance improvements are only active with new configuration file directives, see below for details.

Direct download link: http://www.nynaeve.net/Skywing/nwn2/01231763/xp_bugfix_1_0_22.zip


Changes:

* (Reliability improvement) If a NWN2_Pathfinder object is destroyed, always remove it from the JStar2 secondary pathing list. This resolve a longstanding pathfinding crash that occurred when objects that were pathfinding were then destroyed. This issue was found to be a major remaining contributor to server stability problems.

* (Performance improvement) Added AIUpdate throttling mode; this is controlled by the new AIUpdateThrottle = count-of-milliseconds configuration value and must be enabled manually on upgrade to the latest xp_bugfix. See the example configuration file included for details. This feature keeps track of how much time was spent processing periodic object updates each main loop iteration, and if it exceeds the AIUpdateThrottle value (expressed in milliseconds), then the game server skips future updates for that main loop iteration except for critical objects (PCs, PC controlled objects, areas, and modules). A fairness scheme is implemented so that objects that were skipped have higher priority in receiving update service next main loop iteration. This feature ensures server responsiveness even under high load (maxed out CPU) situations. A recommended throttle value is 32.

* (Performance improvement) Added optional polling modes for network traffic as some environments did not see traffic processed properly when server CPU load was high. This change resolves that problem and is controlled by a new DirectPollNetRecv = 1 option that must be enabled manually on upgrade to this xp_bugfix release. The recommendation is to set this value to 1. If enabled, every main loop iteration will directly poll for up to 50 network packets. See the included example configuration file for details.

* (Performance improvement) CServerAIMaster now tracks CNWSObject pointers instead of object IDs in its internal list of objects that need AIUpdate processing. This substantially reduces expensive lookups through the game object hash table and improves performance during situations where many objects exist in the game world.

* (Performance improvement) Optimized out of the CServerAIMaster list items that only have "benign" item properties which require no periodic updating. This reduces the amount of objects that are scanned for periodic updates each main loop iteration by 50% or more on some environments. Items with temporary properties added are dynamically inserted into the CServerAIMaster list as necessary.

* (Performance improvement) Removed unnecessary hot code path look ups using the game object hash table in CSrverExoAppInternal::GetClientObjectById.

* (Performance improvement) Removed unnecessary hot code path look ups using the game object hash table in CNWSCreatureStats::HasFeat.


Quick summary:

On upgrade, it's suggested to make the following changes to xp_bugfix.ini to take advantage of all of the performance improvements available:

AIUpdateThrottle = 32
DirectPollNetRecv = 1

[Mythyzyn]

Just amazing, as always

I'll try this week end and give you feedback

I have many bench datas on my server, I will tell you I see a difference
_________________
NwN2 Action PW : http://www.lyncya.fr
NeverList : http://neverlist.nwn2.fr

[Max]

OMG... thanks ! I'll try it soon !

[Mythyzyn]

So after few hours of game, this increase really performances

The more I saw is a more than 50% increase in interior zone with many creatures

(Each maps of our module contains 30 to 40+ creatures)
_________________
NwN2 Action PW : http://www.lyncya.fr
NeverList : http://neverlist.nwn2.fr

[Mythyzyn]

An other thing/question about xp_bugfix

Is there a way to forbid the technical map added with the Client Extension ?

We use a specific discovering map system (cf. screens) :

http://www.lyncya.fr/zones-et-cymap.html

But the technical map added in the client extension remove all interest of it :-/

Can you add an option in the xp_bugfix that will forbid the map from the client extension ?
_________________
NwN2 Action PW : http://www.lyncya.fr
NeverList : http://neverlist.nwn2.fr

[Skywing]

The Client Extension already supports this. Clients will run the gui_scliext_identify script on logon, and you can send back a "feature bitmask" to control what the Client Extension area map shows, either globally on a per area basis. See gui_scliext_identify.nss in the FOR_MODULE_BUILDERS folder in the Client Extension zip.

You can do one of these two things:

1) If you want to disable area map features for every area uniformly, just set the appropriate feature disable bits but do not set FEATURE_PER_AREA_MAP_CONTROLS in response to the script running.

2) If you want to control the settings on a per-area basis, just add in the FEATURE_PER_AREA_MAP_CONTROLS bit to the feature bitmask sent along with the feature bitmask desired for the current area. Then after the client loads an area, you can send another feature bitmask that includes FEATURE_PER_AREA_MAP_CONTROLS and the desired feature disable bits for this area. The effect of FEATURE_PER_AREA_MAP_CONTROLS is that if set, the client will disable all of the per area features on every area transition until the server explicitly re-enables them, so if you want to control this on a per-area basis, after each area transition, send the new set of disable bits (including FEATURE_PER_AREA_MAP_CONTROLS) to the client for their new area.

The example code in gui_scliext_identify shows how to set feature bits for a client. You should only do this for a client that has run gui_scliext_identify, otherwise the user will receive an unexpected combat log message.

[Mythyzyn]

Thanks a lot for your answer (and works)

I'll check that !
_________________
NwN2 Action PW : http://www.lyncya.fr
NeverList : http://neverlist.nwn2.fr

[Psionic-Entity]

Hi, I'm having a bit of a problem with using xp_bugfix on a server and I'm wondering if anyone knows a solution. The issue is that custom UI causes massive player lag (in the form of ping reaching 20-30 seconds) when xp_bugfix is installed but not otherwise. The consensus was that people would rather have transition crashes back than deal with it.

It looks like the volume of script GUI updates sent to players is causing the lag, but there's no way to rewrite the scripts (listboxes must be filled, after all) that would reduce it.

Any info on which updates might have affected this or what settings might turn off whatever xp_bugfix does to the UI server to client messages?

[Mythyzyn]

I try what you said (I though)