It would be nice if some sounds that are immersion breaking were fixed. I don't feel like going to a camp in Infinite Dungeons should trigger sounds of people shouting in the streets. I also don't feel like my hero should shout about defeating an enemy when bashing a door/barrel/box/piece of furniture/chest; probably, nothing needs to be said there.
It would be nice if some sounds that are immersion breaking were fixed. I don't feel like going to a camp in Infinite Dungeons should trigger sounds of people shouting in the streets. I also don't feel like my hero should shout about defeating an enemy when bashing a door/barrel/box/piece of furniture/chest; probably, nothing needs to be said there.
According to the livestream recap, they confirmed they'll be facelifting the entire game to modern standards, and I'm thankful they aren't going to do just Aribeth and future content. However, I'm hoping this includes adding more animations to monsters. Some monsters, like the Minotaur, do not animate when using a bow or longbow due to a lack of animations for them. Slings animate fine, but don't visually appear. If it is possible, I'd like them to look back at these creatures and finish up their animations. Also, for creatures that would logically be able to use a weapon but can't (a troll doesn't visually wield or animate with a club, IIRC), I'd like them to add animations so they can use them. As others have suggested, making dynamic versions of some of the creature races would be good too.
I'd also like it if they didn't trample the original creature designs. I'm going to be super sad if they go for any of the PnP balor designs instead of the NWN design. Aribeth looks spot on except for her weird dress thing that was in a bunch of the artwork, so I'm sure I'll be happy with the rest of their work.
Also, I feel this should be a no brainer, but some of the creatures are going to need to need updated portraits. Any portrait that is painted/drawn digitally is fine, but some seem to be the models drawn over (Goblins, Blue Orcs, etc), or literally just the model (the Dragons). I'd like to see modern renditions of these portraits - as in the same portrait but freshly drawn to represent the new model better. It'd be great.
Hey @JuliusBorisov just wanted to make sure that some of my suggestions didn't get lost so I thought I'd post again. If you intentionally overlooked my suggestions because they're not feasible, they simply cannot be done, or they're buried somewhere on the Trello board, then it's all good. I've just posted a bunch in this thread and wanted to make sure they weren't forgotten. My paraphrased list from my posts:
-Put portraits and soundsets in easily accessible file locations so that if we cannot actually incorporate BG, BGII, and ID into NWN, then we can just simply do it ourselves. The reverse being true to incorporate files into the old IE games.
-Expanded color options/palettes for weapons and items. Same with containers, world objects (like doors), and monsters.
-Lore friendly height scales for player characters in character creation. Also possibly lore friendly skin color palettes for different races (as suggested by @Maloney ).
-Tattoo overlays that can be placed over skins, as opposed to entirely new skins with tattoos on them. Custom tattoo positioning, and the ability to make and import custom tattoos.
Tattoos should be almost doable as is, the new multiple UV channel support sorts that out (it'll be down to content creators and how they manage their layouts).
What's needed is the ability to hot-swap textures either during character creation or during gameplay via script.
That would be cool. But, what about using this for when you're splattered with blood? I really liked how my character would end up so bloody in DA:O. It was nice. So, if dynamic tattoos can be done, maybe this could be done when there's hand-to-hand killing involved?
im a fan of Magic The Gathering Artwork, or at least the community style of artists -- i feel each portrait, even each spell, could have a MtG style of artwork for it. Sadly, many of the player portraits are pretty bland --- i feel maybe if there was an app for the public to contribute artwork for nwn, maybe it could help. the game could then download artwork from a cloud server for players and monsters.
The ambient sound effects can use an overhaul. They sound tinny, repetitive, and nowhere near as high quality as this game deserves. Turning off the music and playing with headphones on this week really hammered home how limited they are, you could do so much better with some good sound design.
@1varangian I'd assume its so various larger creatures could fit through them, such as Iron Golems and Minotaur. If they were smaller, such creatures could have difficulty getting through them.
Some feature requests I had made on Redmine (among others already mentioned by other people here) are:
1) Emitters rendered behind transparent textures
This is possible if you define blending additive in the txi of the transparent texture, but it only looks okay in dark places not in outside areas where the colour of the sunlight is added and makes it look really bad. If you have a PC with a torch standing behind a statue made of glass you can see the PC and the torch, but not the smoke or flame of the torch. A fog placeable would also hide all emitters.
2) More than one type of 3d grass for tilesets
The possibility to have more than one type of 3d grass in a tilesets. Three or at the most four should be enough for all purposes. I did some tests and it seems the rendering of 3d grass only happens if the walkmesh material used is "3" for grass. Even if you define new materials in surfacemat.2da and those are named "grass" you don't get 3d grass for those. The one type of 3d grass you can use gets its information from the .set file. [GRASS] Grass=1 GrassTextureName=tcm01_grass3d Density=6.0 Height=0.7 AmbientRed=1.0 AmbientGreen=1.0 AmbientBlue=1.0 DiffuseRed=1.0 DiffuseGreen=1.0 DiffuseBlue=1.0
It would be nice if you could add two or three more entries to the set file labelled [GRASS1],[Grass2] and maybe also [GRASS3] with everything from GrassTextureName to DiffuseBlue. The "Grass=1" for enabling grass would only be needed once. Then have two or three new matrial types in surfacemat.2da: Label Walk WalkCheck LineOfSight Sound Name IsWater Visual 31 Grass1 1 1 1 GR GRASS1 0 * 32 Grass2 1 1 1 GR GRASS2 0 * 33 Grass3 1 1 1 GR GRASS3 0 **
And if one of those material types is used by a walkmesh render 3d grass according to the specifications definded in the .set file which correspond with the name of that material. If the name of the material is "GRASS1" and the set has [GRASS1] GrassTextureName=tcm01_flowers3d Density=3.0 Height=1.0 ... use that grass and if it doesn't, use the grass defined in the [GRASS] section of the .set file instead of not rendering any grass at all. That way people could also add grass that looks the same as the material 3 grass type, but has a different visual effect for footsteps.
3) More pathnodes
This probably belongs in another thread, so I will post it there.
Some feature requests I had made on Redmine (among others already mentioned by other people here) are:
1) Emitters rendered behind transparent textures
This is possible if you define blending additive in the txi of the transparent texture, but it only looks okay in dark places not in outside areas where the colour of the sunlight is added and makes it look really bad. If you have a PC with a torch standing behind a statue made of glass you can see the PC and the torch, but not the smoke or flame of the torch. A fog placeable would also hide all emitters.
2) More than one type of 3d grass for tilesets
The possibility to have more than one type of 3d grass in a tilesets. Three or at the most four should be enough for all purposes. I did some tests and it seems the rendering of 3d grass only happens if the walkmesh material used is "3" for grass. Even if you define new materials in surfacemat.2da and those are named "grass" you don't get 3d grass for those. The one type of 3d grass you can use gets its information from the .set file. [GRASS] Grass=1 GrassTextureName=tcm01_grass3d Density=6.0 Height=0.7 AmbientRed=1.0 AmbientGreen=1.0 AmbientBlue=1.0 DiffuseRed=1.0 DiffuseGreen=1.0 DiffuseBlue=1.0
It would be nice if you could add two or three more entries to the set file labelled [GRASS1],[Grass2] and maybe also [GRASS3] with everything from GrassTextureName to DiffuseBlue. The "Grass=1" for enabling grass would only be needed once. Then have two or three new matrial types in surfacemat.2da: Label Walk WalkCheck LineOfSight Sound Name IsWater Visual 31 Grass1 1 1 1 GR GRASS1 0 * 32 Grass2 1 1 1 GR GRASS2 0 * 33 Grass3 1 1 1 GR GRASS3 0 **
And if one of those material types is used by a walkmesh render 3d grass according to the specifications definded in the .set file which correspond with the name of that material. If the name of the material is "GRASS1" and the set has [GRASS1] GrassTextureName=tcm01_flowers3d Density=3.0 Height=1.0 ... use that grass and if it doesn't, use the grass defined in the [GRASS] section of the .set file instead of not rendering any grass at all. That way people could also add grass that looks the same as the material 3 grass type, but has a different visual effect for footsteps.
3) More pathnodes
This probably belongs in another thread, so I will post it there.
On the grass I like to suggest you go even one step further Have the toolset allow up to three types of model grass(dropdown of all compatible grass/flower/plants models) with density / height setting define for each in the area properties. These would generated on tile-sets marked as grass walkmesh. If you leave all three boxes blank then there is no grass generated. This would add add a lot of variety to each area even though they using the same tile-set. I hope @JuliusBorisov add this into the trello board that already created of height per area category LINK.
That would be better than seeing a *Tumble: success* above the character's head, wouldn't it?
A swift dodge while moving would be best. Over the top flips and rolls might work for acrobatic Rogues, but armored Fighters and robed Wizards use Tumble too.
edit: I realized theres the Mobility feat that does a similar thing. Maybe it all comes down to just having a dodge animation while moving.
~Dialog Visual Revamp Moving Mouths model animations, and a Dialog remake to match would be nice, think KoToR level mouth-movements probatly seeing as otherwise it'd need more systems to make it advanced in lip-movement.
But i think it'd be nice with dialogs doing the zoomed in on characters shifting inbetween the talkers while talking thing that it does in KoToR, Mass Effect and NWN 2 even (atleast for the NPC's with voicelines), especialy with recently shown off graphical-revamp which would benefit it greatly, showing off those HD textures on a closer-perspective as you dialog with NPC's (it could be toggleable all the same for those that prefer the game without it) or for like NPC's with shorter dialogs not having the zoom-in, but it would make for a more immersive experience overall, atleast in my mind.
Some feature requests I had made on Redmine (among others already mentioned by other people here) are:
1) Emitters rendered behind transparent textures
This is possible if you define blending additive in the txi of the transparent texture, but it only looks okay in dark places not in outside areas where the colour of the sunlight is added and makes it look really bad. If you have a PC with a torch standing behind a statue made of glass you can see the PC and the torch, but not the smoke or flame of the torch. A fog placeable would also hide all emitters.
2) More than one type of 3d grass for tilesets
The possibility to have more than one type of 3d grass in a tilesets. Three or at the most four should be enough for all purposes. I did some tests and it seems the rendering of 3d grass only happens if the walkmesh material used is "3" for grass. Even if you define new materials in surfacemat.2da and those are named "grass" you don't get 3d grass for those. The one type of 3d grass you can use gets its information from the .set file. [GRASS] Grass=1 GrassTextureName=tcm01_grass3d Density=6.0 Height=0.7 AmbientRed=1.0 AmbientGreen=1.0 AmbientBlue=1.0 DiffuseRed=1.0 DiffuseGreen=1.0 DiffuseBlue=1.0
It would be nice if you could add two or three more entries to the set file labelled [GRASS1],[Grass2] and maybe also [GRASS3] with everything from GrassTextureName to DiffuseBlue. The "Grass=1" for enabling grass would only be needed once. Then have two or three new matrial types in surfacemat.2da: Label Walk WalkCheck LineOfSight Sound Name IsWater Visual 31 Grass1 1 1 1 GR GRASS1 0 * 32 Grass2 1 1 1 GR GRASS2 0 * 33 Grass3 1 1 1 GR GRASS3 0 **
And if one of those material types is used by a walkmesh render 3d grass according to the specifications definded in the .set file which correspond with the name of that material. If the name of the material is "GRASS1" and the set has [GRASS1] GrassTextureName=tcm01_flowers3d Density=3.0 Height=1.0 ... use that grass and if it doesn't, use the grass defined in the [GRASS] section of the .set file instead of not rendering any grass at all. That way people could also add grass that looks the same as the material 3 grass type, but has a different visual effect for footsteps.
3) More pathnodes
This probably belongs in another thread, so I will post it there.
On the grass I like to suggest you go even one step further Have the toolset allow up to three types of model grass(dropdown of all compatible grass/flower/plants models) with density / height setting define for each in the area properties. These would generated on tile-sets marked as grass walkmesh. If you leave all three boxes blank then there is no grass generated. This would add add a lot of variety to each area even though they using the same tile-set. I hope @JuliusBorisov add this into the trello board that already created of height per area category LINK.
~Dialog Visual Revamp Moving Mouths model animations, and a Dialog remake to match would be nice, think KoToR level mouth-movements probatly seeing as otherwise it'd need more systems to make it advanced in lip-movement.
But i think it'd be nice with dialogs doing the zoomed in on characters shifting inbetween the talkers while talking thing that it does in KoToR, Mass Effect and NWN 2 even (atleast for the NPC's with voicelines), especialy with recently shown off graphical-revamp which would benefit it greatly, showing off those HD textures on a closer-perspective as you dialog with NPC's (it could be toggleable all the same for those that prefer the game without it) or for like NPC's with shorter dialogs not having the zoom-in, but it would make for a more immersive experience overall, atleast in my mind.
~Dialog Visual Revamp Moving Mouths model animations, and a Dialog remake to match would be nice, think KoToR level mouth-movements probatly seeing as otherwise it'd need more systems to make it advanced in lip-movement.
But i think it'd be nice with dialogs doing the zoomed in on characters shifting inbetween the talkers while talking thing that it does in KoToR, Mass Effect and NWN 2 even (atleast for the NPC's with voicelines), especialy with recently shown off graphical-revamp which would benefit it greatly, showing off those HD textures on a closer-perspective as you dialog with NPC's (it could be toggleable all the same for those that prefer the game without it) or for like NPC's with shorter dialogs not having the zoom-in, but it would make for a more immersive experience overall, atleast in my mind.
I do not know KoTOR @JuliusBorisov but what you say happens in NWN2 when you start an important dialogue of the main story you activate a mode (cinema) in this mode the NPCs talk to each other and the interlocutor or the NPC you talk with moves your mouth .. .I do not know how things work but I think it's a great addition to the game! and it would renew most of the dialogues in the basic campaigns! imagine a similar feature while talking to Aribeth at the beginning of the first chapter! seeing my character talking to her and moving his mouth while talking with a cinema-like effect would be very nice.
Here is an example taken from NWN2 (see point 1:29):
Just a thought to go along with the new grasses,set file,walkmesh features. The ability for a pwk to override the walkmesh it's placed on. Maybe a radius setting around the pwk to nullify walkmesh effects. For example, a box in tall grass (so the grass isn't growing thru the box... this usually entails trying to find a piece of dirt patch with wok faces actually set to material dirt). I'm sure there are other situations where this might be handy.
I would kill for an easier way to get custom portraits into the Aurora Toolset. Right now, you have to put them in a .hak and update a .2da file, whereas I feel that the toolset should just use the game's portraits folder.
@krynnmeridia that would be OK if you were only using the toolset for your own amusement, but authors who share their work with other players need to package portraits and other media, too - hence the hak. If using the portraits folder were permitted, it ought to be an option defaulting to "off", because otherwise it would undermine the integrity checking that ensures that what the author sees is what the player gets.
@Proleric I definitely see your point- maybe if you only needed a .hak? I'm just really kind of annoyed at the current process, because I use a massive custom portrait pack (~800 ports, IIRC) that I put together, and getting it into the toolset made me die inside.
Another suggestion- I'd like a way to customize the tileset light colors, as seen here: . The presets are nice, but I'd like full control over them.
Finally, a way to create, save, and share Area Visual Schemes would be nice. These things: . Again, I like a lot of the presets, but they aren't good for everything and the only way to change them involves going to every single terrain block in the area and changing the light colors. You also can't reuse those changes, which means that if you want to create another area with the same color palette, you have to go through and change everything manually again. This is another nightmare for time management, and something that's really bothered me for literal years.
@krynnmeridia , you can add Area Visual schemes for yourself, if you like, by adding lines to environment.2da. This 2da file can live in your override or in your haks once updated. I don't know if there's a handy description of what's what in that file, but it's not too hard to reverse engineer, IIRC.
I've seen the lightcolor question raised before, but I forget if there's anything reasonable that can be done about it - I think mostly I've seen people mod the gui, not the colors. (That doesn't mean it can't be done - I like your suggestion!). I think there's a lightcolor 2da, but I'm not sure if it ties into this or not - I haven't played with it - I've *think* just seen it used for customizing multiple versions of a placeable model with different color (again, IIRC, haven't poked it directly), so I'm not sure if it is relevant.
@shadguy I didn't know that, thanks! I'd still like a way to do it natively in the toolset, especially since, after looking at environment.2da, it looks like a major pain in the butt to do manually.
@shadguy I didn't know that, thanks! I'd still like a way to do it natively in the toolset, especially since, after looking at environment.2da, it looks like a major pain in the butt to do manually.
However, customization is global, cannot be done per-area, due to the .are format used by the game. If @beamdog was to update the system, they'd need to extend the .are gff structure to include new fields to override the current ones:
Right now, main lights and source lights use an index to a predefined palette of colors (for main lights it's a 2da, for source lights the colors are defined by the animation ID in a specific model file, fx_flame01.mdl). As such, custom light colors in an RGB format are not supported. Beamdog would need to add new fields, for example Tile_MainLight1_New, Tile_MainLight2_New, Tile_SrcLight1_New, Tile_SrcLight2_New, and support them on the engine level, by loading them in case they exist in the .are tile entry, and falling back to the current field names in case they're missing. Furthermore, there would be the need to add a new toolset function to be able to pick and set such custom colors. The approach is linear enough, but requires some work.
Regarding environment.2da, it is customizable as @shadguy pointed out, and furthermore it is only used by the toolset, as a template/set of values that are transferred to the .are file, so that the 2da isn't needed anymore once the area settings are set, and you don't need to distribute it to the server/clients. The only annoying limitation is that the environment name that you see in the toolset requires a tlk string - which forces you to re-use a string already present in the dialog.tlk (since adding a custom tlk only for using it in the toolset isn't really practical, you'd need to remember to remove the custom tlk from the module properties before distributing it)
To build your custom environment, first customize your area the way you like it, then open the area/module with the appropriate tool (NwNEditor for example), and check the area properties, like this:
You can just copy and paste the values to the various columns in environments.2da, or, even better, pick an existing environment and just edit its values accordingly to your taste
For tile light colors, you can pick them from the toolset GUI, keeping in mind that:
- color IDs start from 0, not from 1 - so the range is 0-31
- the first value (0) is the top left corner, and the engine reads the values from left to right, and from the top row to the bottom.
Just input the corresponding color IDs into the tile color columns.
It sounds like a lot of work, but the advantage is that once it's done you can apply your environment scheme to any area you create
[edit] By the way, all this is not to say that it wouldn't be nice to have a better system to handle all these settings, just providing some context and a temporary solution while we wait to see whether Beamdog will add such improved tools
@Proleric I definitely see your point- maybe if you only needed a .hak? I'm just really kind of annoyed at the current process, because I use a massive custom portrait pack (~800 ports, IIRC) that I put together, and getting it into the toolset made me die inside.
Incidentally, why do you need to import your 800 portraits pack into the toolset? I'm asking because usually that only makes sense if you want to use the portraits for NPCs
@LaputianBird I've made a bunch of very large modules, each with a very large cast (none of which are published, since they're not very good IMO). I like having all my portraits available in the toolset. Not all the portraits are PCs, either- a lot of them are pictures from the Monster Manuals and the like, since I really hate a lot of NWN's default portraits for the monsters.
@LaputianBird I've made a bunch of very large modules, each with a very large cast (none of which are published, since they're not very good IMO). I like having all my portraits available in the toolset. Not all the portraits are PCs, either- a lot of them are pictures from the Monster Manuals and the like, since I really hate a lot of NWN's default portraits for the monsters.
Alright, I was mainly curious, in the odd chance you were taking an unnecessary step.
Comments
About animation: "Animations in Neverwinter Nights: Enhanced Edition work fine but we’d like to improve them." http://blog.beamdog.com/2018/02/february-9-livestream-recap.html
Added another card: https://trello.com/c/OaGVS203/155-add-missing-animations
-Put portraits and soundsets in easily accessible file locations so that if we cannot actually incorporate BG, BGII, and ID into NWN, then we can just simply do it ourselves. The reverse being true to incorporate files into the old IE games.
-Expanded color options/palettes for weapons and items. Same with containers, world objects (like doors), and monsters.
-Lore friendly height scales for player characters in character creation. Also possibly lore friendly skin color palettes for different races (as suggested by @Maloney ).
-Tattoo overlays that can be placed over skins, as opposed to entirely new skins with tattoos on them. Custom tattoo positioning, and the ability to make and import custom tattoos.
What's needed is the ability to hot-swap textures either during character creation or during gameplay via script.
I had the kind of same idea for voicesets.
And narrow corridors as well.
1) Emitters rendered behind transparent textures
This is possible if you define blending additive in the txi of the transparent texture, but it only looks
okay in dark places not in outside areas where the colour of the sunlight is added and makes it look really
bad.
If you have a PC with a torch standing behind a statue made of glass you can see the PC and the torch, but
not the smoke or flame of the torch. A fog placeable would also hide all emitters.
2) More than one type of 3d grass for tilesets
The possibility to have more than one type of 3d grass in a tilesets. Three or at the most four should be enough for all
purposes. I did some tests and it seems the rendering of 3d grass only happens if the walkmesh material
used is "3" for grass. Even if you define new materials in surfacemat.2da and those are named "grass"
you don't get 3d grass for those.
The one type of 3d grass you can use gets its information from the .set file.
[GRASS]
Grass=1
GrassTextureName=tcm01_grass3d
Density=6.0
Height=0.7
AmbientRed=1.0
AmbientGreen=1.0
AmbientBlue=1.0
DiffuseRed=1.0
DiffuseGreen=1.0
DiffuseBlue=1.0
It would be nice if you could add two or three more entries to the set file labelled [GRASS1],[Grass2]
and maybe also [GRASS3] with everything from GrassTextureName to DiffuseBlue. The "Grass=1" for enabling
grass would only be needed once.
Then have two or three new matrial types in surfacemat.2da:
Label Walk WalkCheck LineOfSight Sound Name IsWater Visual
31 Grass1 1 1 1 GR GRASS1 0 *
32 Grass2 1 1 1 GR GRASS2 0 *
33 Grass3 1 1 1 GR GRASS3 0 **
And if one of those material types is used by a walkmesh render 3d grass according to the specifications
definded in the .set file which correspond with the name of that material.
If the name of the material is "GRASS1" and the set has
[GRASS1]
GrassTextureName=tcm01_flowers3d
Density=3.0
Height=1.0
...
use that grass and if it doesn't, use the grass defined in the [GRASS] section of the .set file instead of
not rendering any grass at all. That way people could also add grass that looks the same as the material 3
grass type, but has a different visual effect for footsteps.
3) More pathnodes
This probably belongs in another thread, so I will post it there.
Have the toolset allow up to three types of model grass(dropdown of all compatible grass/flower/plants models) with density / height setting define for each in the area properties. These would generated on tile-sets marked as grass walkmesh. If you leave all three boxes blank then there is no grass generated. This would add add a lot of variety to each area even though they using the same tile-set. I hope @JuliusBorisov add this into the trello board that already created of height per area category LINK.
That would be better than seeing a *Tumble: success* above the character's head, wouldn't it?
A swift dodge while moving would be best. Over the top flips and rolls might work for acrobatic Rogues, but armored Fighters and robed Wizards use Tumble too.
edit: I realized theres the Mobility feat that does a similar thing. Maybe it all comes down to just having a dodge animation while moving.
Moving Mouths model animations, and a Dialog remake to match would be nice, think KoToR level mouth-movements probatly seeing as otherwise it'd need more systems to make it advanced in lip-movement.
But i think it'd be nice with dialogs doing the zoomed in on characters shifting inbetween the talkers while talking thing that it does in KoToR, Mass Effect and NWN 2 even (atleast for the NPC's with voicelines), especialy with recently shown off graphical-revamp which would benefit it greatly, showing off those HD textures on a closer-perspective as you dialog with NPC's (it could be toggleable all the same for those that prefer the game without it) or for like NPC's with shorter dialogs not having the zoom-in, but it would make for a more immersive experience overall, atleast in my mind.
Here is an example taken from NWN2 (see point 1:29):
Here I found an example from KoTOR:
Add a Dwarf male Hood face.
in arelith, for example, you can use -hood to switch your model to the hood face when you want, but one of the few without this is the dwarves!
Another suggestion- I'd like a way to customize the tileset light colors, as seen here:
The presets are nice, but I'd like full control over them.
Finally, a way to create, save, and share Area Visual Schemes would be nice. These things:
Again, I like a lot of the presets, but they aren't good for everything and the only way to change them involves going to every single terrain block in the area and changing the light colors. You also can't reuse those changes, which means that if you want to create another area with the same color palette, you have to go through and change everything manually again. This is another nightmare for time management, and something that's really bothered me for literal years.
I've seen the lightcolor question raised before, but I forget if there's anything reasonable that can be done about it - I think mostly I've seen people mod the gui, not the colors. (That doesn't mean it can't be done - I like your suggestion!). I think there's a lightcolor 2da, but I'm not sure if it ties into this or not - I haven't played with it - I've *think* just seen it used for customizing multiple versions of a placeable model with different color (again, IIRC, haven't poked it directly), so I'm not sure if it is relevant.
-Dave
However, customization is global, cannot be done per-area, due to the .are format used by the game. If @beamdog was to update the system, they'd need to extend the .are gff structure to include new fields to override the current ones:
Right now, main lights and source lights use an index to a predefined palette of colors (for main lights it's a 2da, for source lights the colors are defined by the animation ID in a specific model file, fx_flame01.mdl).
As such, custom light colors in an RGB format are not supported.
Beamdog would need to add new fields, for example Tile_MainLight1_New, Tile_MainLight2_New, Tile_SrcLight1_New, Tile_SrcLight2_New, and support them on the engine level, by loading them in case they exist in the .are tile entry, and falling back to the current field names in case they're missing. Furthermore, there would be the need to add a new toolset function to be able to pick and set such custom colors. The approach is linear enough, but requires some work.
Regarding environment.2da, it is customizable as @shadguy pointed out, and furthermore it is only used by the toolset, as a template/set of values that are transferred to the .are file, so that the 2da isn't needed anymore once the area settings are set, and you don't need to distribute it to the server/clients.
The only annoying limitation is that the environment name that you see in the toolset requires a tlk string - which forces you to re-use a string already present in the dialog.tlk (since adding a custom tlk only for using it in the toolset isn't really practical, you'd need to remember to remove the custom tlk from the module properties before distributing it)
To build your custom environment, first customize your area the way you like it, then open the area/module with the appropriate tool (NwNEditor for example), and check the area properties, like this:
You can just copy and paste the values to the various columns in environments.2da, or, even better, pick an existing environment and just edit its values accordingly to your taste
For tile light colors, you can pick them from the toolset GUI, keeping in mind that:
- color IDs start from 0, not from 1 - so the range is 0-31
- the first value (0) is the top left corner, and the engine reads the values from left to right, and from the top row to the bottom.
Just input the corresponding color IDs into the tile color columns.
It sounds like a lot of work, but the advantage is that once it's done you can apply your environment scheme to any area you create
[edit] By the way, all this is not to say that it wouldn't be nice to have a better system to handle all these settings, just providing some context and a temporary solution while we wait to see whether Beamdog will add such improved tools