Let us have more control where data is send in chat/combat windows. Like SendMessageToPC function should not be in the combat window, it should be the conversation window.
Allow more events to bind and attach to. Specifically, all of the creature/monster events should also be bindable to PC's. I'd like to see more options for PC events, that aren't tied to the module. Maybe I want to bind some events on some PC's, and others I don't care. Instead of having inefficient code where I check to see if someone is doing something specific on heartbeat, I can bind and unbind the specific event code to any PC and/or object.
Below is a picture of the events you can set for a creature:
Would it not be safe to assume these events exist for PC's, but are just not exposed in NWScript?
These events are all set to "default" for player characters. You can even write a script called "default" and it will execute when any of them is triggered. There's no good way to determine which event triggered the script, though, so there's not much that can be done with it.
Also, not sure if this belongs here or somewhere else... But the ability to set a visibility level to something custom. Not just See Invisbility/See All (Truesight) but different custom layers, so only certain characters can see the creature/PC/placeable.
I could see it being used like this:
const int VISIBILITY_NORMAL = 0x000000;
const int VISIBILITY_INVISIBLE = 0x000001;
const int VISIBILITY_SANCTUARY = 0x000010;
const int VISIBILITY_STEALTH = 0x000100;
const int VISIBILITY_CUSTOM1 = 0x001000;
const int VISIBILITY_CUSTOM2 = 0x010000;
const int VISIBILITY_CUSTOM3 = 0x100000;
const int VISIBILITY_TRUESIGHT = 0x000111;
const int VISIBILITY_ALL = 0x111111; /**DM SIGHT**/
/** Sets the visibility for the given target, 0x000000=normal, 0x000001=invisible, 0x000010=sanctuary, 0x____0= user defined)
void SetVisibility(object oTarget, int nVisibility)
/** Sets the vision for the given target, , 0x000000=normal, 0x000001=invisible, 0x000010=sanctuary, 0x____0= user defined)
void SetVision(object oTarget, int nVisibility)
/** Returns the visibility of the given object **/
void GetVisibility(oObject);
This would allow us to set granular levels of visibility and sight.
Like this:
SetVision(oPC, VISIBILITY_CUSTOM1 | VISIBILITY_CUSTOM2); //PC can now see both CUSTOM1 and CUSTOM2 visibility
These events are all set to "default" for player characters. You can even write a script called "default" and it will execute when any of them is triggered. There's no good way to determine which event triggered the script, though, so there's not much that can be done with it.
I would say any of the .bic editing functions, either used in NWNX or whichever distribution might await these functions, may be able to assist with PC customization by means of event handling.
It's been a long while since I played around with that, but I believe that editing the bic doesn't have any effect. The player still runs "default" for those events. I could well be wrong about that, but in any case, it would be nice if it did work.
I'd like to see a tutorial/handbook for the toolset, 'cause I spent hours with that and barely made a dent in the module I wanted to design. Or is that not the sort of "file format" you mean?
Documentation is a popular request, but file formats would refer to data organization with different extensions, like the BMU "MP3" format, or the text-based "2da" array formats.
These events are all set to "default" for player characters. You can even write a script called "default" and it will execute when any of them is triggered. There's no good way to determine which event triggered the script, though, so there's not much that can be done with it.
I would say any of the .bic editing functions, either used in NWNX or whichever distribution might await these functions, may be able to assist with PC customization by means of event handling.
________________________________________________
What I was suggesting was ability to run-time, dynamically assign events. Not just for PC's, but for everything.
I imagine it would work something like this:
const int EVENT_BINDING_HEARTBEAT = 1;
const int EVENT_BINDING_ONDEATH = 2;
const int EVENT_BINDING_ONSPAWN = 3;
//so on and so forth...
/** Sets the Event binding for the given target, event and script provided to the function **/
void SetEventBinding(object oTarget, int nEventEnumeration, string sScript);
//In Use:
SetEventBinding(oPC, EVENT_BINDING_ONDEATH, "SomeDeathScriptForJustThisGuy");
Not sure this is the right discussion, but I’d love to see an iOS version that can play along side the PC one. Been salivating for that ever since BG:EE on my iPad totally re-opened my love for this type of game by making it so much easier to take everywhere. Connecting to modules etc. Could be done only with internet connection, but creating mods or playing solo could go offline.
As much as I’d love an iPad version, it just makes sense to have it be able to access the amazing trove of PC goodness build up over the years.
These are different hardcoded ProgFX functions Virusman was tackling for NWNCX. Personally, I think a card for the whole list would be most appropriate as an effects softcode request.
100 - EnvironmentMap I haven't seen it used anywhere, but it's actually configurable. ProgFX 101 = apply environment map vdu_envmap001, 102 = vdu_envmap002, etc. I don't know how it looks in game, though. 200 - SelfIllumination Calls some function with 3 floating point params (I guess it's color). Can be softcoded. 300 - LightSource Model name + some parameters. I don't think it's worth modifying. We have enough colors for light sources. 400 - Alpha 3 or 4 params. Can be softcoded. 500 - SelfIlluminationPulse 6 params. Can be softcoded. 600 - Beam Model name. Can be softcoded. 700 - UnloadModel I don't know what this does 800 - Chunk (gib) Heavily coded, nothing to do here. 900 - Mirv Model name + hardoded trajectory. I'm not sure if this will work if you just change the model name. 1000 - TextureReplace Texture name + some offset. Can be softcoded. 1100 - Cheat Cows from hell! 1200 - Spellfail I don't know what this does 1300 - Freeze animations Self-explanatory. Nothing to modify here.
These are different hardcoded ProgFX functions Virusman was tackling for NWNCX. Personally, I think a card for the whole list would be most appropriate as an effects softcode request.
100 - EnvironmentMap I haven't seen it used anywhere, but it's actually configurable. ProgFX 101 = apply environment map vdu_envmap001, 102 = vdu_envmap002, etc. I don't know how it looks in game, though. 200 - SelfIllumination Calls some function with 3 floating point params (I guess it's color). Can be softcoded. 300 - LightSource Model name + some parameters. I don't think it's worth modifying. We have enough colors for light sources. 400 - Alpha 3 or 4 params. Can be softcoded. 500 - SelfIlluminationPulse 6 params. Can be softcoded. 600 - Beam Model name. Can be softcoded. 700 - UnloadModel I don't know what this does 800 - Chunk (gib) Heavily coded, nothing to do here. 900 - Mirv Model name + hardoded trajectory. I'm not sure if this will work if you just change the model name. 1000 - TextureReplace Texture name + some offset. Can be softcoded. 1100 - Cheat Cows from hell! 1200 - Spellfail I don't know what this does 1300 - Freeze animations Self-explanatory. Nothing to modify here.
I know this is off-topic, but did Beamdog hire that Russian Neo we know as "Virusman"?
I'd like to have a change to the Override folder. Make it function like NWN2's Override folder. Allow it to read what's in a folder, so we don't have to dump stuff into the folder, forgetting what the files are for. Make the Override folder neat and tidy!
Ok here another one from the crazy wizard in the tower. hehe The ability to set character models to hand nodes of monster and make the main character invisible or literal have them in the hand node of the giant creature. So you have a giant creature that can grab/ bite in the monster mouth shakes/ grabbed in claw. The effect would not let the person move but still do actions, this get us closer to grapple system and/or creature special attacks like Rake, Constrict, Rend etc.. or even just custom systems to handle this. I already have a swallow whole system in place, but stuff like this would add to the wow affect.
Change sub-race and deity from type-in to a selection list (that can be modified or even re-created from scratch with haks).
Many people hate the forgotten realms (which neverwinter is part of) because there is a ton of subraces, but for every people that hate's it there is someone that loves that level of options.
Also, the forgotten realms is characterized by their deities even if they have no impact in the OC it adds flavor to the game. Clerics and Paladins can worship a deity and be within one step on either axis of alignment, but it would be nice to add an option to force everyone else (i.e. lawful good character's that worship Lolth seems a bit weird imo) to abide by that limit. It would also be nice an option to limit (or enable) demihuman deities to be worshiped only by their race (again, Humans worshiping Lolth might seem a bit out of place imo).
Well, usual disclaimer about not knowing if this is the right place for this suggestion, but here goes:
It would be so nice if the game could pre-load the linked areas to the current area. If a PC is in Area4, with three transitions to Area1, Area2, and Area7, the engine would load all those areas. Then when the PC moves through transition to Area7, which has 2 transitions (to Area4 and Area3), once Area7 is fully loaded, Area4 and Area3 would begin loading in background.
This would make transitions so much nicer and faster. Pie in the sky, maybe. But I love pie.
It would be nice if the bonuses from a Barbarian's Rage ability was in addition to the +12 Ability Bonus from spells and items. As is a well equipped Barbarian can have +12 Str and +12 Con from equipment and spells and then rage for a whopping -2 AC.
Unhardcoding the +12 cap and giving module creators more control over the ability caps would be great.
Well, usual disclaimer about not knowing if this is the right place for this suggestion, but here goes:
It would be so nice if the game could pre-load the linked areas to the current area. If a PC is in Area4, with three transitions to Area1, Area2, and Area7, the engine would load all those areas. Then when the PC moves through transition to Area7, which has 2 transitions (to Area4 and Area3), once Area7 is fully loaded, Area4 and Area3 would begin loading in background.
This would make transitions so much nicer and faster. Pie in the sky, maybe. But I love pie.
Merry Christmas!
-JFK
I tink it will be better, if can set the list of preloaded areas as a property of current area, and can change it with a script instruction like:
int SetPreloadArea( object oArea, object area_to_preload, int slot) Return False on memory out
Or Script only management:
PreloadArea(object Area_to_preload, int slot) Return False on memory out
To free mem any slot, put object_invalid on Area_to_preload.
Add in itemproperty that can adjust Armor check penalty (example master work armor lower armor check penalty by 1) I have work around with custom skill check function and Additional properties, but it does not show on skill list.
Can we get some prerequisites for animal companions/familiars (grayed out but can read the description) I have improved familiars that require a feat to have access and alternate animal companions that we can unlock at different levels of druid/ranger. This would open tier variety
+ Create doors, as placeables can be, at any location. (Relocating doors anywhere beyond doorways is already possible in the Toolset.)
+ Create triggers / encounters / traps with dynamic vector geometry arrays. Functions such as GetGeometry returning the vector array, SetGeometry, and attendant functions to get and set specific point vectors etc.
+ To get/set the bound scripts for all events on all individual objects; creatures, PCs, placeables, areas, and perhaps even module events.
+ OnSpawn events called only once for all appropriate objects; creatures, placeables, doors, items painted in the world, waypoints, triggers, etc.
+ Dynamic, customizable heartbeat events in addition to the default 6 second heartbeat. Functions to register, bind, and set the duration of additional heartbeat events on particular objects. Including changing the duration of any event including the default/zero-ID HB event to 0 seconds, which would deactivate/prevent the event from running until it's duration is reset (from which it will time down from normally) or called singly by a RunHeartbeatEvent() function.
E.g. Deactivate the default 6s hb on PC, enable new 30s hb, and 360s hb instead. Avoids the pitfalls of DelayCommand; including not needing to know what command to delay, as the bound event is independent of the duration for each registered hb.
+ Module events for OnHourChange (or OnNewHour or whatever), for Hour, Day, Week, Month, Year for the modules in-game time. Would have a GetHourNew and GetHourOld (GetDayOld, *New, etc.) functions.
+ Layering of multiple skins items, and other creature items, with itemproperties being additive. If/when itemproperties conflict, the property from the topmost/newest-added layer(s) overrides the lower. GetNumItemLayersTotal and GetNumItemLayersUsed, and SetNumItemLayersTotal (can't be lower than number of creature items currently equipped in that slot ie NumUsed). GetItemAtLayerInSlot to return the object for a particular skin/creature item.
Doubt the same system could be used for the armour slot, or the ring and amulet slots, without new/changed UI elements to allow more flexible layer-by-layer control and visibility to PCs, but this could be the backend for that; that would be fantastic though!
Toolset/Tileset/Objects (mostly):
+ Treat all tileset tiles/variations/objects/segments as appearances that are automatically usable by placeables, even if the endresult is purely cosmetic (lacks collision due to constraints or something).
+ Vice versa, allow all placeable appearances to be placed in the Toolset as "tile sub-parts", which will be baked/rendered as static parts of the area and not placeable objects (no events etc). Even if this is purely cosmetic, this would be awesome. Purely aesthetic area details with no need for functionality/collision/stats/etc could have all of that stripped away and no longer provide overhead, which I assume should allow areas of much greater cosmetic detail/value to be created for the same level of module overhead as currently possible with static objects and whatnot.
I'm assuming there could still be nwscript functions with this allowing for real-time creation and destruction of these "emptied placeables" without treating them as placeables; a function to convert an empty placeable appearance into an actual placeable using that appearance (and vice versa, to empty a placeable of everything and destroy the placeable instance, replacing it with an "emptied placeable") would also be stellar.
+ The above cosmetic / "emptied placeables" rendering should be adjustable client-side by a graphics option. However, this would imply builders having to categorize these emptied placeables into distinct layers, so would vary widely from area-area and module-module.
+ Generally improve how walkmeshes work to allow for: multiple walkable elevations at the same elevation (bridges, balconies, alcoves, etc), and maybe drawing and baking of walkmeshes more closely to how NWN2 handles it.
Comments
Below is a picture of the events you can set for a creature:
Would it not be safe to assume these events exist for PC's, but are just not exposed in NWScript?
I could see it being used like this:
const int VISIBILITY_NORMAL = 0x000000; const int VISIBILITY_INVISIBLE = 0x000001; const int VISIBILITY_SANCTUARY = 0x000010; const int VISIBILITY_STEALTH = 0x000100; const int VISIBILITY_CUSTOM1 = 0x001000; const int VISIBILITY_CUSTOM2 = 0x010000; const int VISIBILITY_CUSTOM3 = 0x100000; const int VISIBILITY_TRUESIGHT = 0x000111; const int VISIBILITY_ALL = 0x111111; /**DM SIGHT**/ /** Sets the visibility for the given target, 0x000000=normal, 0x000001=invisible, 0x000010=sanctuary, 0x____0= user defined) void SetVisibility(object oTarget, int nVisibility) /** Sets the vision for the given target, , 0x000000=normal, 0x000001=invisible, 0x000010=sanctuary, 0x____0= user defined) void SetVision(object oTarget, int nVisibility) /** Returns the visibility of the given object **/ void GetVisibility(oObject);This would allow us to set granular levels of visibility and sight.
Like this:
SetVision(oPC, VISIBILITY_CUSTOM1 | VISIBILITY_CUSTOM2); //PC can now see both CUSTOM1 and CUSTOM2 visibilityWhat I was suggesting was ability to run-time, dynamically assign events. Not just for PC's, but for everything.
I imagine it would work something like this:
const int EVENT_BINDING_HEARTBEAT = 1; const int EVENT_BINDING_ONDEATH = 2; const int EVENT_BINDING_ONSPAWN = 3; //so on and so forth... /** Sets the Event binding for the given target, event and script provided to the function **/ void SetEventBinding(object oTarget, int nEventEnumeration, string sScript); //In Use: SetEventBinding(oPC, EVENT_BINDING_ONDEATH, "SomeDeathScriptForJustThisGuy");As much as I’d love an iPad version, it just makes sense to have it be able to access the amazing trove of PC goodness build up over the years.
We need to be able to make custom rays and add custom visuals on weapons.
-Dave
The ability to set character models to hand nodes of monster and make the main character invisible or literal have them in the hand node of the giant creature. So you have a giant creature that can grab/ bite in the monster mouth shakes/ grabbed in claw. The effect would not let the person move but still do actions, this get us closer to grapple system and/or creature special attacks like Rake, Constrict, Rend etc.. or even just custom systems to handle this. I already have a swallow whole system in place, but stuff like this would add to the wow affect.
Many people hate the forgotten realms (which neverwinter is part of) because there is a ton of subraces, but for every people that hate's it there is someone that loves that level of options.
Also, the forgotten realms is characterized by their deities even if they have no impact in the OC it adds flavor to the game. Clerics and Paladins can worship a deity and be within one step on either axis of alignment, but it would be nice to add an option to force everyone else (i.e. lawful good character's that worship Lolth seems a bit weird imo) to abide by that limit. It would also be nice an option to limit (or enable) demihuman deities to be worshiped only by their race (again, Humans worshiping Lolth might seem a bit out of place imo).
Well, usual disclaimer about not knowing if this is the right place for this suggestion, but here goes:
It would be so nice if the game could pre-load the linked areas to the current area. If a PC is in Area4, with three transitions to Area1, Area2, and Area7, the engine would load all those areas. Then when the PC moves through transition to Area7, which has 2 transitions (to Area4 and Area3), once Area7 is fully loaded, Area4 and Area3 would begin loading in background.
This would make transitions so much nicer and faster.
Pie in the sky, maybe. But I love pie.
Merry Christmas!
-JFK
Unhardcoding the +12 cap and giving module creators more control over the ability caps would be great.
int SetPreloadArea( object oArea, object area_to_preload, int slot) Return False on memory out
Or Script only management:
PreloadArea(object Area_to_preload, int slot) Return False on memory out
To free mem any slot, put object_invalid on Area_to_preload.
+ Create doors, as placeables can be, at any location. (Relocating doors anywhere beyond doorways is already possible in the Toolset.)
+ Create triggers / encounters / traps with dynamic vector geometry arrays. Functions such as GetGeometry returning the vector array, SetGeometry, and attendant functions to get and set specific point vectors etc.
+ To get/set the bound scripts for all events on all individual objects; creatures, PCs, placeables, areas, and perhaps even module events.
+ OnSpawn events called only once for all appropriate objects; creatures, placeables, doors, items painted in the world, waypoints, triggers, etc.
+ Dynamic, customizable heartbeat events in addition to the default 6 second heartbeat. Functions to register, bind, and set the duration of additional heartbeat events on particular objects. Including changing the duration of any event including the default/zero-ID HB event to 0 seconds, which would deactivate/prevent the event from running until it's duration is reset (from which it will time down from normally) or called singly by a RunHeartbeatEvent() function.
E.g. Deactivate the default 6s hb on PC, enable new 30s hb, and 360s hb instead. Avoids the pitfalls of DelayCommand; including not needing to know what command to delay, as the bound event is independent of the duration for each registered hb.
+ Module events for OnHourChange (or OnNewHour or whatever), for Hour, Day, Week, Month, Year for the modules in-game time. Would have a GetHourNew and GetHourOld (GetDayOld, *New, etc.) functions.
+ Layering of multiple skins items, and other creature items, with itemproperties being additive. If/when itemproperties conflict, the property from the topmost/newest-added layer(s) overrides the lower. GetNumItemLayersTotal and GetNumItemLayersUsed, and SetNumItemLayersTotal (can't be lower than number of creature items currently equipped in that slot ie NumUsed). GetItemAtLayerInSlot to return the object for a particular skin/creature item.
Doubt the same system could be used for the armour slot, or the ring and amulet slots, without new/changed UI elements to allow more flexible layer-by-layer control and visibility to PCs, but this could be the backend for that; that would be fantastic though!
Toolset/Tileset/Objects (mostly):
+ Treat all tileset tiles/variations/objects/segments as appearances that are automatically usable by placeables, even if the endresult is purely cosmetic (lacks collision due to constraints or something).
+ Vice versa, allow all placeable appearances to be placed in the Toolset as "tile sub-parts", which will be baked/rendered as static parts of the area and not placeable objects (no events etc). Even if this is purely cosmetic, this would be awesome. Purely aesthetic area details with no need for functionality/collision/stats/etc could have all of that stripped away and no longer provide overhead, which I assume should allow areas of much greater cosmetic detail/value to be created for the same level of module overhead as currently possible with static objects and whatnot.
I'm assuming there could still be nwscript functions with this allowing for real-time creation and destruction of these "emptied placeables" without treating them as placeables; a function to convert an empty placeable appearance into an actual placeable using that appearance (and vice versa, to empty a placeable of everything and destroy the placeable instance, replacing it with an "emptied placeable") would also be stellar.
+ The above cosmetic / "emptied placeables" rendering should be adjustable client-side by a graphics option. However, this would imply builders having to categorize these emptied placeables into distinct layers, so would vary widely from area-area and module-module.
+ Generally improve how walkmeshes work to allow for: multiple walkable elevations at the same elevation (bridges, balconies, alcoves, etc), and maybe drawing and baking of walkmeshes more closely to how NWN2 handles it.
Adding fields to objects is fine, removing or changing them is OK at a pinch, but we do need the files to be legible.