Print

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

[Bogus]

im trying to implement a menu script for my custom smelter that lets you select a class of ore first before presenting to you a selection of ores from that class to pick from. should be basically the same kind of ui that some built in workshops have, like forge, glassmaker etc.

now the problem is that eventful seems to only provide a callin routine for replacing the whole wokshop menu, not just the "Add new task" submenu. how would i go about just replacing that, while keeping the basic menu?

[Warmist]

im trying to implement a menu script for my custom smelter that lets you select a class of ore first before presenting to you a selection of ores from that class to pick from. should be basically the same kind of ui that some built in workshops have, like forge, glassmaker etc.

now the problem is that eventful seems to only provide a callin routine for replacing the whole wokshop menu, not just the "Add new task" submenu. how would i go about just replacing that, while keeping the basic menu?

Eventful only provides a hook: a way to trigger when it's presented. Then you can do anything you want. This includes:

• removing/adding existing buttons (if in "postWorkshopFillSidebarMenu") thus disabling all or part of native reactions
• showing a viewscreen on top of the native one with or without drawing old one and passing what you want to the old screen
• recreating most of the stuff that is in native workshops (my method of choice)

Looks to me that it's enough for you to use the first method. Unless you want something more fancy (e.g. "Souls in workshop: 5 Reactions active!") it should do what you want quite nicely.

I can make an example if you give me more details (and some time...)

[Bogus]

well lets see. this is the callin im using for the script, but it only ever gets called when selecting the workshop, not when entering the add task menu.

Spoiler (click to show/hide)

function fillSideBarCallback(wshop)
   print("smelt menu was called: "..dfhack.gui.getFocusString(dfhack.gui.getCurViewscreen()))   
   local valid_focus="dwarfmode/QueryBuilding/Some/Workshop/Addjob"
    if string.sub(dfhack.gui.getCurFocus(),1,#valid_focus)==valid_focus and wshop:getMaxBuildStage()==wshop:getBuildStage()
    then -- never happens because focus is "dwarfmode/QueryBuilding/Some/Workshop" when script gets called
   SmeltMenu{wshop=wshop}:show()   
    end   
end

eventful.registerSidebar('GUNSMITH', fillSideBarCallback)

now what i need is to replace the normal list of reactions("dwarfmode/QueryBuilding/Some/Workshop/Addjob") with a 2-level menu.

there are 5 distinct classes of ores that may have different side effects when smelting and may need extra fuel, flux, etc. the first page of the menu would let you select a class, the second page would contain a list of ores that belong to that class.

these are not individual reactions tho, it should rather just select a material to run one of 3 existing reactions with (ideally no reactions are involved but duno if thats possible or desirable) - and then just que that up like any other job at a workshop.

recreating most of the stuff that is in native workshops (my method of choice)

i guess that could work too. do you have some code of this for me to look at?

[milo christiansen]

If someone figures out how to do this I want to know! AFAIK it is impossible, but there may be a way to simulate something similar (I just wouldn't know how...).

BTW: I thought something like that was coming in the next version? Wasn't there something like custom reactions menus listed as a coming feature?

[Warmist]

If someone figures out how to do this I want to know! AFAIK it is impossible, but there may be a way to simulate something similar (I just wouldn't know how...).

BTW: I thought something like that was coming in the next version? Wasn't there something like custom reactions menus listed as a coming feature?

It's already in. Though largely undocumented...

here's a minimal working example:
here
The idea is that it shows a screen that inherits from "gui.dwarfmode.WorkshopOverlay". The parent class gives most of "natural functionality" like moving pointer around, selecting other shops etc... (though not extensively tested and might be missing some features).
You only define what you need and with dfhacks gui tools it's easy and quick to make some strange contraction that works differently.

[milo christiansen]

That is adding a replacement sidebar, not adding submenus. Adding a submenu is something completely different.

A submenu would allow you to select a GUI item, that would switch sidebars to display a different menu with a list of workshop job buttons based on your previous choice. Unless that is somehow possible, in that case an example that actually does it would be a lot more helpful...

[Warmist]

That is adding a replacement sidebar, not adding submenus. Adding a submenu is something completely different.

A submenu would allow you to select a GUI item, that would switch sidebars to display a different menu with a list of workshop job buttons based on your previous choice. Unless that is somehow possible, in that case an example that actually does it would be a lot more helpful...

-.- this saddens me... I offer you the world and you want this small thingy.

Yes it's possible (though how i did not thing about this ). I'll work up an example when i get free time. It involves with messing the "df.global.ui_sidebar_menus" in that callback (i.e. after they been filled in) or instead of it (callnative.value=false) to replace the buttons.

There are limitations on what could be done (e.g. no lua scripts on buttons) but it's easier and more native-like.

[Bogus]

making the menu itself doesnt seem so much of a problem, workshop_job already does a similar thing and hooks into the normal menu structure, but it runs on hotkey and doesnt replace anything.

capturing the moment of when the "add new task" submenu is opened and then running the script is what is needed. maybe eventful already provides a way to do this that im not aware of?

[Bogus]

i got part of it to work. it will select material and create a regular job based on a reaction with selected material, job shows up in the normal wokshop menu and seems to behave itself.

however, the script still gets called when entering the workshop menu. "Add new task" menu isnt replaced either. rather you can leave the replacement sidebar with escape and then you end up in the normal workshop menu. so what is needed is a hook to show my menu only when entering "Add new task", the rest seems to work fine.

also the job description only shows the name of the underlying reaction, i dont know how to insert custom name for the description, which would be very desirable because "melt ore" is not very informative.

[Bogus]

managed to get the menu pop up over the "Add new task" menu with this somewhat hacky construction, basically polling the focus state of the ui every couple of frames after entering the basic menu for the workshop in question. when the focus changes to the task submenu, the overlay is shown.

Code: [Select]

local function focuschangeCallback() -- this gets called every 3 frames while in the workshop menu
    local wshop = dfhack.gui.getSelectedBuilding() -- we check if were still in the correct shop type...
    if not wshop or df.building_def_workshopst.find(wshop.custom_type).code ~= 'GUNSMITH' then
print("left workshop menu")
dfhack.timeout_active(timer, nil) -- ...and if not, unhook the callin
return
else  -- if we are still in the correct workshop, we check if the focus is right...
local valid_focus = "dwarfmode/QueryBuilding/Some/Workshop/AddJob"
                if dfhack.gui.getFocusString(dfhack.gui.getCurViewscreen()) == valid_focus and wshop:getMaxBuildStage() == wshop:getBuildStage() then
                        -- ... and if so, we can now display the menu. yay!
print("entered job menu")
SmeltMenu{wshop=wshop}:show()
dfhack.timeout_active(timer, nil)
return
end
timer = dfhack.timeout(3,'frames',focuschangeCallback) -- otherwise, we just restart the timer for every cycle because it just runs once
end
end

function fillSideBarCallback(wshop) -- this gets called when the workshop is selected. it just hooks the callin
timer = dfhack.timeout(3,'frames',focuschangeCallback)
end

eventful.registerSidebar('GUNSMITH', fillSideBarCallback, true)

one problem remains tho, when returning from the overlay menu you end up in the normal "Add new task" submenu.

Code: [Select]

function SmeltMenu:on_close()
gui.simulateInput(dfhack.gui.getCurViewscreen(), 'LEAVESCREEN')
gui.simulateInput(dfhack.gui.getCurViewscreen(), 'D_BUILDJOB')
end
this kinda works to solve that problem, after queing jobs or leaving the menu you would end up in the root of the workshop menu.

from the looks of it you can replicate vanilla workshop menus using that method pretty much 100%. ill post whole code tomorrow when i did some cleanup.

[Bogus]

full script (tutorialized):

Spoiler (click to show/hide)

--local _ENV = mkmodule('gui.addjob-replace') -- does not work for some reason
-- print("loading job overlay")

local eventful = require 'plugins.eventful'

local utils = require 'utils'
local gui = require 'gui'
local guidm = require 'gui.dwarfmode'
local guimat = require 'gui.materials'
local widgets = require 'gui.widgets'
local dlg = require 'gui.dialogs'
local ws = require 'dfhack.workshops'


MyJobOverlay = defclass(MyJobOverlay, guidm.WorkshopOverlay)
MyJobOverlay.focus_path = "dwarfmode/QueryBuilding/Some/Workshop/AddJob"
MyJobOverlay.myWorkshop = 'MYWORKSHOP'
MyJobOverlay.firstpage = true -- which level of the menu we are in.

MyJobOverlay.ATTRS {
   wshop = DEFAULT_NIL, -- presumably unused
    frame_inset = 1,
    frame_background = COLOR_BLACK,   
}

-- setting up the basic menu structure
function MyJobOverlay:init(args)
   self:addviews{
       widgets.Label{
            frame = { l = 0, t = 0 },
            text = {
                { text = 'workshop',}
            }
        },      
      widgets.List{
            view_id = 'list',           
            frame = { l = 0, r = 0, t = 2 }, --, b = 2           
            on_submit = self:callback('onSubmitItem'),
         scroll_keys = widgets.SECONDSCROLL,
        },
      widgets.Label{
            view_id = 'back',
         frame = { l = 0, b = 0 },
            text = {
                { key = 'LEAVESCREEN', text = ': Back',
                  on_activate = self:callback('dismiss') } -- should check wether to close or go back one level
            }
        },
    }
    self:initListChoices()
end

-- first layer of the menu. these choices are over a couple of reaction classes but could be others as well
function MyJobOverlay:initListChoices()
   local choices = {}
    table.insert(choices, {text = 'some group of materials', key = 'CUSTOM_A',   cb = self:callback('initMatMode', 'MY_REACTION_CLASS_1')})
   table.insert(choices, {text = 'another group', key = 'CUSTOM_B',   cb = self:callback('initMatMode', 'MY_REACTION_CLASS_2')})
   table.insert(choices, {text = 'weird stuff', key = 'CUSTOM_C',   cb = self:callback('initMatMode', 'MY_REACTION_CLASS_3')})   
   self:pushContext('Top Layer', choices) -- name doesnt matter
end

-- check through all the materials using the reaction class from above as filter
function MyJobOverlay:initMatMode(rclass) 
   local choices = {}   
    local foo = true
   for i,mat in ipairs(df.global.world.raws.inorganics) do       
      local m = mat.material
      if mat.material.reaction_class then
         for k, v in pairs(mat.material.reaction_class) do
            if (v.value == rclass) then
               -- print("found mat: "..mat.id.." in reaction class: "..rclass)
               self:addMaterial(choices, mat.material, i, mat, rclass)
            end
         end      
      end   
    end
    self:pushContext(rclass, choices)
end

-- add choices into the second level of the menu for each material that qualifies
-- (should check here if items are available so menu items can be displayed in red / disabled)
function MyJobOverlay:addMaterial(choices, mat, idx, parent, rclass)

    -- Find the material name
    local state = 0
    if mat.heat.melting_point <= 10015 then
        state = 1
    end
    local name = mat.state_name[state]
    name = string.gsub(name, '^frozen ','')
    name = string.gsub(name, '^molten ','')
    name = string.gsub(name, '^condensed ','')
   name = string.gsub(name, '^boiling ','')   

    table.insert(choices, {
        text = 'smelt '..name,
        search_key = key,
        material = mat,
        mat_type = 0,
      mat_index = idx,
      cls = rclass,
    })
end


function MyJobOverlay:pushContext(name, choices)
    if not self.back_stack then
        self.back_stack = {}
        self.firstpage = true
    else
        table.insert(self.back_stack, {
            context_str = self.context_str,
            all_choices = self.subviews.list:getChoices(),
            selected = self.subviews.list:getSelected(),
        })
        self.firstpage = false
    end
    self.context_str = name
    self.subviews.list:setChoices(choices, 1)
end


function MyJobOverlay:onGoBack()
    local save = table.remove(self.back_stack)
    self.firstpage = true
    self.context_str = save.context_str
    self.subviews.list:setChoices(save.all_choices)
end


function MyJobOverlay:onSubmitItem(idx, item)
    if item.cb then
        item:cb(idx)
    else
        self:submitMaterial(item.text, item.material, item.mat_type, item.mat_index, item.cls)
    end
end


local function get_reaction(name)
    if not reaction_id_cache then
        reaction_id_cache = {}
        for i,v in ipairs(df.global.world.raws.reactions) do
            reaction_id_cache[v.code] = i
        end
    end
    local id = reaction_id_cache[name] or -1
    return id, df.reaction.find(id)
end


-- setting up some fields for each job item
local function reagentToJobItem(reagent,react_id,reagentId, typ, index, cls)
   local ret_item
    ret_item = utils.clone_with_default(reagent, ws.input_filter_defaults)
    ret_item.reaction_id = react_id
    ret_item.reagent_index = reagentId
   ret_item.new = true --?   
    if reagent.code == 'ore' then -- we check the name of the reagent here to only set the below fields for the main ingredient
      ret_item.mat_type = typ
      ret_item.mat_index = index
      ret_item.reaction_class = cls
   end
   return ret_item
end


-- after selecting a material, we select the appropriate reaction if multiple are present
-- then we create a job and feed it with item/material data from that reaction & our selection
function MyJobOverlay:submitMaterial(text, mat, typ, index, cls) -- mat unused

   -- selecting a reaction based on the mat choice, because they may need different secondary ingredients
   -- you could use just one reaction for all and instead add job items later
   local rname
   if cls == 'MY_REACTION_CLASS_3' then
      rname = 'SPECIAL_REACTION'
   else
      rname = 'EXAMPLE_REACTION'
   end
   
   local rid, reaction = get_reaction(rname)   
   
   local job = df.job:new()
   job.id = df.global.job_next_id   
    df.global.job_next_id = df.global.job_next_id + 1
   dfhack.job.linkIntoWorld(job, true)
   
   job_fields = {         
         job_type = df.job_type.CustomReaction,
         reaction_name = rname,
         mat_type = typ,
         mat_index = index,
      }   
   job:assign(job_fields)
   job.general_refs:insert("#",{new = df.general_ref_building_holderst,building_id = self.wshop.id}) -- workshop reference
      
    for reagentId,reagent in pairs(reaction.reagents) do -- reaction reagents need some more fields before they can be used in the job
      job.job_items:insert('#', reagentToJobItem(reagent,rid,reagentId, typ, index, cls))
   end
   
   -- need to add additional fuel here for [FUEL] reactions, if not at a magma powedered shop
   -- too lazy & and not tested
   -- local fuel={item_type=df.item_type.BAR,mat_type=df.builtin_mats.COAL}
   -- job.job_items:insert('#', reagentToJobItem(fuel,rid,reagentId, typ, index, cls))

   self.wshop.jobs:insert("#",job)   
   
   self:dismiss()
end


function MyJobOverlay:onInput(keys)   
    if keys.LEAVESCREEN or keys.LEAVESCREEN_ALL then
        if not self.firstpage and not keys.LEAVESCREEN_ALL then
            self:onGoBack()
        else
            self:dismiss()
            if self.on_cancel then
                self.on_cancel()
            end
        end
    else
        self:inputToSubviews(keys)
    end
end


function MyJobOverlay:onDestroy()
    if self.on_close then
        self.on_close()
    end
end

-- if we submit a job choice, we dont want to leave the whole workshop, so we just re-enter it
function MyJobOverlay:on_close()
   gui.simulateInput(dfhack.gui.getCurViewscreen(), 'LEAVESCREEN')
   gui.simulateInput(dfhack.gui.getCurViewscreen(), 'D_BUILDJOB')
end


-- we query this function every frame to see if the gui focus changed to the menu we want to replace
local function queryFocus()
   local wshop = dfhack.gui.getSelectedBuilding()
   if wshop and wshop.custom_type and df.building_def_workshopst.find(wshop.custom_type).code == MyJobOverlay.myWorkshop then   
      if dfhack.gui.getFocusString(dfhack.gui.getCurViewscreen()) == MyJobOverlay.focus_path and
         wshop:getMaxBuildStage() == wshop:getBuildStage() then -- this is probably unnecessary because the Addjob focus isnt there if unbuilt      
         -- print("entered focus menu")
         MyJobOverlay{wshop=wshop}:show()
         dfhack.timeout_active(timer, nil)
         return
      end   
      timer = dfhack.timeout(1,'frames',queryFocus) -- we are still in the building, but in a different focus. so keep the query going
   else
      -- print("left workshop menu")
      dfhack.timeout_active(timer, nil)
      return   
   end   
end

-- eventful calls this when we enter the workshop registered below, and this in turn enables above callin
function fillSideBarCallback(wshop)
   timer = dfhack.timeout(1,'frames',queryFocus)      
end

eventful.registerSidebar(MyJobOverlay.myWorkshop, fillSideBarCallback, true)
-- print("job overlay loaded")

-- return _ENV

reaction classes

Spoiler (click to show/hide)

the name tag for the reagents controls wether the material selection should apply to them.
the reaction class tag is filled in by the script so no need to add it here
the material does ofc need to have an ITEM_REACTION_PRODUCT in this example, but the reagent doesnt need the tag

[REACTION:EXAMPLE_REACTION]
[NAME:smelt native ore]
[BUILDING:MYWORKSHOP:NONE] -- not really needed
[REAGENT:ore:1:BOULDER:NO_SUBTYPE:INORGANIC:NONE]
[PRODUCT:100:1:GET_ITEM_DATA_FROM_REAGENT:ore:YIELD_ITEM_A][PRODUCT_DIMENSION:150]
[PRODUCT:100:1:GET_ITEM_DATA_FROM_REAGENT:ore:YIELD_ITEM_B][PRODUCT_DIMENSION:150]
[PRODUCT:100:1:GET_ITEM_DATA_FROM_REAGENT:ore:YIELD_ITEM_C][PRODUCT_DIMENSION:150]
[FUEL] -- doesnt work atm
[SKILL:SMELT]

[REACTION:SPECIAL_REACTION]
[NAME:smelt other ore]
[BUILDING:MYWORKSHOP:NONE]
[REAGENT:ore:1:BOULDER:NO_SUBTYPE:INORGANIC:NONE]
[REAGENT:extra fuel:1:BAR:NO_SUBTYPE:COAL:NO_SUBTYPE] -- this will keep its material
[REAGENT:flux:1:BOULDER:NO_SUBTYPE:INORGANIC:NONE][REACTION_CLASS:FLUX] -- this will keep its reaction class
[PRODUCT:100:1:GET_ITEM_DATA_FROM_REAGENT:ore:YIELD_ITEM_A][PRODUCT_DIMENSION:150]
[PRODUCT:100:1:GET_ITEM_DATA_FROM_REAGENT:ore:YIELD_ITEM_B][PRODUCT_DIMENSION:150]
[PRODUCT:100:1:GET_ITEM_DATA_FROM_REAGENT:ore:YIELD_ITEM_C][PRODUCT_DIMENSION:150]
[FUEL]
[SKILL:SMELT]

it is rather specific in what it does, because it just checks for reaction classes/material types and builds the selections around that. it also needs to be tailored to one workshop, which needs to be custom(although with some slight modification it may work with built in shops too).

i didnt do a whole lot of testing yet but it should be fairly easy to change the selection criteria, add new levels or modify item types instead of materials, or both. the only major weak point is that the job names cant be customized, so the material names will not show up in the job list, the name of the reaction thats being used is shown instead.

the only way to work around that seems to be to actually have a reaction for each one of the entries/possible combinations. reactions can however be created by lua script, so by way of templates one can create dozends of reactions to cover each selection with a custom description (like a vanilla workshop would do).

i tried doing that, but turns out it crashes the game on reload if reactions were saved that dont have an entry in the raw files.

[milo christiansen]

Complicated, but less so than it could be... That could be very useful (with a few tweaks of my own) in my First Landing mod.