What do people think about the radial menu layout? We hardcoded the locations so they would be consistent. If we added the ability to have a fourth class, where would that go? Are there other ideas on radial menu layout? I'd really like to have a place where we could have all the various radials diagrammed for reference and discussion of options.
I think consistency is important for the usability of radial menus in comparison to other styles. If you added the ability to have a fourth class, I think you'd need to increase the size of the radius, even if it means there are sometimes blank options. That said, eight seems the optimum number of items in a radial menu at the same time.
Perhaps have one radial option lead to class choices. If there is only one class for that character, immediately open that class's options submenu. If there are two or more classes, show the class icons. If they click the icon for one of those classes, they go to the options submenu for that class. It may seem like a needless layer, but it should be fairly fast to make a choice when the options are few, simple and obvious.
You could also, I suppose, make the initial radial menu (the first one the player sees) programmable, but you may have to insist one icon is there to open up a menu for "other options" that they removed (to protect the user from their selves). Or, instead, some menus could have blank slots that players could assign, such as on the "choose the class you wish to see the options for" radial menu.
My previous comment to your post disappeared. Perhaps it'll reappear. But just in case: a radial menu can be fine, eight options per radial screen is optimal, perhaps have a radial submenu to choose which class the player wants to see options for, and have any unused spot on that or any other submenu assignable as the player sees fit. Hence you have a consistent skeleton for radial options, but some flexibility as well.
Put your most important radial menu options consistently on the cardinal directions (up, down, left, right) and have assignable slots in the other directions (on a compass: nw, ne, sw, se). So the button for class (leading to a menu to choose which class you want to see options for) can always be on the "North" spot of the initial radial menu. The button for "feats" on the "West" spot. And so on.
What do people think about the radial menu layout? We hardcoded the locations so they would be consistent. If we added the ability to have a fourth class, where would that go? Are there other ideas on radial menu layout? I'd really like to have a place where we could have all the various radials diagrammed for reference and discussion of options.
I like the radial menu layout. The 4th (or more) class would simply go next to the existing ones and/or you'd add a slider in the character menu.
The ability to change an items base type and resref after creation would be quite lovely.
You can rename resrefs at the command line, or in temp0 in windows explorer, if you are careful. After renaming, you'll want to save the mod, close it, and reopen - just refreshing the affected palettes usually doesn't work due to some caching.
Now, that can break stuff; for example, if you re-resref an item, any creature, placeable, or store blueprint referencing that item will think the item is missing. I've got moneo scripts to help me with design maintenance arising from renaming resrefs, but they need to be customized for each operation and folks who use the toolset differently might need to write completely different scripts, but it is doable. I only handle the stuff I care about in my scripts, which keeps them tight. Automating these things in a large mod could lead to situations where you're waiting a long time (for large mods) every time you rename something.
If you're not worried about corrupting cross-references between resources like that though, it's very doable; I tend to rename new designs a lot during initial creation until I settle on some sort of naming convention.
You can change an item's base type with any GFF editor. If you've ever hacked a char with Leto, try the advanced editor and load up the item you want to change from the module's temp0 directory. You can change the baseitem type there by referencing baseitem.2da and updating the constant. You may have some other cleanup to do, either in the gff editor or the TS, depending on how crazy an edit you make. Eg. changing from a misc thin to a misc large item is fairly trivial, but changing a misc item into an armor piece may could some excitement as armors have some different properties than misc items. So, start with something reasonable to learn from and build up from there.
I use the Temp0 or export trick when doing mass deletions but I had no idea you could do the same with resrefs.
Although it is possible I still think it would be nice to be able to edit resref's in the toolset and have it do a cross reference sanity check to void duplicates and enforce the correct properties.
Cisco drilled it in to me that before you begin working you always block out your IP addresses and I can't help but do the same when modding. And like you said, naming conventions can drift during the life of a project and who is working on it.
Sometimes it would be nice to be able to quickly fix a mistake, or create a copy of a magic longsword and quickly change it to a magic hammer.
While we are tossing around dream features... shift/ctrl multi-select would be dreamy!
Can we get an .ini for combat to not automatically hit on a 20. Similar to the saving throws one. With everyone up-scaling levels. This will give option to builders if they want number of attack builds to trump high attack bonus builds. I know this is kinda controversial and that why it be an option.
Can we get an .ini for combat to not automatically hit on a 20. Similar to the saving throws one. With everyone up-scaling levels. This will give option to builders if they want number of attack builds to trump high attack bonus builds. I know this is kinda controversial and that why it be an option.
Agree with ShadowM request. Obviously it would be optional = OFF by default.
Expand the maximum space that server descriptions and module descriptions can have in the server browser. They've always been woefully short because they get truncated if its too long. There's a scroll bar in the server/module description window in the server browser; use it!
I'm not sure if this is where a request like this should go, but since it probably has something to do with ServerDesc.txt, I thought it should go here.
Changing the hardcoded Race Selection Screen to a dynamic List-like selection (like classes, feats... work) so custom player races are possible without the need of nwnx/leto.
Changing the hardcoded Race Selection Screen to a dynamic List-like selection (like classes, feats... work) so custom player races are possible without the need of nwnx/leto.
They said on the stream today that they're doing this.
I’ve seen this feature request in a couple of threads, (though admittedly not as much as I expected to,) and would like to highlight it a little more:
Auto-downloading of .HAKs etc, (Like in Neverwinter Nights 2.)
You guys are doing a fantastic job and really seem to understand the massive value that community content already brings (and will continue to bring,) to Neverwinter Nights. In my opinion, making that content as easily accessible as possible is an immensely powerful feature and kind of a big deal. Especially if you’re hoping to attract new players who might not be used to manually downloading and “installing” a game server’s files prior to connecting.
I accept adding this feature is a lot of faff. It was hard enough to get it working server-side with NWN2, so I can only imagine the pain it was to implement. However, I really think it would be worth it if Beamdog is aiming to achieve more than simply bringing old players back.
Failing that maybe the existing UI could be tweaked so that the server details text is less hidden and is immediately visible upon server selection. This way new players would be less likely to miss important warnings about file requirements, (and where to get said files). There seems to be abundant empty screen space to add this in now judging by the current build of NWN:EE .
You could also add the functionality to send users directly to the required files at the click of a button via the OS’s default browser. However, this is admittedly a more obvious potential user-security issue.
Custom Files should be hashed and checked against the server for clients.
Reasons: - Prevent Cheating from manually editing *.hak's (*.2da differences the server catches, but not different placeables/models and the like which could be used by players to get to places they shouldnt be allowed for example) - Making sure the client has the correct and non-corrupted custom files he needs, reducing possible problems a client could suffer (so many times there where player having problems which got fixed with a redownload)
I always wondered why cut and paste does not work in NMN text box - that really should be fixed - RP and web address for helping players and a lot more are needing cut and paste into the text box. this should not be a huge fix to make and would be a huge benifit to play and help on servers.
Some of these are repeats, but since I'm guessing Beamdog gauges that as an amount of interest as hinted in the streams, so I think its OK
- Softcoding of feats/skills so we can control their behavior via script (HiPS, Pick Pocket, etc).
- Softcode the rest button so that we can determine when / how far away "enemies are near". Often an enemy will be far away but not quite enough and sometimes players are unable to rest and locked out due to map design.
- ini setting for autohit on 20 as mentioned above.
- turn off collision detection for creatures as an option. can currently do this by applying EffectCutSceneGhost to all creatures. It'd be just nice to have a native .ini setting.
- I know this is wishful thinking but I wish new modules would have a cleaned up script library. right now there are three layers of xpacs (counting "x3") all layered on top of each other and its frankly a hot mess and difficult to follow / customize. ai and henchmen feel especially broken (e.g. the horse stuff makes it difficult to follow henchmen code and feels really buggy)
- Will object/creature scaling be in toolset only, or can it be dynamically done in game via script?
Softcode the VFX implementation or expose to scripting determination of what VFX gets applied to different sized creatures. For example, the VFX_DUR_PROT_STONESKIN applies the stone skin "texture" on medium creatures like NPCs, but applies a different cool animation with the spinning rocks on large creatures. It'd be nice to be able to access those different animations directly and, say, apply them to PCs or whatever without resorting to 2da modifications (which I know can be done by adding a new line, and calling out the proper resource for other sizes etc.). I am guessing there are more graphical assets out there that are untapped/unavailable in general through direct script call which might be found in an audit.
Fix the game client so it will run both .bik and .wbm file formats. As it stands right now, it only runs .wbm which breaks compatibility with earlier modules.
Some kind of softcoding or scripting hook into the associate commands on the radial menu would be wonderful (or if there is, I can't find it?).
The associate commands are player shouts, which call the function bkRespondToHenchmanShout() located in the x0_inc_henai script. Almost (all?) the game's AI is scripted versus hardcoded.
I would recommend that ALL hardcoding be removed, everything can be placed in xml files that can be overriden if so desired, it is incredible what the PrC did back in the day but even they found limits at what can be achieved (i.e. They could not change the starting package (gold) of a base class).
Because, let's get real, NWN is not remembered for the greatness of its built in adventure (like Baldur's Gate) but for the never before heard level of configurability, so it makes sense to improve the enhanced edition in that respect.
Also, dunno where to say this, but it should definitively use on the newest opengl and directx versions (and maybe even in vulcan), limiting it to opengl 2.1 and directx 9 would be akin to limiting Baldur's Gate EE to 256 colors.
Two new server ini options due to in part with the new server vault structure making it easier to reveal your alt accounts. Anonymity and separation of OOC and IC is very important on PWs:
HideLogin=0; 0 Is how it works now. 1 will hide the logout/login message for DMS (no so and so has joined/left game as a gamemaster). 2 will hide logout/login message for players or alternatively will say has joined game. PortraitTell=0; 0 is how it works now. 1 changes it so instead of sending a tell to the player account on portrait click, it sends a tell to the character.
Softcode the OnPlayerDying event threshold, defaulted to -10, but allow to anything in an ini file. Most people don't use this because most killing blows take the char to below -10 and the event isn't practical at higher levels. It would be great to use this subsystem for new "dying" methods other than just usually putting effectdeath() here and then working from there.
Comments
Just a personal QoL wish.
Perhaps have one radial option lead to class choices. If there is only one class for that character, immediately open that class's options submenu. If there are two or more classes, show the class icons. If they click the icon for one of those classes, they go to the options submenu for that class. It may seem like a needless layer, but it should be fairly fast to make a choice when the options are few, simple and obvious.
You could also, I suppose, make the initial radial menu (the first one the player sees) programmable, but you may have to insist one icon is there to open up a menu for "other options" that they removed (to protect the user from their selves). Or, instead, some menus could have blank slots that players could assign, such as on the "choose the class you wish to see the options for" radial menu.
The 4th (or more) class would simply go next to the existing ones and/or you'd add a slider in the character menu.
-Trent
Now, that can break stuff; for example, if you re-resref an item, any creature, placeable, or store blueprint referencing that item will think the item is missing. I've got moneo scripts to help me with design maintenance arising from renaming resrefs, but they need to be customized for each operation and folks who use the toolset differently might need to write completely different scripts, but it is doable. I only handle the stuff I care about in my scripts, which keeps them tight. Automating these things in a large mod could lead to situations where you're waiting a long time (for large mods) every time you rename something.
If you're not worried about corrupting cross-references between resources like that though, it's very doable; I tend to rename new designs a lot during initial creation until I settle on some sort of naming convention.
You can change an item's base type with any GFF editor. If you've ever hacked a char with Leto, try the advanced editor and load up the item you want to change from the module's temp0 directory. You can change the baseitem type there by referencing baseitem.2da and updating the constant. You may have some other cleanup to do, either in the gff editor or the TS, depending on how crazy an edit you make. Eg. changing from a misc thin to a misc large item is fairly trivial, but changing a misc item into an armor piece may could some excitement as armors have some different properties than misc items. So, start with something reasonable to learn from and build up from there.
-Dave
I use the Temp0 or export trick when doing mass deletions but I had no idea you could do the same with resrefs.
Although it is possible I still think it would be nice to be able to edit resref's in the toolset and have it do a cross reference sanity check to void duplicates and enforce the correct properties.
Cisco drilled it in to me that before you begin working you always block out your IP addresses and I can't help but do the same when modding. And like you said, naming conventions can drift during the life of a project and who is working on it.
Sometimes it would be nice to be able to quickly fix a mistake, or create a copy of a magic longsword and quickly change it to a magic hammer.
While we are tossing around dream features... shift/ctrl multi-select would be dreamy!
I'm not sure if this is where a request like this should go, but since it probably has something to do with ServerDesc.txt, I thought it should go here.
Auto-downloading of .HAKs etc, (Like in Neverwinter Nights 2.)
You guys are doing a fantastic job and really seem to understand the massive value that community content already brings (and will continue to bring,) to Neverwinter Nights. In my opinion, making that content as easily accessible as possible is an immensely powerful feature and kind of a big deal. Especially if you’re hoping to attract new players who might not be used to manually downloading and “installing” a game server’s files prior to connecting.
I accept adding this feature is a lot of faff. It was hard enough to get it working server-side with NWN2, so I can only imagine the pain it was to implement. However, I really think it would be worth it if Beamdog is aiming to achieve more than simply bringing old players back.
Failing that maybe the existing UI could be tweaked so that the server details text is less hidden and is immediately visible upon server selection. This way new players would be less likely to miss important warnings about file requirements, (and where to get said files). There seems to be abundant empty screen space to add this in now judging by the current build of NWN:EE
You could also add the functionality to send users directly to the required files at the click of a button via the OS’s default browser. However, this is admittedly a more obvious potential user-security issue.
Reasons:
- Prevent Cheating from manually editing *.hak's (*.2da differences the server catches, but not different placeables/models and the like which could be used by players to get to places they shouldnt be allowed for example)
- Making sure the client has the correct and non-corrupted custom files he needs, reducing possible problems a client could suffer (so many times there where player having problems which got fixed with a redownload)
- Softcoding of feats/skills so we can control their behavior via script (HiPS, Pick Pocket, etc).
- Softcode the rest button so that we can determine when / how far away "enemies are near". Often an enemy will be far away but not quite enough and sometimes players are unable to rest and locked out due to map design.
- ini setting for autohit on 20 as mentioned above.
- turn off collision detection for creatures as an option. can currently do this by applying EffectCutSceneGhost to all creatures. It'd be just nice to have a native .ini setting.
- I know this is wishful thinking but I wish new modules would have a cleaned up script library. right now there are three layers of xpacs (counting "x3") all layered on top of each other and its frankly a hot mess and difficult to follow / customize. ai and henchmen feel especially broken (e.g. the horse stuff makes it difficult to follow henchmen code and feels really buggy)
- Will object/creature scaling be in toolset only, or can it be dynamically done in game via script?
Probably more...I'll wait for the Trello boards!
Softcode the VFX implementation or expose to scripting determination of what VFX gets applied to different sized creatures. For example, the VFX_DUR_PROT_STONESKIN applies the stone skin "texture" on medium creatures like NPCs, but applies a different cool animation with the spinning rocks on large creatures. It'd be nice to be able to access those different animations directly and, say, apply them to PCs or whatever without resorting to 2da modifications (which I know can be done by adding a new line, and calling out the proper resource for other sizes etc.). I am guessing there are more graphical assets out there that are untapped/unavailable in general through direct script call which might be found in an audit.
Thanks.
Also an additional radial command for associates called "Move To" where the associate moves to a targeted location.
Softcode the SummonFamiliar and SummonCompanion functions so we can customize them like Summon Monster X.
Because, let's get real, NWN is not remembered for the greatness of its built in adventure (like Baldur's Gate) but for the never before heard level of configurability, so it makes sense to improve the enhanced edition in that respect.
Also, dunno where to say this, but it should definitively use on the newest opengl and directx versions (and maybe even in vulcan), limiting it to opengl 2.1 and directx 9 would be akin to limiting Baldur's Gate EE to 256 colors.
HideLogin=0; 0 Is how it works now. 1 will hide the logout/login message for DMS (no so and so has joined/left game as a gamemaster). 2 will hide logout/login message for players or alternatively will say has joined game.
PortraitTell=0; 0 is how it works now. 1 changes it so instead of sending a tell to the player account on portrait click, it sends a tell to the character.