Jump to content

Jasperre

Members
  • Posts

    24
  • Joined

  • Last visited

Everything posted by Jasperre

  1. Looks good rich, bringing it up to NWN1s level is great. Hope to see some stuff which is missing specific to NWN2 for manipulating properties though maybe that'll be in the "more information" :D (I'd kill for a NPC "ActionUseItem" function among other things...heh)
  2. A few issues to bring to attention: 1. GUI XML files and Hakpacks not co-operating They do not work together. I tried in my beta 1.05 and I put a context menu XML file in the override folder. This worked fine. I put one in a hakpack, associated it with my 1 area test module, it didn't even load the module! (created the hakpack using this tool: http://nwvault.ign.com/View.php?view=NWN2T...Detail&id=9 ) These are the 3 files I used to test: http://finaldeath.co.uk/nwn/files/nwn2/GUI_problems.zip ---- End Server Options ---- [Sat Mar 31 01:11:50] Player [] () Joined as Server Admin 1 [Sat Mar 31 01:11:50] Player () Joined as Player 1 [Sat Mar 31 01:11:50] Loading Module: test_hakpack_gui TRANS: [Sat Mar 31 01:11:50]Not decompressing as not loading from a previously visited module. TRANS: [Sat Mar 31 01:11:50]Setting up Stall Event now. Couldn't load the Hak Pak File "test_contextmenu_hak.hak" Could not load the Module. Missing required HAK file. In addition, TLK files didn't load from hakpacks either. Music, I suspect, also is the same. These 3 types of file could be consolidated, so people who create custom content can distribute it more easily, and module builders can extract it to campaign directories if they wish, or use the hakpacks as is. Just in case why you might wonder why it is more useful, apart from choice, hakpacks provide: A contained set of files with easy ways to instruct module users to use. Module builders don't have to worry about file conflicts ("what overrides what? what zip do I do first? what do I merge?!?! there is no manual to this!) Allows hierarchies of hakpack files to be used like all other file types can be in Allows, with hierarchies, proper "addons" or "optional" hakpacks, ie; you include a placeholder GUI file for an addon feature, which simply doesn't do anything, and a second hakpack holds the actual addon feature which overrides the placeholder in the correct hierarchy, but there are many other examples of this being needed. These don't work in a hakpack file: GUI .ini files (not needed in 1.05 I think right?) GUI XML files. Music (I think, I have not got time to test just now) TLK files - vastly important I forget if multiple talk table files can be used, or if they need to be merged, but simply having them able to be put in a single hakpack file anyway (or set of haks, which all go in the same folder, the hak folder) would be a good idea. In addition, campaign folders suffer from not having access to, I think, TLK and music files. (please correct me if I am wrong). Inconsistency as to where things go make creating anything for the game very hard. Its hard enough having 2 folders for game data - one in the documents one and one in the game folder, and not knowing the hierarchy between those! 2. Logs There are no logs of what is loaded (at least, what hakfiles are loaded and which locations, and in what order). Feedback is needed to find conflicts. Or they are all over the place. EVERYWHERE, like, one in EVERY place, and no one knows where they all are. local temp folder (which is never deleted either, but thats another several hundred megabyte story), my documents, the game install folder, anywhere I missed? Can't there be one log file location for all of these? all the crash reports and server logs? all the error logs? Perhaps an option in the config files :D It also hung when there was an invalid / not found hak. The game should at least go into console more / report an error / go back to main menu right? It would have to be optional, and always off by default, but if a debug setting for finding out: What archives / locations are loaded In what order What separate files load With conflicts reported Would be a good idea. Having each one optional (ie; conflicts separate from what archives are loaded) would be good too. Not being able to find bugs is confusing at the moment with no feedback - my issue above with putting an xml file in which crashed the loading and no feedback is part of this. 3. GUI script exploits Since GUI scripts can execute server-side scripts in multiplayer, and GUI scripts can be edited by players (and there is no option or way clients can readily check for "just using the defaults" or whatnot), there is a "security" risk, ala cheating, available to some players. It is good, in its way, that only gui_ scripts can be executed. It is bad that there are dozens in a default game install. If a server admin does not know to do so, the default death resurrection script could be abused. There are others too, beyond the basic henchmen behaviour changes (which are fine, except they can mess up other peoples henchmen) there are the item naming script and a few others that could be abused in this way. In future expansions I fully expect more default ones will be added (and thus must be, else they'd have to be created by a builder to work at all!). There either should be some documentation or more checks put in such scripts, else it is easier then combing server code to exploit the game! If I am wrong on any of these points please say, I would like to be proved wrong really.
×
×
  • Create New...