ToME WikiNorseband is an unreleased game set in a magical version of our world's Dark Ages; as its name implies, the main plotline centers on Scandinavia and the mythical worlds of Norse legend. (Foreign cultures, monsters and items will exist in Norseband; however, those elements can come only from places where Norsemen have traveled in "real" history.)
The game will be released in two separate formats: (1) as a module for T-Engine 3.x, and (2) as a standalone variant derived from Furyband. The "variant" format is currently an alpha release which requires some bugfixes and new flags added. You can read more about what's already been done (and what needs to be done) on the official Norseband homepage.
After a playable edition (one or the other) has been released, I plan to add spoilers and help files to this article.
Item flavors patch: where to find, where to add?
IngeborgNorden: I recall one of the contributors to ToME writing a source-code patch that expanded the range of possible item flavors. Where is this patch available, and which source files need editing to add this patch properly?
DarkGod: T3 flavors are unlimited already 
IngeborgNorden: Any estimate on the release date for alpha14? 
BucketMan: Take a look at data/flavours.lua. That should help.
IngeborgNorden: *nods* Just looked it over, but I couldn't see where the "fixed" flavors are defined. Is that done in a different script?
On another item-flavor topic: I'd like Norseband to use rods/tips as in ToME 2, since replacing the non-directional rods with orb/gem combos would feel wrong for the setting. (Norsemen didn't make that kind of jewelry, nor did they associate the shape with power and magic.) I'd also like to expand the number of "base" rods from seven to nine, adjusting their relative power accordingly. Does T3 currently permit this?
BucketMan: Add a FLAVOUR flag to the item in question that specifies the flavour you want it to have. For example, from the Blood of Life:
FLAVOUR = "strangely phosphorescent"
The screen display handling itself is in data/items/descs.lua. As to rods, yes. As DarkGod says, 'flavours are unlimited.' And so are items. By the way, when are you going to start work on the T3 version of Norseband? I know you're planning on releasing a T3 version as well as a standalone variant, but once you're familiar with T3, it might not be necessary to do both. I'm looking over your outline on googlepages, and T3 can do everything you're asking for. In fact, some of the more complicated things you're planning have already been done. For instance, 'smithcrafting' as you've described it sounds pretty similar to 'Technomancy' in Dragonball T. Change the names a little and you could probably just copy it over and use it more or less as is. But, point being, these things you're asking for have already successfully been implemented by modules, and without any source code modification at all. You'd probably save yourself a lot of time and energy only doing a single version.
Adding/tweaking other modules' content
IngeborgNorden: I installed DBT last night, BucketMan, but I'm still unable to look at the Technomancy script to see what needs changing: there's no way to get at individual parts of your module through the .team file. Do you know what I might have done wrong?
P.S. I'll start with the T3-compatible Norseband when I can get help with maps and the endgame quests; without those bare bones, the other parts of the module are unplayable.
BucketMan: .team files are renamed zip files. To get at the scripts of any module, change the extension from .team to .zip. Then you can decompress it using any unzip utility.
The relevant files for technomancy will be:
- scripts/subsystems//technomancy.lua: The actual Technomancy subsystem itself.
- scripts/tools: DBT uses tools via a 'u'se command to build/view/disassemble things instead of an mkey. The actual calls to the Technomancy scripts will be in here.
- data/items/items.lua: 'Recipes' are psuedo-randomized, and contained in the item definitions themselves.
Keeping in mind that I've never actually done it, to adapt Technomancy to another module, there will be a few things I'd expect that will need to be done:
(1) Be sure that the script loads. Technomancy.lua is the only DBT script you need to load. tools.lua isn't needed, it's just the method I personally use to call the scripts.
(2) Enter the TVALs and SVALs that you want Technomancy to use into the table in Technomancy.pick_ingred() This will be important. Without doing this, you're going to get about two dozen LUA errors. Basically, Technomancy maintains its own TV/SV tables, and they don't have to match the groupings that your module uses. It shouldn't be a big deal to change. Look for technomancy.pick_ingred() and simply change the TV/SV's to those used by your module. The format should be relatively intuitive. I'm using four TVALS: "TV_CIRCUITRY" "TV_CHEMISTRY" "TV_BULK_MATERIAL" and "TV_HIGH_TECH_COMPONENTS" but you can use any number you'd like. Just add or delete instances of the 'elseif which ==' line. In any case, the point here is that anything that is can be used an as ingredient must be entered into the table. It doesn't care about things made with ingredients. The init script will scan through your items list and identify anything that can be built. Note also it's entirely possible for an ingredient itself to be something that can be built. You'll set that up in the last step.
(3) Decide whether you want to use disciplines, and if so, how many. Disciplines are totally uneccesary for Technomancy to work, but they may be useful for you. Basically, they're categories of different 'types' of Technomancy. For instance, in DBT, 'electronics' is considered a different discipline than 'chemistry.' In Norseband, maybe you'd want 'metalworking' and 'leatherworking.' Or whatever. Etc. Disciplines are really just a convenient way to categorize things. They have no actual effect on ingredients or recipes. (Note that as of the current version the 'view recipe' script is only capable of displaying a single page or recipes per discipline. This works out to a practical limit of 26 recipes per discipline. You could have more, but the user won't be able to see them.)
(4) Account for skill: Technomancy assumes that two skills exist: CONSTRUCTION and DISASSEMBLY. Character skill values will affect chance of success, number of parts retreived during disassembly (or smelting), chance to learn how to build something, etc. You could either add these skills to your module, or change the names in the Technomancy script, but either way, they'll need to match.
(5) Decide on the maximum number of possible different ingredient types in any one recipe: By default this is four, but you can change this by adding/deleting flags in the 'item flag declarations' section near the top. Exta flags isn't a problem. You don't haveto use them all.
(6) Set up an interface to the script How you do this is totally up to you. Personally I use a 'u'se command, but if you want to use an mkey, or even associated them to terrain FEAT's, that should be fine, too. The relevant commands you need to call are:
- technomancy.show_known_recipes(discipline)
- technomancy.interface_to_build(discipline)
- technomancy.dismantle(item, kind)
(7) Define your recipes: (Note that the help text in the Technomancy script is not entirely accurate on this point.) Everything that can be 'built' will need guidelines on how to randomize the recipe to build it. If you take a look at the DBT items script you'll see how to define recipes. For example:
DISCIPLINE = 1
INGRED1_WHAT = TV_FOO
INGRED1_QTY = 1
INGRED2_WHAT = TV_BAR
INGRED2_QTY = 2
An item with these flags would be of the first discipline (whatever that is for your module) and require 1 random item from the TV_FOO list, and two random items from the TV_BAR list. Two important points here: 1) Even if you have only one discipline, you'll still need to have the discipline line for every recipe. 2) I'm personally using TV's for ingredient groupings, but Technomancy does not care if you do this. As long as you properly define your groupings in point 2 above, you're good. I use TV/SV's, but you could just as easily have a 'grouping' defined by any random flag, with any possible group of SV's associated with it, whether or not they belong to the same TVAL.
That should just about cover it, I think. Let me know if you have any difficulty.