One special request from me. right now you cant have more then 15 letters for your textures but sometimes i need way more. I have a pretty special naming convention for everything i create so i know what is what within my 1000 plus texture folder...
So please...raise it up to at least 25!
@NWN_Töml Sorry to disappoint, but that's not at all easy. NWN expects 16.3 names everywhere, and changing that is a lot of work. Changing that in a way that keeps backwards compatibility is even more so.
ah, and this is true also for other resources?
I guess it is true for any external resource, i.e. file names and everything that can translate to a file name. Internal nodes and objects do not seem to have such a limitation
One special request from me. right now you cant have more then 15 letters for your textures but sometimes i need way more. I have a pretty special naming convention for everything i create so i know what is what within my 1000 plus texture folder...
So please...raise it up to at least 25!
@NWN_Töml Sorry to disappoint, but that's not at all easy. NWN expects 16.3 names everywhere, and changing that is a lot of work. Changing that in a way that keeps backwards compatibility is even more so.
ah, and this is true also for other resources?
I guess it is true for any external resource, i.e. file names and everything that can translate to a file name. Internal nodes and objects do not seem to have such a limitation
Request to have the ability to manipulate water flow via Toolset and scripting. Some discussion also in the above thread.
Thanks!
-JFK
Luckily Modders can do this with Shader effects. A non-trivial issue but not something we need beamdog to do, as oppose to some of the more hard coded things.
Request to have the ability to manipulate water flow via Toolset and scripting. Some discussion also in the above thread.
Thanks!
-JFK
Luckily Modders can do this with Shader effects. A non-trivial issue but not something we need beamdog to do, as oppose to some of the more hard coded things.
Actually, we do need BD to open up wind for scripting! Right now, you can only set the values (0,0,0), (1,1,0) and (2,2,0) in the toolset. The shaders depend on wind for a lot of things, but the server can't fine tune it.
Actually, we do need BD to open up wind for scripting! Right now, you can only set the values (0,0,0), (1,1,0) and (2,2,0) in the toolset. The shaders depend on wind for a lot of things, but the server can't fine tune it.
Better to have wind opened up to scripting, that way we can use it to drive shaders rather than having shaders as a work around! That way you can have your spell effects / fog / fire / smoke / weather visuals all showing the same environmental inputs.
Better to have wind opened up to scripting, that way we can use it to drive shaders rather than having shaders as a work around! That way you can have your spell effects / fog / fire / smoke / weather visuals all showing the same environmental inputs.
In the case the issue is about blocking the default weather effects from applying to specific parts of the area. Adding a better technology wouldn't help, unless it overrode the current one.
I'm reiterating my request for better mtr file support. Right now the data is kind of split between mdl and mtr which makes it difficult to use.
1. Specifiying mtr Files Ideally mtr files would be handled through the bitmap parameter. If an mtr with the name from the bitmap parameter is present textures would be loaded from there. If not it behaves like in vanilla NWN and loads the texture file directly. That way it would be very easy to update old content with the new normal and specular maps. But I'm not sure if that change is possible anymore at this point in time.
2. Adding Normal and Specular Maps Right now if we want to use the (default) normal and spec mapping shaders we need to add a renderhint to the mdl file. Renderhint uses a shader based on object/node type. We also have to add texture1 and texture2 to the mdl at the very least with null values. Solely relying on mtr files for textures is not possible, because if texture1/2 is not present in the mdl they are ignored in the mtr as well. This not an issue if we write our own custom shaders but only a minority is willing or capable to do that.
What (kinda) works is explicitly specifying default shaders in the mtr (e.g. vslitc_nm, fslit_nm). Then we can skip texture1/2 in the mdl and the textures in the mtr will always be used. But that leads to toolset crashes if the wrong shaders are specified, as different types of shaders are needed depending on object/node type (what renderhint would choose for us). For example a placeable will cause an error if a static lighting shader is used and the placeable is set to non-static.
If we still wants to use mtr files and make it work reliably with the default shaders we have to add:
bitmap X
renderhint NormalAndSpecMapped
texture1 NULL
texture2 NULL
And then overwrite the textures again in the mtr. That's way too ambiguous and creates too much clutter for my taste. Material files would be more useful and easier to use if renderhint was moved to mtr and the textures always loaded from there:
A single line would be enough to use materials (materialname myMaterial)
Updating vanilla content with normal and specular maps would be easier
Retexturing models and entire tilesets would be easier, as it would only require changing texture names in the mtr
Creating Import/Export scripts would be way easier. It wouldn't require checking multiple files for the same parameters for import. It would make it easier to decide where to put the all the values (Do I want to put texture in the mdl or mtr? Do I need a renderhint or do I use custom shaders?)
In addition to liking Sym's post, I also find it insightful and agree with it.
I want to add that it is easy to add those renderhint and texture lines to a new creature or placeable you just made, a little more work when it is a tileset group, but once you add those lines the model compilers we have now are unable to compile the models. Now you might end up with a 6000 polygon model that is uncompiled and will cause serious lag when it appears in game whereas it worked just fine when it was compiled before.
It is also really bad if you have to add the renderhint and texture lines to an existing tileset of 2500 tiles and not just once for each tile, but once for each mesh of the tile that uses a texture to which you want to add a normal and/or specular map. Even with grep or things like that if they can handle regular expressions this still is a tremendous amount of work and only once you finished it will you be able to see how it will affect framerates, at which point your tileset may already have become unusable and all the work was for nothing.
I'm going to add a few remarks of my own to what @symmetric and @Zwerkules already posted regarding the mtr topic:
1. the game resman already uses the bitmap string for a lookup across different file extension (plt/dds/tga should be the current order). The update would need to add the .mtr on top of the stack, which would enable the material system to work as an optional plugin for body/clothing parts as well (and any other model types that make use of the plt textures) 2. the system would need to be applied not only to the "bitmap" string, but also to the "texture" string (the one used by emitters), hence allowing us to specify materials for such nodes 3. the request would plug in and extend a separate request I posted, that would implement texturepacks for tilesets. Specifically, the "textures" that would be referenced by the tileset config 2da file would be .mtr files as first option, and dds/tga only when the mtr file doesn't exist 4. overall, the system not only would streamline the workflow, but it would also clearly separate the data types, leaving the geometry and mapping to the .mdl file nodes (that need to be served to the engine in a compiled form, whether pre-compiled or compiled on the fly), and the texturing and post-processing (i.e. custom shaders) to be setup in an external & textual environment without the need to handle it inside a 3d modeling program. 5. a fully external material system would allow current import/export scripts and ASCII-manipulation tools to handle the new 1.74 format natively without the need of being reworked
I believe one of the key points of the BD approach is that of extending the range of possibilities for CC makers, while keeping a fundamental backward compatibility. I should hope that such extension won't come at the cost of an unnecessarily complication of the workflow, because that would most likely result in a decreased will to invest time and energies into continuing the NWN tradition of a lively CC scene
Hopefully this is the right place to suggest this. Possible old bug or intended behavior I'm not sure. Copied from NWN Lexicon:
VFX_DUR_FREEZE_ANIMATION 352 Description: Causes a creature to freeze in midanimation. It can be problematic using this for statues: If you script a creature to play an animation, then freeze the creature in the middle of it, you'd expect it to stand that way for the duration of this visual effect. It works perfectly well if the PC is nearby when the visual effect here is applied. If, however, the PC doesn't see the animation being played, and sometimes even if he leaves the area and then comes back, the PC will see the NPC standing frozen, and stiff as a board.
Hopefully this is the right place to suggest this. Possible old bug or intended behavior I'm not sure. Copied from NWN Lexicon:
VFX_DUR_FREEZE_ANIMATION 352 Description: Causes a creature to freeze in midanimation. It can be problematic using this for statues: If you script a creature to play an animation, then freeze the creature in the middle of it, you'd expect it to stand that way for the duration of this visual effect. It works perfectly well if the PC is nearby when the visual effect here is applied. If, however, the PC doesn't see the animation being played, and sometimes even if he leaves the area and then comes back, the PC will see the NPC standing frozen, and stiff as a board.
Hopefully this is the right place to suggest this. Possible old bug or intended behavior I'm not sure. Copied from NWN Lexicon:
VFX_DUR_FREEZE_ANIMATION 352 Description: Causes a creature to freeze in midanimation. It can be problematic using this for statues: If you script a creature to play an animation, then freeze the creature in the middle of it, you'd expect it to stand that way for the duration of this visual effect. It works perfectly well if the PC is nearby when the visual effect here is applied. If, however, the PC doesn't see the animation being played, and sometimes even if he leaves the area and then comes back, the PC will see the NPC standing frozen, and stiff as a board.
1) Fixing the Wearable Armors to better match D&D 3.0 rules by un-hardcoding the appearance to specific AC values, making any "chest" appearance able to have any AC value and Any Dex Bonus value.
Some crossovers in D&D exist that were wrongly categorized in NWN, like the "Chainshirt" with an AC +4 with Dex Bonus +4 in the "Medium Armor" category. (Should be "Light Armor" category)
Would also allow for existing appearances, like the chest-tabards to be included in different 'weight' categories for light, medium and heavy armors.
2) UN-hardcode Ability bonus stacking. Things like Natural Armor do not stack (which is correct, they shouldn't) but also ability-score modifying enhancements shouldn't stack either, for example, Belts with +2 STR and Gloves with +3 STR should _NOT_ give you +5 STR... it should take the greater value and not the sum. I know a lot of L33T power builds would be gimped by this so instead of making it cross-the-board change, at least un-hardcode it, so it can be toggled active/inactive.
D&D 3.0 edition rules are the basis for this game great! But a lot of those rules (like mentioned above) were wrongly implemented in NWN (and carried over to NWN-EE) -whatever can at least be un-hardcoded for a PW/Custom Module builder to make a true-er D&D 3.0 rules experience, all the better!
On the roadmap you can also find unhardcoding the armor 2da, that would allow making different types of armor. The main problem is that the armor type AC value is also the row index number more or less as a rough explanation.
I also think stacking rules should be more strictly observed or at least it should be easier to enforce them for modders. I believe it would probably need a redo of the effects / item properties systems so that it accurately checks for type, source, and name when determining if it stacks or overlaps. The most common erroneous stacking is from saving throws, also damage and attack bonuses, rather than ability scores.
Without reading all the pages here, I'd like to make a suggestion for the addition of custom content.
Currently, the game requires data be input into 2da files for such things as appearances of characters and other models (containers, props, etc.).
What we really need is a method by which appearances are referenced not by numeric index, but by some kind of string tag, or unique code. If individuals want to give their appearance an alias, create an appearance alias 2da where specific codes can be referenced by a string.
As a suggestion, replace the model file name column in appearance.2da with a reference to meshes.2da. The layout of meshes.2da would simply have:
line number
unique appearance code (indexed column)
appearance model file
optional appearance alias (default ****)
default envmap reference (overridden by content from appearance.2da)
vanilla option (provides a backup plan in case this mesh is not on the client side)
This would allow any number of models to be used as an appearance for props and characters without getting in the way of each other by line number, and would not require individuals to use a specific service or hosting point to dispense their custom content.
The code generator can be simple, and should reduce almost all double-indexing. Use primarily a timestamp, and modify for something associated with the machine of the content creator. Perhaps a third randomizing agent is needed. The timestamp alone should prevent double indexing. For custom content created in the past, convert the upload date-time code on "The Vault" to an appropriate unique ID.
Update scripting to allow reference of the meshes by alias rather than appearance id using GetAppearanceByAlias() or GetAppearanceByUniqueId(). Provide a list of variables for existing content. Allow CEP and other packages to create a separate appearance alias variable set.
Allow an attempt to reference appearances without that appearance being available in the directory structure. Return a default not-available mesh for appearances not physically available.
As another option, develop another file type which stores appearances by containing just the model and some appearance file. Possibly envmaps and textures. Create a subdir called meshes, much like HAK or ERF. Automatically append to the engine any files in that folder, so that they can be used in the toolset. Files are named using their unique code (note: longer than 16 chars).
To prevent abuse of bounding sizes and walkspeed over network play, bounding sizes are pulled from ID-matching appearances on the server. This allows users to modify the appearances of their units on their own machine if they really want to, but prevents their appearance from overcoming obstacles or modifying their walk speed. Any scripting call to a uniqueID or alias while in network play will use the server 2das and meshes folder.
If a suitable match is not found on the client side, a vanilla option specification uses an existing model which is part of the original package. For example, if the server has a MESHES folder which contains a new orc model, but the client has not yet downloaded that mesh kit in to their MESHES folder, then the client defaults to using the appearance of the vanilla orc.
And I very much forgot to request this earlier, but I kinda have always needed it: give the toolset the ability to raise/lower tiles without raising or lowering the adjacent tiles. Please please please. We could do so much with this.
HEY! you #DEV guys were looking for Borland C++ Builder to help rebuild Neverwinter Nights for EE right? I found some stuff listed for just that - will any of this help you??
I would love the ability to modify the point buy system at character creation. Currently we get a pool of 30 points to start with but there's no way to adjust that up or down. Different campaigns/modules might want to have the option to tinker with that.
I would also love to be able to change the action bar keybindings. The f1-f12 buttons are not comfortable to use imo. I'd prefer to be able to remap the action bar buttons to the standard 1 through = sign.
I would love the ability to modify the point buy system at character creation. Currently we get a pool of 30 points to start with but there's no way to adjust that up or down. Different campaigns/modules might want to have the option to tinker with that.
I would also love to be able to change the action bar keybindings. The f1-f12 buttons are not comfortable to use imo. I'd prefer to be able to remap the action bar buttons to the standard 1 through = sign.
I have two suggestions. One should be easy to implement but is of minor usefulness. The second is probably a lot harder to implement but would open up the game to some huge possibilities.
First suggestion:
Control tile animations with two new scripting commands: SetTileAnimation(vector vWhere, int iBoolean); int iBoolean=GetTileAnimation(vector vWhere);
The first is a command to either turn on (TRUE) or off (FALSE) any tile animation for the tile (or tile group) at the x and y location stored in the vector. The second command returns TRUE if the tile animation is running or FALSE if the tile animation is not running, or the tile or group has no valid animation. You can test in-script whether or not a tile has a valid animation by trying to set it to TRUE and then testing it. If it's still FALSE, then the tile has no valid animation.
Why? This would be good for stories where you have to deliver grain to a windmill. Logically, the windmill wouldn't be running until you deliver the grain. Similarly, if you needed to deliver a part to repair the water pump, logically it wouldn't be running until you left the building after delivering the part.
Second suggestion:
Tile variants, controlled by two new scripting commands: SetTileVariant(vector vWhere,int iVariant); int iVariant=GetTileVariant(vector vWhere);
This would allow you to have multiple "variants" of a particular tile or tile group, which can be switched between in scripting by using the variant number.
Why? Suppose you want to simulate seasons and/or the growing of crops?
Seasons: Seed heads in summer (current default), yellowed grass in autumn, withered stalks in winter and flowers in spring. (Variants 0-3, respectively)
Crops: An area of ground could look exactly like all the surrounding areas until you hire a farmer to farm it, then the script changes it from variant 0 to variant 1 and suddenly the earth looks tilled with furrows ready for planting. A little later and the script changes it to variant 2 showing the earth has been planted. Later still, the variant is changed to 3 and green shoots are showing.
Variants 4 and 5 show the crops half-grown and then fully mature, ready to be harvested.
Variant 6 shows the crops have been harvested and only stubble is left, then variant 7 shows fallow earth which is ready to be tilled for the next planting.
The first feature would be nice to have, but the second would be absolutely fantastic. If implemented correctly (so that variant 0 is always whatever the current tile texture is), it should be compatible with 1.69.
GIve player and NPC actions category flags to (for example) allow a NPC to remain seated while holding a conversation.
Basically, any action which doesn't conflict with the currently running action can be performed concurrently without cancelling the previous action.
Sitting would not set the flag which says that the action requires the NPC to be mobile. Start Conversation would have a flag set which says that it requires the NPC to be immobile.
Since the two flags do not conflict, the player would be able to converse with the NPC without the NPC ceasing to sit. The action would not be cancelled.
If the NPC is walking, then their "mobile" flag is set, which means that an On Conversation has to interrupt the current action before it can start the conversation.
Once a conversation has started, the NPC has a flag set which requires them to cancel the conversation in order to be able to move to another place (unless they're moving in order to sit down and the place is close to where they are now, similar to how a player can move a short distance before conversation is automatically cancelled).
For compatibility, all actions without flags would be treated as "all flags required" so all actions by default would conflict with all other actions, as they do right now.
I'd like to request the ability to select the default skin color on a per-race basis (RacialTypes.2da or Appearances.2da would be ideal, I think).
As a secondary request, it would be nice to limit the color selection for skin selection during character creation. I.E: This race can only select from X, Y, and Z colors.
Comments
1. Specifiying mtr Files
Ideally mtr files would be handled through the bitmap parameter. If an mtr with the name from the bitmap parameter is present textures would be loaded from there. If not it behaves like in vanilla NWN and loads the texture file directly.
That way it would be very easy to update old content with the new normal and specular maps. But I'm not sure if that change is possible anymore at this point in time.
2. Adding Normal and Specular Maps
Right now if we want to use the (default) normal and spec mapping shaders we need to add a renderhint to the mdl file. Renderhint uses a shader based on object/node type.
We also have to add texture1 and texture2 to the mdl at the very least with null values. Solely relying on mtr files for textures is not possible, because if texture1/2 is not present in the mdl they are ignored in the mtr as well.
This not an issue if we write our own custom shaders but only a minority is willing or capable to do that.
What (kinda) works is explicitly specifying default shaders in the mtr (e.g. vslitc_nm, fslit_nm). Then we can skip texture1/2 in the mdl and the textures in the mtr will always be used. But that leads to toolset crashes if the wrong shaders are specified, as different types of shaders are needed depending on object/node type (what renderhint would choose for us).
For example a placeable will cause an error if a static lighting shader is used and the placeable is set to non-static.
If we still wants to use mtr files and make it work reliably with the default shaders we have to add: And then overwrite the textures again in the mtr. That's way too ambiguous and creates too much clutter for my taste. Material files would be more useful and easier to use if renderhint was moved to mtr and the textures always loaded from there:
I want to add that it is easy to add those renderhint and texture lines to a new creature or placeable you just made, a little more work when it is a tileset group, but once you add those lines the model compilers we have now are unable to compile the models. Now you might end up with a 6000 polygon model that is uncompiled and will cause serious lag when it appears in game whereas it worked just fine when it was compiled before.
It is also really bad if you have to add the renderhint and texture lines to an existing tileset of 2500 tiles and not just once for each tile, but once for each mesh of the tile that uses a texture to which you want to add a normal and/or specular map. Even with grep or things like that if they can handle regular expressions this still is a tremendous amount of work and only once you finished it will you be able to see how it will affect framerates, at which point your tileset may already have become unusable and all the work was for nothing.
1. the game resman already uses the bitmap string for a lookup across different file extension (plt/dds/tga should be the current order). The update would need to add the .mtr on top of the stack, which would enable the material system to work as an optional plugin for body/clothing parts as well (and any other model types that make use of the plt textures)
2. the system would need to be applied not only to the "bitmap" string, but also to the "texture" string (the one used by emitters), hence allowing us to specify materials for such nodes
3. the request would plug in and extend a separate request I posted, that would implement texturepacks for tilesets. Specifically, the "textures" that would be referenced by the tileset config 2da file would be .mtr files as first option, and dds/tga only when the mtr file doesn't exist
4. overall, the system not only would streamline the workflow, but it would also clearly separate the data types, leaving the geometry and mapping to the .mdl file nodes (that need to be served to the engine in a compiled form, whether pre-compiled or compiled on the fly), and the texturing and post-processing (i.e. custom shaders) to be setup in an external & textual environment without the need to handle it inside a 3d modeling program.
5. a fully external material system would allow current import/export scripts and ASCII-manipulation tools to handle the new 1.74 format natively without the need of being reworked
I believe one of the key points of the BD approach is that of extending the range of possibilities for CC makers, while keeping a fundamental backward compatibility. I should hope that such extension won't come at the cost of an unnecessarily complication of the workflow, because that would most likely result in a decreased will to invest time and energies into continuing the NWN tradition of a lively CC scene
I think it could be extended to display at least 256 if not 512 which should be more than enough.
I also posted before about the classes.2da limit which if I recall correctly was limited at 256 or so, and should probably be extended to 1048.
VFX_DUR_FREEZE_ANIMATION 352
Description: Causes a creature to freeze in midanimation. It can be problematic using this for statues: If you script a creature to play an animation, then freeze the creature in the middle of it, you'd expect it to stand that way for the duration of this visual effect. It works perfectly well if the PC is nearby when the visual effect here is applied. If, however, the PC doesn't see the animation being played, and sometimes even if he leaves the area and then comes back, the PC will see the NPC standing frozen, and stiff as a board.
Is it possible to get this fixed?
1) Fixing the Wearable Armors to better match D&D 3.0 rules by un-hardcoding the appearance to specific AC values, making any "chest" appearance able to have any AC value and Any Dex Bonus value.
Some crossovers in D&D exist that were wrongly categorized in NWN, like the "Chainshirt" with an AC +4 with Dex Bonus +4 in the "Medium Armor" category. (Should be "Light Armor" category)
Would also allow for existing appearances, like the chest-tabards to be included in different 'weight' categories for light, medium and heavy armors.
2) UN-hardcode Ability bonus stacking. Things like Natural Armor do not stack (which is correct, they shouldn't) but also ability-score modifying enhancements shouldn't stack either, for example, Belts with +2 STR and Gloves with +3 STR should _NOT_ give you +5 STR... it should take the greater value and not the sum. I know a lot of L33T power builds would be gimped by this so instead of making it cross-the-board change, at least un-hardcode it, so it can be toggled active/inactive.
D&D 3.0 edition rules are the basis for this game great! But a lot of those rules (like mentioned above) were wrongly implemented in NWN (and carried over to NWN-EE) -whatever can at least be un-hardcoded for a PW/Custom Module builder to make a true-er D&D 3.0 rules experience, all the better!
I also think stacking rules should be more strictly observed or at least it should be easier to enforce them for modders. I believe it would probably need a redo of the effects / item properties systems so that it accurately checks for type, source, and name when determining if it stacks or overlaps. The most common erroneous stacking is from saving throws, also damage and attack bonuses, rather than ability scores.
Currently, the game requires data be input into 2da files for such things as appearances of characters and other models (containers, props, etc.).
What we really need is a method by which appearances are referenced not by numeric index, but by some kind of string tag, or unique code. If individuals want to give their appearance an alias, create an appearance alias 2da where specific codes can be referenced by a string.
As a suggestion, replace the model file name column in appearance.2da with a reference to meshes.2da. The layout of meshes.2da would simply have:
- line number
- unique appearance code (indexed column)
- appearance model file
- optional appearance alias (default ****)
- default envmap reference (overridden by content from appearance.2da)
- vanilla option (provides a backup plan in case this mesh is not on the client side)
This would allow any number of models to be used as an appearance for props and characters without getting in the way of each other by line number, and would not require individuals to use a specific service or hosting point to dispense their custom content.The code generator can be simple, and should reduce almost all double-indexing. Use primarily a timestamp, and modify for something associated with the machine of the content creator. Perhaps a third randomizing agent is needed. The timestamp alone should prevent double indexing. For custom content created in the past, convert the upload date-time code on "The Vault" to an appropriate unique ID.
Update scripting to allow reference of the meshes by alias rather than appearance id using GetAppearanceByAlias() or GetAppearanceByUniqueId(). Provide a list of variables for existing content. Allow CEP and other packages to create a separate appearance alias variable set.
Allow an attempt to reference appearances without that appearance being available in the directory structure. Return a default not-available mesh for appearances not physically available.
As another option, develop another file type which stores appearances by containing just the model and some appearance file. Possibly envmaps and textures. Create a subdir called meshes, much like HAK or ERF. Automatically append to the engine any files in that folder, so that they can be used in the toolset. Files are named using their unique code (note: longer than 16 chars).
To prevent abuse of bounding sizes and walkspeed over network play, bounding sizes are pulled from ID-matching appearances on the server. This allows users to modify the appearances of their units on their own machine if they really want to, but prevents their appearance from overcoming obstacles or modifying their walk speed. Any scripting call to a uniqueID or alias while in network play will use the server 2das and meshes folder.
If a suitable match is not found on the client side, a vanilla option specification uses an existing model which is part of the original package. For example, if the server has a MESHES folder which contains a new orc model, but the client has not yet downloaded that mesh kit in to their MESHES folder, then the client defaults to using the appearance of the vanilla orc.
https://winworldpc.com/library/dev
I would also love to be able to change the action bar keybindings. The f1-f12 buttons are not comfortable to use imo. I'd prefer to be able to remap the action bar buttons to the standard 1 through = sign.
The second request has been on the Input board for some time: https://trello.com/c/RZyEGW4m/154-add-keybindings
First suggestion:
Control tile animations with two new scripting commands:
SetTileAnimation(vector vWhere, int iBoolean);
int iBoolean=GetTileAnimation(vector vWhere);
The first is a command to either turn on (TRUE) or off (FALSE) any tile animation for the tile (or tile group) at the x and y location stored in the vector.
The second command returns TRUE if the tile animation is running or FALSE if the tile animation is not running, or the tile or group has no valid animation.
You can test in-script whether or not a tile has a valid animation by trying to set it to TRUE and then testing it. If it's still FALSE, then the tile has no valid animation.
Why?
This would be good for stories where you have to deliver grain to a windmill. Logically, the windmill wouldn't be running until you deliver the grain.
Similarly, if you needed to deliver a part to repair the water pump, logically it wouldn't be running until you left the building after delivering the part.
Second suggestion:
Tile variants, controlled by two new scripting commands:
SetTileVariant(vector vWhere,int iVariant);
int iVariant=GetTileVariant(vector vWhere);
This would allow you to have multiple "variants" of a particular tile or tile group, which can be switched between in scripting by using the variant number.
Why?
Suppose you want to simulate seasons and/or the growing of crops?
Seasons:
Seed heads in summer (current default), yellowed grass in autumn, withered stalks in winter and flowers in spring.
(Variants 0-3, respectively)
Crops:
An area of ground could look exactly like all the surrounding areas until you hire a farmer to farm it, then the script changes it from variant 0 to variant 1 and suddenly the earth looks tilled with furrows ready for planting. A little later and the script changes it to variant 2 showing the earth has been planted. Later still, the variant is changed to 3 and green shoots are showing.
Variants 4 and 5 show the crops half-grown and then fully mature, ready to be harvested.
Variant 6 shows the crops have been harvested and only stubble is left, then variant 7 shows fallow earth which is ready to be tilled for the next planting.
The first feature would be nice to have, but the second would be absolutely fantastic. If implemented correctly (so that variant 0 is always whatever the current tile texture is), it should be compatible with 1.69.
GIve player and NPC actions category flags to (for example) allow a NPC to remain seated while holding a conversation.
Basically, any action which doesn't conflict with the currently running action can be performed concurrently without cancelling the previous action.
Sitting would not set the flag which says that the action requires the NPC to be mobile.
Start Conversation would have a flag set which says that it requires the NPC to be immobile.
Since the two flags do not conflict, the player would be able to converse with the NPC without the NPC ceasing to sit. The action would not be cancelled.
If the NPC is walking, then their "mobile" flag is set, which means that an On Conversation has to interrupt the current action before it can start the conversation.
Once a conversation has started, the NPC has a flag set which requires them to cancel the conversation in order to be able to move to another place (unless they're moving in order to sit down and the place is close to where they are now, similar to how a player can move a short distance before conversation is automatically cancelled).
For compatibility, all actions without flags would be treated as "all flags required" so all actions by default would conflict with all other actions, as they do right now.
As a secondary request, it would be nice to limit the color selection for skin selection during character creation. I.E: This race can only select from X, Y, and Z colors.
Thanks!
https://trello.com/c/jDIueN1V/209-new-tile-animations-controls
https://trello.com/c/iFnD9H2s/210-allow-npcs-to-remain-seated-while-holding-a-conversation
My halfling is wearing a Cloak of Elvenkind and a Leather Armor +1, aka the Ambassador of Portugal starting pack.