Print

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

[CaptainMcClellan]

The title pretty much sums it up, I'd like some tags to be added to the building reactions to allow those buildings (when properly connected) to produce a variable amount of power.
To wit:

• [PRODUCES_POWER:X] The reaction causes the building to start building
• [POWER_PRESSURE:X:Y:Z] An optional tag that takes in account breakdowns. At X ticks the building's description will contain "making an unsettling noise", at Y ticks it will be described as "shuddering violently" or "smoking" and at Z ticks it will go "critical" and deconstruct itself. (Preferably, in a violent dwarf injuring fashion comparable to a cave-in.)
• [CEASE_POWER] ( Or [CUT_POWER]) The reaction stops its host building from producing power.
• [DRAINS_PRESSURE:X:Y]Decreases the building's POWER_PRESSURE by X over Y ticks. 0 is instant.
• [REQUIRES_MECHS] Reaction requires the building to contain at least one mechanism.

I shouldn't think that it'd be too much trouble... And it'll allow all kinds of cool generators. ( Imagine, if you will, a Steam generator, or a Dwarven generator. )

Using the Steam generator as an example. ( Didn't do it syntactically correct, because I'm in a bit of a hurry.

[REACTION:BOIL_WATER]
Takes water in a bucket and boils it into pressurized steam. Consumes fuel.
[PRODUCES_POWER:200] -Provides 200 power to connected mechanisms.
[POWER_PRESSURE:10000:15000:25000] - Goes critical at 25000 ticks.
[REQUIRES_MECHS]

[REACTION:VENT_STEAM]
[DRAINS_PRESSURE:1000:100] -Drains 1000 ticks worth of pressure over 100 ticks.

[REACTION:EXTINGUISH_BOILER]
[CEASE_POWER] - The generator stops producing power and building pressure.


Also, less for the sake of practicality and more for the sake of fun... This custom building tag:
[RELEASES_MAT_ON_CRITICAL:X:<STATE>:<TYPE>:<MATERIAL>] where X is the radius of the release from the center tile of the former building

For example [RELEASES_MAT_ON_CRITICAL:3:GAS:INORGANIC:WATER] would theoretically release a 3*3 cloud of steam on the break-down of the steam generator, centered on the former center tile of the former steam engine.

[StagnantSoul]

Sounds simple, but I doubt it is.

[Putnam]

[REQUIRES_MECHS] shouldn't really be necessary, since reactions are attached to buildings anyway and buildings have all of their items to build with defined in the building.

[CaptainMcClellan]

[REQUIRES_MECHS] shouldn't really be necessary, since reactions are attached to buildings anyway and buildings have all of their items to build with defined in the building.

Eyeah, good point Putnam.

Sounds simple, but I doubt it is.

Yeah. In honesty, it's probably at least a day's work, maybe two. ( I can't see it being more than two, especially if Toady has things as modular as the RAWs would suggest. )

[Putnam]

Heh, that's a pretty strong underestimation. I'd say a week at least. Consider that all the power buildings are completely hardcoded right now and that there is no pressure in any of them.

[CaptainMcClellan]

Heh, that's a pretty strong underestimation. I'd say a week at least. Consider that all the power buildings are completely hardcoded right now and that there is no pressure in any of them.

Alright, I'll admit that I don't know about Dwarf Fortress's internal mechanisms, but it doesn't seem like it would take that long. Except perhaps to code in the functions of going the generator going critical.

[stuntcock42]

Alright, I'll admit that I don't know about Dwarf Fortress's internal mechanisms, but it doesn't seem like it would take that long.

Take a look at the description of the DFHack steam engine and then skim through some of the code if you're feeling adventurous.

You're free to propose changes which you think are good for the game, of course.  But if you're pitching something as a quick-fix, then you might want to adjust your idea so that it's more closely congruent to the current systems and codebase.

For example - the DFHack steam engine must be designated as a custom Workshop (even though "Furnace" is more thematically appropriate) because the Dwarf Fortress memory and code structures do not treat Furnaces as eligible for machine-connection.  If you ask Toady "please let us apply the [MACHINE_CONNECTION] tag to any Workshop via the raws instead of DFHack code" then sure - that's a one-day task.  But if you ask for the new [MACHINE_CONNECTION] tag to work with all types of buildings (including furnaces, siege engines, etc) then it might turn out to be more complicated than we expect.

The DFHack steam engine also ties directly into the building's inventory: the building contains several discrete Water items, each of which generates 100 units of power (until it gets destroyed by item-decay logic).  Thus, the building doesn't know its power output but can calculate it whenever the game asks.  The vanilla power generators (Waterwheels and Windmills) are similar - they can determine their power output by checking the status of the tiles above or beneath them.

If power generation is instead governed by a highly-variable integer (e.g. Pressure = 24136) which is not connected to the state of the environment or the building's contents, then the Building class would need a new instance variable to store it.


-- The stuff below doesn't deal directly with your suggestion, but rather with your example --

We currently lack a reaction tag for "this operation requires water so the assigned Dwarf shall please fill a bucket from a valid Water Source or Well and then bring it to the building."  Hence, you see custom reactions in various mods which magically drain environmental water from the space around the workshop.  Adding [BRING_BUCKET_OF:INORGANIC:WATER:150] to the reaction raws would hopefully not a major complication, but it's definitely something new.

The idea of a building providing subtle status/warning information is novel, but where would it appear?  In the [q]uery menu?  In the Loo[k] menu?  The View i[t]ems in Buildings menu?  As a new Alert?  Or would this also be configurable via new RAW tags?

The proposed danger/inaccuracy of the device (e.g. "stoke the boiler until it starts making noises, and hope that it doesn't explode") is neat, but it might require too much attention from the player.  Many Dwarf Fortress players seek to setup efficient automated workflows; if you ask them to micromanage boilers then they're going to be disappointed.

I like the fact that players could cause a catastrophe by choosing to deconstruct a Steam Generator but forgetting to vent its pressure beforehand.  Ideally, a Dwarf Fortress disaster should involve stupidity on the player's side as well as the AI's.

[CaptainMcClellan]

Alright, I'll admit that I don't know about Dwarf Fortress's internal mechanisms, but it doesn't seem like it would take that long.

Take a look at the description of the DFHack steam engine and then skim through some of the code if you're feeling adventurous.

You're free to propose changes which you think are good for the game, of course.  But if you're pitching something as a quick-fix, then you might want to adjust your idea so that it's more closely congruent to the current systems and codebase.

For example - the DFHack steam engine must be designated as a custom Workshop (even though "Furnace" is more thematically appropriate) because the Dwarf Fortress memory and code structures do not treat Furnaces as eligible for machine-connection.  If you ask Toady "please let us apply the [MACHINE_CONNECTION] tag to any Workshop via the raws instead of DFHack code" then sure - that's a one-day task.  But if you ask for the new [MACHINE_CONNECTION] tag to work with all types of buildings (including furnaces, siege engines, etc) then it might turn out to be more complicated than we expect.

The DFHack steam engine also ties directly into the building's inventory: the building contains several discrete Water items, each of which generates 100 units of power (until it gets destroyed by item-decay logic).  Thus, the building doesn't know its power output but can calculate it whenever the game asks.  The vanilla power generators (Waterwheels and Windmills) are similar - they can determine their power output by checking the status of the tiles above or beneath them.

If power generation is instead governed by a highly-variable integer (e.g. Pressure = 24136) which is not connected to the state of the environment or the building's contents, then the Building class would need a new instance variable to store it.


-- The stuff below doesn't deal directly with your suggestion, but rather with your example --

We currently lack a reaction tag for "this operation requires water so the assigned Dwarf shall please fill a bucket from a valid Water Source or Well and then bring it to the building."  Hence, you see custom reactions in various mods which magically drain environmental water from the space around the workshop.  Adding [BRING_BUCKET_OF:INORGANIC:WATER:150] to the reaction raws would hopefully not a major complication, but it's definitely something new.

The idea of a building providing subtle status/warning information is novel, but where would it appear?  In the [q]uery menu?  In the Loo[k] menu?  The View i[t]ems in Buildings menu?  As a new Alert?  Or would this also be configurable via new RAW tags?

The proposed danger/inaccuracy of the device (e.g. "stoke the boiler until it starts making noises, and hope that it doesn't explode") is neat, but it might require too much attention from the player.  Many Dwarf Fortress players seek to setup efficient automated workflows; if you ask them to micromanage boilers then they're going to be disappointed.

I like the fact that players could cause a catastrophe by choosing to deconstruct a Steam Generator but forgetting to vent its pressure beforehand.  Ideally, a Dwarf Fortress disaster should involve stupidity on the player's side as well as the AI's.

Mmmm... It's sort of a cross between the two: It's both a feature I'd like to see incorporated at some point and a "quick fix" to provide the functionality with (hopefully) minimal effort to get it shoehorned in before the next update. ( If it's possible, of course, and Toady's priorities are his own so that'll be up to him when or if this gets done.)

I don't necessarily need it be a furnace and was not aware of the DFHack plugin. While I still would like to see this implemented in the vanilla game, I may make do with modding the plugin to what I want to happen. ( I'm not too great at that, admittedly. ) I'm perfectly fine just having it be a workshop, since that's kinda what I'd intended anyway.

Yeah, I was pretty much aware that that's what that would mean. I'm still kind of noobish, but I don't see why it's that hard to define another variable and link it to the building's structure. Is there anything that I'm not aware of that would make this super time consuming and hard?

Huh. I thought a reaction with a water-filled bucket would work. Can you not specify a water-filled bucket like you can with a Lye bucket?

Yeah, thanks. I like the idea myself and hope it can be applied to other buildings for the sake of managing wear. I was thinking that the warnings would appear in the [q]uery and loo[k] menus, the idea being that you have to keep a casual eye on it to make sure it's not about to explode and flood the surrounding area with boiling water. I should think that the critical would be announced in the same way as the production of an artifact or the arrival of a forgotten beast, but the warnings themselves? Hm... Perhaps displayed in the regular alerts bar. I just don't want it to incur mass spam. And for the alerts, if there are any, it should only throw them when a building reaches "shuddering violently" and roughly 3 times after, with increasing urgency. Any more than that, and I feel like it's going to be spammy.

Well, see that's where it being controlled by a raw tag is handy. Simply mod the values so that the building in question doesn't build pressure. Worst (or best, depending on your point of view) case scenario, just add a tag to the init file that disables this sort of pressure calculation altogether. ( Just how you can with temperature. ) I'd like to give players the option, personally, because I know that a lot of players don't really care for micromanaging so much as I do and don't get as much of a thrill from watching chaos occur because reality ensued. ( More importantly I recognize that the players don't necessarily want to always be managing things and want their mechs to stand forever. There've been plent of times when that is the case for myself even. ) I think, though, that if it gets implemented, people will adjust (or disable) and at least a third of the fan base will enjoy it.

Totally.

[stuntcock42]

Yeah, I was pretty much aware that that's what that would mean. I'm still kind of noobish, but I don't see why it's that hard to define another variable and link it to the building's structure. Is there anything that I'm not aware of that would make this super time consuming and hard?

No; it's a completely normal thing, and it's the most reasonable way to accommodate your request (pressure, powergen, criticality, warnings, explosions, etc).  But - from a programming point of view - the memory structure of a building is surprisingly small (especially when contrasted with the jillions of thoughts and emotions which define creatures).  This may indicate that Toady is deliberately avoiding complexity in his Buildings, and (if so) might make him opt for a native solution (e.g. DFHack's use of inventory) rather than including a new variable.

Huh. I thought a reaction with a water-filled bucket would work. Can you not specify a water-filled bucket like you can with a Lye bucket?

You can, and it will work.  But dwarves will not fill buckets on their own initiative - they'll simply use water-filled buckets which already exist (e.g. ones that are created by an interrupted Fill Pond job).  Hence, you'll end up with a valid water source, lots of empty buckets, idle laborers, halted steam generators, and constant job-cancellation spam ("Urist cancels Stoke the Boiler: Needs water-filled bucket!").

I poked around with this idea a bit when I was trying to setup water-dependent alcohol reactions.  But I ended up using the same approach as DFHack's steam engine or Meph's brewery - just magically suck water from the surrounding tiles.  Of course, you can designate a small Pond zond so that the water actually gets carried to the workshop/furnace by dwarven laborers (with buckets).  Since the reaction ultimately involves an equivalent input of time/effort/risk ("risk" mainly applies to outdoor water sources), it feels like a reasonable compromise.

If you're dedicated to the bucket-as-a-reagent version of the Reaction, then it's possible to setup overcommitted Pond zones which will tend to yield "extra" buckets full of water.  Unfortunately, this approach is very difficult to balance - you'll probably find that ALL of your buckets become filled with water, and then you'll be unable to produce Milk or Lye.

[CaptainMcClellan]

Yeah, I was pretty much aware that that's what that would mean. I'm still kind of noobish, but I don't see why it's that hard to define another variable and link it to the building's structure. Is there anything that I'm not aware of that would make this super time consuming and hard?

No; it's a completely normal thing, and it's the most reasonable way to accommodate your request (pressure, powergen, criticality, warnings, explosions, etc).  But - from a programming point of view - the memory structure of a building is surprisingly small (especially when contrasted with the jillions of thoughts and emotions which define creatures).  This may indicate that Toady is deliberately avoiding complexity in his Buildings, and (if so) might make him opt for a native solution (e.g. DFHack's use of inventory) rather than including a new variable.

I was under the impression that he was just prioritizing. From all of the interviews I've read, he only goes into detail on any particular subject when ( ( It's fun for him || He thinks it'll enrich the world ) && Player demand is medium-to-high || He needs it for another function of the game || Player demand is VERY HIGH.^* || he's determined to get a feature just because he said he would in his plans for the update) The demand for this is only medium at best, but I'm hoping the fact that it wouldn't be masochistically difficult can be used as a reason to do it, with some friendly nudging. That'll only work if he can just slap in the values within less than a week and shove the next version out to testing without being off-schedule. Besides, buildings are (relatively) simple compared to creatures, no matter how you're looking at it, so the need is not that great to go into it. I mean power production or receiving power and the ability to mod that into a building are seriously the only things I can think of that would improve the game by going into further detail on buildings. ( And even then, I only thought of them because I wanted a new power-source to go with my infinite energy generators to get them going easier.)

Well, I guess there's also automatic reactions on receiving power, but we'll cross that bridge when we come to it. (Again, just being a noob, but even that seems like it could be handled with a simple if statement: like

Code: [Select]

if(IS_POWERED==TRUE){ //While the building has power, within the main execution loop.
  while(REACTIONS){ //A stand-in for the actual while statement which is basically to read for reactions until there are no more.
    if(REACTION.IS_POWERED && REACTION.REQUIRES POWER) { //A dummy check for the [IS_POWERED] and [REQUIRES_POWER]
     //execute reaction.
}
      read(NEXT_REACTION) //Fetch the next reaction, whatever it is.
}
}

I don't really know how the internal mechanisms of DF work, but that's just general programming reasoning that should work if there's no more complicated stipulations that I'm just simply not foreseeing due to ignorance. )

_{* Something like >=95% of all the players based on sampling the suggestion forum.}

~snip: the rest.~

Huh. Who knew that water would be the most complicated element of a nuclear reactor steam engine? Water, you're stupid flexible and useful, but that leads to a lot of stipulations on your functions. ( Both true IRL and in DF. ) I'll probably go with the magically pumping up water and add a corkscrew and a pipe to the building's ingredients to justify it in my feelings. It'd be more realistic anyway.

As per the only other stipulation I can think of - where to plug your gears/axles into - here's what I have, in the form of options.

Option 1:

Code: [Select]

      [][][]
   IN>[][][]>OUT
      [][][]
If the building both requires power and produces it, just as an example. With the hard-coded values for where the in and out go for a custom building. ( Like how water-wheels and wind-mills work. )

Option 2:

Code: [Select]

        ^
        V
     [][][]
   <>[][][]<>
     [][][]
       ^
       V

Have the ability to select a building's orientation at building, with input and output on opposite sides and based on context. ( Like how axles and screw-pumps work. )

Option 1 is simpler, but Option 2 is better. I'll take whichever gets this in the game faster.

[CaptainMcClellan]

Bump.