Author Topic: [BUG] Basher/steel interaction in SuperLemmini  (Read 446 times)

0 Members and 1 Guest are viewing this topic.

Offline WillLem

  • Posts: 1623
  • #SaveTheGrenader
    • View Profile
[BUG] Basher/steel interaction in SuperLemmini
« on: January 13, 2021, 11:52:18 PM »
This video shows it better than I can tell it, but basically - even with Classic Steel turned OFF, and with the steel area resized to fit the block exactly, there are sometimes wierd instances of a lemming hitting "invisible" steel in the vicinity of the actual steel area.

I'll investigate this a little further, but I'm fairly certain it's a bug.

Edit Simon: Spelling of title
« Last Edit: January 17, 2021, 07:03:06 PM by WillLem »

Online kaywhyn

  • Posts: 902
    • View Profile
Re: [BUG] Wierd steel behaviour
« Reply #1 on: January 14, 2021, 12:15:16 AM »
It sounds exactly like what I described in my post happening on level 10 of Ron Stard's Rodents SL pack in your SL remastering topic: https://www.lemmingsforums.net/index.php?topic=5372.msg89500#msg89500. In particular, this line:

Quote
Also, it's quite inconsistent that the current steel behavior is enabled for the non-custom SL packs, but then in custom packs the steel is indestructible and seems to have a really huge hit area so that bashers turn around sooner rather than bash directly up against the steel and then turn, as I saw when I did level 10 of Ron Stard's Rodents SL pack, which admittedly took me by surprise but also resulted in so much frustration because you had to assign the basher at the right position.

The only thing I don't know is if the resizing of the steel area is exactly fit with the steel block. I would have to open up the level in the editor to find out. If it's indeed the same as in your video, it would seem that it might be the way Tsyu intended. Hard to say, though.

Offline ericderkovits

  • Posts: 628
    • View Profile
Re: [BUG] Wierd steel behaviour
« Reply #2 on: January 14, 2021, 12:27:17 AM »
yes, this happened to me sometimes when I was editing levels in reunion, pimolems and dovelems. I remember a dovelems level (Valley of the Chameleons(coward 28)), I had to adjust the steel because a lemming kept hitting steel below where the bottom of the block was when the lemming had to mine below it. The steel extended too far below the block.  I definetly think this is a bug.
Maybe a bug in the editor with the steel where it doesn't make the steel exactly where it should be. Not sure. or maybe even with the SL player engine. I also do notice sometimes a lemming in levels will hit steel before he actually should too.

also I do notice some traps trigger points are too big too in SL. especially those shadow set smasher traps. The lemmings have to be farther away than with the NL same traps.

So I do think there are still issues in SL that are annoying. I just wish Tsyu was online more so we could ask him these questions.
« Last Edit: January 14, 2021, 12:48:51 AM by ericderkovits »

Offline WillLem

  • Posts: 1623
  • #SaveTheGrenader
    • View Profile
Re: [BUG] Wierd steel behaviour
« Reply #3 on: January 14, 2021, 01:22:46 AM »
After some investigation, I have established the following:

1) "Classic steel" is the one that is sometimes destructible, depending on the location of the skill assignment relative to the steel area. This is to replicate the bug present in many early Lemmings platforms, and is largely undesirable.

2) Confusingly, "Autosteel" and "Simple Autosteel" options are interpreted differently by SuperLemmini than by NeoLemmix, thus:

[SuperLemmini]{Autosteel} = The steel area fits the steel block exactly, and is indestructible
[NeoLemmix]{Autosteel} = The steel area fits only the visible part of the steel block, and is indestructible

[SuperLemmini]{Simple Autosteel} = No function (the steel is completely destructible)
[NeoLemmix]{Simple Autosteel} = The steel area fits the steel block exactly, and is indestructible

3) I have detailed how each destructive skill interacts with "SuperLemmini-style Autosteel" in this post. Worth a look if you're interested.

The only thing I don't know is if the resizing of the steel area is exactly fit with the steel block.

Doing this results in the exact same behaviour as enabling "Autosteel" for SuperLemmini levels (as opposed to the NeoLemmix Autosteel behaviour). So, maybe check if Autosteel has been enabled as well?

There are definitely some bugs relating to steel in SuperLemmini, that - upon closer inspection - appear to be exclusive to SuperLemmini, as opposed to emulation or modelling behaviour.

also I do notice some traps trigger points are too big too in SL. especially those shadow set smasher traps. The lemmings have to be farther away than with the NL same traps.

So I do think there are still issues in SL that are annoying. I just wish Tsyu was online more so we could ask him these questions.

Agreed re: Tsyu.

The shadow traps could have something to do with their position; I've noticed that objects are often offset slightly between LVL and NXLV conversions. In fact, the LVLs of Oh No! which you extracted are sometimes quite NeoLemmix-unfriendly for this exact reason, and the objects do need to be moved manually to match what's expected. I've needed to do several level updates to Amiga Lemmings, and I'll likely simply end up using the original NXLVs in the next update for that particular pack.

Online kaywhyn

  • Posts: 902
    • View Profile
Re: [BUG] Wierd steel behaviour
« Reply #4 on: January 14, 2021, 09:35:11 AM »
Is there a way to extract levels from a .lzp file? If there isn't, there's no way for me to check whether or not autosteel is enabled.

Offline namida

  • Administrator
  • Posts: 11328
    • View Profile
    • NeoLemmix Website
Re: [BUG] Wierd steel behaviour
« Reply #5 on: January 14, 2021, 09:39:15 AM »
Is there a way to extract levels from a .lzp file? If there isn't, there's no way for me to check whether or not autosteel is enabled.

IIRC they're just zip files with a different extension.

Online kaywhyn

  • Posts: 902
    • View Profile
Re: [BUG] Wierd steel behaviour
« Reply #6 on: January 14, 2021, 09:53:24 AM »
Is there a way to extract levels from a .lzp file? If there isn't, there's no way for me to check whether or not autosteel is enabled.

IIRC they're just zip files with a different extension.

Thanks, it worked! Opening them with Winrar did the trick ;)

The only thing I don't know is if the resizing of the steel area is exactly fit with the steel block.

Doing this results in the exact same behaviour as enabling "Autosteel" for SuperLemmini levels (as opposed to the NeoLemmix Autosteel behaviour). So, maybe check if Autosteel has been enabled as well?

Autosteel is not checked. How do you check the steel hit box area? Do you just select the steel piece? When I select any piece, the yellow box always goes a bit beyond the size of the piece on the right side only. I wonder what that means.

Offline WillLem

  • Posts: 1623
  • #SaveTheGrenader
    • View Profile
Re: [BUG] Wierd steel behaviour
« Reply #7 on: January 14, 2021, 03:47:44 PM »
Autosteel is not checked.

Do you mean for Ron Stard's level?

How do you check the steel hit box area? Do you just select the steel piece? When I select any piece, the yellow box always goes a bit beyond the size of the piece on the right side only. I wonder what that means.

Press F7 to view steel rendering, then F4 to display the hit box areas (semitransparently) in front of the steel blocks. As for the yellow box going beyond the right side of the piece, I think that's simply one of life's many mysteries :lemcat: - to hazard a guess, though, it could be something to do with enhancing the "selectability" of a piece, possibly.
« Last Edit: January 14, 2021, 04:44:52 PM by WillLem »

Offline namida

  • Administrator
  • Posts: 11328
    • View Profile
    • NeoLemmix Website
Re: [BUG] Wierd steel behaviour
« Reply #8 on: January 14, 2021, 05:51:27 PM »
Quote
Press F7 to view steel rendering, then F4 to display the hit box areas (semitransparently) in front of the steel blocks. As for the yellow box going beyond the right side of the piece, I think that's simply one of life's many mysteries :lemcat: - to hazard a guess, though, it could be something to do with enhancing the "selectability" of a piece, possibly.

Graphics in most Lemmings ports - which includes SuperLemmini (via WinLemm) - ultimately can be traced back to the DOS / Amiga versions, where due to a technical limitation, the width of all terrains / objects had to be divisible by 8. So, for a piece that's intended to be eg. 26px wide, they'd have to add some blank space to bring it up to 32px. (NeoLemmix has trimmed a lot of the empty space. On top of this, for pieces where empty space is not removed, the editor will usually trim it out at runtime, and adjust the coordinates when saving / loading to compensate.)

Now in some cases, that "padding" space is there even on pieces that could fit into a smaller canvas. I'm not sure why, except possibly they might have been cloned and edited from larger pieces?

Online kaywhyn

  • Posts: 902
    • View Profile
Re: [BUG] Wierd steel behaviour
« Reply #9 on: January 14, 2021, 08:56:07 PM »
Autosteel is not checked.

Do you mean for Ron Stard's level?

Indeed.

Quote
How do you check the steel hit box area? Do you just select the steel piece? When I select any piece, the yellow box always goes a bit beyond the size of the piece on the right side only. I wonder what that means.

Press F7 to view steel rendering, then F4 to display the hit box areas (semitransparently) in front of the steel blocks. As for the yellow box going beyond the right side of the piece, I think that's simply one of life's many mysteries :lemcat: - to hazard a guess, though, it could be something to do with enhancing the "selectability" of a piece, possibly.

Thanks! I just tried it, and indeed the steel area is fit to the block, but it's the same problem as seen in your video: Bashing away the wooden planks at the top on either side will sometimes cause the basher to stop earlier than it should. This means that the hit box of the steel is larger than it really is. I have already mentioned that the box for autosteel is not checked. Therefore, the basher has to be placed very precisely in order to avoid leaving any of the wooden plank intact. I'll likely upload a replay or even a video showing both in a bit.

Edit: Ok, my videos are uploaded.

My solution to Amusing 10 of Ron Stard's Rodents pack for Superlemmini: https://www.youtube.com/watch?v=jC-ty_av1Q4

Same level but with a basher stopping earlier than usual: https://www.youtube.com/watch?v=VIFUrjgzgog

As you can see, even though I bash at about the same place in both videos, one of them bashes away all of the wooden terrain completely, while the other one stops earlier due to the steel area being larger than is indicated in the editor, even with autosteel off. Therefore, the basher has to be placed very precise.

Even with all of the explanations, it's hard to say if it's the fault of the editor or the SL engine.

Graphics in most Lemmings ports - which includes SuperLemmini (via WinLemm) - ultimately can be traced back to the DOS / Amiga versions, where due to a technical limitation, the width of all terrains / objects had to be divisible by 8. So, for a piece that's intended to be eg. 26px wide, they'd have to add some blank space to bring it up to 32px. (NeoLemmix has trimmed a lot of the empty space. On top of this, for pieces where empty space is not removed, the editor will usually trim it out at runtime, and adjust the coordinates when saving / loading to compensate.)

Now in some cases, that "padding" space is there even on pieces that could fit into a smaller canvas. I'm not sure why, except possibly they might have been cloned and edited from larger pieces?

Thanks for the explanation. I totally forgot reading about the divisibility by 8 thing. It seems that the newest NL editor is far more user friendly than the much older versions. I haven't yet played with it, but I have a feeling that it will be quick to pick up. I just hope that's true when I actually start using it.
« Last Edit: January 14, 2021, 09:27:13 PM by kaywhyn »

Offline WillLem

  • Posts: 1623
  • #SaveTheGrenader
    • View Profile
Re: [BUG] Weird steel behaviour
« Reply #10 on: January 15, 2021, 04:28:12 AM »
This means that the hit box of the steel is larger than it really is.
---
As you can see, even though I bash at about the same place in both videos, one of them bashes away all of the wooden terrain completely, while the other one stops earlier due to the steel area being larger than is indicated in the editor, even with autosteel off

It's "classic steel" that usually causes those sorts of issues, "autosteel" behaves exactly the same as manually fitting the hit box to the steel block.

I think what's going on here is not a problem with the steel area itself, but actually with the Basher's steel checking. The fact that the Basher can destroy all of the wooden plank, if assigned at a certain point, would seem to confirm this (i.e. the steel is indestructible, and the terrain immediately surrounding it is destructible, the variable here is the positioning of the Basher).

Given that the steel bug I noted is also a Basher thing, I'm guessing that the Basher's steel check point is all over the place and just needs to be refined somehow.

I need to learn Java more quickly...!!!
« Last Edit: January 15, 2021, 06:11:06 AM by Simon »

Online kaywhyn

  • Posts: 902
    • View Profile
Re: [BUG] Weird steel behaviour
« Reply #11 on: January 15, 2021, 06:28:39 AM »
I think what's going on here is not a problem with the steel area itself, but actually with the Basher's steel checking. The fact that the Basher can destroy all of the wooden plank, if assigned at a certain point, would seem to confirm this (i.e. the steel is indestructible, and the terrain immediately surrounding it is destructible, the variable here is the positioning of the Basher).

That's a possibility, but I believe the same thing also happens with terrain, whether solid or added terrain. I think this is the case in level 8 of Ron Stard's Rodents pack. I'm not sure if you solved it yourself yet, though. It was originally impossible on Superlemmini due to what I'm guessing are the basher checks. This would seem to suggest otherwise about the steel hit boxes supposedly being bigger than they actually are and that you might be right about the basher checks being out of wack. Then again, I think it could be argued that the basher checks are far less forgiving and hence they seem to stop more easily in Superlemmini than they do in, say, NL or other engines. However, I think here it's simply a case of the distances between the walls in the level. I'm not sure what Ron Stard did to fix the level to make the level now possible, but I'm guessing he simply made a really minor adjustment in the positions.

Offline Turrican

  • Posts: 142
    • View Profile
Re: [BUG] Weird steel behaviour
« Reply #12 on: January 15, 2021, 10:28:55 PM »
Thanks! I just tried it, and indeed the steel area is fit to the block, but it's the same problem as seen in your video: Bashing away the wooden planks at the top on either side will sometimes cause the basher to stop earlier than it should. This means that the hit box of the steel is larger than it really is. I have already mentioned that the box for autosteel is not checked. Therefore, the basher has to be placed very precisely in order to avoid leaving any of the wooden plank intact.

First of all in the old games/engines , steel works like this: The steel pieces when you first place them in the level "doesn't know" that they are steel , so you need to place steel properties on them ( which are practically their hitboxes ) .

The rule for the steel properties ( hitboxes ) is : their position need to have x and y coordinates that are 4 , or multiples of 4 , and their size also ( x and y ) need to be 4 , or multiples of 4. The reason is that they need to be perfectly alligned to the 4x4 grid , the old engines/games use.

The thing here is , that these rules doesn't apply to the steel terrain pieces , they appy only on their hitboxes. That means that there may exist inconsistences , between the position of a steel piece and the position/size of it's hitbox , becauce the steel piece doesn't need to follow the "everything must be multiples of 4" rule , it's hitbox follows.

But the interesting thing here , is that in that level by Ron Stard , that doesn't seem to be the issue . If you load that level in Lemmix , you will see that the steel properties in that part of the level , are perfectly alligned with the steel pieces.

Another thing that I have found , is that what you describe here , happens also in the Lemmix version of the level , in the same way.

So , the reason that it happens , seems to be ( if I am correct ) the way basher checks works in the old engines/games. The rule they follow in the old games is : The basher , checks for terrain , every second basher stroke.

The wooden piece at that part of the level , needs 6 basher strokes (2x3) , in order to be bashed. So it seems that after the sixth stroke , another basher terrain happens , and recognizes that steel will be encountered in the next stroke? If that's the case , that also explains why if you assign the basher some pixels earlier , you will have a small wood piece remaining not bashed , after the sixth stroke.

« Last Edit: January 15, 2021, 10:36:35 PM by Turrican »
My Youtube channel ( Turrican Lemm )  :
https://www.youtube.com/channel/UCYGFBOHdYITHlsqa203Tu8Q

Offline WillLem

  • Posts: 1623
  • #SaveTheGrenader
    • View Profile
Re: [BUG] Weird steel behaviour
« Reply #13 on: January 16, 2021, 04:29:06 AM »
That's a possibility, but I believe the same thing also happens with terrain, whether solid or added terrain.

I'm not sure what you mean here. Can you clarify what you mean by "solid or added terrain" please?

Then again, I think it could be argued that the basher checks are far less forgiving and hence they seem to stop more easily in Superlemmini than they do in, say, NL or other engines.

Possibly...

their position need to have x and y coordinates that are 4 , or multiples of 4 , and their size also ( x and y ) need to be 4 , or multiples of 4. The reason is that they need to be perfectly alligned to the 4x4 grid , the old engines/games use.
---
But the interesting thing here , is that in that level by Ron Stard , that doesn't seem to be the issue . If you load that level in Lemmix , you will see that the steel properties in that part of the level , are perfectly alligned with the steel pieces.

The NeoLemmix 1.43 editor allows pixel-perfect placement of steel hit boxes, it doesn't need to be a multiple of 4. After further investigation, I'm pretty sure that the issue is with Basher's terrain checks.

So , the reason that it happens , seems to be ( if I am correct ) the way basher checks works in the old engines/games. The rule they follow in the old games is : The basher , checks for terrain , every second basher stroke.

The wooden piece at that part of the level , needs 6 basher strokes (2x3) , in order to be bashed. So it seems that after the sixth stroke , another basher terrain happens , and recognizes that steel will be encountered in the next stroke? If that's the case , that also explains why if you assign the basher some pixels earlier , you will have a small wood piece remaining not bashed , after the sixth stroke.

Yes, exactly, it seems that this is what's going on. I'm not sure if it's something that can be fixed.

In any case, I've gone ahead and released the OG remasters with autosteel enabled and classic steel disabled, because this is the best possible behaviour you can get from SuperLemmini with the physics as they currently are.

Online kaywhyn

  • Posts: 902
    • View Profile
Re: [BUG] Weird steel behaviour
« Reply #14 on: January 16, 2021, 04:59:48 AM »
That's a possibility, but I believe the same thing also happens with terrain, whether solid or added terrain.

I'm not sure what you mean here. Can you clarify what you mean by "solid or added terrain" please?

Best to see this on level 8 of Ron Stard's Rodents pack for SL. Have you solved it yet? It should be clear how the builders need to be placed, and so the solution is very dependent on where and when you start bashing. It pretty much suffers from the same problem as level 10 in that the basher placement is crucial. A pixel too late and it won't go all the way through, but a pixel too early and same thing. The only thing that will change is where the basher stops so that what the basher is able to destroy seems to be dependent on how the basher checks work in SL, which seems to be quite wack like you said. I believe this would support the basher checks being very out of place regardless of whether it happens with steel or terrain, but especially added terrain. Then again, there's not much room for the builder staircase to get high enough to make the precision not as maddening, but even then... Perhaps I can test on another level to see if a full length builder staircase makes a difference after bashing away a wall.

edit: Ok I tested this on Tame 1, and how much a basher destroys a builder staircase going in the same direction as the basher is extremely dependent on where and when you start bashing. It seems that the best way to get the basher to go the maximum distance before stopping would be to bash in such a way that only a pixel of wall remains before the builder staircase. In this way, only about 4 builder bricks of the staircase remain. Otherwise, none or just barely the foot of the staircase gets destroyed but lemmings can still walk up the staircase.

So, this definitely seems to be due to how basher checks work in SL. They seem to just be all over the place, whether with steel or with terrain/added terrain like with a builder staircase. If this is still unclear, I apologize, since I'm having trouble explaining what I meant myself. All of this is making my head spin :crylaugh:
« Last Edit: January 16, 2021, 05:10:29 AM by kaywhyn »