Skip to content

Suggestions Thread: Structural (file formats, references, "hardcodedness", configuration)

1235711

Comments

  • SherincallSherincall Member Posts: 387
    There's no way GFF fields get removed. That'd break everything. At most they'd add more validation, such that some values that are invalid but were swallowed by the old game throw an error in the new one.

    @Omnipsi Those are valid requests. Some (OnSpawn, OnHourChange, customizable heartbeats) can be done in nwscript currently, though not as elegantly. Door/trigger painting and changing scripts can be done in NWNX. I know people are getting tired of me saying this, and I know NWNX is no good for single-player modules, but I'm just mentioning it in case it solves someone's use case. Item layering is "doable" but would get really messy.
    Anyone is free to PM me if they need help implementing any of the above.
  • OmnipsiOmnipsi Member Posts: 31
    @Sherincall Yep! Almost all of those suggestions arise from what I've scripted in the past in, indeed, quite clunkier ways than integration into the base game would facilitate.

    That said, the in-game painting of doors and triggers, and the rebinding of event scripts in particular (especially for the player characters events, to avoid the flaws and limitations of the "default" script) are actually ones I've wanted for singleplayer module building for a long time.

    You're definitely right though! My main motivator is just avoiding/reducing the practice of recursive delay loops as much as possible... :s
  • OmnipsiOmnipsi Member Posts: 31
    Change .mod Module archive format to contain .erf capsules within:

    Module resource limitations are no fun! Using haks to segregate resources isn't very fun either! Allow .mod archives to contain .erf archives (and/or other .mod archives?), and to load & unload those dependent resources when needed -- in Toolset, and in game (nwscript)!

    A la, dynamic resource loading; just for erf capsules within self-contained modules, instead of any external manipulation or resource-by-resource management. (NWNX:EE can still do all of that, probably much more efficaciously with a capsule loading backend to hook into and abuse lol.)

    To facilitate: nwscript functions to LoadCapsule and UnloadCapsule in real-time, operating on the preexisting capsules within the self-contained .mod archive! SP modules could load the capsule of areas (and their dependent content) currently needed, unloading that capsule when the PC moves to the next capsule of areas/content. Servers could more easily separate "geographical" and other demarcated batches of areas/content (as opposed to haks), unloading and loading content as its needed in real-time, improving server and client performance (if/when decently implemented by the mod builder, that is).

    Within the Toolset this would necessitate being able to drag resources from the "module palette" to an opened "capsule palette" and back and forth, easily relocating the corresponding files to the corresponding .erf within the .mod (temp0) archive. Resources saved to capsules would be manipulable as normal in the Toolset, when the capsule is opened alongside the module. The root of the .mod archive would still contain all the core module-specific resources (events, settings, start point, whatnot) along with universal resources the builder leaves there, ie scripts, items, and other core blueprints, that would be loaded with the mod and not be unloadable in real-time.
  • Dark_AnsemDark_Ansem Member Posts: 992
    This last suggestion would likely break compatibility. I fail to understand why the need for retro compatibility is so strong.
  • ShadowMShadowM Member Posts: 573
    Can we have mirror image spell, I love that spell, Yes I / others can do a workaround that sucks. So even if it an engine type workin that be great. :smile:
  • mangamusclemangamuscle Member Posts: 30

    This last suggestion would likely break compatibility. I fail to understand why the need for retro compatibility is so strong.

    NWN has been used to create modules and PWs for more than 15 years now. Making it so NWN can't run those modules would be insulting to the people that a) kept the game going even after it was abandoned by BioWare and b) are the most likely to purchase and support NWN:EE.
    Think of NWN as Windows, one of the reasons over the years people have choose it is because of the vast library of titles available. But with every new version of windows there comes new features that sometimes break compatibility. In the end people did not stop buying windows because many new titles were available (and you can always install an old version of windows on a separate hard disk if you really want to play the old classics).

    The real questions here should be "is said feature really worth breaking compatibility?" and "it is just a feature that will no longer be available or will it really break down modules?". If the new features are worth it no doubt people will buy NWN:EE and update the modules to work in it and write even more custom content, NWN:EE needs to be exciting and for that it needs new features the creator community wants.
  • SherincallSherincall Member Posts: 387
    Omnipsi said:

    Change .mod Module archive format to contain .erf capsules within:
    [snip]
    unloading and loading content as its needed in real-time, improving server and client performance (if/when decently implemented by the mod builder, that is).

    @Omnipsi Can you explain how this will improve performance? The server (and client, but that's a different story) already unload unused resources. It would be extremely difficult for you to manually manage these in nwscript better than the server does already - and the overhead of such scripts would likely render it pointless anyway.
    Grouping them into capsules makes it easier to add and remove whole systems when building a module - maybe moving an entire section between modules - but it only makes life easier for the dev. It doesn't affect performance.

    As a "let us do this so we can build things easier" request, this makes perfect sense. As a "let us do this to get better runtime performance", I don't think so.
  • OmnipsiOmnipsi Member Posts: 31
    @Sherincall Completely understandable! If that's the case, then my bad for misunderstanding. My assumption was:

    I'm assuming a system like ResMan/DynRes, where for example a persistent world may have hundreds of areas and thousands of scripts -- including heartbeats and whatnot -- and if many of those areas can be unloaded from the server at runtime it wouldn't have to process any of the scripts or other game systems in those unused areas unless a player wishes to go to those areas.

    Basically, what Sinfar does with it's "ERFs" / web interface.
  • SherincallSherincall Member Posts: 387
    Sorry, I might have misunderstood. That's active (i.e. spawned) objects, a wholly different beast. Areas are a bit weird in that they are always spawned. If you have an area with a creature in it, both the area and the creature will run the HB scripts.

    You can despawn the creature, and even the area in some cases with the new functions. If you're requesting functions to make it easier to despawn/respawn the already active object instances, then I totally misunderstood the request - but I still don't see why the recursive ERF unpacking is needed. The ERF (and MOD) contain the templates which are used to create the instances. Unloading the templates is done automatically. Again, areas are a bit weird in that the template is also an instance.

    FWIW, unless you literally have 10000+ areas in the module, simply despawning all the objects and bailing early in the HB script if no PCs are around will be enough. The overhead of starting and immediately ending the 10k scripts every 6 seconds isn't a big deal at all.
  • OmnipsiOmnipsi Member Posts: 31
    Yeah I was referring to the instances. I was under the impression nwscript HB events were more onerous than that, though, whoops. So yeah that's not actually a useful feature, hah.

    For the "recursive ERF" thing, that's to make it easier to build with the 16k resource limitation, directly within the Toolset (no external muckery). Automatically segmenting the module into (optional) sub-modules/erfs within the larger module archive, instead of manually removing resource files to separate .hak files.

    In that case, I just want modules to cope with resource limitations efficiently while still being self-contained; each sub-module/erf also facilitates/necessitates separate palette groupings, and the ERF export/import feature could export/import the erf archive (instead of selecting individual files as now) out of the module erf, making it much easier to share and collaborate on module building (without having to resort to using git or complex organizational hierarchies or any other bureaucracy).

  • SherincallSherincall Member Posts: 387
    Worth noting that the 16k resources limit is a bug that should be fixed regardless of recursive ERF implementation. The format supports much more resources. Agreed that managing the mod resources could use a lot of love.
  • JFKJFK Member Posts: 214
    This is a great suggestion. Should you post it on the Trello boards too? I'd vote for it.

    -JFK
  • ProlericProleric Member Posts: 1,316
    @JFK Thanks. I don't think I'm authorised to make new cards on Trello, but maybe Beamdog will, if people like my post here.
  • SymphonySymphony Member, Developer Posts: 142
    @Proleric This is an interesting idea, one I'd thought of a few times. Currently a way to prevent module players from using overrides/patch haks to change the default NWN resources used in the module (that come from the default installation), if module designers don't want them to, is to include the whole game's stock resources in their module haks! Which is kind of silly.

    Meanwhile, there's also likely an adverse reaction from players being told that they can't use their favorite sky/tile/head overrides by a module creator, so it is of course difficult to take sides, much like the issues I raised in the Area Rendering Customization discussion.

    Ultimately, however, the real issue is that if Beamdog changes the way that haks/overrides are stored/downloaded/loaded, which is something they feel strongly about changing, it may emphasize or de-emphasize the need for a setting like this to be present.

    With the current way that hak contents are validated (they aren't), however, losing overrides/patches (which are still loaded on client launch) wouldn't be foolproof, the haks on my computer for servers I am looking at/helping are often modified when I change their contents to audition fixes/upgrades before sending them to the server/module authors/admins for consideration.
  • TheUncertainManTheUncertainMan Member Posts: 49
    Already mentioned this around Christmas, just repeating in case it got buried.

    Please allow support for Wav 32bit PCM, as opposed to the vvurrent 16bit PCM limit.
    I hope the new sound subsystem can accommodate this.
  • SymphonySymphony Member, Developer Posts: 142
  • TheUncertainManTheUncertainMan Member Posts: 49
    Symphony said:
    Cheers! Cast my vote!
  • VirakeVirake Member Posts: 1
    Something needs to be done with the localization system.

    The original version of NWN had a colossal mountain of text. Every localizable string was stored in a single file called "dialog.tlk". The total number strings in it was 112009, and they were randomly mixed, by which I mean there was no way to isolate strings that related to general content (such as UI, spells, standard items, etc), from those that related specifically to the campaigns. There was also no logic to how the strings were ordered in the file, so you could expect to see 10 class names, followed by 5 dialogue options, followed by 9 item descriptions, followed by another 7 class names, and so on. This turned any localization effort into a madness-inducing punishment, because one couldn't divide the text into manageable chunks to set milestones.

    For example, let's say we want to make it possible to build modules and play them in my language. For that, we would (logically) only need to translate the interface, and wouldn't have to bother with the official campaigns. Alas, it's impossible with the current setup — for the reasons explained above. It's even worse with custom modules, since those usually don't have any localizable TLK-files at all, so we'd have to manually edit the modules themselves, possibly breaking them, and making updates incompatible (since they'd overwrite the translated text).

    Thus, my suggestions:
    1. Split the "dialog.tlk" into several smaller files with clusters of categorized strings: campaign A, campaign B, campaign C, interface, spells, feats, skills, standard items, standard NPCs, etc.
    2. Streamline the process of converting the TLK-files into common formats, such as XLS, XML, or plain text, so we could use localization tools to accurately measure the text and manage the translation process.
    3. Add a feature to the Toolset, or make an external utility, that would parse the module and export all localizable strings into custom TLK-files, while replacing the text in the module with references to the strings from the newly created TLK-files.
    Curiously, the original version of NWN's Toolset had a feature that allowed to store localizable strings in different languages, and to display a different version of a string depending on PC's gender. Also, at least one language (I was able to confirm Polish) had special tokens in "dialog.tlk" that accommodated the use of vocative case, effectively solving the problem translators face when localizing RPGs in Slavic languages.

    The issue with the current system is that the list of supported languages and those special tokens seem to be hardcoded into the game, or at least I wasn't able to find the way to modify them. In any case, my suggestions:
    1. Make language-specific tokens modifiable.
    2. Store localizable strings outside the module's file (preferably as categorized TLK-files).
  • SherincallSherincall Member Posts: 387
    edited January 2018
    CNWSMessage::SendServerToPlayerGuiTimingEvent() has a BYTE to specify which event we're timing. Valid values are 1-8 and they translate into string refs hardcoded on the client:
    [66919]Text:    Recovering Trap...
    [66921]Text:    Disarming Trap...
    [66923]Text:    Examining Trap...
    [66924]Text:    Setting Trap...
    [66925]Text:    Resting...
    [66926]Text:    Unlocking...
    [66928]Text:    Locking...  
    Could we get values above e.g. 127 to instead index into a custom 2DA for the text? This will let us schedule custom events like "Reloading..." or "Equipping..." and so on.
  • SurekSurek Member Posts: 9
    I know this wont be all that popular a suggestion however, as a builder I think having more options are always better. I would like to see an easier way to disable multiclassing, currently I think the only way to do this is a work around through scripting by deleveling a character and letting them know multiclassing is not allowed unless I missed something somewhere. I would like to see the option to somehow bypass the whole multiclassing thing all together.

    Sorry if this is not the right place to post this
  • ShadowMShadowM Member Posts: 573
    edited January 2018
    I would love a custom GUI screen that lets DM see a players Journal entries and edit/add journal entries of PC/party in-game and hit update and player journal flashes. I'm sure DMs would love this feature :)
  • BalanorBalanor Member Posts: 176
    While it's not possible for DMs to view player journals, it is already possible for DMs to create in-game dynamic journals that are updated and will have the player journal button flash when added/updated through the use of custom tokens. The Thay PW relies heavily on this for our DM scheduled events, rather than posting them on a forum site somewhere. Right now we have it setup to affect all players in the PW, but it could certainly be modified to apply only to a party or individual PC, if desired.
  • ShadowMShadowM Member Posts: 573
    edited January 2018
    Balanor said:

    While it's not possible for DMs to view player journals, it is already possible for DMs to create in-game dynamic journals that are updated and will have the player journal button flash when added/updated through the use of custom tokens. The Thay PW relies heavily on this for our DM scheduled events, rather than posting them on a forum site somewhere. Right now we have it setup to affect all players in the PW, but it could certainly be modified to apply only to a party or individual PC, if desired.

    I know, I have already done this in my base. I confused this is suggestion board and it is possible if they make the programing changes and add a custom UI. Imagine how much easier it would be to have a journal list of the selected player where you could just copy paste update a journal entry and/or click an add/delete button and to expanded to endless adventures. It just what we have taken to the next level, plus this would be out of the box no scripts needed and new people who dm would have a easier time.
  • Sunssarathi2029Sunssarathi2029 Member Posts: 32
    In mine opinion NWN EE or original lives mostly from its modding community so gradual softcoding of game (non UI) would be best option. I always thought of NWN as mine divine playground building and destroying worlds at whim.
  • ShadowMShadowM Member Posts: 573
    Can we get a new module event, called feat intercept. This would allow us to intercepting activating feat call into a script so we can add scripted requirement and function. Example You should not be able to activate furry of blows with a shield. With module event you can intercept it activation with a script requirement. This would save hassle with custom 2da work and ugly workarounds.
    Some custom function would be int GetlastFeatActivated() object GetlastfeatActivatedby
  • EurgigaEurgiga Member Posts: 8
    edited January 2018
    From the perspective of an NWN model maker/tweaker, the method by which the game composes and animates player characters is archaic and has long limited content creation. I couldn't guess if each of these could be done, but I would do the following to best enable your own development team and modelers like myself to make high-quality, flexible content.

    The robe and cloak emitters support skinmesh, transparency (cloak only) and can track multiple bones. Please extend this functionality to all emitters that comprise player characters. This is essential for being able to create more modern player models that flex, bend and flow through their motions rather than looking like a set of play-doh balls that've been gobbed together for a stop-motion project. Transparency in conjunction with these more flexible emitters will allow layering of parts to create the illusion of more complex geometries without having to waste modeling time and processing power. Parts that don't take advantage of this new feature would still be backwards-compatible but it opens up new avenues for us to develop in.

    If possible, it would be wonderful if we could skin parts on players and NPCs with animated textures. As with the above, lets the community create some cool things and cheat on our geometry a bit. I think the basic functionality of this has been explored with NWShader.

    NWN does character heads like a game from its time; that is to say it does them badly. Heads and hair are a single piece and helmets replace the head entirely. Ideally I would like to see heads broken up into bald heads and separate hair models like any modern sensible game does for flexibility and file size. I would additionally like hair to be able to skin to bones and support animation, it would be a massive improvement over danglymesh. I'd like helmets to not be hardcoded to modeltype 1. I'd like them instead to default to modeltype 2, the same modeltype as used by weapons. Weapons are gorgeous- they respect bones, support independent animations, skinning, transparency, everything. Extending this functionality to the helm slot in conjunction with modernizing the head composition will do absolute wonders for those of us out there prettifying this old workhorse of a game.

    Practically, however, I don't think it's developmentally feasible to redo how heads are composed. Helmets supporting modeltype 2 would be more than enough to allow new development in avenues impossible before while maintaining compatibility with existing content. Of course, please add the ability to call the helmet nodes for a modeltype 2 helmet as well- scripters will doubtless want to play with helmets that can be modified like weapons.

    I would like the armor of a dynamic player character to no longer control the appearance of the shin and foot emitters. I would like this responsibility shifted to the boot slot and have boots made modeltype 2 like with helmets above. Upper = kneecap, middle = shin, lower = foot. I'd like the same thing done for forearms/hands, having their appearance controlled by the bracer slot. By breaking up which parts control which emitters a bit you'll enable better and more flexible customization of dynamic characters.

    If possible, it would also be beneficial to change how NWN creates its races. Rather than having separate models for each race, the game should instead scale a single male or female dynamic character's individual nodes to a set of presets for that race/phenotype. This means I've only got to create two models instead of twenty-four if I want to support every base race, gender and phenotype. It also means that if, say, a new race is modded in, I don't have to create new models for it. Instead, the new race scales my existing model by its own presets- i.e. this makes our work waaaaaay more compatible and drastically reduces the overall workload on the modelers and disk footprint on your computer.
    Struck through, this is probably impractical.

    Finally, I'd like to encourage the development of a robust set of updated content creation tools so that the community can take advantage of all these lovely new toys.

    Post edited by Eurgiga on
Sign In or Register to comment.