[0.12.x][v0.12.10] Bob's Logistics mod

[bobingabout]

Right now it makes the vanilla long handed inserter completely pointless and more expensive than the standard inserter.

the long inserter is actually somewhere between standard inserter and fast inserter.

Inserter:
extension_speed = 0.03,
rotation_speed = 0.014,

long inserter:
extension_speed = 0.0457,
rotation_speed = 0.02,

fast inserter
extension_speed = 0.07,
rotation_speed = 0.04,

so not completely useless.

[Tyrindor]

Right now it makes the vanilla long handed inserter completely pointless and more expensive than the standard inserter.

the long inserter is actually somewhere between standard inserter and fast inserter.

Inserter:
extension_speed = 0.03,
rotation_speed = 0.014,

long inserter:
extension_speed = 0.0457,
rotation_speed = 0.02,

fast inserter
extension_speed = 0.07,
rotation_speed = 0.04,

so not completely useless.

Ah I wasn't aware it was slightly better.

One thing I have noticed, when copy/pasting inserter settings you end up opening the GUI each time (Shift+LMB). May want to change that keybind. Maybe shift+e?

[iamwyza]

One thing I have noticed, when copy/pasting inserter settings you end up opening the GUI each time (Shift+LMB). May want to change that keybind. Maybe shift+e?

I rebound it to ctrl+lmb for myself (you can rebind this mod in the controls menu)

[bobingabout]

I'm thinking SHIFT + E Myself actually. CTRL + LMB Is another good choice, but doesn't make as much sense with every other key being on SHIFT.

Of course, if you really want CTRL + LMB, you can still change the keybind. in fact I think it'll stay on your current keybind after I change the default.

[OvermindDL1]

Ctrl+LeftClick seems quite natural from my testing. Although having it open when just clicking on it without any modifier keys would be best if that could be worked out decently. ^.^

Utterly awesome update you've done though! Just modded 0.13 since I finally completed that last achievement now that the latest patch has fixed them. Vanilla is so dreadfully short and easy, back to mods!

[bobingabout]

Guys.

I had a go at removing the long, near, far, long short, short long, long near, short far inserters, and migrating them to standard fast, express, filter etc inserters.... And they all changed range to standard inserters. Migration doesn't keep the length settings!

What do you think I should do?

[Nexela]

If it comes down to it. Just migrate em to reg inserters

Check out what GotLag did for migration also viewtopic.php?f=93&t=13525&start=120#p181595

[bobingabout]

Yeah, I could probably do it with a migration script, but not in the same mod that removes the old ones.... unless I leave the entities in there, and only remove the items, recipes and technologies.

Without looking at GotLag's stuff... find one of the entities to remove, store the location of the hands, and direction, delete and replace the entity, and then update the hand locations.

[bobingabout]

Well, I've created a migration script... but It's not perfect...

Though, looking at GotLag's, his would have the same flaws.

1. Long Handed Burner Inserter -> Burner Inserter doesn't stay long handed, despite running through the same script as the other types of inserter.
2. Any items currently in-hand get lost.
3. Any wire connections, and conditions are also lost.

I mean, I can see script instructions to see what is in the hand, but not put something in the hand, and instructions to add a wire, but not get a list of existing wire connections, or conditions.
I have no idea why it won't set the hand positions for burner.

Thoughts?

[Nexela]

Well a little bit of fixing upping should be expected!

Also just started a Bob's Mod/Angel's playthrough and it is like learning to walk all over again...... Except I might restart as I forgot to revert some Bob Config and Extra Chests changes....

[Aikonn]

Guys.
I had a go at removing the long, near, far, long short, short long, long near, short far inserters, and migrating them to standard fast, express, filter etc inserters.... And they all changed range to standard inserters. Migration doesn't keep the length settings!
What do you think I should do?

I was expecting this change. I totally agree with it. New feature to set inserters drop and pickup location is super cool (maybe little OP in some way).

Leave old entities in game for now, remove recipies etc. That will give us time to adjust.

I love your mod and I will not give you hard time because you are improving it.
We are all still playing experimental version - we should be okay with changes like this.

[bobingabout]

if you look at the previous post, I had a go at a migration script to auto-upgrade the entities (find an entity, create a new one of the new type, copy settings, delete original) but there's just some settings that won't copy.

[kinnom]

why not save the settings on a ghost entity?

[bobingabout]

why not save the settings on a ghost entity?

Well, if you tried to create a ghost clone... it wouldn't work because:
if you turn the existing entity into a ghost... the entity name that it is a ghost of is read only, so it would only be able to turn back into itself.

if you copy the settings from the original entity to a ghost of the new entity... you still have the exact same problems that there doesn't seem to be a way to read and/or write certain flags, entity or ghost.

so... using a ghost entity as a go between would change nothing.

using the game's built in entity migration is the best option for retaining the most information, it keeps the items that are in the hand, circuit wire connections, and conditions, the only information lost is the pickup and drop positions.
what we would need is a method to store all entity locations, and their hand positions, then run an entity migration script, then restore all entity hand positions. this would require a minimum of 2 steps.

Step 1, a script (must be control.lua script) scans and stores the positions of all entities, and their hand positions in the global table.
Step 2, run a migration json script to update the entities.
Step 3, a script (again, must be control.lua) loads all stored hand positions, and restores them on the entities.

Due to the fact that migration json scripts are always run before any lua scripts, step 2 can be run as the same step as step 3, but step 1 must be a different game load/save operation.

so the true answer would be to load a special migration mod... that includes a control.lua script to store all inserter positions to the global table, then remove the migration mod to install the updated logistics mod, which finishes off the migration to the new entity.

[Neemys]

Instead of doing a migration mod, why not doing step 2 as script as well ? so all 3 step can be done in one load.

Your script will be already searching all old entities to store their value, why not replacing them at the same time ?

[bobingabout]

Instead of doing a migration mod, why not doing step 2 as script as well ? so all 3 step can be done in one load.

Your script will be already searching all old entities to store their value, why not replacing them at the same time ?

Because the JSON part ALWAYS runs first, so the entities will be replaced and their hand positions will be lost before the lua script can read them.

And, if you check back to my last post on the previous page, doing the JSON part as a LUA script can't copy certain things... like hand contents, and anything related to logistic networks (wires, conditions etc).

[kinnom]

with ghost entity I meant a seperate, invisible entity on the same place

[bobingabout]

with ghost entity I meant a seperate, invisible entity on the same place

I know exactly what you mean, but the problem remains, either there is no hook to read the variable, no hook to write it, or neither. so entity, or ghost makes no difference at all, there's parts of the settings you just can't copy.

If you're talking about just the hand positions... well, the JSON always runs first, so there'd be nothing left to copy from if you used a JSON replacement. so you'd need at least 2 mods, and the same result could be achieved with a globals table.

[Neemys]

Instead of doing a migration mod, why not doing step 2 as script as well ? so all 3 step can be done in one load.

Your script will be already searching all old entities to store their value, why not replacing them at the same time ?

Because the JSON part ALWAYS runs first, so the entities will be replaced and their hand positions will be lost before the lua script can read them.

And, if you check back to my last post on the previous page, doing the JSON part as a LUA script can't copy certain things... like hand contents, and anything related to logistic networks (wires, conditions etc).

Yeah i read your post and the third point suprised me so I made a test. Using only side inserter and test mod in 0.12. I used smart side inserter to load and unload thing from smart chest.
Those side smart inserter had two wire, one on the next pole, the other to the next smart chest (in 0.12).
Migrating to 0.13, the wire to the pole was kept, but not to the chest. That's not side inserter's fault but the game's because when they migrate smart chest they do not keep circuit network connection (maybe they only use JSON migration). But the wire to the pole and the condition on inserter was kept. so his script does his job. The game doesn't.

So lua migration can keep circuit network and condition if the connected entities keep the circuit network connection too.

Haven't test the two other point, but maybe they can be kept in a table and script restored after.

But free to you to do it the way you prefer, only lua (1 pass to migrate) or using JSON and lua (2 pass). You already have done great job by upgrading it for 0.13 in such short time.

[bobingabout]

Yeah i read your post and the third point suprised me so I made a test. Using only side inserter and test mod in 0.12. I used smart side inserter to load and unload thing from smart chest.
Those side smart inserter had two wire, one on the next pole, the other to the next smart chest (in 0.12).
Migrating to 0.13, the wire to the pole was kept, but not to the chest. That's not side inserter's fault but the game's because when they migrate smart chest they do not keep circuit network connection (maybe they only use JSON migration). But the wire to the pole and the condition on inserter was kept. so his script does his job. The game doesn't.

So lua migration can keep circuit network and condition if the connected entities keep the circuit network connection too.

Haven't test the two other point, but maybe they can be kept in a table and script restored after.

But free to you to do it the way you prefer, only lua (1 pass to migrate) or using JSON and lua (2 pass). You already have done great job by upgrading it for 0.13 in such short time.

Okay, it does keep filters, but here is the code from side inserters:

Code: Select all

function ReplaceInserter(ins)
  local itype = "inserter"
  local smart = false
  local filters = {}
  local fuel
  if string.sub(ins.name, 1, 6) == "burner" then
    if ins.get_inventory(defines.inventory.fuel).get_item_count() > 0 then
      fuel = ins.get_inventory(defines.inventory.fuel)[1]
    end
    itype = "burner-inserter"
  elseif string.sub(ins.name, 1, 4) == "fast" then
    itype = "fast-inserter"
  elseif string.sub(ins.name, 1, 4) == "long" then
    itype = "long-handed-inserter"
  elseif string.sub(ins.name, 1, 5) == "smart" then
    smart = true
    itype = "filter-inserter"
    for i = 1,5 do
      filters[i] = {index = i, name = ins.get_filter(i)}
    end
  end
  local position = ins.position
  local direction = ins.direction
  local left, right
  if string.match(ins.name, "left") then
    direction = (direction + 6) % 8
    left = true
  elseif string.match(ins.name, "right") then
    direction = (direction + 2) % 8
    right = true
  end
  local near = string.match(ins.name, "near") ~= nil
  local force = ins.force
  local energy = ins.energy
  local newins = game.surfaces[1].create_entity{
    name = itype,
    position = position,
    direction = direction,
    force = ins.force
  }
  newins.energy = energy
  if fuel then
    newins.insert(fuel)
  end
  if smart then
    for i = 1,5 do
      newins.set_filter(i, filters[i].name)
    end
  end
  ins.destroy()
  if left then
    RotateLeft(newins)
  elseif right then
    RotateRight(newins)
  end
  if near then
    ToggleInserterDrop(newins)
  end
end

(to note: I only looked at this for ideas, and to see what was going on, I didn't actually use any of it in my own script, which you'd clearly see if you compared the 2... the one I'm not using anyway, because I decided to take a different approach, see below. if interested, here is the code I'm not going to use:)

Code: Select all

local function replace_inserter(inserter, newname)
  local newinserter = game.surfaces[1].create_entity{
    name = newname,
    position = inserter.position,
    direction = inserter.direction,
    force = inserter.force
  }
  newinserter.pickup_position = inserter.pickup_position
  newinserter.drop_position = inserter.drop_position
  newinserter.energy = inserter.energy

  if string.sub(newname, 1, 6) == "burner" then
    if inserter.get_inventory(defines.inventory.fuel).get_item_count() > 0 then
      newinserter.insert(inserter.get_inventory(defines.inventory.fuel)[1])
    end
  end

  if string.sub(newname, 1, 6) == "filter" then
    for i = 1, 5 do
      newinserter.set_filter(i, inserter.get_filter(i))
    end
  end

  newinserter.direction = inserter.direction
  inserter.destroy()
end


local entities = game.surfaces[1].find_entities_filtered{area = {{-50000, -50000}, {50000, 50000}}, type= "inserter"}

for i, inserter in pairs(entities) do
  if inserter.name == "long-handed-burner-inserter" then
    replace_inserter(inserter, "burner-inserter")

  elseif inserter.name == "fast-long-inserter" then
    replace_inserter(inserter, "fast-inserter")
  elseif inserter.name == "fast-near-inserter" then
    replace_inserter(inserter, "fast-inserter")
  elseif inserter.name == "fast-far-inserter" then
    replace_inserter(inserter, "fast-inserter")

  elseif inserter.name == "filter-long-inserter" then
    replace_inserter(inserter, "filter-inserter")
  elseif inserter.name == "filter-near-inserter" then
    replace_inserter(inserter, "filter-inserter")
  elseif inserter.name == "filter-far-inserter" then
    replace_inserter(inserter, "filter-inserter")
  elseif inserter.name == "filter-short-far-inserter" then
    replace_inserter(inserter, "filter-inserter")
  elseif inserter.name == "filter-short-long-inserter" then
    replace_inserter(inserter, "filter-inserter")
  elseif inserter.name == "filter-long-near-inserter" then
    replace_inserter(inserter, "filter-inserter")
  elseif inserter.name == "filter-long-short-inserter" then
    replace_inserter(inserter, "filter-inserter")

  elseif inserter.name == "express-long-inserter" then
    replace_inserter(inserter, "express-inserter")
  elseif inserter.name == "express-near-inserter" then
    replace_inserter(inserter, "express-inserter")
  elseif inserter.name == "express-far-inserter" then
    replace_inserter(inserter, "express-inserter")
  elseif inserter.name == "express-short-far-inserter" then
    replace_inserter(inserter, "express-inserter")
  elseif inserter.name == "express-short-long-inserter" then
    replace_inserter(inserter, "express-inserter")
  elseif inserter.name == "express-long-near-inserter" then
    replace_inserter(inserter, "express-inserter")
  elseif inserter.name == "express-long-short-inserter" then
    replace_inserter(inserter, "express-inserter")
  end
end

In there, I see no mention of circuit networks, logistic networks, hand contents, or logistic conditions (filters are a seperate thing)

It's those things without references that during my experiments weren't copied, and I can't see a way to copy.



Moving on... My progress so far, I have code that will save all hand positions to a global table, and code that will restore from a global table, along with the standard migration script.

The problem is, global tables are mod locked...

So... as things stand, 0.13.5 will save all hand locations to a global table, so you load the game, it creates the table, then you save the game.
update to 0.13.6, which has a .json migration script, and also iterates through the global table, and writes hand positions back to inserters.
upgrade complete.

there are no additional scripts for saving hand positions of inserters you add, or change after the initial table has been created.
And if you don't care about the hand positions, skipping 0.13.5 and going straight to 0.13.6 will work fine, the only thing is that no table of positions table will be created, so no positions will be restored.

EDIT:
Something else I've noticed that is interesting though... if you migrate an entity that hasn't had it's hand positions customised, the migrated entity moves hand positions to that of the new entity.
If you migrate an entity that has had it's hand positions customised, the new entity keeps the customised hand positions... so this might be easier to migrate than I thought... simply load and save the positions of the hands of every entity in a special "save hand positions" mod, then update, and upon migrating, the hands will be in the same positions.

Either way, blueprints would remain broken...

Further testing is required.