Factorio Forums

Degraine wrote:It might help if the yellow belt recipe produced two like the vanilla recipe. As it stands, the recipe's cost in plates has been quadrupled, not doubled.

bobingabout wrote:I've been considering a belt speed reballance too, isntead of speeds of 0.5/32, 1/32, 2/32, 3/32, 4/32 and 5/32 (speed is tiles per tick, /32 makes it pixels are default zoom level per tick) which gives you speeds of 6.66, 13.33, 26.66, 40, 53.33 and 66.66 items per second, I have been considering 0.75/32, 1.5/32, 2.25/32, 3/32, 3.75/32 and 4.5/32 instead, which gives speeds of 10, 20, 30, 40, 50 and 60 items per second.

RocketManChronicles wrote:Interestingly, the blue belts will keep the same throughput as they are in vanilla, which is what most of my builds target to begin with.

RocketManChronicles wrote:

bobingabout wrote:I've been considering a belt speed reballance too, isntead of speeds of 0.5/32, 1/32, 2/32, 3/32, 4/32 and 5/32 (speed is tiles per tick, /32 makes it pixels are default zoom level per tick) which gives you speeds of 6.66, 13.33, 26.66, 40, 53.33 and 66.66 items per second, I have been considering 0.75/32, 1.5/32, 2.25/32, 3/32, 3.75/32 and 4.5/32 instead, which gives speeds of 10, 20, 30, 40, 50 and 60 items per second.

Oh! Those numbers are quite nice to target to!

Interestingly, the blue belts will keep the same throughput as they are in vanilla, which is what most of my builds target to begin with.

orzelek wrote:For hiding the yellow belts you should really consider having underground and splitter on black ones.
When playing Xander there are also lower grade belts and not having splitters and undergrounds makes it really annoying to use them.
If black belts will become "fully featured" it will make it much less annoying that upgrade to yellows will require a lot preparation.

Now we only need to get Factorio devs to make belt upgrading easier

Ratzap wrote:

orzelek wrote:For hiding the yellow belts you should really consider having underground and splitter on black ones.
When playing Xander there are also lower grade belts and not having splitters and undergrounds makes it really annoying to use them.
If black belts will become "fully featured" it will make it much less annoying that upgrade to yellows will require a lot preparation.

Now we only need to get Factorio devs to make belt upgrading easier

I see that as an extra incentive to crack on and unlock the yellow ones. Then you can use the black belts for cheapness but still build undergrounds/splitters for where you need them. Adding black UG/splitter seems pointless to me since no-one in their right mind would want to use them and getting yellow is a matter of minutes.

I've been considering a belt speed reballance too, isntead of speeds of 0.5/32, 1/32, 2/32, 3/32, 4/32 and 5/32 (speed is tiles per tick, /32 makes it pixels are default zoom level per tick) which gives you speeds of 6.66, 13.33, 26.66, 40, 53.33 and 66.66 items per second, I have been considering 0.75/32, 1.5/32, 2.25/32, 3/32, 3.75/32 and 4.5/32 instead, which gives speeds of 10, 20, 30, 40, 50 and 60 items per second.

orzelek wrote: Please remember that what you are stating as "matter of minutes" will vary with game settings and mod setup. Not everyone plays in same way... so why assume that no-one would use black undergrounds/splitters?

Ratzap wrote:

orzelek wrote: Please remember that what you are stating as "matter of minutes" will vary with game settings and mod setup. Not everyone plays in same way... so why assume that no-one would use black undergrounds/splitters?

Yes but that's my point exactly. Those changes are self inflicted, why should Bob change his stuff or add things for edge cases which have nothing to do with taking his mods and playing them? Balancing Bobs around the play time used just with his own mod suite will only use black belts for a matter of minutes (ie sub an hour).

jodokus31 wrote:One other thing regarding the inserter overhaul:
I tested it and it look really fine so far. But if an other mod uses the filter-inserter as ingredient, it will require an express-filter-inserter instead, and they are gated behind blue science.
Here is an example, where it is a problem: viewtopic.php?f=190&t=14294&start=180#p350711

jodokus31 wrote:I also needed to upgrade my blueprints via upgrade planner to use the new inserter types, because otherwise, it removed the wires on placing.

bobingabout wrote:

jodokus31 wrote:One other thing regarding the inserter overhaul:
I tested it and it look really fine so far. But if an other mod uses the filter-inserter as ingredient, it will require an express-filter-inserter instead, and they are gated behind blue science.
Here is an example, where it is a problem: viewtopic.php?f=190&t=14294&start=180#p350711

Unfortunately, I can't account for every single case. I made the internal how I thought would best fit the majority of cases.

bobingabout wrote:

jodokus31 wrote:I also needed to upgrade my blueprints via upgrade planner to use the new inserter types, because otherwise, it removed the wires on placing.

Ah bollocks. This is due to the way I delete and replace ghost entities if they're an old type. unfortunately, this was the only way I could come up with since you can't migrate a ghost to a ghost.

jodokus31 wrote:One thing is also a bit unpractical. I now use the override buttons to place long inserters. But, if I forget to switch it off and place a blueprint, the length are not preserved as in blueprint, but all inserter are getting long inserters. I don't know if it can be suppressed, if it is placed by a robot and this issue might be older, but I never used the override buttons before.
Or maybe its an issue of nanobots, which i used as "robot"

However, I think, I like the new inserter overhaul

  if
    entity.type == "inserter"
    or (entity.type == "entity-ghost" and entity.ghost_type == "inserter" and not (player.cursor_stack and (player.cursor_stack.type == "blueprint" or player.cursor_stack.type == "blueprint-book")))
  then
    bobmods.logistics.set_positions(entity, event.player_index)
  end

bobingabout wrote:

jodokus31 wrote:One thing is also a bit unpractical. I now use the override buttons to place long inserters. But, if I forget to switch it off and place a blueprint, the length are not preserved as in blueprint, but all inserter are getting long inserters. I don't know if it can be suppressed, if it is placed by a robot and this issue might be older, but I never used the override buttons before.
Or maybe its an issue of nanobots, which i used as "robot"

However, I think, I like the new inserter overhaul

uuuuhhh.... let me check my code.
Inserters mod and logistics mod both includes this block of code on on_built_entity

Code: Select all

  if
    entity.type == "inserter"
    or (entity.type == "entity-ghost" and entity.ghost_type == "inserter" and not (player.cursor_stack and (player.cursor_stack.type == "blueprint" or player.cursor_stack.type == "blueprint-book")))
  then
    bobmods.logistics.set_positions(entity, event.player_index)
  end

The 3rd line here is checking if the entity is a ghost of an inserter, and the player isn't holding a blueprint or blueprint book, so in theory even if the over-ride is turned on, inserters placed by a blueprint shouldn't be effected.
unless of course the base game changed something and I'm doing something wrong now.

Going over things, that SHOULD still be correct.


I guess it depends how nanobots works, does nanobots placing something call on_built_entity? I can add in further exceptions if requested to.

  if
    (entity.type == "inserter" and not event.revived)
    or (entity.type == "entity-ghost" and entity.ghost_type == "inserter" and not (player.cursor_stack and (player.cursor_stack.type == "blueprint" or player.cursor_stack.type == "blueprint-book")))
  then
    bobmods.logistics.set_positions(entity, event.player_index)
  end

jodokus31 wrote:

bobingabout wrote:

jodokus31 wrote:One thing is also a bit unpractical. I now use the override buttons to place long inserters. But, if I forget to switch it off and place a blueprint, the length are not preserved as in blueprint, but all inserter are getting long inserters. I don't know if it can be suppressed, if it is placed by a robot and this issue might be older, but I never used the override buttons before.
Or maybe its an issue of nanobots, which i used as "robot"

However, I think, I like the new inserter overhaul

uuuuhhh.... let me check my code.
Inserters mod and logistics mod both includes this block of code on on_built_entity

Code: Select all

  if
    entity.type == "inserter"
    or (entity.type == "entity-ghost" and entity.ghost_type == "inserter" and not (player.cursor_stack and (player.cursor_stack.type == "blueprint" or player.cursor_stack.type == "blueprint-book")))
  then
    bobmods.logistics.set_positions(entity, event.player_index)
  end

The 3rd line here is checking if the entity is a ghost of an inserter, and the player isn't holding a blueprint or blueprint book, so in theory even if the over-ride is turned on, inserters placed by a blueprint shouldn't be effected.
unless of course the base game changed something and I'm doing something wrong now.

Going over things, that SHOULD still be correct.


I guess it depends how nanobots works, does nanobots placing something call on_built_entity? I can add in further exceptions if requested to.

I checked and tested a bit. I think, its related to Nanobots and how the entity is placed.
If I change the above code to this, it seems to work correctly. However, I dont know, if it could break other things.

Code: Select all

  if
    (entity.type == "inserter" and not event.revived)
    or (entity.type == "entity-ghost" and entity.ghost_type == "inserter" and not (player.cursor_stack and (player.cursor_stack.type == "blueprint" or player.cursor_stack.type == "blueprint-book")))
  then
    bobmods.logistics.set_positions(entity, event.player_index)
  end

jodokus31 wrote:

Code: Select all

    (entity.type == "inserter" and not event.revived)