Print

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

[IndigoFenix]

So I hear some people (ag, warmist) have been working on powered workshops.

I've been doing some experimentation myself (using lua scripts) and I've managed to come up with a system that can read power levels of nearby buildings and operate based on them.  Currently, they do not have any effect on the power train itself, neither shutting it down if the power required isn't sufficient nor serving as a power source.  Instead, each machine system determines how many custom machine-using buildings are attached to it, and then allocates its surplus power among them.  (Some machines operate more efficiently if provided with more power - the drilling rig, for instance, can pump liquids up more z-levels if it has more power available).

Now, interacting with power systems directly would be possible, but since DF never seems to actually check if its machines are outputting or requiring the correct amount of power (they only add or subtract from the power level or required power when a new machine component is added or removed) the only way to do this would be to have the plugin script handle the power calculations by itself - by counting up the machine components directly, and adding/subtracting any custom components along with it.  (The update script runs whenever a building is created or destroyed, or when the total power level of a machine system changes.)

The problem with this is that since the script is doing all the calculations, it would have to be able to determine whether or not a building is a machine component or not.  For custom powered workshops, or power-providing workshops such as the steam engine, that means they would need to follow a convention, or the script would not allow them to update properly.

Since there are other people working on machines right now, it would probably be best if we all worked together on this.

I will start off with the following suggestions:
Have all workshops that constantly consume/require power be called DFHACK_MACHINA_MIN_POWER_(number)_(actual workshop name).
Have all workshops that constantly output power be called DFHACK_MACHINA_OUT_POWER_(number)_(actual workshop name).
Have all reactions that require a workshop with a minimum power level be called DFHACK_MACHINA_MIN_POWER_(number)_(actual reaction name).
Have all reactions that produce power be called DFHACK_MACHINA_OUT_POWER_(number)_FOR_(number of ticks)_(actual reaction name).

Yeah, using long workshop/reaction names to store data is kind of messy, but it's simpler than linking them to inorganics.
So... any thoughts on this?

[Warmist]

To tell the truth i forgone the "raw coding" all together. The mechanical workshops have a lot more options, parsing them from raws is a pain, raws get messy as hell and it's not extentable. I know that most of modders would love to have all the features in the raws, but imho a line of lua is way nicer then having "DFHACK_MACHINE_MIN_POWER(10)_ANIMATE(XXXYYYXXX)_ANIMATE...." (after all i made a system for animated workshops, like the screw pump or gears. I could be wrong and there might be some other better way of doing this but i think currently this is simplest for all of us.
Btw line of code (in next dfhack version) that allows for powered workshop (simplest version, non animated, just uses 15 power):

Code: [Select]

require('plugins.building-hacks').registerBuilding{name="BONE_GRINDER", consume=15, gears={x=0,y=0}, --connection point}
more complicated, with animated gear tile:

Code: [Select]

require('plugins.building-hacks').registerBuilding{name="BONE_GRINDER",
  consume=15,
  gears={x=0,y=0}, --connection point
  animate={
    isMechanical=true, --animate the same connection point as vanilla gear
    frames={
    {{x=0,y=0,42,7,0,0}}, --first frame, 1 changed tile
    {{x=0,y=0,15,7,0,0}} -- second frame, same
    }
  }
More info here

Also because this is still unreleased, suggestions are welcome.
Edit: also workshops that emit constant power are possible, but i doubt the usefulness of such workshops. It's totally non controllable so i can't think of any real use cases (i.e. all other energy sources are much more interesting). Also mimicking the steam engine is not yet possible even with this system (due to variable energy input/output).

[IndigoFenix]

Oh, right - I guess more options would be messy.  I just made it so that it automatically connects to any 'gear' tile (that looks like a gear assembly).

So next DFhack version will have powered workshops, like the millstone... I guess that would suit most needs.  Does it work regardless of the order of construction?  I recall there was a problem with that earlier on.  Also, does it allow direct connection between different custom powered workshops?

I'd like to suggest making it so that the same building could have some reactions that require power, some that don't, and some that require different amounts of power.

At any rate, making them raw-codeable should be simple once that next version comes out.  So I'll hold off on that for now.

Of course, some machines would need a much more complicated system - like power sources (the description in that link says that it isn't possible to change the power output at runtime, although this isn't, strictly speaking, entirely accurate - it would just need to update the entire system from scratch every time a power-source activated or shut down) or the aforementioned drilling rig, which requires different amounts of power depending on its depth, operates with different levels of efficiency depending on it's power level, and operates even without an operator as long as it's powered (like a screw pump).  So making a standard system for this kind of thing isn't off the table.

[Meph]

As the modder who uses this stuff most:
I am ok with raws.
I am ok with lua/ruby.
I am not ok with compiled plugins, because I cant see the script behind it, and cant easily change it.

[Warmist]

So next DFhack version will have powered workshops, like the millstone... I guess that would suit most needs.  Does it work regardless of the order of construction?  I recall there was a problem with that earlier on.  Also, does it allow direct connection between different custom powered workshops?

not directly, the same problem is still persistant.

I'd like to suggest making it so that the same building could have some reactions that require power, some that don't, and some that require different amounts of power.

Well currently it works just like quern. All jobs disappear/get canceled if energy is not supplied. Not sure if i could make it more flexible...

At any rate, making them raw-codeable should be simple once that next version comes out.  So I'll hold off on that for now.

Of course, some machines would need a much more complicated system - like power sources (the description in that link says that it isn't possible to change the power output at runtime, although this isn't, strictly speaking, entirely accurate - it would just need to update the entire system from scratch every time a power-source activated or shut down) or the aforementioned drilling rig, which requires different amounts of power depending on its depth, operates with different levels of efficiency depending on it's power level, and operates even without an operator as long as it's powered (like a screw pump).  So making a standard system for this kind of thing isn't off the table.

The problem is that e.g. if you load a game with mechanical workshop without dfhack df does not know how to update the power and it gets desyncronized (same thing would happen if you did the update thing really) that in turn either makes it take 2x energy or gives out too much.
As for drilling thing: i suggest making a simple drill script (e.g. that allows to remove some tile at position) taking in to account: liquids, trees, constructions, creatures, undiggable blocks etc... that should keep you busy till we make better mechanical workshop support

[Putnam]

As the modder who uses this stuff most:
I am ok with raws.
I am ok with lua/ruby.
I am not ok with compiled plugins, because I cant see the script behind it, and cant easily change it.

You can see the code behind it, usually on the creator's github.

If the plugin maker wants there to be settings stuff, they'll probably make a raw or lua level for easy access.

[IndigoFenix]

Hmm... is there a way of changing the state of a gear assembly?
You'd think it would be gear_flags.disengaged, but that doesn't seem to work.

[Warmist]

Hmm... is there a way of changing the state of a gear assembly?
You'd think it would be gear_flags.disengaged, but that doesn't seem to work.

I don't think we can. But try building:setTriggerState(x), maybe it's used for that.

[IndigoFenix]

Hmm... is there a way of changing the state of a gear assembly?
You'd think it would be gear_flags.disengaged, but that doesn't seem to work.

I don't think we can. But try building:setTriggerState(x), maybe it's used for that.

Where is that?  How do I use it?

Edit: Found it.  Seems to take two arguments.  Any way of telling what kind of object it expects?

[Warmist]

it expects building and int. If you call it with ":" it needs only one argument (that is why it's a method, also virtual method if you know what that means), more building vmethods are here: df-structures . The building:vmethod(x) is shorthand for building.vmethod(building,x).

[IndigoFenix]

Hmm, well that doesn't seem to be it.

I'm learning a bit more about how the game stores data on machines though.  I'm going to see if I can get two machines to link together.  It seems that it might be possible to have two machines operate as if they are connected even if they are nowhere near each other.

[Quietust]

I just tried building:setTriggerState(x) on a gear assembly and it worked just fine, just as it ought to.

One important thing to note is that it doesn't matter what number you specify - whether you do setTriggerState(0) or setTriggerState(1), the gear assembly will always toggle rather than explicitly turning on or off. After all, that's how they work when you link them to levers, and pulling a lever just does setTriggerState(N) (based on the state of the lever) on all linked buildings.

[IndigoFenix]

I just tried building:setTriggerState(x) on a gear assembly and it worked just fine, just as it ought to.

One important thing to note is that it doesn't matter what number you specify - whether you do setTriggerState(0) or setTriggerState(1), the gear assembly will always toggle rather than explicitly turning on or off. After all, that's how they work when you link them to levers, and pulling a lever just does setTriggerState(N) (based on the state of the lever) on all linked buildings.

Oh.  Huh.  I guess I didn't think it would be so simple.  Single-tile boolean operators, here I come.

Also, as for linking together machines, this SHOULD work.  I think.  Unless I missed something.  But, how do you insert numbers into a 'userdata' table?  Regular inserts don't seem to work.

Spoiler (click to show/hide)

Code: [Select]

--To link two machines together:
--Get all their machine components.
--compRaise = #machineA.components.
--For each of machineA.components, if building_id == connectorA, conA = the component's index.
--Set each components.connections in machineB to have its value raised by compRaise.
--Also, find the building with its id and set its machine.machine_id to machineA's id.
--If it is the building to be connected, add conA to its connections.  Also, conB = its index in the connections array + compRaise.
--for machineA.components[conA], add conB to its connections.
--machineA.cur_power = machineA.cur_power+machineB.cur_power
--machineA.min_power = machineA.min_power+machineB.min_power
--Add all of machineB's components to machineA.  (Could be done earlier, while looping through them the first time)
--Delete machineB.

function linkMachineComponents(buildingA,buildingB)
local machineA = getMachineById(buildingA.machine.machine_id)
local machineB = getMachineById(buildingB.machine.machine_id)
local compRaise = #machineA.components
local conA = nil
local conB = nil
for i=0,#machineA.components-1,1 do
component=machineA.components[i]
if component.building_id == buildingA.id then conA = i break end
end
for i=0,#machineB.components-1,1 do
component=machineB.components[i]
compBuilding=getBuildingById(component.building_id)
compBuilding.machine.machine_id = machineA.id
for c=0,#component.connections-1,1 do
component.connections[c] = component.connections[c] + compRaise
end
if compBuilding.id == buildingB.id then
table.insert(component.connections,conA)
conB = i+compRaise
end
table.insert(machineA.components,component)
end
table.insert(machineA.components[conA].connections,conB)
machineA.cur_power = machineA.cur_power + machineB.cur_power
machineA.min_power = machineA.min_power + machineB.min_power
table.remove(df.global.world.machines.all,machineB)
end


[Putnam]

Rather than table.insert, you use ref:insert(index,num). "index" can be the string '#' or simply #ref to insert at the end.


See here.

[IndigoFenix]

Thanks

One more problem for today... Kind of a really weird one.
Basically I'm trying to check if there are powered or unpowered machine components adjacent to a building.  The gear positions are fine, the buildings being checked are correct, but for some reason the check for whether the machine is active or not doesn't work right.  Instead, it seems to always respond with whatever state the machine was in when the building was built - even though it's checking the building again from the start.  Is this something weird about how the dfhack.buildings.findAtTile function works?  Maybe it tries to speed up the function by returning the same building data if the same position is called twice, but botches things whenever machines are concerned?

Never mind, it was simply not updating properly.

What would you say is the best way of determining when the state of a machine changes?  Buildings being created or destroyed can be listened for with eventful, but what about for when the power level of a machine changes, or when a gear assembly is engaged or disengaged?