CE change page "player collects element" option is kinda weird

[SLAPPYHAPPY2000]

Hi, everyone.

While playing around with Custom Elements in Rocks'n'Diamonds, I wanted to have something change if the player collected a regular, non Custom Element emerald.
However, "collecting" does not apply to all methods of collecting a gem!
Snapping the gem does not trigger the Custom Element change, which seems wrong to me, since when you are snapping a gem (or any other collectable element), you are still collecting it and it still gets added to your total or inventory.
Is it supposed to be like this? I am playing on a Windows 10 operating system, and the version of Rocks'n'Diamonds is 4.2.3.1.

Have a nice day!

[Holger]

Indeed this is by intention, to be able to distinguish between collecting an element (while walking), and snapping an element (while standing), if this should be required for your specific CE intentions.

But it is no problem to achieve what you want: Just add another CE change page (press the "new" button at the bottom of the "change" tab), copy all settings from the first change page, but use "player snaps" instead of "player collects" for the second change page -- that's it!

[TheOnyxGuy]

Well, in that case, it breaks some of the older levelsets, where you can collect and snap items, but nowadays snapping will just... break them down. Maybe, kinda like the "old and new game engine", this should be optional and distinguishable enough for the game to automatically know what mode of "collecting" for CE that should be?

[Holger]

Well, in that case, it breaks some of the older levelsets, where you can collect and snap items, but nowadays snapping will just... break them down.

Hm, I am not aware of any changes in CE conditions that would break existing levels.

Do you have an example level that does not work anymore with the current version, but that worked with version x.y.z?

[TheOnyxGuy]

For example, few of my works like Blox (both of 'em). There's elements which can remove all blocks of same color at once upon collecting, and, nowadays... only collecting, since snapping just cancels that kind of function.
Here's what that potentially looks like

[Holger]

Just checked this issue. Indeed! That should never happen!

This bug was introduced with R'n'D 4.2.2.1.

First, I've tried to reproduce this with a CE that disappears if a second CE is collected. This works (also with the latest R'n'D version) with both collecting and snapping if the test level was created with R'n'D 4.2.2.0 or earlier.

But when testing with "Blox 2", level 004, I can see that this does not work with 4.2.2.1 and newer!

These are two bugs: The first bug is that the CE collecting/snapping behavior was changed at all. Which also means that I was wrong with what I wrote before. ("Indeed this is by intention [...]") Apparently I remembered that wrong!

Then, the behaviour of existing levels should not change, and indeed I added code that attempts to prevents this, but which apparently fails at it.

The whole objective of that change was something different: To delay CE changes until a triggering element is completely collected or snapped, instead of triggering the CE change when collecting/snapping starts, which can result in weird behavior if the CE action causes the player to relocate.

Here's the commit that broke it:

Code: Select all

commit ca2d65072bf921ae4341eaa86ff7f674f3e3ba91
Author: Holger Schemel <info@artsoft.org>
Date:   Mon Jan 4 12:21:36 2021 +0100

    changed triggering CE actions by digging or collecting
    
    Before this change, when CEs are triggered by the player digging or
    collecting some tile or element, the trigger action was executed
    immediately when the player started digging or collecting.
    
    While this generally works fine, it looks (and behaves) strange when
    the related CE action causes the player to relocate to a different
    position in the playfield (CEs that are "teleporting" the player). In
    such cases, the player's dig or collect action is usually executed at
    both the old and the new player position, which is not how it really
    should work.
    
    This change fixes this behaviour by delaying the CE trigger action
    until the dig or collect action is finished, so that only the tile at
    the old player position gets digged or collected, but not the tile at
    the new player position (if the triggered CE causes the player to
    relocate).
    
    This commit improves the workaround in commit fd0ec980.

I have to check this again, debug and fix it.

[TheOnyxGuy]

Speaking of softlocking, there's yet another levelset at least I have which is 'currently' uncompletable at all. Specifically, there was a little tiny bit when you could do a step before a step preventing action would occur (envelope showing, in this case), which was then later fixed.
I made a while ago a levelset "The Dark Maze of Yam-Yams", and one of it's levels has that instant start where you have to do quick first step before the envelope even appears (which is a little bit bullsh***y of me to do such thing really, so that's more of my error) to avoid both softlock and death from a falling rock, but nowadays the game prevents you from doing the first step, displays the envelope and then lets you move but you don't have a chance to escape it anymore.
I would not say that's a bad change, again, that, I would count, more of my error of exploiting the game like that.

[filbo]

Eizzoux, you should post the level that has that behavior change -- you may be right that it 'shouldn't' work in the new scheme, but Holger might disagree... let him observe the difference and decide?

[TheOnyxGuy]

Well, I already mentioned it in the reply

I made a while ago a levelset "The Dark Maze of Yam-Yams", and one of it's levels has that instant start where you have to do quick first step before the envelope even appears

The levelset itself is over here, level 003.

[TheOnyxGuy]

Funny enough, you gave me an opportunity to check it again, and... weirdly enough, that issue isn't relevant anymore, since it does not prevent you from moving before the envelope appears after 0 frames of element change. I guess that was case only in few of previous versions, probably around 4.1.0.X-4.2.2.X, but I clearly remember I couldn't do a step around a year ago in that level, but what I don't remember is the exact version I was trying that levelset out at that time.

4.2.3.1

sgrdf.png (417.48 KiB) Viewed 22754 times

[Holger]

I guess that was case only in few of previous versions, probably around 4.1.0.X-4.2.2.X, but I clearly remember I couldn't do a step around a year ago in that level, but what I don't remember is the exact version I was trying that levelset out at that time.

Yes, I think I remember that I fixed such a bug as you described it, and it must have been around those versions.

But I found out more regarding this problem:

For example, few of my works like Blox (both of 'em). There's elements which can remove all blocks of same color at once upon collecting, and, nowadays... only collecting, since snapping just cancels that kind of function.

Although this is still a bug in the last three versions of R'n'D (since 4.2.2.1), it does indeed not affect existing, older level sets -- until you explicitly set "latest_engine: true" in "levelinfo.conf", which you did (at least) in both "Blox 2" and "The Dark Maze of Yam-Yams"!

This option tells the game "forget about all compatibility stuff for older game engine versions, and use the latest version of the game engine, without using any compatibility tweaks at all".

This makes sense for native level sets (like Supaplex or Emerald Mine), to always use the latest version of the game, but it does not make sense for older R'n'D levels (levels using the R'n'D game engine) that should play just like they were designed to play in older versions of R'n'D, including slightly different behaviour in those older game versions.

Therefore, removing this option from the "levelinfo.conf" file of all your older level sets should fix them!

[Holger]

I have now fixed this bug which occurs with levels created with R'n'D version 4.2.2.1 and newer (when snapping a diggable or collectible element and having a CE event that triggers when this element is digged or collected, which should also fire if the element is snapped).

Thanks for pointing me into the right direction for this issue! (Even if the bug encountered when playing your own level sets was caused by the faulty "latest_engine: true" setting in your "levelinfo.conf" files.)

[TheOnyxGuy]

Looking back at this, I think this issue could be resolved instead by adding "Player collects" condition which reacts to only collecting, but not snapping, and renaming the old one as "Player collects/snaps". That would keep both options together without any conflicts and also keep older levelsets safe from bugging out.