[SUG] Steel is always steel, even if it's partially behind terrain

[Simon]

I'm not sure I understand what you mean by "convex", in this context...?

Good catch. It depends on what tiles and pixels really are.

(Reminder: A set is convex iff for all points x, y of the set, the straight line segment that connects x with y is also fully part of the set. When you travel straight from x to y, you won't leave the set.)

If we define the pixels as squares with nonzero area each, then each pixel already contains infinitely many points of 2-D space, and even the triangle's staircase surface fails to be convex. In this world, the only convex shapes are filled rectangles and the empty set.

Sometimes, I've envisioned terrain tiles as 2-D objects with smooth 1-D boundary lines, and then the convexity becomes more interesting because there are many more convex shapes than only the filled rectangles. This world view is nice to discuss intuition, e.g., when a steel algorithm mismatches intuition in a glaring way. This was my world view in the inverse-banana paragraph.

-- Simon

[kaywhyn]

I'm not sure I understand what you mean by "convex", in this context...?

Simon's already explained what it means to be convex in a geometrical context, but I'll give an example and put it in layman's terms, as being a math instructor myself I like to simplify explanations as much as I can for my students, though I acknowledge and have found that some mathematical topics are not that easy to explain clearly!

This is an example of a convex polygon. Basically, if you take any side of the square and extend it indefinitely in either direction, it will never cross the interior of the polygon. This must be true for all sides of the polygon, where no matter how much you extend them in either direction they won't ever go inside the polygon.

In contrast,

this star polygon is non-convex, or concave. For if you take any side and extend it in either direction, it will cross the interior of the polygon. It doesn't necessarily have to be true for all sides crossing the interior, but rather if even one side extended makes it reach the interior, then it's concave, not convex.

This is kind of easy to remember, as concave has the word cave, where I like to think of it as the inside of something you explore, and so any side extended that goes in the interior is non-convex.

[Simon]

How possible would it be to just detect whether the entire block is covered, and if so then remove it as steel? Then, if even 1px is visible, the entire block becomes steel again.

Can be more annoying than it appears on first sight.

For each steel tile occurrence in a level: Loop over all pixels of the steel tile (as loaded from disk, not as in the level), filter for solid pixels, transform the pixel's coordinates to the level according to the steel tile's occurrence in the level. The result I call "levelpixel". Nested loop over all tile occurrences that will be drawn later, filter for occurrences whose bounding box intersects the the levelpixel. Then nested loop over all pixels of the tile, filter for solid pixels, transform the pixel's coordinate according to the tile's occurrence, and return true if it's the levelpixel.

Four loops nested (six loops if you count x- and y-loops separately), thus sounds very expensive, you'll have to take good care to filter early what you don't need.

Or render the level's physics map twice, once with and once without the steel tile, and see if the two physics maps agree. Again, you can ditch all earlier-drawn tiles for speed in both renderings.

Begs another question: Is the game really the right place for this? I'd warn the user directly in the editor that his steel tile is fully covered and will be deleted. Early feedback, no surprises.

Is all this worth so much brainpower? I'd still let the banana/moss turn the covered steel into earth, it'll be okay. What problem led to this? Who got confused? What got backrouted? (I have my fun drilling into proposals and finding counterexamples, I don't mind continuing.)

-- Simon

[WillLem]

(Reminder: A set is convex iff for all points x, y of the set, the straight line segment that connects x with y is also fully part of the set. When you travel straight from x to y, you won't leave the set.)

If we define the pixels as squares with nonzero area each, then each pixel already contains infinitely many points of 2-D space, and even the triangle's staircase surface fails to be convex. In this world, the only convex shapes are filled rectangles and the empty set.

I'll give an example and put it in layman's term
---
This is an example of a convex polygon. Basically, if you take any side of the square and extend it indefinitely in either direction, it will never cross the interior of the polygon
---
this star polygon is non-convex, or concave. For if you take any side and extend it in either direction, it will cross the interior of the polygon

Riiight! Thanks, this helped

Yes - I can see how looking for the convex/concaveness of a steel tile would help to determine its shape relative to what intersects it, but I'm a long way from being able to tackle this sort of thing by myself tbh.

Or render the level's physics map twice, once with and once without the steel tile, and see if the two physics maps agree. Again, you can ditch all earlier-drawn tiles for speed in both renderings

I think I like this option better, if only because then we also have the opportunity to draw the steel to 2 layers at the same time, and achieve the "destroy terrain stuff over steel, but leave the steel underneath intact" aesthetic.

Begs another question: Is the game really the right place for this? I'd warn the user directly in the editor that his steel tile is fully covered and will be deleted. Early feedback, no surprises.

I had this exact same idea! Yes, maybe the Editor could just delete any steel tiles that are entirely beneath terrain tiles, and aren't eraser pieces.

The only issue with this is that it doesn't prevent someone then writing the hidden steel tile back in with a text Editor. Ultimately, it would have to be sorted out in-game anyway.

Is all this worth so much brainpower?

Probably not tbh

Still, a challenge is a challenge!

What problem led to this? Who got confused? What got backrouted?

A lot of it comes down to my own personal preferences more than anything. Steel has never really been completely well-behaved in any Lemmings clone/port. Always bumping steel to the very top layer and never allowing it to be erased would solve all problems from a purely physics POV, but... then we can't decorate or make wierd and wonderful shapes out of the blocks.

I'm not even too bothered about backroutes, hidden steel, that sort of thing. Those are other people's concerns that I'm just being aware of for discussion purposes.

It's about finding a balance: let's decorate steel, but let's not allow it to be completely hidden. And, let's destroy overlapping terrain to reveal the steel underneath. For me, that would settle it once and for all.

[Crane]

I have one other suggestion, although it will require a modification to the editor... terrain pieces have a "Steel Cancel" flag, which erases the steel zone where it overwrites the steel plate.  There might be cases where erasing and adding the same piece on top might not be ideal (e.g. if both the steel plate and visible piece are "No Overwrite").  Just a thought.

[WillLem]

I have one other suggestion, although it will require a modification to the editor... terrain pieces have a "Steel Cancel" flag, which erases the steel zone where it overwrites the steel plate.

Do you mean as an optional behaviour, similar to No Overwrite?

[Crane]

Yes, as an optional behaviour.

[WillLem]

Yes, as an optional behaviour.

I've added the idea to the wish list in case we decide to keep "steel is always steel" behaviour in SLX - it's definitely worth considering.

Three points of discussion:

1) This would essentially revert steel back to current NL behaviour whenever the flag is used. So, we'd end up with the best (and worst) of both worlds. An obvious drawback to this is never knowing what type of steel behaviour to expect, and that's even if the feature is never misused to intentionally troll the player with partially-destructible steel. The idea kind of negates the proposed "steel is always steel" behaviour, making it suddenly "steel is whatever the designer wants it to be"; not necessarily a bad thing, but whether or not it's a good thing depends very much on the player!

2) With that said, it's kind of already possible to do this (i.e. with a "steel is always steel" system) by simply placing a terrain piece over a steel block, setting the terrain piece to "Erase", duplicating it in-place, then setting the duplicated piece to "Not Erase". To keep steel behaviour intact in such a scenario, we'd need to also check for erasing pieces and see if they are completely obscured by terrain. Otherwise, we could end up with hidden, partially-erased steel blocks! Note to self: It's currently possible to do this in the SLX working copy, so maybe the next release of SLX should keep NL steel behaviour until we can get a solution together for this particular problem...

3) Maybe it's overcomplicating things? It's not difficult to create a custom steel piece which can be used as an eraser and then grouped with the visible steel piece to create a resulting single piece of the desired shape. Moreover, there are already dozens of steel pieces which have pretty much every possible shape covered between them, without even needing to create any more.

Erasing and grouping has revolutionised what's possible in the Editor; I almost feel like it'd be more worthwhile (and, frankly, much less effort) to add some generic-shaped steel pieces to the default "Special" style (triangles, squares, circles, etc) so that they can be used for the type of case you're describing. In the event that we go ahead with "steel is always steel", would that satisfy?

[namida]

If it doesn't look like steel, it shouldn't be steel. If you want steel blocks to always be fully steel, perhaps they should always be drawn in front of all non-steel terrain?

[WillLem]

If you want steel blocks to always be fully steel, perhaps they should always be drawn in front of all non-steel terrain?

I have considered this, yes; maybe the best bet would be to draw steel on a higher layer than terrain. We could then make pre-decorated steel blocks for orig_dirt, which I believe is the only style to have decorated steel in the OGs.

We can still partially erase steel blocks in the editor, and fill the deleted area with terrain on the lower layer, for Crane's example. This would give the appearance of the steel block being "behind" the terrain.

But yeah... I'm beginning to realise that we really can't have it both ways. For now, let's keep NL steel behaviour and make sure that any decoration in the OG levels is at least 1px in from the edge. Whatever else we do will either be a lot of mess or a lot of effort.

[WillLem]

So, just to be clear: for the next release of SuperLemmix (version 2.4), steel behaviour will be as it is in NeoLemmix.

I did originally want to battle-test "steel is always steel", but there are too many possible complications for it to actually end up being that simple. Better, then, to leave it as it is for now.