| View previous topic :: View next topic |
| Author |
Message |
Blayde Windwalker
Joined: 02 Jan 2005
Posts: 18
|
 Posted: Tue Jan 04, 2005 21:08 Post subject: Suggestions Please |
 |
|
I am looking to install NWNX2 to support persistent chests, both bank vaults and item chests for personal houses and faction homes.
Can anyone suggest a mod/script to download that works with NWNX2 and 1.65?
Thanks. |
|
| Back to top |
|
 |
Manuel
Joined: 30 Dec 2004
Posts: 51
|
| Posted: Tue Jan 04, 2005 23:13 Post subject: |
|
|
| Here's some scripts at the Vault. Scroll down to the Scripts section. Not sure if they are good or bad or somewhere in between. Likely all of the above. Anyone authored some of these or are using them? I understand that the Talus Speech System is quite popular. |
|
| Back to top |
|
|
dguntner
Joined: 31 Dec 2004
Posts: 116
|
| Posted: Wed Jan 05, 2005 5:31 Post subject: |
|
|
| Manuel wrote: | | I understand that the Talus Speech System is quite popular. |
I know I'd be using it if it only ran on Linux. 
--Dave |
|
| Back to top |
|
|
Blacksting
Joined: 03 Jan 2005
Posts: 107
|
| Posted: Wed Jan 05, 2005 20:44 Post subject: |
|
|
As much as NWNX might have some advantages in stability the easiest way to accomplish persistent chests is with StoreCampaignObject and RetrieveCampaignObject. Make chests with unique tags and use them as the "name" of the database and save the contents with Store (as well as a successive integer key pointing to the object key so Retrieve can easily cycle through the database.) If you want I can post the short scripts I use.
By the way... before the forums moved someone was talking about "hooking" the Store and Retrieve functions to make them more efficient. As it turns out RetrieveCampaignObject was done more than perfectly by Bioware and could not be improved upon (actually the NWNX version was twice as bad)...... but StoreCampaignObject was not. I am not sure what future improvements have been made on this hook. |
|
| Back to top |
|
|
Earandel
Joined: 29 Dec 2004
Posts: 6
|
| Posted: Wed Jan 05, 2005 21:08 Post subject: |
|
|
| Blacksting wrote: |
By the way... before the forums moved someone was talking about "hooking" the Store and Retrieve functions to make them more efficient. As it turns out RetrieveCampaignObject was done more than perfectly by Bioware and could not be improved upon (actually the NWNX version was twice as bad)...... but StoreCampaignObject was not. I am not sure what future improvements have been made on this hook. |
That's a pretty negative way to put it 
In reality, the hooked RCO calls were 0.00152 seconds slower on average, while the SCO calls were each 0.163 seconds faster. So when doing write and read calls, the difference in the reads is actually negligible when looking at the net gain.
That was also on a complete test module. The code for the test was not intended to be production quality at all. It was just a proof of concept - to demonstrate to myself that the approach was working and that there were performance gains. There's also the issue of shared resources that was brought up - the NWServer and MySQL engine running on the same machine.
But seeing as how the approach has been changed significantly, those numbers probably won't mean much in the end. Maybe the hooked functions will be faster, maybe they won't. The only way to know for sure is to test them when its done, an at that time, I'll have to look at the whol picture - read times, write times, file bloating issues, etc. to determine if the plug-in has merit. |
|
| Back to top |
|
|
Makzimia De Graf
Joined: 31 Dec 2004
Posts: 55
Location: San Diego CA.
|
| Posted: Thu Jan 06, 2005 4:26 Post subject: |
|
|
We actually went a lot further with our chests to solve an issue that arises constantly, an old bug that bioware never seemed to sort out... stuck lids!!! addicted2rpg our resident scripting guru made an autofix set of scripts. In conjunction with the NWNX2 / MySQL combo, we have virtually unbreakable chests now. The only remaining issue, and never did work out why, is TMI's if more than a certain number of stackables is placed in one.
As far as performance goes, if we were to use a DB per chest even, with having had well over 8,000 players drop things in chests over the last 17 mths biowares DB would have probably crapped out by now. I know it certainly did when put to use on other intensive stuff initially.
Having said all that, ANYTHING that makes the system run smoother, more reliably and faster is good in my view gain me .0010 seconds each second for each player, and I would be happy still 
_________________
Makzimia De Graf
DM/Creator Island of Fredian
fredian.game-host.org:5123
Forums at http://castille.us/fredian/Forums |
|
| Back to top |
|
|
Papillon
x-man
Joined: 28 Dec 2004
Posts: 1060
Location: Germany
|
| Posted: Fri Jan 07, 2005 0:00 Post subject: |
|
|
| Blacksting wrote: |
As it turns out RetrieveCampaignObject was done more than perfectly by Bioware and could not be improved upon (actually the NWNX version was twice as bad)...... but StoreCampaignObject was not. I am not sure what future improvements have been made on this hook. |
The current performance of the NWNX object storage engine is as following:
283 scrolls in a chest, table pwobjdata which is like pwdata, just with a blob column.
MySQL Data path:
283x SetPersistentObject(scroll) = 234ms
Loop over the resultset, creating 283x scrolls = 297ms
ODBC Data path:
283x SetPersistentObject(scroll) = 266ms
Loop over the resultset, creating 283x scrolls = 330ms
Size on disk: 513KB (using MyISAM storage engine)
Bioware DB:
283x StoreCampaignObject(scroll) = 625ms
283x RetrieveCampaignObject() = 313ms
Size on disk: 2,20 MB
No storage: (just the function calls without any data written)
283x StoreCampaignObject(scroll) = 125ms
283x RetrieveCampaignObject() = 0ms (nothing created)
Specs: Athlon 3200+, local MySQL 4.1.7-nt, local NWN Client (reduced priority), and local NWN Server.
_________________
Papillon |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
