Concrete should take 10 times less times to recycle or give back refined concrete loop

[worph]

The suggestion is mildly ridiculous

I find it more ridiculous to assume that the development team decided to nerf a single items recycling time, almost 2 years after release for no apparent reason.

They could have removed hazard concrete as a separate item.
They could have (and should have by the same logic) done something about chest-based recycling.
At least half the forum is crying about them removing space-casinos daily.
This is one way to reliably get a reasonable amount of quality iron in the early game, without megabasing.

I am generally very open about the fact that I could be wrong; I could be, I very well might be.
Nerfing concrete for no apparent reason seems maximally ridiculous to me and I would rather assume a reality where otherwise very competent people do things for a reason. Call me naive, if you like.

[nzer]

I find it more ridiculous to assume that the development team decided to nerf a single items recycling time, almost 2 years after release for no apparent reason.

I probably can't articulate why very well, but I genuinely don't know why you would believe this. Wube strike me as particularly strong-headed about their "vision" of the game, and I would not have any trouble believing this change came from a single dev who felt hazard concrete circumvented the intended difficulty around concrete recycling.

In fact how they're handling space casinos makes that far more believable to me than this having anything to do with making quality iron easier to come by. I didn't see anyone complaining about space casinos. On the contrary, the general consensus seemed to be that they were a lot more fun than stamping the same upcycler loop down several hundred times, and frankly tying optimal quality processing to the central mechanic of the entire expansion makes a lot of sense thematically. I'm not one of the more vocal critics of this, but in general there's quite a lot of "play the game the way we want you to" going on in Space Age, compared to the base game.

[Alfonse215]

This is one way to reliably get a reasonable amount of quality iron in the early game, without megabasing.

... is it, though? Let's look at "the early game, without megabasing".

You showed a diagram where there were 5 steps between mining and plates where you could apply quality. On paper, that sounds nice, but there's a problem: throughput.

If this is the early game, then you probably don't have much scrap productivity. So every scrap yields maybe 0.09 concrete (5 levels of scrap productivity). Scrap does mine twice as fast as ore, so that's 0.18 concrete for every ore.

But how much iron ore do you get out of concrete? While the recycling recipe speed does not take into account that the recipe generates 10 items, the recycling recipe percentages definitely do. So that's not a 25% chance of an iron ore for every concrete; it's 2.5%. So on average, you need 40 concrete to make 1 iron ore. To get 40 concrete, you must recycle 444 scrap. Which is equivalent to 222 ore from a miner.

If you give a BMD 4 QM2s (base quality), that's an 8% quality bonus. With 222 ore drops from the mining drill, you will get 1.8 rare ores.

So even if every ore you get out of the scrap method were guaranteed to be a rare drop, you'd still be better off mining ores. Especially since you would only need to put quality modules in the mining drills; no need for recyclers or assembler machinery.

If this was WUBE's attempt to make "early game" quality easier, it is a failure.

[worph]

I probably can't articulate why very well, but I genuinely don't know why you would believe this. Wube strike me as particularly strong-headed about their "vision" of the game, and I would not have any trouble believing this change came from a single dev who felt hazard concrete circumvented the intended difficulty around concrete recycling.

Reasonable. If this were the case I think they failed, like many others. I think removing hazard concrete entirely as an item would be a much better solution then. (and giving it the old red/green wire treatment, while still consuming concrete). And chests should have their recycling time increased like 30x, to be comparable to 5 steel (don't know the exact numbers).

In this case I would even argue they are not opinionated enough, paradoxically. If this is truely the way they intend people to play the, i.e. requiring many recyclers for more robust materials arbitrarily. They should absolutely also remove the LDS shuffle, by the same logic.

It's frankly kind of weird the direction they chose to balance things, assuming you are right. But I can see it.

[Alfonse215]

I probably can't articulate why very well, but I genuinely don't know why you would believe this. Wube strike me as particularly strong-headed about their "vision" of the game, and I would not have any trouble believing this change came from a single dev who felt hazard concrete circumvented the intended difficulty around concrete recycling.

Reasonable. If this were the case I think they failed, like many others. I think removing hazard concrete entirely as an item would be a much better solution then. (and giving it the old red/green wire treatment, while still consuming concrete). And chests should have their recycling time increased like 30x, to be comparable to 5 steel (don't know the exact numbers).

This all presumes that the goal of the change was to make disposing of waste on Fulgora harder to deal with. I don't really think it was. What WUBE did with hazard concrete is to effectively say that it's just concrete with a paintjob, so it shouldn't recycle differently from concrete. It's a change that on some level makes sense. If the game shipped that way on 2.0's release, nobody would be thinking of how it makes concrete on Fulgora harder to dispose of.

And while you can say "giving it the old red/green wire treatment, while still consuming concrete", that's a *far* more invasive change. No item in the game has ever worked like the thing you're suggesting. Even red/green wires never worked like that. In 1.1, they were distinct items you crafted and used. In 2.0, they ceased to be distinct items; they became virtual items but those require no resources. What you're talking about is some hybrid of these: a virtual item that also uses a resource, but that resource isn't the same item as the virtual item. And that resource also needs to be usable in its normal state.

That's obviously not impossible to do if you have access to the engine, but it is much harder (and more error-prone) than just adding a flag to the recycler recipe generating logic. You'd have to come up with some new UI stuff to make placing it viable (and you need to tell players where that UI is, because it won't be in their crafting menu or personal inventory). You have to change how ghost placement works so that hazard concrete ghosts request regular concrete and are instantly converted to hazard (and unconverted when deconstructed). Etc.

Between the two of those, changing the hazard concrete recycling recipe is by far the simplest change that would cause the least implementation pain.

[worph]

That's obviously not impossible to do if you have access to the engine, but it is much harder (and more error-prone) than just adding a flag to the recycler recipe generating logic. You'd have to come up with some new UI stuff to make placing it viable (and you need to tell players where that UI is, because it won't be in their crafting menu or personal inventory). You have to change how ghost placement works so that hazard concrete ghosts request regular concrete and are instantly converted to hazard (and unconverted when deconstructed). Etc.

The UI could stay exactly the same, except that if you click on it, nothing happens, no manual crafting.
If you place it, it just uses concrete instead.

[Alfonse215]

That's obviously not impossible to do if you have access to the engine, but it is much harder (and more error-prone) than just adding a flag to the recycler recipe generating logic. You'd have to come up with some new UI stuff to make placing it viable (and you need to tell players where that UI is, because it won't be in their crafting menu or personal inventory). You have to change how ghost placement works so that hazard concrete ghosts request regular concrete and are instantly converted to hazard (and unconverted when deconstructed). Etc.

The UI could stay exactly the same, except that if you click on it, nothing happens, no manual crafting.
If you place it, it just uses concrete instead.

There is no item in the game that works like that. They would have to build a system where there's an item that "exists" except it doesn't, can be created but not by the player, and consumes a completely different item when it is placed. Oh, and robots have to be able to pick up these non-items too and place them as the correct item.

Again, it's not impossible to implement that the way you suggest, but you cannot tell me that this is anywhere near as simple as adding maybe 5 lines to a couple of Lua scripts.

[worph]

Again, it's not impossible to implement that the way you suggest, but you cannot tell me that this is anywhere near as simple as adding maybe 5 lines to a couple of Lua scripts.

I assume neither of us knows how simple or complex it would be. Or at least I don't have access to the factorio codebase, can't speak for you.
Essentially I am suggesting a UI "hack" so to speak. Everything is concrete, but you can place concrete in two ways. Both cost the same ressource, both return the same ressource. But one is displayed differently, as the hazard variant.

[eugenekay]

There is no item in the game that works like that. They would have to build a system where there's an item that "exists" except it doesn't, can be created but not by the player, and consumes a completely different item when it is placed. Oh, and robots have to be able to pick up these non-items too and place them as the correct item.

base/prototypes/tile/tiles.lua:

Code: Select all

{
    type = "tile",
    name = "hazard-concrete-left",
    order = "a[artificial]-b[tier-2]-b[hazard-concrete-left]",
    subgroup = "artificial-tiles",
    needs_correction = false,
    next_direction = "hazard-concrete-right",
    transition_merges_with_tile = "concrete",
    minable = {mining_time = 0.1, result = "hazard-concrete"},
    mined_sound = sounds.deconstruct_bricks(0.8),
    collision_mask = tile_collision_masks.ground(),
    walking_speed_modifier = 1.4,
    layer = 15,
    layer_group = "ground-artificial",
    decorative_removal_probability = 0.25,
    placeable_by = {item = "hazard-concrete", count = 1},
    variants =
    {
      transition = tile_graphics.generic_texture_on_concrete_transition,

      material_background =
      {
        picture = "__base__/graphics/terrain/hazard-concrete-left/hazard-concrete-left.png",
        count = 8,
        scale = 0.5
      }
    },
    walking_sound = tile_sounds.walking.concrete,
    driving_sound = tile_sounds.driving.concrete,
    build_sound = tile_sounds.building.concrete,
    map_color={176, 142, 39},
    scorch_mark_color = {r = 0.373, g = 0.307, b = 0.243, a = 1.000},
    vehicle_friction_modifier = concrete_vehicle_speed_modifier,

    trigger_effect = tile_trigger_effects.hazard_concrete_left_trigger_effect(),

  },
  {
    type = "tile",
    name = "hazard-concrete-right",
    order = "a[artificial]-b[tier-2]-c[hazard-concrete-right]",
    subgroup = "artificial-tiles",
    needs_correction = false,
    next_direction = "hazard-concrete-left",
    transition_merges_with_tile = "concrete",
    minable = {mining_time = 0.1, result = "hazard-concrete"},
    mined_sound = sounds.deconstruct_bricks(0.8),
    collision_mask = tile_collision_masks.ground(),
    walking_speed_modifier = 1.4,
    layer = 15,
    layer_group = "ground-artificial",
    decorative_removal_probability = 0.25,
    placeable_by = {item = "hazard-concrete", count = 1},
    variants =
    {
      transition = tile_graphics.generic_texture_on_concrete_transition,

      material_background =
      {
        picture = "__base__/graphics/terrain/hazard-concrete-right/hazard-concrete-right.png",
        count = 8,
        scale = 0.5
      }
    },
    walking_sound = tile_sounds.walking.concrete,
    driving_sound = tile_sounds.driving.concrete,
    build_sound = tile_sounds.building.concrete,
    map_color={176, 142, 39},
    scorch_mark_color = {r = 0.373, g = 0.307, b = 0.243, a = 1.000},
    vehicle_friction_modifier = concrete_vehicle_speed_modifier,

    trigger_effect = tile_trigger_effects.hazard_concrete_right_trigger_effect()
  },

The “hazard-concrete” item defaults to placing the “hazard-concrete-left” tile type; but it can also be rotated to place “hazard-concrete-right”. Both yield the “hazard-concrete” item when mined. So it is absolutely possible for a single "concrete" item to be used for multiple different tile types. The bigger issue would be writing a Migration to convert all existing hazard-concrete items - and the factory breakages resulting from the hazard-concrete recipe no longer being available.

Good Luck!

[Alfonse215]

There is no item in the game that works like that. They would have to build a system where there's an item that "exists" except it doesn't, can be created but not by the player, and consumes a completely different item when it is placed. Oh, and robots have to be able to pick up these non-items too and place them as the correct item.

base/prototypes/tile/tiles.lua:

Code: Select all

{
    type = "tile",
    name = "hazard-concrete-left",
    order = "a[artificial]-b[tier-2]-b[hazard-concrete-left]",
    subgroup = "artificial-tiles",
    needs_correction = false,
    next_direction = "hazard-concrete-right",
    transition_merges_with_tile = "concrete",
    minable = {mining_time = 0.1, result = "hazard-concrete"},
    mined_sound = sounds.deconstruct_bricks(0.8),
    collision_mask = tile_collision_masks.ground(),
    walking_speed_modifier = 1.4,
    layer = 15,
    layer_group = "ground-artificial",
    decorative_removal_probability = 0.25,
    placeable_by = {item = "hazard-concrete", count = 1},
    variants =
    {
      transition = tile_graphics.generic_texture_on_concrete_transition,

      material_background =
      {
        picture = "__base__/graphics/terrain/hazard-concrete-left/hazard-concrete-left.png",
        count = 8,
        scale = 0.5
      }
    },
    walking_sound = tile_sounds.walking.concrete,
    driving_sound = tile_sounds.driving.concrete,
    build_sound = tile_sounds.building.concrete,
    map_color={176, 142, 39},
    scorch_mark_color = {r = 0.373, g = 0.307, b = 0.243, a = 1.000},
    vehicle_friction_modifier = concrete_vehicle_speed_modifier,

    trigger_effect = tile_trigger_effects.hazard_concrete_left_trigger_effect(),

  },
  {
    type = "tile",
    name = "hazard-concrete-right",
    order = "a[artificial]-b[tier-2]-c[hazard-concrete-right]",
    subgroup = "artificial-tiles",
    needs_correction = false,
    next_direction = "hazard-concrete-left",
    transition_merges_with_tile = "concrete",
    minable = {mining_time = 0.1, result = "hazard-concrete"},
    mined_sound = sounds.deconstruct_bricks(0.8),
    collision_mask = tile_collision_masks.ground(),
    walking_speed_modifier = 1.4,
    layer = 15,
    layer_group = "ground-artificial",
    decorative_removal_probability = 0.25,
    placeable_by = {item = "hazard-concrete", count = 1},
    variants =
    {
      transition = tile_graphics.generic_texture_on_concrete_transition,

      material_background =
      {
        picture = "__base__/graphics/terrain/hazard-concrete-right/hazard-concrete-right.png",
        count = 8,
        scale = 0.5
      }
    },
    walking_sound = tile_sounds.walking.concrete,
    driving_sound = tile_sounds.driving.concrete,
    build_sound = tile_sounds.building.concrete,
    map_color={176, 142, 39},
    scorch_mark_color = {r = 0.373, g = 0.307, b = 0.243, a = 1.000},
    vehicle_friction_modifier = concrete_vehicle_speed_modifier,

    trigger_effect = tile_trigger_effects.hazard_concrete_right_trigger_effect()
  },

The “hazard-concrete” item defaults to placing the “hazard-concrete-left” tile type; but it can also be rotated to place “hazard-concrete-right”. Both yield the “hazard-concrete” item when mined. So it is absolutely possible for a single "concrete" item to be used for multiple different tile types. The bigger issue would be writing a Migration to convert all existing hazard-concrete items - and the factory breakages resulting from the hazard-concrete recipe no longer being available.

Good Luck!

Yes, you can make a concrete item place a hazard concrete tile. And have it be mined as a concrete item. So... how do you make a concrete item *also* place a concrete tile? And how do you decide which is used when?

Because that's what we're talking about here. There's a ghost of a hazard concrete tile, and right next to it is a ghost of a concrete tile. If hazard concrete isn't a separate item that can be picked up and used, then a bot needs to pick up concrete, fly over there, and place it as concrete or hazard concrete. How does that work?

[eugenekay]

Yes, you can make a concrete item place a hazard concrete tile. And have it be mined as a concrete item. So... how do you make a concrete item *also* place a concrete tile? And how do you decide which is used when?

Because that's what we're talking about here. There's a ghost of a hazard concrete tile, and right next to it is a ghost of a concrete tile. If hazard concrete isn't a separate item that can be picked up and used, then a bot needs to pick up concrete, fly over there, and place it as concrete or hazard concrete. How does that work?

Hazard Concrete is a separate Item from Concrete currently:
base/prototypes/item.lua:

Code: Select all

{
    type = "item",
    name = "hazard-concrete",
    icon = "__base__/graphics/icons/hazard-concrete.png",
    subgroup = "terrain",
    order = "b[concrete]-b[hazard]",
    inventory_move_sound = item_sounds.concrete_inventory_move,
    pick_sound = item_sounds.concrete_inventory_pickup,
    drop_sound = item_sounds.concrete_inventory_move,
    stack_size = 100,
    weight = 10*kg,
    place_as_tile =
    {
      result = "hazard-concrete-left",
      condition_size = 1,
      condition = {layers={water_tile=true}}
    },
    random_tint_color = item_tints.bluish_concrete
  },

The place_as_tile property on the item determines the Tile that is selected by default. The Rotate key will switch to the next_direction tile; you can have a chain of Concrete --> Hazard-Concrete-Left --> Hazard-Concrete-Right --> Concrete, though this may lead to other issues. Robots will fetch the item specified in placeable_by.

My point is that it is theoretically possible to combine Concrete with Hazard Concrete items, using existing API mechanics. I have no opinion on whether this is wise.

[macdjord]

And while you can say "giving it the old red/green wire treatment, while still consuming concrete", that's a *far* more invasive change. No item in the game has ever worked like the thing you're suggesting. Even red/green wires never worked like that. In 1.1, they were distinct items you crafted and used. In 2.0, they ceased to be distinct items; they became virtual items but those require no resources. What you're talking about is some hybrid of these: a virtual item that also uses a resource, but that resource isn't the same item as the virtual item. And that resource also needs to be usable in its normal state.

That's obviously not impossible to do if you have access to the engine, but it is much harder (and more error-prone) than just adding a flag to the recycler recipe generating logic. You'd have to come up with some new UI stuff to make placing it viable (and you need to tell players where that UI is, because it won't be in their crafting menu or personal inventory). You have to change how ghost placement works so that hazard concrete ghosts request regular concrete and are instantly converted to hazard (and unconverted when deconstructed). Etc.

Note that this is, in fact, possible, and you don't even need access to the underlying engine to do it. The Maraxis planet mode implements its custom planet-specific mechanics using 'vanilla' building that way: when you're on Maraxis and place the vanilla building, it is silently replaced with a visually identical custom building that has different mechanics; this custom building is coded to return the vanilla building as an item when mined.

The process isn't quite seamless, but the only issues I've noticed are that the custom building has a separate Factoriopedia entry (which can get confusing, since it has the same name and icon as the vanilla building, and there's no note or anything to explain what's going on) and the custom building also exists as a separate signal on circuit networks and requests (which can potentially result in some confusing but minor bugs if you use one signal while thinking you're using the other).