Wish List

[twinj]

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

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 . Oh yeah.

8. Java plugin.
9. To work with PostgreSQL

Thanks again.

[chris421]

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.

[Papillon]

The first wishlist got lost, unfortunately. Please feel free to post your ideas in this thread.
_________________
Papillon

[Acrodania]

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.

[Acrodania]

17) Installation of NWNX4 in its own directory instead of the root of NWN2.

[Asmodae]

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

[Senalaya]

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.

[Acrodania]

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...

[weby]

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"

[Grumalg]

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

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

--- Grumalg ---

[pdwalker]

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

[chaoslink]

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.]

[dougnoel]

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.

[Nightdew]

Support C# assemblies as plugins.

[DeathMutant]