Print

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

[NCommander]

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

[NCommander]

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

[scamtank]

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.

[NCommander]

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.

[Meph]

Just posting to watch, but very interesting. I'll read through it later.

[Quietust]

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.

[Vattic]

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.

[NCommander]

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.

[NCommander]

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.

[Jiri Petru]

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!

[NCommander]

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.

[NCommander]

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)

[Witty]

Damn NCommander, you've really been doing some DFhack magic here recently. Can't wait to see your work implemented.

[The Master]

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.

[NCommander]

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.