[MOD 0.17] HandyHands - Autocrafting - v1.2.2 ammo & pause

[Qon]

I realize that I can still do that with this mod, by sacricifigin precious Tool Belt slots (early game, when I only have ten!) on Electric Circuits and on Gear Wheels (two stacks of the later!). It's just...

Yes, you can already do that.... and that stage of play will not last that many minutes anyways. After that you have a few assemblers crafting those intermidiates with chests as input at the very least. If you don't hand craft the intermidiates your handcrafting will be sped up many times over.

You don't need two stacks of gears on the toolbelt though. While holding gears in hand press HandyHands-Increase key (default U now) to increase the auto crafting limit of gears. Then you can let HH craft up to 4 stacks where 3 of them can sit in your regular inventory.

It would be possible to add the ability to autocraft things not locked on the toolbelt, but the application is so small and it would make the mod less simple. Right now only toolbelt locked items are autocrafted, which makes it very easy to grasp how it works.

[iamwyza]

I didn't see this in the posts I glanced over, but it'd be great to have handyhands not try to build stuff in your toolbar if the following rules are met:

1. The item in question is being requested by the Personal Logistics slots
2. You are in a logistics network
2. The item in question is being fullfill by a logistics request.


Basically "if the network is already building it for me, don't hand craft it." But if I'm not in the network (out building an outpost) or the network can't fullfill my request, then I'd want HH to do its thing.

Thoughts? I love HH early game, but late game logistics bots make it annoying except those times when i'm out doing outpost buildings

[Qon]

2[3]. The item in question is being fullfill by a logistics request.

Sounds like a good suggestion. I don't think point 3 is possible directly, but it could work decently if I check the amount in the network and assume the bots will deliver it to the player in question (instead of somewhere else). If the items are delivered somewhere else and not continously assembled then logistics storage will drop and HH will then start crafting a little bit later. But when they deliver it to the player it's removed from storage so HH would believe the items disappeared while they are in transit towards you. Could be tricky to have it work sensibly. Hopefully the amount of CPU time it will take to check logistics storage as often as HH would need that info isn't too great also.

If you autotrash items then the extra handcrafted items shouldn't be much of a problem. The autotrash mod gives you the option to only autotrash in a specific network.

[wvlad]

Hi, I have a few improvements for this mod (1.5.1 based), it'd better if you upload the source to GitHub for easier pull requests.

I added the possibility to mark things to be autocrafted regardless of their presence in hotbar. When you are holding an item there is a hot key to toggle "always autocrafting mode" - Ctrl+Alt+Shift+Y. I also commented out the "auto-off" feature, I don't like it showing me "press a hotkey to reenable autocrafting" each time I enter ghost mode. And also I commented out the "delete all settings" feature when you press "decrease" and it's already at 0 - it may happen accidentally.

Of course you can compare it and copy only changes you need (e.g. with WinMerge).

control.lua

Code: Select all

-- HandyHands. Factorio mod: Automatically start handcrafting 1 item that is filtered in your quickbar whenever your crafting queue is empty. Prioritises items in your hand. It's like logistics slots for early game!
-- Copyright (C) 2016  Qon

-- This program is free software: you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation, either version 3 of the License, or
-- (at your option) any later version.

-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-- GNU General Public License for more details.

-- You should have received a copy of the GNU General Public License
-- along with this program.  If not, see <http://www.gnu.org/licenses/>

local mod_name = 'HandyHands'

local debugging = false

local max_arr = {0, .2, .5, .8, 1, 2, 3, 4}
local work_tick = 5

-- If we complete an autostarted craft then mark it as done so that the next
-- crafting queue size check knows it wasn't because the player canceled it.
script.on_event(defines.events.on_player_crafted_item, function(event)
    local p = game.players[event.player_index]
    local data = global.players_data[event.player_index]
    if data.current_job == event.item_stack.name then
        data.current_job = nil
        data.hh_request_tick = game.tick
    end
    global.players_data[event.player_index] = data
end)

-- Init all new joining players.
script.on_event(defines.events.on_player_joined_game, function(event)
    local p = game.players[event.player_index]
    if debugging then p.print('joined!') end
    local data = global.players_data[event.player_index]
    if data == nil then
        data = init_player(event.player_index)
    end
    global.players_data[event.player_index] = data
end)

-- The mod core logic
script.on_event(defines.events.on_tick, function(event)
    for player_index = game.tick % work_tick + 1, #game.players, work_tick do
        local p = game.players[player_index]
        if p.connected and p.controller_type ~= defines.controllers.ghost then
            local data = global.players_data[player_index]
            local canceled_autocraft = false
            if data.current_job ~= nil and p.crafting_queue_size > 0 then
                if data.current_job ~= p.crafting_queue[#p.crafting_queue].recipe or p.crafting_queue[#p.crafting_queue].count > 1 then
                    data.current_job = nil
                elseif p.crafting_queue[data.current_job] ~= nil and p.crafting_queue[data.current_job].recipe == nil then
                    canceled_autocraft = true
                    data.paused = true
                end
            end
            if p.crafting_queue_size == 0 then
                if data.current_job ~= nil then
                    canceled_autocraft = true
                    data.paused = true
                end
            -- end
            -- if p.crafting_queue_size == 0 then
                if not data.paused and (data.hh_request_tick + work_tick >= game.tick or game.tick % 200 == game.tick % 5) then
                    data.hh_request_tick = data.hh_request_tick - work_tick
                    hh_player(player_index)
                end
            end
            if canceled_autocraft then
                --p.print(mod_name..' is now paused until you hit increase or decrease key (Options > Controls > Mods).')
                data.current_job = nil
                data.paused = false -- no pause
            end
        end
    end
end)

function hh_player(player_index)
    local p = game.players[player_index]
    if p.connected and p.controller_type ~= defines.controllers.ghost then
        local data = global.players_data[player_index]
        if p.crafting_queue_size == 0 then
            -- init_player(player_index, false)
            if data.paused ~= true then
                local qb = p.get_quickbar()
                local ab = p.get_inventory(defines.inventory.player_ammo)
                local filter = nil
                local count_filter = nil
                local max_filter = nil
                local cs = p.cursor_stack
                local item
                
                if not data.always then data.always = { } end
                
                -- List is an iterator over all items that are candidates for autocrafting.
                -- qb: The quickbar items. We filter away items which are not "filtered" (blue item lock on quickbar) and pick the "filter" instead of the item stack.
                local list = { list_iter_filt_map(qb, function(q,i,a) return a.get_filter(i) ~= nil and not data.always[a.get_filter(i)] end, function(q,i,a) return a.get_filter(i) end)}
                if p.character then
                    -- ab: ammoo bar. All non-empty stacks are autocrafting candidates.
                    table.insert(list, list_iter_filt_map(ab, function(q,i,a) return q.valid_for_read and not data.always[q.name] end,       function(q,i,a) return q.name end))
                end
                
                -- also craft all these items ragardless of inventory
                local with_settings = { }
                for item,dummy in pairs(data.always) do
                	table.insert(with_settings, item)
                end
                table.insert(list, list_iter_filt_map(with_settings, function(q,i,a) return true end,       function(q,i,a) return q end))
                
                list = iterlist_iter(list)
                for item in list do
                    -- Check that we can craft this item. If not, skip.
                    if p.force.recipes[item] ~= nil and ((p.get_craftable_count(item) > 0  and p.force.recipes[item].enabled == true) or p.cheat_mode) then
                        local prio_filter = 1
                        local ci = p.get_item_count(item)
                        local setting = data.settings[item]
                        if setting == nil then
                            setting = data.settings['Default']
                            if setting == nil then
                                p.print(mod_name..' Error: Uninitialised Default setting.')
                            end
                        end
                        local stsz = game.item_prototypes[item].stack_size
                        -- For better interaction with stack size changing mods: Pretend that the max stack size is only 1/10 as big.
                        if stsz >= 500 then
                            stsz = stsz / 10
                        end
                        mi = math.ceil(stsz*setting)
                        -- Don't keep autocrafting this item if it will just end up in logistics trash slots.
                        if p.character and p.auto_trash_filters[item] then
                            mi = math.min(mi, p.auto_trash_filters[item])
                        end
                        if filter ~= nil then
                            prio_filter = count_filter/max_filter
                        end
                        -- prio is a bit backwards. Lower prio numbers for high priority items.
                        local prio_current = p.get_item_count(item)/mi
                        local item_held = cs.valid_for_read and cs.name == item
                        -- Prioritise items held in cursor above all. Prioritise less fulfilled autocraft requests.
                        local prioritised = prio_current < prio_filter or item_held
                        if (p.name:find("logis")) then
                        	p.print("need "..tostring(mi) .. " cur "..p.get_item_count(item))
                        end
                        -- Check that we can craft the item
                        if prio_current < 1 and prioritised then
                            filter = item
                            count_filter = ci
                            max_filter = mi
                            if cs.valid_for_read and cs.name == item then
                                break
                            end
                        end
                    end
                end
                -- "filter" here is our chosen item to craft.
                if filter ~= nil then
                    if p.cheat_mode == false then
                        p.begin_crafting{count=1, recipe=filter, silent=true}
                        data.current_job = filter
                    else
                        p.begin_crafting{count=(max_filter-count_filter), recipe=filter, silent=true}
                    end
                end
            end
        end
        global.players_data[player_index] = data
    end
end
-- Handle hotkey presses.
script.on_event('handyhands-increase', function(event) change(event, true) end)
script.on_event('handyhands-decrease', function(event) change(event, false) end)

function change(event, positive)
    local p = game.players[event.player_index]
    -- init_player(event.player_index, false)
    local data = global.players_data[event.player_index]
    data.hh_request_tick = game.tick
    if data.paused == true then
        data.paused = false
        p.print(mod_name..' is now running again!')
        global.players_data[event.player_index] = data
        return
    end
    local item = 'Default'
    if p.cursor_stack.valid_for_read == true then
        item = p.cursor_stack.name
        if data.settings[item] == nil then
            data.settings[item] = data.settings['Default']
        end
    end
    local changed = false
    if positive then
        for i = 1, #max_arr do
            if max_arr[i] > data.settings[item] then
                data.settings[item] = max_arr[i]
                changed = true
                break
            end
        end
    else
        for i = 1, #max_arr do
            if max_arr[#max_arr-i+1] < data.settings[item] then
                data.settings[item] = max_arr[#max_arr-i+1]
                changed = true
                break
            end
        end
    end
    if changed then
        if item == 'Default' then
            p.print('Changed default autocraft stack size.')
            for k in pairs(data.settings) do
                if k ~= 'Default' then
                    local trash_warning = ''
                    if p.character and p.auto_trash_filters[k] ~= nil and p.auto_trash_filters[k] < math.ceil(game.item_prototypes[k].stack_size*data.settings[k]) then
                        trash_warning = ' [Auto trash: '..p.auto_trash_filters[k]..']'
                    end
                    p.print(k..': '..data.settings[k]..' stacks ('..math.ceil(game.item_prototypes[k].stack_size*data.settings[k])..' items)'..trash_warning)
                end
            end
            p.print('Default'..': '..data.settings['Default']..' stacks.')
        else
            local trash_warning = ''
            if p.character and p.auto_trash_filters[item] ~= nil and p.auto_trash_filters[item] < math.ceil(game.item_prototypes[item].stack_size*data.settings[item]) then
                trash_warning = ' [Auto trash: '..p.auto_trash_filters[item]..']'
            end
            p.print(item..': '..data.settings[item]..' stacks ('..math.ceil(game.item_prototypes[item].stack_size*data.settings[item])..' items)'..trash_warning)
        end
    elseif positive == false and data.settings[item] == 0 then
        if item == 'Default' then
            --init_player_settings(event.player_index, true)
            --data = global.players_data[event.player_index]
            --data.settings['Default'] = 0
            --p.print('All your HandyHands settings were deleted.')
            --p.print('Default'..': '..data.settings['Default']..' stacks.')
        else
            data.settings[item] = nil
            p.print('Your HandyHands setting for item '..item..' was deleted and will use the same setting as Default (currently '..data.settings['Default']..' stacks).')
        end
    end
    global.players_data[event.player_index] = data
end

script.on_event('handyhands-toggle-always-for-item', function(event)
    local p = game.players[event.player_index]
    local data = global.players_data[event.player_index]
    data.hh_request_tick = game.tick
    local item = 'Default'
    if p.cursor_stack.valid_for_read == true then
        item = p.cursor_stack.name
        if data.settings[item] == nil then
            data.settings[item] = data.settings['Default']
        end
    else
    	p.print("Take an item to toggle autocrafting for it")
    	return
    end
    
    if not data.always then data.always = { } end
    
    if not data.always[item] then
    	data.always[item] = true
    	p.print("Autocrafting always for "..item.." enabled")
    else
    	data.always[item] = nil
    	p.print("Autocrafting always for "..item.." disabled")
    end
    global.players_data[event.player_index] = data
end)

function init(event, force)
    -- Might be called with nil event and force
    if global.players_data == nil or force then
        global.players_data = {}
    end
    for i = 1, #game.players do
        init_player(i,force)
    end
end

function init_player(player_index, force)
    return init_player_settings(player_index, force)
end

function init_player_settings(player_index, force)
    local wasnil = global.players_data[player_index] == nil
    if wasnil or force then
        global.players_data[player_index] = {}
        global.players_data[player_index].hh_request_tick = 0
        global.players_data[player_index].hh_last_exec_tick = 0
        global.players_data[player_index].settings = {}
        global.players_data[player_index].settings['Default'] = 0.2
        -- Only for beginners, so that you don't lose your starting iron to ammo before you have your pick axe ;>
        if wasnil then
            global.players_data[player_index].settings['firearm-magazine'] = 0.05*100/game.item_prototypes['firearm-magazine'].stack_size
            game.players[player_index].print('HandyHands autocrafting enabled for quickbar filtered items and ammo. Default amount: '..global.players_data[player_index].settings['Default']..' stacks.')
            game.players[player_index].print('Change HandyHands autocrafting limits with hotkeys (Options > Controls > Mods).')
            game.players[player_index].print('Empty cursor: change Default. Forget all HandyHands settings by deleting Default setting.')
            game.players[player_index].print('Individual item settings are modified when held in cursor and deleted when decreased below 0.')
        end
    end
    return global.players_data[player_index]
end

function map(l,f)
    local r = {}
    for i = 1, #l do
        r[i] = f(l[i], i, l)
    end
    return r
end
function filter(l,f)
    local r = {}
    for i = 1, #l do
        if f(l[i], i, l) then
            r[i] = l[i]
        end
    end
    return r
end

-- Gives an iterator over items in list l which are first filtered by function f and then mapped over by function m.
-- f(c,i,a) and m(c,i,a) are given 3 parameters: (current_element, index_of_element, array)
function list_iter_filt_map(l,f,m)
    local i = 0
    local n = #l
    return function()
        while i < n do
            i = i + 1
            if f == nil or f(l[i], i, l) then
                return m(l[i], i, l)
            end
        end
    end
end

-- Flattens an iterator over iterators over elements to an iterator over elements.
-- Basically it turns {{1,2},{3,4,5},{},{6},{7,8}} into {1,2,3,4,5,6,7,8} but for iterators instead of lists.
function iterlist_iter(il)
    local i = 1
    return function()
        while i <= #il do
            local el = il[i]()
            if el ~= nil then
                return el
            end
            i = i + 1
        end
    end
end

script.on_init(init)
script.on_event(defines.events.on_player_joined_game, function(event) init_player(event.player_index, false) end)

-- Data migration
script.on_configuration_changed(function(event)
    local function allprint(s)
        for i = 1, #game.players do
            game.players[i].print(s)
        end
    end
    local handy = event.mod_changes[mod_name]
    if handy then
        local function pre_state()
            local function init(event, force)
                -- Might be called with nil event and force
                if global.players_data == nil or force then
                    global.players_data = {}
                end
            end
            init()
            if debugging then allprint('Ran "pre_state" migration.') end
        end
        local function indirect_state()
            -- Clean up old junk
            global.max_arr = nil

            -- Proper init of new players
            if global.players_data == nil then
                global.players_data = {}
            end
            local function init_player_settings(player_index, force)
                if global.players_data[player_index] == nil or force then
                    global.players_data[player_index] = {}
                    global.players_data[player_index].settings = {}
                    global.players_data[player_index].settings['Default'] = 1
                end
                return global.players_data[player_index]
            end
            for i = 1, #game.players do
                init_player_settings(i,false)
            end

            -- Migration of player settings from older versions
            local max_arr = {}
            max_arr[-1] = 0
            max_arr[0] = 0.5
            for i=1, 4 do
                max_arr[i] = i
            end
            for i = 1, #global.players_data do
                local data = global.players_data[i].settings
                for i,v in pairs(global.players_data[i].settings) do
                    data[i] = max_arr[v]
                end
                global.players_data[i].settings = data
            end
            if debugging then allprint('Ran "indirect_state" migration.') end
        end
        local function add_tick_state()
            for i = 1, #global.players_data do
                global.players_data[i].hh_request_tick = 0
                global.players_data[i].hh_last_exec_tick = 0
            end
            if debugging then allprint('Ran "add_tick_state" migration.') end
        end
        local migrations = {pre_state, indirect_state, add_tick_state}
        local migration_index = {
            ['1.0.'] = 1,
            ['1.1.'] = 2,
            ['1.2.'] = 2,
            ['1.2.'] = 3,
            ['1.3.'] = 3
        }
        -- If loading a save with no known incompatability, do a non-destructive init
        local s = ''
        if handy.old_version ~= nil then
            _, _, s = string.find(handy.old_version, '(%d+%p%d+%p)%d+')
            if migration_index[s] ~= nil then
                for i = migration_index[s], #migrations do
                    migrations[i]()
                end
            end
        end
        init()
        if debugging then
            if handy.old_version ~= nil then
                allprint(mod_name..' v'..handy.old_version..' updated to v'..handy.new_version)
            else
                allprint(mod_name..' v'..handy.new_version..' was installed.')
            end
        end
    end
end)

-- Remote interface is alpha. Please contact mod author if you want to use it.
remote.add_interface('handyhands', {
    -- call change(player_index, positive) to simulate increase/decrease hotkey events. (positive: true for increase, false for decrease)
    change = function(player_index, positive) change({player_index = player_index}, positive) end,
    -- set(player_index, item, limit) sets the autocraft limit for a specific item to the provided limit. limit == nil to remove the setting. Limits are in stacks (float).
    set = function(player_index, item, limit) global.players_data[player_index].settings[item] = limit end,
    -- call settings(player_index) to get the Key/Value pairs to get the stack size limits
    -- call settings(player_index, limits) to set the Key/Value pairs stack size limits (limits is a Key[item_name] --> Value (stacks_to_craft) object)
    settings = function(player_index, limits)
        if limits ~= nil then
            global.players_data[player_index].settings = limits
        end
        return global.players_data[player_index].settings
    end,
    -- call paused(player_index) to get paused state for the player
    -- call paused(player_index, set) to set paused state for the player (set is a boolean)
    paused = function(player_index, pause)
        if pause ~= nil then
            global.players_data[player_index].paused = pause
        end
        return global.players_data[player_index].paused
    end
})

data.lua

Code: Select all

data:extend({
  {
    type = "custom-input",
    name = "handyhands-increase",
    key_sequence = "U",
    consuming = "none"
  },{
    type = "custom-input",
    name = "handyhands-decrease",
    key_sequence = "J",
    consuming = "none"
  },{
    type = "custom-input",
    name = "handyhands-toggle-always-for-item",
    key_sequence = "CONTROL + SHIFT + ALT + Y",
    consuming = "none"
  }
})

[Qon]

Hi, I have a few improvements for this mod (1.5.1 based), it'd better if you upload the source to GitHub for easier pull requests.
Of course you can compare it and copy only changes you need (e.g. with WinMerge).

Hello! It's nice that you mod and share your edits!
While I will take a bit of extra consideration time on the specific edits you have done, the changes are unlikely to enter my main branch. The changes have been qonsidered in the past and rejected because I decided that the current behaviour was closest to optimal.

I added the possibility to mark things to be autocrafted regardless of their presence in hotbar.

This means you can't stop autocrafting a specific item if you don't have it. Also severs the simple connection of "blue means autocraft and hotbar locked". Might be an optional feature (can be disabled in the mod settings) in the future. But I'm not sure there's much benefit to the idea. Autocrafting 10~ items that you want constant access too is enough with vanilla items for me at least. After that you get robots and items you can't really handcraft.

When you are holding an item there is a hot key to toggle "always autocrafting mode" - Ctrl+Alt+Shift+Y. I also commented out the "auto-off" feature,

I'm trying to keep the hotkeys to a minimum. I wish I didn't even need the 2 that are in atm. That's why pausing doesn't need a hotkey and happens automatically by the same action that you would use to cancel the started autocraft, that's an action you would do anyways when pausing. And it would be annoying if you canceled a autocraft and the mod just added it immediatly again!

I also commented out the "auto-off" feature, I don't like it showing me "press a hotkey to reenable autocrafting" each time I enter ghost mode.

Enter ghost mode? A mod or setting char to nil by command? Not something I do so haven't had any problems with this.

And also I commented out the "delete all settings" feature when you press "decrease" and it's already at 0 - it may happen accidentally.

It requires at least two clicks while the mod is running. And you don't change that setting that often anyways so you probably don't spam the hotkeys as fast as you can. Setting default to 0 doesn't pause items with individual settings so if you want to pause you use the pause feature, right?

I have never been remotely close to an accidental reset. In what scenario would that happen for you?

[wvlad]

It may happen when I press the shortcut several times. Factorio filters "print" messages and some of them are not shown if you print them frequently. So I press "J" twice but see the message only once so I press it again and bum - my settings are gone.

Enter ghost mode? A mod or setting char to nil by command? Not something I do so haven't had any problems with this.

Yes, like mod that locates my logistics items on map.

When you are holding an item there is a hot key to toggle "always autocrafting mode" - Ctrl+Alt+Shift+Y. I also commented out the "auto-off" feature,

I'm trying to keep the hotkeys to a minimum. I wish I didn't even need the 2 that are in atm. That's why pausing doesn't need a hotkey and happens automatically by the same action that you would use to cancel the started autocraft, that's an action you would do anyways when pausing. And it would be annoying if you canceled a autocraft and the mod just added it immediatly again!

The shortcut is not about pausing, when you don't want to keep some items in hotbar but still want to autocraft them you can press that shortcut.

btw, It's a requested feature:

I realize that I can still do that with this mod, by sacricifigin precious Tool Belt slots (early game, when I only have ten!) on Electric Circuits and on Gear Wheels (two stacks of the later!). It's just...

[Qon]

It may happen when I press the shortcut several times. Factorio filters "print" messages and some of them are not shown if you print them frequently. So I press "J" twice but see the message only once so I press it again and bum - my settings are gone.

I thought that only happened to messages that were identical. Did some further testing, appears the standard message getting blocked triggers a full block of all messages for that fraction of a second. I might have to add some random spaces at the ends of all lines to circumvent this nasty Factorio behaviour. If this is solved then you will never accidentally delete all your settings again, right?

The shortcut is not about pausing, when you don't want to keep some items in hotbar but still want to autocraft them you can press that shortcut.

So you removed pause, settings deletion and enabled autocrafting of items not hotbar locked. All of the safety features that gives you the power to stop HH, gone? Is that really the behaviour you want? Seems like you could end up in a really frustrating spot. I hope for your sake you never need to quickly pause the mod or similar.

btw, It's a requested feature:

I realize that I can still do that with this mod, by sacricifigin precious Tool Belt slots (early game, when I only have ten!) on Electric Circuits and on Gear Wheels (two stacks of the later!). It's just...

And I have already responded to that message...

I realize that I can still do that with this mod, by sacricifigin precious Tool Belt slots (early game, when I only have ten!) on Electric Circuits and on Gear Wheels (two stacks of the later!). It's just...

Yes, you can already do that.... and that stage of play will not last that many minutes anyways. After that you have a few assemblers crafting those intermidiates with chests as input at the very least. If you don't hand craft the intermidiates your handcrafting will be sped up many times over.

You don't need two stacks of gears on the toolbelt though. While holding gears in hand press HandyHands-Increase key (default U now) to increase the auto crafting limit of gears. Then you can let HH craft up to 4 stacks where 3 of them can sit in your regular inventory.

It would be possible to add the ability to autocraft things not locked on the toolbelt, but the application is so small and it would make the mod less simple. Right now only toolbelt locked items are autocrafted, which makes it very easy to grasp how it works.

[rulerofdabacon]

A couple strange bugs, one of which may not be a bug. First of all, for some reason the mod doesn't autocraft any Yuoki items. Secondly, whenever it cues up another crafting item, it sort of "resets" whatever gui I'm in, including things such as the text box for blueprints, which was really annoying until I figured out what was doing it. Is there any way you could fix either of these?

Edit: only resets the gui when crafting things involving bob's basic circuit boards, including the circuit boards themselves. And in fact, it seems to do it whenever it finishes any stage of the crafting of something. That is to say, whenever it completes all of a certain ingredient. Also, for a bit of perspective on the gui reset, it does the base game's production monitor as well. It will set it back to 5 seconds each time it resets.

Second edit: So it's even manual crafting with the basic circuit boards, so ignore that bit. But I'd still like to be able to have it do yuoki items.

[Qon]

for some reason the mod doesn't autocraft any Yuoki items.

I'll look into it.


*looking into it...*


Yuoki names his recipies "incorrectly". HH assumes the recipe for the item is named the same as the item it tries to autocraft. This works for vanilla items and while it is an assumption that can be wrong, it's fast and simple. It could be solved by going through all the recipies in the game and building a second hashmap on top of the regular one (provided by the game), every time you load a save. While it's doable it also seems like an unproportional amount of work.

Or Yuoki could rename his recipies to fit the convention all other items do.

Right now he names his recipe for "y-stuff" something like "y-stuff-recipe". Why he decided to have "-recipe" in the name of many of his recipies is a bit baffling to me.

Also a recipies with several products (uncommon in vanilla, not handcraftable anyways since those are oil products) and items that have several recipies to produce them can't really be solved perfectly automatically. Then there are multiple options and HH can't really know what option is the best. And the recipie name could be anything. The extra plate recipies adds multiple paths and irregular names. "y-refined-copper" requires "y-pure-copper" and produces "copper-plate" like the regular copper plate recipe as an example (this one is a smelting recipie so it can't be handcrafted anyways though).

The recipe for "y-mixed-fuel" is named "y-coaldust-mixing-recipe" for some reason only known to Yuoki. So it's not named after the item AND it adds a "-recipe".

I'm not sure if I want to bother fixing this when Yuoki is doing so many weird things with his recipe names and structure. The simplest fix is to give the recipies sensible names, but only Yuoki can do that unless you want to patch it yourself every time he releases an update. If you message Yuoki about it tell me after what his response is.

Edit:
I'll forget about this in a while and if Yuoki never hears of it or doesn't want to take action then I'll need a reminder q:
Also technically the recipe names are not wrong, they just don't follow the convention all other items do. And that convention helps immensly when doing recipe lookups, so I think people should stick to it.

[eradicator]

for some reason the mod doesn't autocraft any Yuoki items.

I'll look into it.
*looking into it...*
Yuoki names his recipies "incorrectly". [...]

I don't really care about what you think about Yuoki's mods. But your assumption that every item can always be crafted by exactly one recipe that is exactly the same as the item-name and that that recipe also happens to be handcraftable is fundamentally wrong. You even mention items with multiple recipes yourself. Building a reverse-lookup table is computationally cheap enough to do once per load per on_research_finished. Though as i'm currently working on a mod that also requires reverse-recipe lookup i do realize that this is not an easy task to program at all. But you putting the blame on other people when it's really a defect in your mod annoyed me enough to post this.

For a simple reverse-lookup it would be sufficient to loop through all recipies and check if they're handcraftable. And then just take the first one. Here's some example code that does exactly that:

Code: Select all

local lookup = {}
local function update_lookup(force) --lookup must be per force
  lookup[force.name] = {}
  
  for _,recipe in pairs(force.recipes) do
    for _,product in pairs(recipe.products) do
      if (not lookup[force.name][product.name]) and
         (recipe.enabled) and
         (recipe.category == 'crafting') then
        lookup[force.name][product.name] = recipe.name
        end
      end
    end
  end

[Qon]

But your assumption that every item can always be crafted by exactly one recipe that is exactly the same as the item-name and that that recipe also happens to be handcraftable is fundamentally wrong.

Yes. But I'm also lazy, busy, don't think it's interesting to code the fix and wish someone else could do it. :^]
And it works for vanilla, would be so nice if if every modder just stuck with that convention since it has no real downsides. Wishful thinking, not really blaming Yuoki here.

It has to be on load AND research. Otherwise the lookup has to be saved and keeping state correct over multiple versions is a real pain and a big invitation for the strangest of bugs. And it wouldn't even give any real benefits.
I will have to fix it eventually, I want the mod to be smooth. It should just work.

[eradicator]

Yes. But I'm also lazy, busy, don't think it's interesting to code the fix and wish someone else could do it. :^]

Well. I kinda already did post that code above which should at least solve 90% of the issues. I can releate to the first bit of that reasoning more than i want to though...

And it works for vanilla, would be so nice if if every modder just stuck with that convention since it has no real downsides. Wishful thinking, not really blaming Yuoki here.

As you already noted yourself and as i tried to explain there are simply situations where sticking to that convention is either undesirable or straight out impossible. It's called a "convention" and not a "rule" for a reason :P

It has to be on load AND research. Otherwise the lookup has to be saved and keeping state correct over multiple versions is a real pain and a big invitation for the strangest of bugs.

True. But that's adding two lines of code. Not too difficult. For bug-safety you could use it as a fallback only when your current method fails. Though imho "guessing" the recipe name is equally bug-prone.

And it wouldn't even give any real benefits.

How about the benefit of actually working and pleasing your userbase. :P

[Qon]

Yes. But I'm also lazy, busy, don't think it's interesting to code the fix and wish someone else could do it. :^]

Well. I kinda already did post that code above which should at least solve 90% of the issues. I can releate to the first bit of that reasoning more than i want to though...

The last 10% of the work requires 90% of the time...
It has to be integrated with the code and tested, the migrations needs a checkup, the changelog and version number has to be updated in 2 places and so on.
Integration requires you to make sure each player can access it on join to a multiplayer server and so on. I want to call it once per force join if possible, unless that requires too much work for too little benefit. Was a while since I read the documentation and this change requires that I read up on it again. Otherwise it breaks in multiplayer. And I have to make sure other special cases like that are covered.
But the code looks sensible so I might just throw it in once all prep work is done...

And it wouldn't even give any real benefits.

How about the benefit of actually working and pleasing your userbase.

The non-existing benefits was about saving the recipe map with map save, not about fixing the bug.

[eradicator]

The last 10% of the work requires 90% of the time...

The last 10% i was thinking about were even more edgy-edge cases (like fixing the assumption that the player can actually craft the "crafting" category). But yea sure, debugging/testing and updating all the pages takes time too.

the migrations needs a checkup

As it's a pure runtime change it shouldn't need any migration.

Integration requires you to make sure each player can access it on join to a multiplayer server and so on. I want to call it once per force join if possible, unless that requires too much work for too little benefit. Was a while since I read the documentation and this change requires that I read up on it again. Otherwise it breaks in multiplayer. And I have to make sure other special cases like that are covered.

I actually thought about that and my conclusion was that that on_load and on_research_finished should be sufficient. Creating the table from scratch every time the function is called (as opposed to extending the existing table) is actually there to prevent any possible desyncs.
My reasoning is as follows: The table only changes when research finishes. So any player joining inbetween researches will get the same results in on_load as all the other players already have. And joining on the same tick as on_research_finished would just execute the same function twice so no desync potential there either.
If you wanted to go the "totally 200% sure always" way i guess you could just update the tables for all forces every time any player joins. But that sounds like overkill.

[rulerofdabacon]

I understand ... in the very past was some conflicts with recipe/items with other mods. So i changed to this name-schematic.
It would need a complete rewrite of the mod, but because it's nessesary anyway for upcomming versions of factorio it will maybe happen.
At the moment is no short/quick fix around to make the mod compatible with HandyHands. Sorry.

YuokiTani's reply to my PM. Thoughts?

[Qon]

I understand ... in the very past was some conflicts with recipe/items with other mods. So i changed to this name-schematic.
It would need a complete rewrite of the mod, but because it's nessesary anyway for upcomming versions of factorio it will maybe happen.
At the moment is no short/quick fix around to make the mod compatible with HandyHands. Sorry.

YuokiTani's reply to my PM. Thoughts?

I guess I'll have to deal with it...

0.16 will break HH too if the changes proposed in the FF goes through. Not sure how far away 0.16 is though.

[eradicator]

@rulerofdabacon: Other than "not suprised that he had his reasons"? No. Not really.

0.16 will break HH too if the changes proposed in the FF goes through. Not sure how far away 0.16 is though.

I bet there's still going to be a way to read the "filters" on the quickbar. So. Break, yea. Make unfeasible, no.

[rulerofdabacon]

What changes are you talking about specifically? I haven't read them all (though I've read most of the new ones since I came back to playing factorio) and even the ones I do read, I don't always catch everything. What change are they thinking they're going to make?

[eradicator]

What changes are you talking about specifically? I haven't read them all (though I've read most of the new ones since I came back to playing factorio) and even the ones I do read, I don't always catch everything. What change are they thinking they're going to make?

Changing the quickbar to not be an actual inventory. So it doesn't contain stacks of items. Just buttons to pull them out of your main inventory quickly. Imho it's pretty much decided this is going to happen.

[NeilN]

Any plans to update this for 0.16?