[1.1.32] Unexpected behaviour of LuaTile hidden_tile

[MewMew]

This prints "sand-1"

Code: Select all

/c
p = game.player.position
game.surfaces.nauvis.set_tiles({{name = "sand-1", position = p}}, true)
game.surfaces.nauvis.set_tiles({{name = "concrete", position = p}}, true)
game.surfaces.nauvis.set_tiles({{name = "sand-2", position = p}}, true)
game.print(game.player.surface.get_tile(p).hidden_tile)

But this prints NIL

Code: Select all

/c
p = game.player.position
game.surfaces.nauvis.set_tiles({{name = "sand-1", position = p}}, true)
game.surfaces.nauvis.set_tiles({{name = "sand-2", position = p}}, true)
game.print(game.player.surface.get_tile(p).hidden_tile)

Expected to both to be NIL

[KeepResearchinSpoons]

Lemme elaborate on what is going on:
TL;DR: the under-tile does not get updated on set-tiles. Thus we can not rely on get_tile.hidden_tile . It would _not_ be the last _update_ one but the last to have went _under the concrete_ one. (which does not happen on set_tiles as you may guess)



We want to test a tile by id
be it covered or be it not.

Thus you use smth like

Code: Select all

if tile.name == "tutorial-grid" or tile.hidden_tile == "tutorial-grid" then

good? good.

Once we get the tile we reset it with a surface.set_tiles to say "grass-1"
And you know what?

When the tile is not covered with concrete it just works.
And when the tile WAS covered the under tile is now tutorial grid and it DOES NOT GET UPDATED to nil on set_tiles()
So instead the check above passes just fine, even with the tile updated to grass we still have the hidden tut in place.


True, we could ask for another type of concrete here and thus we may want to remeber the original under tile...
However, just use this small code with sands and replace the condition above to suit sand-1.

There is no way to update the under-tile directly.
So instead of the one set_tiles we need to make it 3 times (new-tile, concrete, new-tile). (the first one is pushed underground)
Just to be sure we can reliably test the tile by id would the player cover it with bricks or would they not... at any random time and place.

[eradicator]

the under-tile does not get updated on set-tiles.

It should be though.

[KeepResearchinSpoons]

The expected behavior would either be
>> a clever set_tiles that sanitizes the undertile to nil if the tile is below the concrete/cover layer (can't cover other tiles and thus can't have undertiles). This would mean it just works and we could rely on the ids we get with get_tile.
>> an api to directly overwrite the "stacked inside" tile. My suggestion would be yet another argument to set_tiles taking the {under_id, pos} since it seems to not just accept unnamed args anyways.

Would also be great if we could chunk-set-reset ores en masse but they are entities and are generally outside this thread's bounds.

[sar]
Would also be great to get the coin item in the filters list alongside the raw-fish item.
Would also be great to get the plane-item back! so that markets would sell these lifesaving-tokens once more.
But aside being great for scenarios (which have the large public servers population size and impact... just like the factorio-minesweeper one that THIS debugging session started with) it does not mean that much for a freeplay, right? :think: Would need to add these to suggestions later. Probably.
[/sar]

[KeepResearchinSpoons]

the under-tile does not get updated on set-tiles.

It should be though.

open up the freeplay. Set up sizes to 50x50 to skip the crash site
then
(/c + code)
first do this

Code: Select all

function setter(name) game.surfaces[1].set_tiles({{name=name,position={1,1}}}) end
function tester() local tile = game.surfaces[1].get_tile({1,1}) return tile.hidden_tile end

then this

Code: Select all

setter("tutorial-grid")
setter("concrete")
setter("grass-1")

game.print(tester())

One may think that it is a grass tile.
Little do they know that it has a hidden tutorial-grid inside!

And also this little grassy passes the

Code: Select all

if tile.name == "tutorial-grid" or tile.hidden_tile == "tutorial-grid" then

test just fine :>

[KeepResearchinSpoons]

The ability to set undertiles is quite tempting.
With a simple code as this

Code: Select all

function setter(name,pos) game.surfaces[1].set_tiles({{name=name,position=pos}}) end
function loop(area,f) for x = area[1][1],area[2][1]-1 do for y = area[1][2],area[2][2]-1 do f({x,y}) end end end

function waterstep(pos) setter("water-green",pos) setter("concrete",pos) end
function make_spleef(size) loop({{-size,-size},{size,size}},waterstep) end

make_spleef(25)

you get a contraption that is aliek the spleef-arena in mc.
being on the childish level of a minigame that you only need to advertise right...
Still, look how easy the code is, you can *just* paste it to console and it works!

ofc for the win u still have to buff the mine speed tremendously, equip all players with a brick and do something around the latency...
you can also make some water tiles passable and add random bitters spawns just for fun, make a consumed fish shoot splosive particles on the cursor aimed position while removing the nearby tiles with a random chance etc. And remember the "advertise" part! Ranking, showcasing, racing, titles and such.

Alas for getting undertiled with dead-water you need to either teleport players, avoid the starting position at all (all those filter pos if "character" each call) or make all the chars spirited away and back (store inventory and states and all) right after the tiles being set.
With a crude code above you shall simply get killed each time you reset the area for a round. There's just no simple way around that.
More of a context then anything but Making or CopyPasting this is much faster then restarting for a next adventure mod. yet seeking a scenario distribution site/git and tweaking it right afterwards. Dynamic lua load for these modules to an admin panel would be a fun killer feature in the scenario world but would also be a very dangerous move opening a flood gate with a factorio becoming a platform-kin more of a product.

p.s. in truth I am very grateful that f-te and co. party keeps youngsters outta the web. But this train rides the future. Minigames can also target ppl that thought even bobs (not the py) to be way hard and daring. Consider the bitter battles having historically the greatest public online numbers. Pretty sure they can give you some detailed stats on players prefs they have collected over the while.

Best regards the main issue.
I wish us all less debuggin hours spent and more fun collected and pumped around.
And best of luck.
/ : - : - :

[Klonan]

The hidden tile is only updated if the tile put on top is minable, such as concrete, stone path, etc.

Also you can set and read the hidden tile directly:
https://lua-api.factorio.com/latest/Lua ... idden_tile
https://lua-api.factorio.com/latest/Lua ... idden_tile

For now I will move this to modding help, as nothing here seems to me like a bug

[MewMew]

Maybe add a description to this?
https://lua-api.factorio.com/latest/Lua ... idden_tile
That it only is set when a minable tile is placed and it is never deleted except manually with surface.set_hidden_tile()

Many hours spent figuring out a glitch in a map and it was a sneaky hidden tile in the end.

[eradicator]

The hidden tile is only updated if the tile put on top is minable, such as concrete, stone path, etc.

What is the rationale for that behavior? Is there such a huge performance penalty on an additional "if hidden_tile ~= nil" check? Seems odd to me otherwise to check for minability only to ignore it.