View previous topic :: View next topic |
Author |
Message |
TroveLord
Joined: 22 Nov 2006 Posts: 136 Location: Italy
|
Posted: Fri May 11, 2007 18:25 Post subject: |
|
|
Yes, forgot to mention that. 1.06.968 |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Sat May 12, 2007 14:28 Post subject: |
|
|
I've yet to adapt NWNX 1.08 to NWN 1.06 - right now, it only works with the final NWN 1.05. I think I should have something ready soon. _________________ Papillon |
|
Back to top |
|
|
TroveLord
Joined: 22 Nov 2006 Posts: 136 Location: Italy
|
Posted: Sat May 12, 2007 16:35 Post subject: |
|
|
Ok I thought it was an error on my end. I'll stay tuned then. |
|
Back to top |
|
|
GodBeastX
Joined: 09 Aug 2006 Posts: 65
|
Posted: Tue May 15, 2007 17:44 Post subject: |
|
|
Papillon, you're awesome for your unpaid work |
|
Back to top |
|
|
chris421
Joined: 07 Apr 2005 Posts: 53
|
Posted: Sat May 19, 2007 5:26 Post subject: |
|
|
Testing for ya, Papi.
Typically I like to run without SQLLite support. I delete the INI, and rename the DLL to something else...
Under 1.08 SQLLite appears to try to load anyway--even though I've renamed the file extension!
Quote: | NWN Extender 4 V.0.0.7
(c) 2007 by Ingmar Stieger (Papillon)
visit us at http://www.nwnx.org
* Loading plugins...
* Loading plugin xp_mysql.dll: Successfully registered as class: SQLoff
* Loading plugin xp_sqlite.dll_REMOVE: Successfully registered as class: SQL
* Loading plugin xp_time.dll: Successfully registered as class: TIME
* Disabling general protection fault error dialog.
* NWNX4 activated. |
Also, I was initially trying to run with an old (1.07) flavor of xp_clock.dll and xp_system.dll in my NWNX4 (1.08) folder. Good lord did that cause grief. Oddly, what crashed was NWN2SERVER. |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Sun May 20, 2007 14:43 Post subject: |
|
|
I was thinking about adding a version check, but honestly wanted to avoid the hassle... maybe I'll add something simple which ignores pre-1.08 plugins .
I did not change the way the plugins are detected... I tend to rename mine like this: "xp_sqlite.dll" -> "xxp_sqlite.dll". _________________ Papillon |
|
Back to top |
|
|
Grinning Fool
Joined: 12 Feb 2005 Posts: 264
|
Posted: Sun May 20, 2007 17:18 Post subject: |
|
|
I will be (finally) updating hashset to use this tonight, and hopefully will be able to get to the demo mods at the same time. _________________ Khalidine, a NWN2 persistent world
Looking for volunteers. |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Sun May 20, 2007 22:36 Post subject: |
|
|
Cool! Please do not hesitate to provide your feedback on the new interface. If there is something that can be improved, please point it out. _________________ Papillon |
|
Back to top |
|
|
Grinning Fool
Joined: 12 Feb 2005 Posts: 264
|
Posted: Mon May 21, 2007 4:55 Post subject: |
|
|
More of a change than I expected, so I may not be able to finish tonight. My one thought about the interface is this: is the 'function' specifier necessary for the various GetData calls? Would it make more sense (and perhaps be a little more efficient) for the plugin to maintain state enough to know why a callback is being invoked?
Consider the situation where someone is calling SQLGetData 30 times, for 30 different columns. That means that instead of just checking it once, the plugin will have to compare the function text to "GETDATA" 30 times.
This could be worse if a plugin supports a larger range of possible function names.
EDIT: Two suggestions/thoughts
1) Now that i think about it, a plugin that does maintain state could easily ignore that parmeter. Nothing says that it must do the comparison to the char buffer.
2) This would be a somewhat large-ish change. But is there a r eason to continue using strings to identify function? What about using ints, with appropriate const definitions for readability in script and plugin code both. For example:
const int SQL_EXEC = 0
const int SQL_GETDATA = 1
const int SQL_ESCAPE_STRING = 2
const int SQL_NEXT = 3
etc.
All of the Get/Set functions could do away with the char * param1, in that case -- and slow string compares for function checks would get replaced with much faster switch on an int value...
Edit #2: Suggestion two has more appeal to me, as passing out the function name every time /does/ allow for nested operations. In hashset, I'm basically ignoring the function name and using the int param for this purpose. However, for the 'utilities' plugin I'm working on this won't work; nor would it for mysql or others that use the int value for other purposes.
Last but not least... I just wanted to confirm that sParam1 is still the game object itself. (I may have this confirmed by the time you're back online, with any luck) _________________ Khalidine, a NWN2 persistent world
Looking for volunteers. |
|
Back to top |
|
|
nosfe
Joined: 25 Apr 2007 Posts: 22
|
Posted: Mon May 21, 2007 17:26 Post subject: |
|
|
mhh yes, compare STRING...i anderstand ...
I like compare INT |
|
Back to top |
|
|
virusman
Joined: 30 Jan 2005 Posts: 1020 Location: Russia
|
Posted: Mon May 21, 2007 19:03 Post subject: |
|
|
I think, you won't notice the difference. Comparing 7-character strings 30 times is almost nothing. NWServer itself copies long strings dozens to thousands of times on every cycle. |
|
Back to top |
|
|
sihart25
Joined: 20 Feb 2007 Posts: 5
|
Posted: Mon May 21, 2007 20:29 Post subject: |
|
|
version 1.07 works for me but 1.08 does'nt at the moment the log files say yes/successful ( i am trying the timer demo) but the module saying no nwnx4;
install nwnx4. |
|
Back to top |
|
|
Gryphyn
Joined: 20 Jan 2005 Posts: 431
|
Posted: Tue May 22, 2007 0:18 Post subject: |
|
|
@GF, comparing the strings vs ints.
Depends on the architecture 32bit = 4char's at a time, 64bit = 8 char's.
The O/S is going to perform its comparisons on the contents of a 'register'.
So in most cases you'll get very similar performance unless you have a number of strings all starting with the same 4/8 characters. (subsequent checks needed to establish equality)
Cheers
Gryphyn |
|
Back to top |
|
|
Grinning Fool
Joined: 12 Feb 2005 Posts: 264
|
Posted: Tue May 22, 2007 6:52 Post subject: |
|
|
In typical standard C/C++ library implementations, strings are compared one character at a time. The MSVC implementation of strcmp (and related) functions is no different; it will loop through each individual character of source and target strings, and compare them one at a time by subtracting source dest char value from source char value. Too, performing a word-based comparison would not account for the null-termination character of strings. _________________ Khalidine, a NWN2 persistent world
Looking for volunteers. |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Tue May 22, 2007 7:58 Post subject: |
|
|
I think this is not a good way to go about this. Usually, one should have a solid measurement to base optimisations upon. The whole point is moot if you would not have a performance difference in reality.
I'd suggest a small experiment: Create a new function in the time plugin that compares like 500 strings of 30 characters, then compares 500 ints, and use the timer infrastructure to measure the runtime. I guess that you will not see a difference (within measurement accuracy). _________________ Papillon |
|
Back to top |
|
|
|