Neverwinter Nights Forum Update

Remove all ads!

(Originally posted by Z-Layrex)

David Gaider, Designer

Effects: VFX_IMP_* -type effects can only be applied with DURATION_TYPE_INSTANT.

More:

Quote: apparently not...it is working fine now. just needed to make the object usable...which sucks, because now the object show up. Anyone know the visual effect for the Gas Trap?

You don't actually have to make it useable... it just can't have the 'static' box checked. As for the gas trap, it's not a visual effect... you're looking for EffectAreaOfEffect. I think Minor Gas Trap is EffectAreaOfEffect (AOE_PER_FOGACID, "NW_T1_GasMinoC1", "****", "****") ... but if you just want the visual of the cloud and not the effect just change the script reference in there to another "****".

And More:
Again, it doesn't have to be useable... just not static. Try making it a temporary effect (can have high duration). I'm not positive persistent AOE's can be permanent. That might not be the problem, tho. You might need to use ApplyEffectAtLocation with an AOE, instead (all the trap scripts seem to use this).

New Things:

Quote: 1. Allow the scripting of radial menus, including adding an option to a character's main radial as well as adding subradials. This includes the ability to do more than five subradials in a spell, and even to make sub-subradials and sub-sub-subradials.

Maybe I'm missing something. Why are more radial menus needed?

Quote: 2. We hope that someday, items might be able to have their own scripts...this would add in making spells like "bless weapon" as well as helping the poor fellows feel equal to NPCs and the like.

I doubt items will ever carry their own scripts. What can eventually be hoped for are more module events like OnActivateItem that allow you to script custom items within a module.

Quote: 3. We require "set" functions, so that they may compliment the "get" functions, and allow such marvels of the infamous sex changing girdles, spells such as "alter self", and allow such role playing options as changing one's deity and name (or declaring a subrace that you forgot).

A lot of these things can be done by the Effect commands (no sex-change effect yet, though), but I agree... more commands to directly affect changes in stuff is nice and will likely be looked at in the future.

Quote: 4. We need a compliment to the polymorph effect that that will only change the appearance of a creature, but none of its other abilities, as well as the potential to allow a polymorphed creature to be able to still equip (and perhaps stay equipped) after the shapechange. Then such delights as casting a spell while a Fire Giant (as one ought to be able to do, according to the Core rules) may be enjoyed.

Fire Giant models can cast spells. I assume you are referring to an ability to switch models so that players can assume creature models. It's hard to say if this will be possible anytime soon. There is a demand for more playable races, so we will definitely look at it in the future... the real issue for other models is being able to don equipment and have it reflected on the model. That requires considerable animation work. Simply switching models without consideration for equipment is also a possibility, I suppose.

Quote: 5. Our modifications are fettered, for our "hak paks" do not receive the priority they are due. Instead, we must tamper with the sacred "override" folder, a place that should be reserved for you alone.

You are incorrect, here. The hakpaks have the highest priority for override. If you are referring to the current issue with some of the 2DA's not overriding in-game 2DA's when included in a hakpak, that is fixed in the next patch. Aside from that, keep in mind that 2DA editing is not officially supported.

Quote: 6. Lastly, our ability to add comments and explanations for new spells and items is sorely pressed, and we require a method to reference such information to a file that is not the lengthy and unwieldy "dialog.tlk".

New spells? Again, I assume this is through 2DA editing, which is not supported. The only reason that we would have to edit the dialog.tlk table would be so imported custom resources (like models, tilesets, music, sounds, etc.) would have a tag so they can be selected from within the toolset. It may be possible that these tags can be added without requiring the dialog.tlk file, in which case no editor would be needed. If the dialog.tlk file ends up requiring to be edited, then I assume you could indeed use such a function for what you want to do.

More:

Quote: 1. Data structures: arrays, lists, maps

These will probably get added eventually, yes.

Quote: 2. Being able to write and read a file (make it secure by only allowing it to be in a special NWN dir). This will be helpful for storing data that needs to be editable without having to mess with #include scripts, recompiling, rebuilding, etc.

Mmm. I suspect that any I/O functionality will be restricted to specific commands with very restricted uses. Security is the primary reason that no I/O was included in the initial release.

Quote: 3. Need to be able to edit "Examine" string from within the script. So that when people examine something, they see a scripted string.

That sounds reasonable.

Quote: 4. Need to be able to create arbitrary, dynamically templatable dialogue trees from inside a script. This could be used for DM and Developer Helper type NPCs to report back to you all kinds of game parameters inside a dialogue (as opposed to one liners).

I have no idea what you mean by 'arbitrary, dynamically templatable'. I've used custom tags to report in-game data through dialogue... beyond that, I'm not sure what you're expecting.

Quote: 5. Definitely need scriptable radial or some other kind of menu! This can be used to make items such as 'Rod of Lordly Might' so when you use it, it gives you several options and you can turn it into a weapon of your choice. You can also use it to make an item such as "Rod of Teleportation" that can memorize 5 locations and teleport you back to any of the 5 locations, all in one item.

Not sure this requires a scriptable radial menu. More slots that the current Unique Power and Unique Power - Self, maybe, insofar as OnActivateItem-scripting goes is certainly possible.

Quote: 6. Allow scripts on any items. You can make it secure by implementing a sandbox model, like in Java.

This most likely will not happen, as I've already said. More item-related events will probably come in the way of the module events list.

Quote: 7. This is a biggie: need to be able to assign and de-assign event scripts/functions to any object from within a script.

Possible, I suppose.

Quote: 8. Functions should become first class. You should be able to store functions inside arrays, lists, maps. This will allow complicated automata to be created.

And, um, how many people would actually use this? Arrays, lists and maps, themselves, are likely only to be used by the programming elite.

Quote: 9. This one is a biggie: optimize for speed. Write a JIT compiler for your language.

This is a biggie, is it?

Quote: 10. Allow configurable heartbeats to lessen the impact of a 6 second spike. Not everything needs to be processed on the round. We can fudge it with DelayCommand even now, but it would be nice to have some syntactic sugar for it.

As you say, using DelayCommand combined with SignalEvent allows you to create a customized heartbeat in the OnUserDefined area. I can't see them changing the standard OnHeartbeat, itself, but you never know... would make it a little more user-friendly, I suppose.

Player Death: There is a reason why GetLastKiller doesn't work for PC's. When PC's 'die' (are reduced to 0 or below HP) their OnPlayerDying event fires. In most cases this eventually leads to an EffectDeath being used to kill the player officially. So as far as the program is concerned, the PC was not killed by an object. A GetLastPCKiller command would certainly make that easier, I agree. I'll certainly pass the suggestion along... though I think it'll be a while before we consider adding new scripting functions in.

Noel Borstad, Programmer

Checking For An Item: The object GetItemPossessedBy() command would be easier in this case than iterating through their inventory. Pass in the tag and the PC, and it will return the item if the have it, or OBJECT_INVALID if they don't. Iterating through an inventory is a pain because you have to also check equipped slots and containers.

Changing Models: To turn the commoners into ghouls you will have to destroy each one and spawn a ghoul in at their location (you'll probably also want to play a visual effect to cover the pop) The template gargoyles, and some of the lycanthropes have this behaviour. For your vampire, do CreateObject(OBJECT_TYPE_CREATURE, "nw_vampire", lWaypoint, TRUE) in the onUsed script for the coffin (make it useable, but no inventory).

Brenon Holmes, Programmer

Future Things:

Quote: We need more events. Some events would work better if they were split into two events that happened before and after.

OnBeforePCRest
OnAfterPCRest

These two exist already. There are 3 events that call the module rest for a PC... rest starting, rest cancelled and rest completed. There are access functions to determine which event type was called.

Quote: ~snip~The ability to change the scripts that are assigned to various handlers at runtime would be very handy and powerful. Please add this one?~snip~

This functionality already exists via ExecuteScript(). You can store a script set on a string on the object, then get the object to execute that script in it's event handler...

Quote: ~snip~Perhaps add GetFirstItemInContainer(oContainer), GetNextItemInContainer(oContainer), and GetItemContainer(oItem) functions?~snip~

These also already exist via GetFirstItemInInventory()... if you call the function on an item with inventory, then it will iterate through that item's item repository.

Quote: ~snip~David, I have to say that I totally disagree with this. I don't think the use of arrays etc. are advanced programming. I'm hardly an advanced programmer, and I find I am starving for these abilities. GOD, the long pain in the ass scripts that I have to write to make up for the lack of arrays. I really can't understand why they weren't included in the first place.~snip~

Basically what is being discussed is pointers... data structures containing function pointers and all that that entails... not too likely. Arrays as a defined structure would be nice... and probably possible... but the ability to have dynamic arrays of function pointers isn't too likely...