logo logo

 Back to main page

The NWNX Community Forum

 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
Wish List
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic    nwnx.org Forum Index -> Development
View previous topic :: View next topic  
Author Message
twinj



Joined: 11 Feb 2005
Posts: 16

PostPosted: Tue Jun 20, 2006 14:19    Post subject: Wish List Reply with quote

I saw teh news for this but I couldnt find it? I did look and search, maybe I am daft Wink.

Wishes
1. NWServer CPU Priority and Affinity option. I think it worked for NWNx2.
2. Resource Manager - scripts to start off with
3. A text builder, file builder and compile script caller that will work from within game. ( for a framework to be able to create a pluginable system for builders )
4. Non Intrusive object functionality. If possible.
5. Same as before and a server auto reload option.
6. Be able to handle more than one module or server. NWNx 4 for each server and a main overlap to group.??
7. Everyones appreciation for your hardwork!

Thanks mate Smile. Oh yeah.

8. Java plugin.
9. To work with PostgreSQL Smile

Thanks again.
Back to top
View user's profile Send private message
chris421



Joined: 07 Apr 2005
Posts: 53

PostPosted: Wed Jun 21, 2006 2:47    Post subject: Reply with quote

If we agree this is a wish list...

10. Touched on above: the ability to pass a "-ini" startup parameter to specify unique nwnx.ini's for the purpose of spawning multiple server instances from the same NWNX home. This would mean changes for NWNPID. Maybe enumerate the filenames like NWNPID.0, NWNPID.1, etc.

11. What good is #10 without the ability to specify the nwnserver home in nwnx.ini itself. This could help to identify the correct PID when running multiple instances. NWNX4 wouldn't arbitrarily hook the first nwnserver.exe process it saw. It would qualify the correct instance by its Drive:\Path\nwnserver.exe.

12. x64 compatibility.
Back to top
View user's profile Send private message
Papillon
x-man


Joined: 28 Dec 2004
Posts: 1058
Location: Germany

PostPosted: Sat Jun 24, 2006 0:15    Post subject: Reply with quote

The first wishlist got lost, unfortunately. Please feel free to post your ideas in this thread.
_________________
Papillon
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Acrodania



Joined: 02 Jan 2005
Posts: 208

PostPosted: Sat Jun 24, 2006 0:46    Post subject: Reply with quote

13) Built in support for Firebird

14) Support for more than one database connection at one time

15) Service instead of runtime

16) Delay start of module on initial start of service/application to allow the OS time to finish its stuff in case of a server reboot before starting the module.
Back to top
View user's profile Send private message
Acrodania



Joined: 02 Jan 2005
Posts: 208

PostPosted: Sat Jun 24, 2006 0:51    Post subject: Reply with quote

17) Installation of NWNX4 in its own directory instead of the root of NWN2.
Back to top
View user's profile Send private message
Asmodae



Joined: 07 Jan 2005
Posts: 55

PostPosted: Fri Jun 30, 2006 15:58    Post subject: Reply with quote

I believe the plan is for NWNX4 to support multple server processes now, perhaps even across machines. It would be nice to have the server reset functionality built in, or at least a method to get a handle to the server process so it could be manipulated/shutdown.

I'm not sure how this would work in a networked environment though.

- Asmodae
_________________
Nepenthe - An NWN2 Persistant World, coming to a planet near you. http://www.nepentheonline.com
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
Senalaya



Joined: 29 Dec 2004
Posts: 82
Location: Germany

PostPosted: Mon Jul 17, 2006 9:45    Post subject: Reply with quote

Just a comment to have multiple NWNX/NWN instances on the same server. That already works with NWNX2, if:

- Each module is set to a specific, own CPU with the CPU=x parameter.
Though it doesn't matter if the CPUs are based on physical CPUs, cores or hyperthreading.

- Each module has it's own NWN directory.
With changing the settings in the NWN.ini, multiple modules can share directories like Database, Modules, Servervault, Override.

Example:

\NWNDIR1 (full Standalone Server + NWNX)
\NWNDIR2 (full Standalone Server + NWNX)

\NWNSHARED\DATABASE
\NWNSHARED\HAK
\NWNSHARED\MODULES
\NWNSHARED\OVERRIDE
\NWNSHARED\SERVERVAULT

I running up to 4 NWN instances on a server with 4 CPUs (2 physical wih hyperthreading enabled), all of them with NWNX.
One little sideeffect, when using a module directory other than the default one, is that the module name won't show on the nwnserver GUI, but everything still works fine.
Back to top
View user's profile Send private message
Acrodania



Joined: 02 Jan 2005
Posts: 208

PostPosted: Mon Jul 17, 2006 17:57    Post subject: Reply with quote

I think the reason behind the request (and certainly why I would want it) is so that there is ONE copy of NWNX running, but hooking into multiple NWServers.

No worrying about CPU affinity, etc...
Back to top
View user's profile Send private message
weby



Joined: 20 Jul 2006
Posts: 2

PostPosted: Thu Jul 20, 2006 1:52    Post subject: Reply with quote

Ability to set threshholds for things like memory usage and uptime to reboot the server.


Ability to return things that we do not have funtions for in NWN if they are still missing in NWN2, by digging those from the data sctructures. Things like:
Go through all areas: "GetFirstArea"/"GetNextArea"
System Info: "GetSystemTime"/"GetSystemDate"
More info on effects: "GetEffect DurationLeft"
More area info: "GetGroundHeight"/"GetTileset"
Spell info: "GetKnowSpell", "GetSpellInSlot"
Enumerate all variables on an object: "GetFirstVariable" "GetNextVariable" "GetVariableName" "GetVariable type"
Actionlist things "GetQueAction" "RemoveQueAction"
And ofcourse the generic: "ReadDataFromGFF" (would be great with the hash table funtionality)
Raw faction Funtionality...



And to set things ofcourse: "SetRemainingSpellUses" "SetGoodEvilValue" "SetLawChaosValue" "SetSpellInSlot"
Back to top
View user's profile Send private message
Grumalg



Joined: 04 Nov 2005
Posts: 70

PostPosted: Fri Jul 28, 2006 0:09    Post subject: My NWNX4 wishlist Reply with quote

Some time ago I made some suggestions to Papillon in PM's. At the time he said he liked them and would add them to his to-do list for future NWNX, but that he had no plans to update NWNX at that time. I'm posting these as a reminder in case that to-do list entry was misplaced Smile

While one can use the NWNX reset plugin (and I do) to allow scripted server resets, it gives no capability for automating server maintenance tasks. I also would prefer a graceful shutdown of NWServer compared to just killing the process. I therefore propose the following command be added to NWNX.


"NWNX!RESET" [, "<command line w/ args or executable name>"]

Issueing this command would act by:

1) stoping watchdog timers
2) gracefully shutting down NWServer
(possibly via close or click message sent to windows or controls)
3) executing external program and waiting for it to complete
4) restarting NWServer
5) restarting watchdogs

Within the external program (I'm thinking .bat here, but actual .exe should be possible) one would do various maintenance tasks. These could include table/index maintenance via MySQL command line functions, backing up the DB, backing up .bic or other NWN files. If such backups were directed into the log.n tree you could also get automatic purgeing of old backups due to log file rotation without needing to watch HD space use of backups.

I originally suggested that the executeable name be an .ini setting, but passing a command line w/ args would be more flexible. Passing an actual command line does have a 'dark side' in that it's potientially subject to abuse, such as the DMClient being used to execute a script that allowed passing the command line in with a command such as format the HD. One can of course make sure not to have a script that can be reached with full argument passing as a security measure. By having a .ini enable/disable option you could lock out it's use if you wanted for security reasons. Better still would be a 'check box' in the NWNX GUI allowing enable/disable of the function so that it could be turned on, used, then disabled without needing to restart NWNX in order to use the function. I could live with the executeable name as an .ini setting if you feel the security concerns are too great.


"NWNX!SHUTDOWN" [, "<text message to display in a NWNX popup dialog>"]

This second suggestion for a new command addresses the issue of module dependance on a DB. As a module becomes more dependant upon the DB it becomes more likely you would want the module to be shut down and *not* restart if a failure occurs in the DB engine as either things won't work right or players could find an exploit if the DB stops working. It's easy to check for DB failure in a script. This command could also be used to provide for automated limited hours of operation of a PW. The optional text message for dialog display would be very handy as on returning to a server that had shut itself down, you wouldn't be left wondering why it happened. I can live without the dialog message if it's too difficult to implement.


"NWNX!EXECUTE" [,"<command line w/ args or executable name>"]

This command occured to me after the earlier PM conversation. It would be very powerful, but also subject to the 'dark side' issues, possibly handled as described above. As an example of it's potiential power, the NWNX char deletion plugin could have been done with one or more uses of passing a command line down to delete or relocate files eliminating the need for a plugin at all. While I don't personally have a particular use in mind for this, I expect turning this power loose would result in many clever uses appearing from NWN community members getting around various NWN limitations. While very useful, this might be too dangerous to implement and I consider the above two commands much more important.

If it's easy enough to do, it would be nice if you could get the return values from executed commands back with RESET or EXECUTE, perhaps via SQLFetch(), as this opens a way to get external information into NWServer without the limitations of what can be done via the DB. I realize that issues exist when waiting for execution that takes too long can result in NWServer timing out and abandoning the script attempting such a call. It may be better to 'Shell and Continue' instead of 'Shell and Wait' because of this.


Crossing fingers and hopeing some of this will appear in NWNX4 Smile

--- Grumalg ---
Back to top
View user's profile Send private message
pdwalker



Joined: 09 Aug 2005
Posts: 22

PostPosted: Mon Aug 21, 2006 8:44    Post subject: update statement improvement Reply with quote

the sql update statement should return the number of rows updated so we do not have to do insert, update statement pairs as is currently done in nwnx2
Back to top
View user's profile Send private message
chaoslink



Joined: 23 Aug 2006
Posts: 37

PostPosted: Thu Aug 24, 2006 19:34    Post subject: Reply with quote

1. Hook ALL known (useful) functions in NWNX.
2. Provide an interface for plugins to subscribe as a function handler (create a handler list - configurable order).
3. Provide plugin some control over function handling flow
3.1 pass to the next handler in list
3.2 stop after processing this handler
3.3 execute all other handlers and return execution to this handler
4. Provide a "C" interface - it would be nice to simply expose a handler method rather than a class


Hooking everything in NWNX and delegating to plugins, you can eliminate (or manage) contention between to modules which both hook the same function.

[edit: oh, and please.. please.. PLEASE try to write portable code. I really cringe there is so much effort required to port applications and modules that it doesn't get done. If the NWNX and demo modules a) reduce duplicate code to only that which deviates between Windows and Linux and b) provide build mechanisms for both platforms, then future module developers will have a good example to go off of.]
Back to top
View user's profile Send private message
dougnoel



Joined: 21 Mar 2005
Posts: 27
Location: VA

PostPosted: Wed Aug 30, 2006 15:54    Post subject: Reply with quote

I would like to create a NWNX SCO/RCO plugin that uses the GFF model to rip apart any object and store it in individual data fields.

I'd also like to implement the ability to search for a label in a GFF file (like Description) and be able to modify it and shoot it back to NWN/2. Basically a generic function that expects you to know the label, but can find the info based on that, so we don't have to hard-code hex addresses.

I've been working on these two things, but Avlis has recently been sucking up my dev time.
Back to top
View user's profile Send private message Send e-mail
Nightdew



Joined: 07 Sep 2006
Posts: 2

PostPosted: Thu Sep 07, 2006 2:51    Post subject: C# Plugins Reply with quote

Support C# assemblies as plugins.
Back to top
View user's profile Send private message
DeathMutant



Joined: 15 Sep 2006
Posts: 2

PostPosted: Fri Sep 15, 2006 22:59    Post subject: Re: update statement improvement Reply with quote

pdwalker wrote:
the sql update statement should return the number of rows updated so we do not have to do insert, update statement pairs as is currently done in nwnx2


I second this.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    nwnx.org Forum Index -> Development All times are GMT + 2 Hours
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group