[0.16.x] Bob's Mods: General Discussion

[orzelek]

I have a starter game with Bob's and Angels and I find new revamped belts pretty harsh - standard belt cost is pretty steep for something you need to use in large quantities from the start to actually build up your base.
Playing with all the mods makes the game quite slow already - and with revamped belts there is aneed to make even more materials just to have belts for base building. This makes building starting base that much slower - and it was pretty slow to begin with.

[Degraine]

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.

[orzelek]

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.

I'm thinking about making small mod that will multiply belt recipe outputs by predefined amount. Making lots of belts was always a bit of an annyoance for me so making them in batches of 5 would be pretty helpful. Only potential issue is that it would affect cost of science packs that use belts and compensating for that could be a bit more work.

[Ratzap]

Or you could just mine more and wait. Leave it building belts, flip it into the background and do something else - it's the only sane way to deal with mods like sea block or xanders.

Playing just with Bobs it's fine as it is now. Your problem is you're adding more on top, which is NOT Bobs problem, it's yours. That belt multiplier you're talking about - I'm sure I've seen one (or something very similar) on the mod portal.

[bobingabout]

I'm getting deja vu here. Haven't we already gone down the whole "Yellow is too expensive" thing before? I've already reduced the price down to only 2 iron gears instead of 4.
Have you tried using the black belts?

You know what, I'm going to lock yellow belts behind a research wall. Put them on Logistics 1 along with the splitter and underground belt. That way, when people go looking for a belt, they won't even see the yellow one, just the grey one, and instead of thinking "Why are my yellow belts so expensive?" they'll instead think "Oh, he must have recoloured yellow belts to grey".

I know, black belts are slow.

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]

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.

[bobingabout]

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.

That's not an accident
Unfortunately, it does away with red being twice the speed of yellow, and green being twice the speed of red
but instead you end up with blue being twice the speed of yellow, and purple being twice the speed of red.
Yellow remains twice the speed of black, but, not as crap.

[orzelek]

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

[jodokus31]

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.

I dont know, if thats a good idea, because it will mess up quite a lot. Also, I think, the red and yellow belt will be to good for its price. I think, I won't upgrade to higher belts.
I would give the grey belts a splitter and underground with only 2 underground length or considering removing grey belts again and make yellows a bit cheaper, esp. the belt itself.
For me, its also quite good how it is now.

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

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

[Ratzap]

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.

[orzelek]

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.

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?

[IanRaven]

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.

I'd love this change to belt speed, because it would help planning the production rates of items.

[Ratzap]

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).

[orzelek]

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).

So you are basically stating that we shouldn't play any other mods with bob's set or be ready to fight with black belts for few hours since we like to play bigger mod pack. Thats very unfriendly to other mods but I can understand the reasoning behind it.
I'll leave the decision to bobingabout.

[bobingabout]

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.

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]

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.

I think, they fixed it properly. It may occur problematic in other situations, because filter-inserter was not a very high-tech item, but express-filter-inserter is a bit more advanced, material- and science-wise

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.

Actually, its not a big deal, if you know, which inserter needs to be upgraded to what:
- long-handed-inserter -> red-inserter
- filter-inserter -> express-filter-inserter
- fast-inserter -> express-inserter
- stack-inserter -> express-stack-inserter
- stack-filter-inserter -> express-stack-filter inserter.

I also upgraded my whole map and this gave me a big bonus of materials, because the new inserter are quite more expensive

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

[bobingabout]

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.

[jodokus31]

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

[orzelek]

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

The revived bit is added by Nanobots mod - and I think Bluebild mod will also use it after it's fixed. So it should be a good way to detect if object has been "built" by some mod.

[bobingabout]

Code: Select all

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

This change makes sense to me, I don't see how it would break anything, because that line was only really there to check if you placed the entity. if it is called by being revived, you don't want to apply the override.