Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Meph]

Not just the balance, its also that some players rather like the simulation part of DF, and Mana-for-Magic is very much rts/rpg. And to properly display it and let players see and understand the system. Maybe a cooldown based on willpower/intelligence on the interactions would be better.

Fireball = Wait_Period 5000 ticks - 1 tick * willpower. This time someone with 4000 willpower can cast Fireball once every 1000 ticks, but a weak-willed mage with 1000 willpower has to wait 4000.

[Putnam]

Nah, mana-for-magic is a pretty good way to do the simulation thing, even if it's abstracted somewhat. I know Harry Potter and the Methods of Rationality uses mana somewhat, though it's more about exhaustion than anything (which I also think is a good way to do a "mana" system--make interactions increment exhaustion during battle).

[Roses]

An exhaustion mana system is already doable using existing scripts, although they definitely aren't optimized for it.

I could write a mana system, as described by Godly, but it would have the large caveat that it won't be working properly until we can accurately determine an interactions user.

[Godlysockpuppet]

If you guys manage to make something like this, I'd love you for it  Mana for magic style, like I described is what I'd prefer.

[Roses]

All scripts have been updated to, what I am now calling, v1.0. I tested them all briefly, but like and code there is bound to be bugs that slipped by. Please let me know if you find any.

In addition I have added some exciting new scripts, two of which are my upgradebuilding and upgradeitem scripts.

Want to be able to add and take away reactions from a building?
Want to change the way a building looks?
Want to provide a make shift building sorting function? (Meph's idea)
Then you want upgradebuilding.lua!

Code: [Select]

upgradebuilding - used to upgrade buildings from one to another, or to change them from one to another
Requires a reaction an inorganic and corresponding buildings

REACTION OPTIONS:
All reagents with [PRESERVE_REAGENT] will be added to the building materials of the upgraded building and can be reclaimed by destroying the upgraded building
Reagents without the [PRESERVE_REAGENT] tag will be consumed and will not be able to be reclaimed
The first product must be the inorganic with the syndrome attached to it
Subsequent products will be created as normal

EXAMPLE REACTION:
[REACTION:LUA_HOOK_UPGRADE_BUILDING_EXAMPLE_1] <- LUA_HOOK_UPGRADE_BUILDING is required
[NAME:upgrade building]
[BUILDING:TEST_BUILDING_1:NONE]
[REAGENT:A:1:BOULDER:NONE:INORGANIC:NONE][PRESERVE_REAGENT]
[REAGENT:B:1:BOULDER:NONE:INORGANIC:NONE][PRESERVE_REAGENT]
[REAGENT:C:1500:COIN:NONE:INORGANIC:SILVER]
[PRODUCT:100:0:BOULDER:NONE:INORGANIC:UPGRADE_BUILDING]

INORGANIC OPTIONS:
Inorganics must have a syndrome with two [SYN_CLASS:] tags
Valid arguments for the first SYN_CLASS;
here - this will change this particular building
BUILDING_TOKEN - this will change a randomly selected building of the given token (e.g. TEST_BUILDING_1)
Valid arguments for the second SYN_CLASS;
upgrade - this will upgrade the building from the name to one higher (i.e. TEST_BUILDING_1 -> TEST_BUILDING_2)
downgrade - this will downgrade the building from the name to one lower (i.e. TEST_BUILDING_2 -> TEST_BUILDING_1)
BUILDING_TOKEN - this will change the building to a completely new token (i.e. TEST_BUILDING_1 -> RESEARCH_BUILDING)

EXAMPLE INORGANIC:
[INORGANIC:UPGRADE_BUILDING]
[USE_MATERIAL_TEMPLATE:STONE_VAPOR_TEMPLATE]
[SPECIAL]
[SYNDROME]
[SYN_CLASS:here]
[SYN_CLASS:upgrade]
[MATERIAL_VALUE:0]

BUILDING OPTIONS:
Nothing special is required from buildings except when using the upgrade/downgrade option
then the buildings you wish to change need to be named in the convention BLAH_BLAH_BLAH_1, BLAH_BLAH_BLAH_2, etc...

EXAMPLE BUILDINGS:
[BUILDING_WORKSHOP:TEST_BUILDING_1]
[NAME:Soul Forge]
[NAME_COLOR:7:0:1]
[DIM:3:3]
[WORK_LOCATION:1:1]
[BLOCK:1:0]
[TILE:0:1:207]
[COLOR:0:1:0:7:0]
[TILE:1:1:207]
[COLOR:1:1:MAT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE]
[BUILDMAT]
[WORTHLESS_STONE_ONLY]

[BUILDING_WORKSHOP:TEST_BUILDING_2]
[NAME:Upgraded Soul Forge]
[NAME_COLOR:7:0:1]
[DIM:3:3]
[WORK_LOCATION:1:1]
[BLOCK:1:0]
[TILE:0:1:207]
[COLOR:0:1:0:7:0]
[TILE:1:1:207]
[COLOR:1:1:MAT]

RESTRICTIONS!
Only upgrade between buildings of the same type (i.e. WORKSHOP->WORKSHOP)
Only upgrade to buildings of the same size (i.e. 3x3 -> 3x3)
Only upgrade to buildings with the same center and work spot (I don't know if this is strictly necessary, haven't done much testing)
Be careful about forbiden tiles in a building, the effect of changing these tiles without redefining the building is unknown
Tired of losing an items quality when changing it in a reaction?
Tired of losing an items history when changing it it in a reaction?
Tired of items being a one and done with no chance for upgrading them?
Then you want upgradeitem.lua!

Code: [Select]

upgradeitem - used to upgrade item from one to another, or to change them from one to another
Requires a reaction an inorganic and corresponding items

REACTION OPTIONS:
All item reagents with [PRESERVE_REAGENT] will be flagged for upgrading
Reagents without the [PRESERVE_REAGENT] tag will be consumed
The first product must be the inorganic with the syndrome attached to it
Subsequent products will be created as normal

EXAMPLE REACTION:
[REACTION:LUA_HOOK_UPGRADE_ITEM_EXAMPLE_1] <- LUA_HOOK_UPGRADE_ITEM is required
[NAME:upgrade armor]
[BUILDING:UPGRADE_SMITH:NONE]
[REAGENT:A:1:ARMOR:NONE:INORGANIC:NONE][PRESERVE_REAGENT]
[REAGENT:C:1500:COIN:NONE:INORGANIC:SILVER]
[PRODUCT:100:0:BOULDER:NONE:INORGANIC:UPGRADE_ITEM]

INORGANIC OPTIONS:
Inorganics must have a syndrome with two [SYN_CLASS:] tags
Valid arguments for the first SYN_CLASS;
this - this will change the items in the reaction
all - this will change all items of the same type and subtype as the items in the reaction
ITEM_TOKEN - this will change a randomly selected item of the given token (e.g. ITEM_ARMOR_TEST_1)
Valid arguments for the second SYN_CLASS;
upgrade - this will upgrade the item to one higher (i.e. ITEM_ARMOR_TEST_1 -> ITEM_ARMOR_TEST_2)
downgrade - this will downgrade the item to one lower (i.e. ITEM_ARMOR_TEST_2 -> ITEM_ARMOR_TEST_1)
ITEM_TOKEN - this will change the item to a completely new token (i.e. ITEM_ARMOR_TEST_1 -> ITEM_ARMOR_ELF_ARMOR)

EXAMPLE INORGANIC:
[INORGANIC:UPGRADE_ITEM]
[USE_MATERIAL_TEMPLATE:STONE_VAPOR_TEMPLATE]
[SPECIAL]
[SYNDROME]
[SYN_CLASS:this]
[SYN_CLASS:upgrade]
[MATERIAL_VALUE:0]

ITEM OPTIONS:
Nothing special is required from items except when using the upgrade/downgrade option
then the item you wish to change need to be named in the convention BLAH_BLAH_BLAH_1, BLAH_BLAH_BLAH_2, etc...

EXAMPLE ITEMS:
[ITEM_ARMOR:ITEM_ARMOR_TEST_1]
[NAME:armor:armor]
[PREPLURAL:suits of]
[MATERIAL_PLACEHOLDER:leather]
[ARMORLEVEL:1]
[UBSTEP:1]
[LBSTEP:1]
[SHAPED]
[LAYER:ARMOR]
[COVERAGE:100]
[LAYER_SIZE:20]
[LAYER_PERMIT:49]
[MATERIAL_SIZE:6]
[LEATHER]
[HARD]
[BARRED]
[SCALED]

[ITEM_ARMOR:ITEM_ARMOR_TEST_2]
[NAME:plated hide:plated hides]
[ARMORLEVEL:3]
[SHAPED]
[LAYER:ARMOR]
[COVERAGE:100]
[LAYER_SIZE:25]
[LEATHER]
[LAYER_PERMIT:49]
[MATERIAL_SIZE:9]
[BARRED]
[HARD]
[METAL]

RESTRICTIONS!
Only upgrade between the same types (i.e. ARMOR -> ARMOR), never upgrade to different types
Can upgrade anything with a subtype (including toys, instruments, siegeammo, etc...)
Will not downgrade if item is at _1 and will not upgrade if there is no higher _#
Sometime later this week I will also be releasing a bunch of example interactions and reactions that showcases some of the fun things you can do with all the scripts.

[Meph]

As said countless times in PM's: I love you. This changes... so much.

Question: When you say BUILDING/ITEM_TOKEN you do mean ID? As in:

Code: [Select]

[INORGANIC:UPGRADE_BUILDING] => used in the workshop called "Spire"
[USE_MATERIAL_TEMPLATE:STONE_VAPOR_TEMPLATE]
[SPECIAL]
[SYNDROME]
[SYN_CLASS:here]
[SYN_CLASS:GREATER_SPIRE] => is the building ID of the building "Greater Spire"
[MATERIAL_VALUE:0]
Are vanilla buildings supported? Can I add a reaction to the tanner (which has no building raws, but I can reactions to it) and transform it into something else?

What exactly do you mean by this: "ITEM_TOKEN - this will change a randomly selected item of the given token (e.g. ITEM_ARMOR_TEST_1)" Does this mean it will not change the item used as reagent? Please make an example of its use, because I cant really think of anything...

"all - this will change all items of the same type and subtype as the items in the reaction"... so fort wide upgrades? Do you know if it affects items that are currently in use? For example could I send a priest to the shrine, pray to the gods, and they super-upgrade all armors.

Its all reaction based, which makes it hard to do anything with time/ticks. I know I have plenty, no countless, of options with the scripts already, but how hard would it be to add a timer? Upgrade turns weapons into "blessed weapon" or "poisoned weapon" and the blessing or poison wears off.

I will test this into oblivion, make so much use of it, and might even base the entire insect race on this, because this is seriously the greatest addition to DF since interactions.

Request/Suggestion: Changing materials is possible as well with this? Currently you allow to "take iron sword => make iron super-sword". You change item subtype. Another great use would be "take rusty iron sword => make iron sword". You change the material. Sword was made of "rusty iron" before, and now its "iron". You can even make "hardened iron" later on. This would be a very fine solution to the free goblinite. Give them bad-quality materials but good items, and your dwarves have to refine them first. You can still melt them, atomsmash or sell them, but you also have the option to remake them into more useful items.

EDIT: PS: Is this a typo in your tokens.txt?    MANNER)SM_EYELIDS => it has a ) instead of an I.

EDIT2: Thumbs Up for the included Readme. And I saw the .pngs you made linked on github. The documentation is first grade, thank you.

[Roses]

As said countless times in PM's: I love you. This changes... so much.

Question: When you say BUILDING/ITEM_TOKEN you do mean ID? As in:

Code: [Select]

[INORGANIC:UPGRADE_BUILDING] => used in the workshop called "Spire"
[USE_MATERIAL_TEMPLATE:STONE_VAPOR_TEMPLATE]
[SPECIAL]
[SYNDROME]
[SYN_CLASS:here]
[SYN_CLASS:GREATER_SPIRE] => is the building ID of the building "Greater Spire"
[MATERIAL_VALUE:0]

Yes, what I mean is the ID, I should change that in my description.

Are vanilla buildings supported? Can I add a reaction to the tanner (which has no building raws, but I can reactions to it) and transform it into something else?

Vanilla buildings are not supported right now, although I was able to change between different vanilla workshops (tanner -> leatherworker). I will test how the game handles changing vanilla to custom and back. As long as the game doesn't have a fit about the changes it should be quite easy to implement vanilla buildings.

What exactly do you mean by this: "ITEM_TOKEN - this will change a randomly selected item of the given token (e.g. ITEM_ARMOR_TEST_1)" Does this mean it will not change the item used as reagent? Please make an example of its use, because I cant really think of anything...

Yeah, I really didn't know how to word what I meant. So basically I didn't want to have to make a whole crap ton of inorganics for every single upgrade so I made a system so that a single inorganic (included in my post above) will upgrade any item by changing the number included in the ID (ITEM_ARMOR_TEST_1 -> ITEM_ARMOR_TEST_2). This means you just need to use the same ID with different numbers for your items and it will do all the upgrading for you. But I realized that some people might like the option to totally change the item ID and might not want to rely on my naming convention. That is what the other option is for. You will need a separate inorganic for each upgrade, but it will allow you to change to any item ID of the same type.

Personally I will just stick with the naming convention of upgrades having different numbers, and only having one single inorganic.

EDIT: Just realized you were asking about something else. Yes that is exactly what it does, so say a dwarf prays at a shrine using a longsword, then someones longsword somewhere on the map will change. I was thinking an example might be if you have an opponents item, say a giants club, and then the giants invaded again, you could run a reaction that would weaken one of the giants clubs. Not incredibly useful, but was only about 2 minutes more of coding, so I figured I would include it.

"all - this will change all items of the same type and subtype as the items in the reaction"... so fort wide upgrades? Do you know if it affects items that are currently in use? For example could I send a priest to the shrine, pray to the gods, and they super-upgrade all armors.

Yep, that is exactly what it is, fort wide upgrades. It should work for all items, including those in use.

Its all reaction based, which makes it hard to do anything with time/ticks. I know I have plenty, no countless, of options with the scripts already, but how hard would it be to add a timer? Upgrade turns weapons into "blessed weapon" or "poisoned weapon" and the blessing or poison wears off.

Actually using the wrapper.lua script you could already get a timer effect, although it would be hackish and not very friendly to code. I will instead add an option for a third SYN_CLASS in both upgradebuilding and upgradeitem inorganics that will function as a duration. This will be fairly easy with both and would allow temporarily upgrading all armor or weapons. (I'll add it to the todo list)

Request/Suggestion: Changing materials is possible as well with this? Currently you allow to "take iron sword => make iron super-sword". You change item subtype. Another great use would be "take rusty iron sword => make iron sword". You change the material. Sword was made of "rusty iron" before, and now its "iron". You can even make "hardened iron" later on. This would be a very fine solution to the free goblinite. Give them bad-quality materials but good items, and your dwarves have to refine them first. You can still melt them, atomsmash or sell them, but you also have the option to remake them into more useful items.

Actually changing material is already possible with my imbueitem.lua script. In fact, that is all it does. I made it so that magic knights could "imbue" there weapons or armor with different properties (by physically changing the material). Currently it only works for equipped items. But I can add the functionality to a reaction system as well.

EDIT: PS: Is this a typo in your tokens.txt?    MANNER)SM_EYELIDS => it has a ) instead of an I.

Yes, yes it is

Added to the todo list:
-Change TOKEN to ID
-Check vanilla building changes
-Add duration check
-Add material changing

[Meph]

Thank you for the quick answers. Material changes would be really nice, I have been asked about this in the past, but was never able to do so. A Imbue version that runs from reactions on items used in them would be very helpful.

Stupid question: Can this be used to make a copy of an item somehow? What I mean is this: Reaction calls for "any weapon" and some metal. The "any weapon" is preserved, and the product is a copy of said weapon, using the metal as material. Its not strictly speaking an upgrade, but it might be easy to change the script slightly to allow this. It would be nice for foreign items that invaders drop. Retro-engineer tech of other civs. Sorry to add more to your todo list, but it just came to mind.

Vanilla buildings are not supported right now, although I was able to change between different vanilla workshops (tanner -> leatherworker). I will test how the game handles changing vanilla to custom and back. As long as the game doesn't have a fit about the changes it should be quite easy to implement vanilla buildings.

I was thinking less of turning a custom building into a vanilla building, but turning the hardcoded vanilla buildings into something else. Not for me or MasterworkDF, but for people that make total conversions. Why would a Warhammer 40k: Necromunda mod have a tanner? Or a clothier? Or why should a non-humanoid race build a masonry or carpenty workshop?

[Roses]

Again, creating items is already present in script form (from several different people, but also in my package of scripts) so it should be relatively easy to add an option for recreating items. I may make an entirely different script with another LUA_HOOK set of reactions (mostly just copying and pasting really) so that I don't worry about making the upgrade script more complicated then it needs to be.

And as for total conversion mods and changing vanilla buildings, it may actually be possible, using a text editor combined with a different script, to have the Tanner building appear as Leather Synthesizer (as an example) in the building list, then when it is built, automatically change it to be the custom building Leather Synthesizer. The player would never know that the building they built was just a re-named tanner, and instead would just assume there was no Tanner in the game. Of course you couldn't really get rid of the vanilla buildings, but you could make it so that a player never sees them or their vanilla reactions. Not something I would be terribly interested in, but it would be interesting to try and get it to work. I will add it to the very bottom of the todo list

[Meph]

Wait, insolors string dump replacer already allows changing names of hardcoded buildings. So that can already be done, no need to add this then.

Copying items is currently not possible with the scripts I know. Creating new ones, yes, but nothing that would take the item type and sub type and material from the reaction.

[Deon]

I have no words. This forces me in DF modding before the next version. I JUST CANNOT MISS IT!

[Meph]

Here some suggestions of use:

Lesser Forge => Forge => Greater Forge. (Sequential Low to High Upgrades)
This way you can make tech trees and start with cheap and weak gear and have the race level up one building at a time to get to the next higher one. Could be from adding more resources, could be by getting rare buildmats, or just time.

Council => Council of War/Peace/Commerce (Exclusive choice, get one of three)
This way you can make things mutually exclusive. The council is just an empty basis, and depending on how the players leads his fort, he might use the War-Council which helps with combat/sieges, a Peace council which could pacify dwarves, or a Commerce council, which can call caravans and affect trade.

Decoration => Lamp/Rug/Statue/Tree/Sign/Candelabra/Fireplace (Just use it as a fake sub build menu)
All tilesets have lots of unused tiles. But making a single-tile workshop and adding X amount of reactions that "upgrade" it into another single tile workshop, you can give players access to X tiles. Lets say you like all trees, plants and gem tiles as decoration, you can add reactions to upgrade it to those. "Plant conifer tree" "Plant oak tree" "Plant plump helmet" "place diamond" etc. This allows a large amount of flexibility in fortress designs, all for the price of a single entry in the build menu.

Workshop - Oriented North => Oriented East/South/West (Use it to orient workshops just like siege engines)
Players often say that workshops that have an entry in a specific way dictate their fortress design. With this, just make 4 building designs, one with the door/entryway north, one with east, one facing south and one facing west. This way players can "turn" them. The four workshops would otherwise be identical and have the same reactions.

Questions for Roses: Did you test Workshop Profiles and Stockpile Links? I assume that both are deleted/reset.

[splinterz]

amazing work Roses, really impressive stuff here!

Here some suggestions of use:

Workshop - Oriented North => Oriented East/South/West (Use it to orient workshops just like siege engines)
Players often say that workshops that have an entry in a specific way dictate their fortress design. With this, just make 4 building designs, one with the door/entryway north, one with east, one facing south and one facing west. This way players can "turn" them. The four workshops would otherwise be identical and have the same reactions.

oh that's huge. perhaps we can finally get the arbalest in masterwork to shoot through fortifications by moving the 'operator' to an edge tile...

[Meph]

Potentially possible if the script works fine with changing the work tile. But... I dont want to say anything... but the arbalest/trebuchet operator dwarf counts as a pet for the duration, and can simply be pastured closer to the fortification. Exploiting this, you could even pasture him far away from the arbalest/trebuchet, and he would still fire projectiles. I'd much rather use Warmists dragonfire engines.

To orient workshops you would need to either add 3 reactions each (orients N/E/S/W, minus the one its already oriented at), which adds a lot to the menu, or 2 (rotate 90° clockwise/counterclockwise) to each, or just add 1 reaction (rotate building). In the last example it would be 4 different reactions, but only 1 in each version of the workshop. I personally think the 2-reaction solution would be most elegant.

Reactions would require no skill, so any dwarf would do them, instantly and with no skill gain. Maybe I should write a template for this and post it later...

[splinterz]

Potentially possible if the script works fine with changing the work tile. But... I dont want to say anything... but the arbalest/trebuchet operator dwarf counts as a pet for the duration, and can simply be pastured closer to the fortification. Exploiting this, you could even pasture him far away from the arbalest/trebuchet, and he would still fire projectiles. I'd much rather use Warmists dragonfire engines.

To orient workshops you would need to either add 3 reactions each (orients N/E/S/W, minus the one its already oriented at), which adds a lot to the menu, or 2 (rotate 90° clockwise/counterclockwise) to each, or just add 1 reaction (rotate building). In the last example it would be 4 different reactions, but only 1 in each version of the workshop. I personally think the 2-reaction solution would be most elegant.

Reactions would require no skill, so any dwarf would do them, instantly and with no skill gain. Maybe I should write a template for this and post it later...

personally i really liked the arbalest siege engine, dragonfire seems a bit.. gnomish? anyway, the biggest problem with the arbalest was that it couldn't shoot through fortifications unless you manually pastured the operator next to it (presumably; i've never tested this). but not having to go through that process to pasture would be very nice and much more user friendly.

maybe it would be possible to modify the script to choose a direction prior to building, as opposed to building, and then upgrading/rotating it to face the desired direction?