Bay 12 Games Forum
Dwarf Fortress => DF Modding => Topic started by: NCommander on April 28, 2015, 10:41:49 pm
-
So, I was fuzzing aorund with DF's memory and .... I kicked off the Dwarven Economy ... in DF2014
(http://i.imgur.com/WzJqd8M.png)
(http://i.imgur.com/FxXnXB6.png)
(http://i.imgur.com/QcAFIvq.png)
(http://i.imgur.com/E3IhaQT.png)
I knew the economy code was still semi-present in DF, though it supposedly caused the game to crash the instant it was kicked on.
It's not 100% functional; dwarves don't claim rooms, my guess because they never take the Go Shopping job to get one (I've yet to get this to kick off), but they do pay from their account for food, and will pay for pets. Shops are buildable but due to the same Go Shopping stuff, never claimed.
I'm still O_o;ing over it. Maybe when I finish with dwarfvet, I might see if I can get this fully functional (and rewritten to be less broken, k).
-
All hail NCommander!
PTW
-
Well, heck. I'd play around with that! Hack, Urist, hack!
-
There are some data structures necessary for the economy that do not get populated anymore (specifically ones related to wages), and they currently are not known to DFHack so there are some things which simply won't work.
-
Yes I saw that under UI, the economy is still available if you activate it. A reminder for those excited about it: this feature was removed for good reasons.
-
There are some data structures necessary for the economy that do not get populated anymore (specifically ones related to wages), and they currently are not known to DFHack so there are some things which simply won't work.
Holy cow, Quietust himself.
*bows and is not worth*
Well, in seriousness, its not like DF2010 which just fell over on this face; my test fort with economy active ran for quiet awhile before it shutdown; I posted screenshots mostly to see if there was any interesting in trying to bring it back. I actually did a search on your name and economy to find your notes since I remember talking about it. I wanted to take a stab at filling in the missing data structures by getting DF to crash, and failed to actually *get* a crash.
My guess is the routine to initial the economy is not in DF at all anymore; an optimizing compiler would likely notice its dead code and make it *poof* into non-existence. Roughly speaking, this is what appears to work/not-work
* Go Shopping never fires
* Dwarves don't claim rent control rooms (possible due to the previous issue)
* Noble ACCOUNT_EXEMPT works
* Prices DO get adjusted, but no notification
* Food and such is properly paid out
* Immigrating dwarves have their account properly set at 200
* Children don't appear to share their parents accounts anymore
* Manager seems to go meet with the expedition leader
I can patch around 2 similar to how my animal caretaker plugin works, though without one, the economy doesn't really do much.
The wages table seems to get populated; I can see it just fine under the manager, and z->{Prices/Currency} work when I browse them, and have sane numbers attached. I'm just not sure to pay wages code is attached to anything; I can work around this if need be as well as attaching a tick timer to the game, looking at jobs, and then paying dwarves out instead of having DF itself handle the account.
My intent was actually to try and rewrite this feature from the ground up for the extent possible, and gauge any interest if possible; the current economy code really would only serve as a framework for what I was thinking of.
-
And yet a cat still ignores all dwarven decency...
-
I'm interested. In fact, I'd be interested in helping, but this might be too deep down the rabbit hole (with DFhack) for me.
-
Well, when I get some free time, since I know the offset of the economy_active flag from DFHack-40d, I need to play a game of 40d in which the economy kicks off, and set a write watchpoint on it to find the chunk of code that enables it, then work backwards from that entry point to determine the data structures it touches. As I see prices adjusting in my current DF2014+Economy game, I'm hoping that's all it would need; the biggest issue is since dwarves don't claim rooms, everything else falls apart.
Beyond that, its mostly defining and implementing new logic if I'm doing to actually do this.
-
PTW
-
So, I had to run errands for most of today, but while I was doing them, I was seriously able to think about how a new economy plugin could work, as well as learning lessons from the old one.
As implemented, the economy is supposed to essentially make your fortress a capitalist society. The problem with that a typical dwarven fort doesn't represent that sort of system; dwarves work together as a whole to accomplish goals, weather they're hauling, soldering, healthcare, etc. Without hauling, which didn't pay anything as far as I know, nothing happens, and these dwarves become destitute.
As I sketch some ideas, I only need a few bits and pieces from the existing economy code.
Here's roughly what I'm thinking.
- The Fortress Account
- The Fortress itself would have an account. The fortress account grows by creation of coins, or by taxing guilds (dwarves themselves shouldn't be taxed, once its paid out, its theirs to keep. All transactions within the fortress go from this account to the guilds, and then the dwarf. A subset of dwarves would be paid directly from the fortress accounts, such as haulers..
- Coins themselves are owned by the bookkeeper, and not by individual dwarves; this prevents splitting, coin hauling, etc. They physically exist within the fortress, but throw them into a stockpile and call them good. No need to haul them everywhere. If possible, I'd also attach a value multiple to them to make them attractive for trading (i.e., paying for goods in cold hard cash).
- Restoration of Guilds
- 23a had guilds which dwarves belonged to and represented their works. This is a step in the right idea, but the old dwarvish economy didn't take it far enough, and was too rigid
- Each job pays into the guild, NOT to the dwarf. So if you do 25 mining jobs, the wage for each job goes into the guild's master account until the end of the month; this is likely something that will only exist within DFHack itself, and not within DF's existing economy code
- The economy DFHack plugin would keep track of the number of jobs done by each dwarf, and use that to track which guild they're part of. For instance, if a dwarf did mining for most of a month, they were part of the miners guild, even if their top skill was fish dissector. At the end of the month, the job count is zeroed out, and starts again. So if one month they do nothing but mining, they'd be a part of the mining guild, NOT part of the fishers guild. The following month, if they did nothing but make mechanisms, they'd be part of the engineers guild
- Guild leaders can make mandates if they're not getting enough work, to do something relevant to their guild.
- At the end of each month, the guild figures how much it should get generated, and makes a withdraw from the fortress account. Then each guild pays out to their members, based on skill, number of jobs a dwarf did for that guild, etc. I haven't worked out the specifics, but *every* dwarf in that guild will get something. So if a miner is badly injured in a cavein and can't work for a season, they will still get some dwarfbucks, though less if they actually did something for that guild.
- Products created are property of the fortress, not of the guild; dwarves in effect are getting paid to create them; the fortress simply automatically buys everything it can
- Not all money is paid out to dwarves, some stay within the guild itself
- Unguilded Dwarves
- Some dwarves won't be paid out from a guild since they're working for the fortress directly. This likely includes the noble special labors like "Update Stockpile Records", soldering, hauling, a few other things
- If there isn't enough labor to establish a guild, i.e. one dwarf makes a few mechanisms, and no other engineering happens then they will be paid from the fortress accounts instead of a non-existent guild
- Civil service doesn't pay well, but *does* pay consistently; enough to afford quarters and food. Minimum wage is calculated out from the cheapest of rooms available, plus cost of food, and a little on top
- Children will get a small amount of money for food from the fortress account each season.
- In effect, the fortress itself is a superguild.
- Taxes
- Unless one minted coins near nonstop, the Fortress Account would be quickly depleted after a few months. To prevent this happening, guilds are taxed to make up shortfalls in the fortress account. I'll likely need to implement an inflation mechanic to keep this working sanely.
- Taxes are only levied if the fortress can't pay out; since the fortress can make some money on its own through the sale of items (food, clothes) and rent
- Dwarves themselves aren't taxed. Once money is in their accounts, its theirs to spend on food, rent, and clothes.
- We calculate out how much is required to come out of the fortress account, and leverage taxes against the most wealthy guilds (though a bit from all of them as well). Money from the guild is moved back into the fortress account; this happens automatically, no tax collector noble to muck crud up.
- The fortress can go into debt if it simply can't cover its costs. This is a bad thing; likely a negative thought starting with the economy nobles, and working downward. Basically, if your fortress can't cover its own costs, stress levels go up. Minting coins is a solution, exports is another (maybe have"offerings" be goods being sold in the greater world, when something is offered, DB go into the fortress account; I could possibly tie this into trade agreements, but I don't know if DFHack has the necessary hooks to look at these programatically, and use it as a pseudo-supply and demand system).
The end result should be a system that doesn't starve your dwarves, but have them moving throughout the fortress, each earning a living, buying food they like if they can afford it, fancy clothes made of dragon leather, etc., else just falling into the rank and file. The economy shouldn't be something that requires micromanagement, more something that keeps the fortress acting like a living organism.
As of right now, to implement any of things, I need to do the following:
- Build a reliable job detector; I already semi-do this for dwarfvet, I just need to ramp it up.
- Create classes in a new plugin to handle the guilds.
- Figure out how to set the price of items within the fortress; as of right now, they're all initialized to 1; I'm going to need to spend some time with gdb and the item structures. This is the only thing I don't know how to do right now. This is the only thing that requires the current economy code to be active, the rest can be done via DFHack tick handlers; worse case scenario, I can watch for the eat/drink jobs, and the items attached to them. Painful, but doable.
- Define new nobles in the raws for guilds, and have them assigned automatically if a guild is created.
- Get room purchasing to work, or failing that, auto-assign rooms based on a dwarves balance (may be saner way to go; prevents them from starving themselves because they bought a million db apartment for a month; dwarf logic isn't foolproof in this regard).
- Generate mandates to prevent the fortress from going into debt to badly.
As a whole, the system needs to do the following:
- Prevent useless labor from gumming up the works (coin stacking)
- NOT require large amounts of micromanagement; guild leaders and the bookkeeper should generate mandates to keep things moving smoothly, but otherwise stay out of the way.
- Make the fortress feel alive, and be fun to have enabled. Not something condemned to the disabled pile because it breaks the game in half.
- Be fun, challenging and yet worthwhile. If you want dwarves to be truly happy with amazing mansions, you need to make sure they can afford it. A productive fortress is a happy fortress! By having a fortress flush with money, dwarves can afford loads of stuff (minimal wage will dictate what your civil service dwarves can afford; may extend this to all guilds as well).
I'm slightly worried I'm designing something too big, but knowing what I know from previous DFHack adventures, I honestly think this should be doable ...
-
This sounds awesome I have heard of the dwarven economy but it was long before I played. I would be happy to test (read play with it).
-
Ambitious, but do give us a heads-up if and when you run into an unscalable wall with the project. It's more considerate than just vanishing forever.
-
Ambitious, but do give us a heads-up if and when you run into an unscalable wall with the project. It's more considerate than just vanishing forever.
Well, I'm pretty sure I can get help for some of it. I just wish my X86 assembly was up for scratch. I used to work on embedded ARM and later AArch64 things, I can read (and code) ARM assembly in my sleep, but x86 being a CISC instruction set + variable word size makes my brain hurt. Right now, if I harness the old economy code, I probably need a patch to nuke legendaries from being economy exempt.
I'm probably going to work on this when I get frustated with dwarfvet (today's 'fix spot usage' bug drove me nearly batty).
-
This could work, I'd suggest trying not to tie it to gold coins but instead simmulate a dematerialized system that assumes that Dwarves write down their accounts. The economy caused tons of stacks of 1 coins and killed fps. Perhaps you could mint coins and have a 'store coins in vault' job that destroys the coin stack and put that into the account.
The civil service and child care ideas are particulary nice. I'll watch this closely, this is cool.
-
This could work, I'd suggest trying not to tie it to gold coins but instead simmulate a dematerialized system that assumes that Dwarves write down their accounts. The economy caused tons of stacks of 1 coins and killed fps. Perhaps you could mint coins and have a 'store coins in vault' job that destroys the coin stack and put that into the account.
The civil service and child care ideas are particulary nice. I'll watch this closely, this is cool.
Coins only destacked because they were physically tied to a dwarf. In the proposed system, they exist, but either have no owner, or are ALL owned by the bookkeeper. I've minted quite a few stacks of coins, and as long as they aren't destacked, I haven't had any appreciable FPS drop due to it.
Under the old economy, each dwarf started with an account of 200 coins. Coins are minted in stacks of five hundred. Thus the moment the economy kicked off, for every three dwarves, you'd end up with four separate items. 2 stacks of 200, and 2 stacks of 100 per three dwarves. Add balance flux, and here in lies the path to madness (or the old economy)
As long as all the coins are unowned, they'll only destack if you do so on the trading interface.
My thought here is you can trade your money for goods, and have a value multipler based inflation, and other stuff. Theorically, coins exist in the in-memory raws, but I suspect DF might explode into confetti if I tried messing with it; there are some memory structures one is better off leaving alone.
Today and likely tomorrow is shot as far as implementing code, and I still have to work on dwarfvet, but I'm going to try and implement the job watcher this weekend, which underpins the entire thing. If I can make that work, the rest becomes implementation details :)
-
As a note, I'm looking at the DF labors, and figuring out how they should be divided. Under 23a/40d, this was simpler, but there are quite a few labors that are part of a profession. I could lump them all together, i.e., the Stoneworkers labors equal one guild, but there's some things that shouldn't go like that.
i.e.
- Seige Operating IMHO, is a civil service job.
- Pump Operating too.
- The Farmers guild would be insanely large.
- The division between things like carpentry, and wood working, or masonry/stonecrafting. A crafts guild seems unavoidable, but I'm drawing a blank on how better to organize it since a few crafts jobs like waxworking doesn't go with anything else. (I could throw it, beekeeping, and leatherworking under a ranger guild, but that's a stretch ...)
Unfortunately, there's no easy way to tell what labor is doing a specific job. I'm going to have to look more closely at the ingame job structs for forge jobs and such.
Here's the total list of jobs the game has (all 231), and what I can easily track. https://github.com/DFHack/df-structures/blob/master/df.job-types.xml
-
Yeah, just the farmer jobs would count for several guilds at least. I think the question here is whether you're going strictly for gameplay effects or follow in Toady's footsteps and aim blindly for historical accuracy and watch the fireworks.
Candle makers and charcoal burners and other seemingly super-niche jobs used to be important and respected, so a wax chandlers' guild for instance (beekeepers + wax workers) wouldn't feel amiss. Colliers (wood burner + lye maker + potash maker) could account for one, too.
Soapmakers just by themselves have apparently been important enough to organize since the time of Charlemagne and after considered one of the vital professions among bakers and builders. Pressers are so close to millers in function that they'd count as one. Bone carvers (scrimshanders) were more interested in whale bone and walrus teeth above land animals (which shouldn't really yield that much usable bone, really), so they could well be part of the fishmongers' society. Then there's only the obvious connections left like bowyers + woodcrafters and such things.
-
Yeah, just the farmer jobs would count for several guilds at least. I think the question here is whether you're going strictly for gameplay effects or follow in Toady's footsteps and aim blindly for historical accuracy and watch the fireworks.
Candle makers and charcoal burners and other seemingly super-niche jobs used to be important and respected, so a wax chandlers' guild for instance (beekeepers + wax workers) wouldn't feel amiss. Colliers (wood burner + lye maker + potash maker) could account for one, too.
Soapmakers just by themselves have apparently been important enough to organize since the time of Charlemagne and after considered one of the vital professions among bakers and builders. Pressers are so close to millers in function that they'd count as one. Bone carvers (scrimshanders) were more interested in whale bone and walrus teeth above land animals (which shouldn't really yield that much usable bone, really), so they could well be part of the fishmongers' society. Then there's only the obvious connections left like bowyers + woodcrafters and such things.
If someone needs to read a/many wikipedia page(s) to understand the decisions I've made, I've failed as a designer.
-
Just posting to watch, but very interesting. I'll read through it later.
-
The wages table seems to get populated; I can see it just fine under the manager, and z->{Prices/Currency} work when I browse them, and have sane numbers attached. I'm just not sure to pay wages code is attached to anything; I can work around this if need be as well as attaching a tick timer to the game, looking at jobs, and then paying dwarves out instead of having DF itself handle the account.
There are actually two different wage tables - one for guild-specific adjustments (the initial page of the Wages screen), and another for the base value of each individual job (which shows up once you press left/right), and it is the latter one which is not initialized (and which is actually used when paying dwarves for completing their jobs).
If you need assistance locating any special economy-related code in any particular version of Dwarf Fortress, let me know - from the work I've done reverse-engineering version 0.23, I've gotten to know my way around DF disassemblies quite well.
-
It wouldn't unrealistic to have lots of specialist guilds, but I'm unsure how many would be too many for game play purposes. All those mandates and required rooms for the guild leaders could become overwhelming. Could be solved if you restrict it so either only larger groups can form guilds or only the more powerful guilds make demands. Larger numbers wouldn't be so bad so long as their names are fairly obvious.
Have started to look through and logically group the jobs list you linked.
-
So I started to get into the coding part of this, and realized my job watcher ran into an annoying issue. If a job disappears from the queue, there's no indication if it canceled or succeeded. I haven't had much luck figuring out the memory addresses for where the missing wage tables are; ideally, a hook of when a job cancels or succeeds would be awesome, but there's no easy way to do that with DFHack. I need to find the wage paying code, and write a hook in DF to jump into a function in DFHack
Failling that, I may need to redesign the system to look at time performing each job instead. Forging/crafting jobs are slightly irritating because I can't determine what skill is being used easily (I ran into this with dwarfvet), though that means guilds with dwarves that work uber-fast (Legendaries) are going to have a problem.
-
Having absolutely no luck at this. Just spent the last several hours staring at IDA disassembly and other things. I managed to find the function that shows the second wage table in both Linux and Windows DF2014, and the same one in 40d, and I managed to find the loop counter (set to 203 on 40d, and 0 on 2014) that runs the entire thing. But thats as far as I got. In desperation, I tried changing strings in memory and other values with WinDbg; it appears to me wages are stored in a structure in memory. I've searched through the entire chunk of memory DF references through wages, and I can't find a raw value anywhere. As the *only* prices I've seen are 1, 5, 10, and 20, I'm wondering if its either a bit field I'm not seeing, or some sorta define, like #define WAGE_PRICES_5 2, or something like that.
To say the least, I'm feeling rather put out, at least with restoring the old school DF economy. It doesn't stop me from wanting to implement what I wrote above, but I'm not a reverse engineering guru.
-
If you want to simplify the work, you don't have to count every dwarf's every job to decide into which guild they belong. Dwarves are already separated into groups - the colors - so just consider each of them a guild, and each dwarf the member of the guild of their color.
Sure, then you can have a yellow Carpenter dwarf with mining labour enabled, all even though he'd spend all of his time mining, he'd still be considered a member of the Carpenters' guild. Well... is it wrong? Just imagine it's dwarven bureaucracy. The game by itself will eventually reassign him to the gray, mining group if his mining skill becomes dominant. Perfect. Dwarven guilds are just too slow and resistant to change. Changing membership takes in-game months. Call that a feature.
The advantage of this is that all "guild" tracking is already built into the game so you don't have to count anything. Just take the guilds that are already there.
You will even have the haulers' guild!
-
If you want to simplify the work, you don't have to count every dwarf's every job to decide into which guild they belong. Dwarves are already separated into groups - the colors - so just consider each of them a guild, and each dwarf the member of the guild of their color.
Sure, then you can have a yellow Carpenter dwarf with mining labour enabled, all even though he'd spend all of his time mining, he'd still be considered a member of the Carpenters' guild. Well... is it wrong? Just imagine it's dwarven bureaucracy. The game by itself will eventually reassign him to the gray, mining group if his mining skill becomes dominant. Perfect. Dwarven guilds are just too slow and resistant to change. Changing membership takes in-game months. Call that a feature.
The advantage of this is that all "guild" tracking is already built into the game so you don't have to count anything. Just take the guilds that are already there.
You will even have the haulers' guild!
Well, with a *lot* of help of Quietust (who showed me the error of my disassembling ways), the wage index now has population code, and dwarves get paid for their jobs which work on a per-job basis to the dwarf. All I have to do now is write something that looks at the accounts, notice increases, and move it automatically to the fortress or guild account. So basically this became reality because I'm lazy :).
Since I can directly control the wages, I can implement most of the other things I wanted with considerably less effort than I was planning. The last remaining issue is they do not claim rooms (or shops, but I'm considering that a feature at this point), and assigning them does not work properly. I'm guessing this is an issue with the flags on the room are bugged. I found the code that controls the flags from the "q" menu, but haven't found what they use to claim them (still working on that bit). My guess is its looking at the dormitory flag when looking if a room is for rent, but that's just a guess.
-
Ok, so a bit more progress.
I walked through the points in the code that checks economy_active, and while I found the magic bit of code that handles dwarven sleepiness a dwarf sleeps, I've yet to find the room assignment code (I thought it was tied to sleep). I did find that dwarves sleeping in Barracks is formally a "feature", not a bug, even if they have an assigned room; they consider it as a list of beds to crash in.
Dwarves buy food, but not booze (its free). I'm guessing this is because a Price field is never set on the booze supplies.
I think I've worked out the basis of how the DFHack plugin will work
Initialization:
* Set the wage tables for all jobs
* Give the bookkeeper a mandate to mint coins to mark the start of the economy (DFHack will check the coins in fortress to fully activate)
* When activation kicks:
* Set ui->economy_active
* Initialize the wage table
* Populate the fortress account with the value of coins minted
* Set the following tick handlers
* Confiscate all coins and assign them to the bookkeeper
* Watch all dwarvish accounts for increases, and confiscate them. Each time this happens, we keep track of how much we took (representing work done by that dwarf).
* Decreases represent rent/food. These go into the fortress account.
* Calculate fortress minimum wage (average the 10+ cheapest apartments value, + some for food. If I can get drink to have a price, bonus!)
* At the end of each work season:
* Create a guild if there's been a significant amount of work AND members in a field (the base game used 25 jobs)
* Guild leader auto appointed from available dorfs. Don't think I'll give them room requirements.
* Destroy a guild if there are very few members and little work
* If the guild exists calculates minimum wage for each dwarf + a bonus based on how much they worked that season*
* Else treat as civil service
* Essentially a guild means a dwarf makes more DB
* Civil service/welfare dwarves get minimum wage
* If a guild can't pay out due to too many dwarves, not enough work, guild leader generates a mandate to increase work
* Fortress account pays out the shortfall (guilds can never go negative).
* If the Fortress Account goes bust, levy taxes
* Guild bonuses go first; generates an unhappy thought in dwarves that are members of that guild
* Need to check if "unhappy to be taxed" thought is still in the game
* If the Fortress Account is still negative
* Fortress goes into major debt
* - this should be timed with how often dwarves pay rent, I haven't figured it out yet)
-
Damn NCommander, you've really been doing some DFhack magic here recently. Can't wait to see your work implemented.
-
Assuming you can get this working, this is going to be one of the coolest things we've added to DF in a very long time.
-
Assuming you can get this working, this is going to be one of the coolest things we've added to DF in a very long time.
Well, aside from the parts that need a binpatch (legendaries primarily), the rest is already done in some way. I think creating mandates is the only thing that hasn't been done before, but the memory structure is known, so theorically, its a matter of fill in the blanks.
* dwarfvet watches units for jobs
* make-monoarch assigns a dwarf to a noble position
* I've got code that populates the wage tables already and flips the economy on (trivial once Q pointed me to the right places).
I may try implementing part of it tonight though.
-
I had some time today to screw with this some more (and yes, I know, I need to finish dwarfvet), and was able to successfully create mandates on the fly, especially some *weird* ones, as well as revise a specter from times long past:
(http://i.imgur.com/6hcIgwF.png)
I can in effect create a mandate for *any* type of item, set how long they last, and set what, if any punishments they get if the mandate is unfulfilled. It appears material mandates still work (i.e., I can make a "Make copper coins" mandate if I so choose), and assign them to guild leaders on the fly.
I haven't actually managed to get any of the other guild jobs show up (I'm going to have to look at 40d's mandate structure more indepth to figure out the magic, blindly poking values isn't working here. That means playing a 40d fort until economy fires, and then wait for a guild request to pop. Ugh).
I suspect its connected to a unit requests, but that in and of itself didn't do the trick ...
EDIT: Testing shows the game doesn't properly register jobs done for these mandates. Obviously I'm either setting something wrong in memory *or* there's a second place I need to jiggle. Still, progress. I need to write a DFHack plugin to dump mandates the game creates naturally and figure it out from there.
-
Guild job mandates use the mandate's "item type" field to indicate the guild being covered - 0 (BAR) for Miners, 1 (SMALLGEM) for Carpenters, 2 (BLOCKS) for Masons, 3 (ROUGH) for Metalsmiths, 4 (BOULDER) for Jewelers, and 5 (WOOD) for Craftsdwarves. Additionally, jobs will only count toward guild mandates if the job falls within that guild (e.g. it used one of the Metalworking skills) and the unit that performed the job is a member of that guild (e.g. by having one of the Metalworking professions).
-
1) PTW
2) Are you still working on this?
-
PTFW
-
PTW. Are you still working on this?
-
I am, but last week was finals week, and I needed to blow some stress by going long distance bike riding. I'll be home later this week, and when I set out again, I'll be bringing everything required to work on this on my laptop.
-
This is incredibly cool! Can't wait to see a release for this.
-
I would help but I would have no idea what im doing.........
get this and dwarf vet working and then......well......this is bay12. we will find something.
-
PTW. Neat stuff you're doing here!
-
Maybe you already said and I didn't understand it, but I have a small question:
Are there any concrete in-game advantages for this yet? I mean, I know it's not the reason why we would use it, but right now it looks like this:
- if you make mistakes it completely ruins the fortress (as it should be);
- if you perfectly adjust everything, you have the same game you had before, without any rewards for your job, and just another thing that could go wrong sooner or later.
I don't know, do dwarves care if they get paid? Do they get a "He felt happy for being paid recently" thought, or something similar? That would be more than enough.
-
Ptw.
-
PTW
-
Oh my god!
PTW!
-
Maybe you already said and I didn't understand it, but I have a small question:
Are there any concrete in-game advantages for this yet? I mean, I know it's not the reason why we would use it, but right now it looks like this:
- if you make mistakes it completely ruins the fortress (as it should be);
- if you perfectly adjust everything, you have the same game you had before, without any rewards for your job, and just another thing that could go wrong sooner or later.
I don't know, do dwarves care if they get paid? Do they get a "He felt happy for being paid recently" thought, or something similar? That would be more than enough.
Yes, I guess a transition from communism to capitalism shouldn't be that sharp.
-
Watching and waiting.
-
So am I.
-
An idea about the coins value as a credit: Suppose all of the materials in an embark is counted by the Mountainhome as a negative credit based on the absolute value of said items, (say 5 credits of debt = 1 embark point). The purpose of the economy, and of taxing, is to first pay back the Mountainhome for the expense of the expedition, then to create a positive balance with the Mountainhome by selling them minted coins. The bookkeeper would still be keeping track of the accrued wealth of each dwarf, but the coins would be shuffled off with each year's merchants.
If shares in the total Fortress wealth were shared with guilds based on the total hours of work done by all the dwarves in the fortress that month, and therefore passed along to the dwarves of each guild, such that they could then use those shares as the currency for room, board and luxury items present in the fortress. Dwarves with unspent shares could then use them to place orders with the Merchants coming from the Mountainhomes, and thereby aquire stuff that is on their personality's "likes" list.
The entire purpose of an economy is to create a system built to allocate limited resources. This is why rarity increases the value of something up so high, while something available to all is also usually very very cheap. Goods will therefore cost the time required to produce it, plus the cost of its materials. However, depending on how rare the available time to produce these goods is, will make the item more or less rare, and therefore multiply its value using straight supply and demand values. If the supply of alcohol or food decreases below the demand for it from the local population, that is the threshold where the price to acquire each new drink and meal will increase.
However, the goal of the economy should be a system that maximizes overall dwarven happiness. This should be much more easily catered to, since the moods of all the dwarves is easily monitored. The "happiness index" of a fortress, would then measure how robust its economy is, which would guide the decisions for guilds who would also be monitoring it's member's happiness levels and pop mandates when a guildmember's happiness went below a certain threshold. The reason for the economy, therefore, would be to help the Overseer create a more successful fortress.
A thought about the thresholds: they should be raised each time the fortress increments up one civilization level: Outpost-->Village-->Town-->City-->Mountainhome. The "poverty standard" (ie, the point at which negative thoughts begin occuring due to not having enough), should increase in value for each increment. This would simulate the very real modern equivalent of first, second and third world expectations, where the poverty in one culture is the palace in another. Also, Well established guilds in a Mountainhome may become lucrative enough to gamble on founding new outposts of their own, which creates a cycle of value from the other side, as merchants arriving to the Mountainhome could be bringing tributes from those outposts who are themselves paying off their debts and sending coins and goods back to the guilds that sent them, to be sold at an inflated price in the Mountainhome, according to the current market. Sounds like some wonderful end-game fun eh?
This text: http://www.econ.canterbury.ac.nz/personal_pages/bob_reed/econ3003/book/area1c2.htm (http://www.econ.canterbury.ac.nz/personal_pages/bob_reed/econ3003/book/area1c2.htm) might be of use, if you like.
-
Is this still going or not?
-
This could work, I'd suggest trying not to tie it to gold coins but instead simmulate a dematerialized system that assumes that Dwarves write down their accounts. The economy caused tons of stacks of 1 coins and killed fps. Perhaps you could mint coins and have a 'store coins in vault' job that destroys the coin stack and put that into the account.
The civil service and child care ideas are particulary nice. I'll watch this closely, this is cool.
this. If all the coins were stored together, and dwarves just had notes listing their wealth, like a checkbook or bank notes, then they would never need touch the coins, they would just abstractly have paper money representing how much cash they own. It would mimic actual economies until the gold standard was dissolved and salvage FPS.
-
Perhaps we should have a 'vault' structure that acts in that purpose.
It would be neat if it could be robbed by thieves and 'broken' by construction wreckers.
When broken, rather then drop it's stored coinage it acts as bin for its wealth. Coins remain abstract until withdrawn by The bank-dwarf or stolen by a thief.
The bank-dwarves just keep a ledger of the fortress' accounts in their offices.
-
Why not "simply" have dwarves create low-priority jobs to combine partial stacks of coins they own? (I am aware this is not simple.)
I like the idea of physical coinage - it's just that dwarves wouldn't recombine stacks that was the problem, IIRC.
-
That's... Not possible, IIRC. That would require Toady's efforts.
-
Combining stacks with DFHack is possible, and creating jobs is somewhat possible (see diggingInvaders), although it may be horribly broken as of 0.40.20. (I fixed a workflow issue recently, although that involved issues with not cleaning up after suspended jobs correctly, so newly-created jobs might not run into issues.) I don't know if DFHack research has uncovered anything about priorities, though.
-
You can really combine stacks? And it checks to make sure they're identical? And it doesn't alter quality, subtype, material?
How?!?!
-
Well, you have to account for all of that yourself too. The simplest way is to increase the stack size of one item and delete the other item - I think there are combine_drinks and combine_plants scripts that do this in DFHack 0.40.24-r5, if you're interested.
-
Oh. Well, that won't work for automatic reactions. I don't think. :(
Still, good to know!
-
How's this doing?