I have been on-off with the NWN Toolset for a long time, this time I’ve decided to dive deeper than I had ever before. And I started to ask myself questions about the basic workflow for various things. Cause I felt like I was doing something wrong.
I used to think this way: I’ll create a new module “ModuleOfAwesome”, and this is my main module and I’ll do the area designs here, test scripts and also import lots of custom content for testing. When I messed up here, I didn’t even knew about the export feature - so I lost all of my items etc. cause I wanted to start “fresh” yet again.
// Lately I’ve begun to think that this is the worst thing to do, I found out when one time I messed up an “global” script. I told to myself that from now on, I will test the scripts inside an separate test module. Then I figured, for anything new I am going to import - I’ll always test inside separate modules too! And if I like anything, I’ll export (from test module) and import (into the “main module”). Am I on the right path with this one?
I wanted to ask the more experienced users a bit more specifically
Do you design a new area inside an separate module and later import it into your main module?
How to you create different items & assets, that you are wanting to use for years to come inside your other modules? Do you create these also in a blank module and again export all the items / objects? Are you keeping things separated in a way, like “items.erf” and “objects.erf” (having separate modules for these both).
Can you recommend or point me to an solid naming scheme for areas,creatures, items, objects, scripts, conversations (etc.) - something which is preferably an standard community “template” here? I’d absolutely prefer to follow something like that, what the more experienced Toolset users are doing!
And if you have any more tips about workflows with the Toolset, please share!
Now I’m about the worst person to be replying to this because I don’t think my approach is classic so better to wait until the more experienced come along but what I do is
At the end of day 1 get a version that works and call it “Master1” (usually adding date)
Start of day 2 I save that as “Test1” and then proceed on that one.
If, during the day I make a fair amount of progress I save regularly increasing the version by 1 so “Test2”, “Test3” etc.
At the end of day 2 the last completely working module becomes “Master2”
So, if during the day I get a crash or something is flaky that I don’t like I go back to the previous “Test” version and continue from there again.
Important thing is I always finish the day by testing what will become the day’s Master properly.
I’m not an experience modder, but I have some suggestions:
depends on the complexiry of the area
Creating them somewhere and store them as erf is fine.
a) make unique names for tag and blueprint ID, Never use a blueprint ID - such as “item004” or “area001” - given by the toolset. (I “lost” two or three areas for until I learned this.)
b) use speaking names, if possible.
c) see above, there is no rule, but it’s no witcheswork.
d) make copies of your mod, but always keep the old saves. For my mod I’m working on, I’ve already 30 or 40 copies - so there is a good chance to find something again, after it was accidently deleted in the current version.
Once confident, I started doing most things in the main module, taking regular backups so that major screw-ups can be regressed.
However, for anything really tricky, such as evaluating new tilesets or scripts, I tend to make a simple throw-away module. In theory, the results can be exported, but often the trial module is such a mess that rebuilding from scratch is cleaner.
As a halfway house, I have a test area in the main module for evaluating changes that need the haks etc, which can be removed and refreshed if necessary.
I have a related question, figure I ask it here.
Do custom blueprints and palettes slow down the module or affect in negatively in somehow otherwise?
Let’s say you decided to use CEP in your module, it has lots of new appearances for placeables and creatures etc. By default it comes without new blueprints and palettes
Next, you design a living room and need a table. Now, you may create a single table right now and proceed to next placeables in the room or, knowing that you will design many living rooms in the future and they will need to be diverse, you could spend time to create a set of different looking tables and use them as palette, and never return to designing table placeables again.
That would be more efficient, but with that practice your module will eventually have very many custom blueprints.
No problem at all except the hak and module size. Which might be important. For example, I removed all blueprints from CEP haks since I am using nwsync so players need to download each file. And I am using the CEP 1 Complete version which already removed duplicates (+ I do not use ceppatch haks since they contain duplicates in CEP 1 Complete version).
Instead I moved the blueprints into development module, since again if I put them into live module it would increase its size and the size is important if you need to send the new version to server via http or ftp. Alternatively and probably better option is to put them into override. But that might get confusing if you work on multiple different modules.
I used to maintain a separate ERF module, but now I just export/import from previous modules. There are pros & cons to maintaining a separate ERF module. For me, the con of spending the time outweighed the pro of version control.
A lot of folks like to prefix their custom content (scripts, items, creatures, etc.) with their initials, e.g. bh_ or phod_. That works well for publishing your custom content for use in other modules. For my personal work, I don’t bother. For henchman and NPCs, I’ll prefix their ResRef and Tag with “hen_” and “npc_” respectively. Also, I’ll name their convo the same as their Tag. If there is a journal entry exclusively concerning them, I’ll use the same tag. For example, Eggbert the Bully has a ResRef, Tag, Convo, and journal entry all called “NPC_Eggbert.” For scripts, I’ll use as prefixes, “oe” for OnEnter, “ou” for OnUsed, “taw” for Text Appears When, “at” for Action Taken, et cetera. Again this works well for my modules but I would prefix them with “grym” for custom content to be shared with the world.
Also, to echo @Shadooow, deleting your palette (except for spawning creatures) before publishing your module can reduce the size of the module tremendously if you make use of custom placeables.
