Zelda I doesn't work properly in 3.2.6.0

Found a bug in R'n'D? Report it here!

Moderators: Flumminator, Zomis

Post Reply
Tomi
Posts: 339
Joined: Wed Aug 03, 2005 3:37 pm
Location: Slovakia

Zelda I doesn't work properly in 3.2.6.0

Post by Tomi » Fri Jan 02, 2009 4:35 pm

1. A wall near the center of the screen has incorrect texture. (Maybe associated with the "wheel"/"amoeba" bugs in the past.)

2. Texts (when you get an item) display incorrectly.

Both bugs above are "graphical" - maybe existing tapes still work. But I wouldn't bet on it. This looks like an engine incompatibility.

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Sat Jan 03, 2009 6:09 pm

In 3.2.6.0, it seems as if not all of the CE change pages triggered by "Change by page of" [an element changing in the same engine scan] are being triggered.

This breaks anything based on the design of Alan's FMV. When 3.2.6.0 first came out, I wanted to make a level that combined some of the new features with FMV, but then I learned that it was broken. :cry:

In my opinion, this is a major limitation of 3.2.6.0. I don't fully understand how Zelda II works (without using "Change by page of" in the same way), but I'm glad that it does work.

User avatar
Holger
Site Admin
Posts: 3112
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Wed Jan 28, 2009 9:20 am

I think I have an idea about this problem -- in 3.2.6.0, I removed a terribly nasty bug regarding "change by page of" or "change by element" (or something similar), and the bugfix ran cleanly through my test suite (which automatically runs R'n'D through a whole lot of R'n'D levels with test tape solutions).

I will have to have a look at this again, as graphical bugs won't show up in that test suite (and as most of Alan's cool demos aren't really suited for "solvable" test tapes available for the test suite).

User avatar
Holger
Site Admin
Posts: 3112
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Tue Mar 31, 2009 8:09 pm

I've fixed these bugs for existing (older) levels (including Zelda, Zelda II and FMV); it will be available soon with the upcoming R'n'D 3.2.6.1, which also fixes the crash bug of version 3.2.6.0.

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Tue Mar 31, 2009 9:55 pm

That sounds great! :)

When you say that you fixed it for older levels, does that mean that in the future, we will no longer be able to use "Change by page of" with changes with these conditions? :?

User avatar
Holger
Site Admin
Posts: 3112
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Sat Apr 04, 2009 10:09 pm

> When you say that you fixed it for older levels, does that mean that in the
> future, we will no longer be able to use "Change by page of" with changes
> with these conditions?

The "change by page of" functionality should work as designed, just as before. What stops to work with newer versions are unintended side effects caused by a major programming bug. But then, you wrote:

> In 3.2.6.0, it seems as if not all of the CE change pages triggered by
> "Change by page of" [an element changing in the same engine scan] are
> being triggered.

Is this really true? Are there any (simple, if possible) examples to demonstrate this? (It wouldn't be the first bugfix that introduces new bugs.)

Here's an explanation of what was fixed exactly (from src/files.c):

Code: Select all

    /* This is needed to fix a problem that was caused by a bugfix in function
       game.c/CheckTriggeredElementChangeExt() introduced with 3.2.5 that
       corrects the behaviour when a custom element changes to another custom
       element with a higher element number that has change actions defined.
       Normally, only one change per frame is allowed for custom elements.
       Therefore, it is checked if a custom element already changed in the
       current frame; if it did, subsequent changes are suppressed.
       Unfortunately, this is only checked for element changes, but not for
       change actions, which are still executed. As the function above loops
       through all custom elements from lower to higher, an element change
       resulting in a lower CE number won't be checked again, while a target
       element with a higher number will also be checked, and potential change
       actions will get executed for this CE, too (which is wrong), while
       further changes are ignored (which is correct). As this bugfix breaks
       Zelda II (and introduces graphical bugs to Zelda I, and also breaks a
       few other levels like Alan Bond's "FMV"), allow the previous, incorrect
       behaviour for existing levels and tapes that make use of this bug */

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Mon Apr 06, 2009 11:02 pm

The following level was made in Rocks'n'Diamonds 3.2.6.0:
changepages.level

CE 2 increases its CE value by 1 after a delay of 0.
CE 3 changes to empty space after a delay of 0.

CE 1 sets the player's shield to NORMAL on change by page of CE 2 or CE 3 (any page).

When you start the level, CE's 1 and 2 are on the field, but the player does not get a shield (even though I would expect him to). Replace CE 2 on the field with CE 3 and the player will get a shield.

(This example is about as simple as I could figure out how to get it. :wink: )

User avatar
Holger
Site Admin
Posts: 3112
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Tue Apr 07, 2009 7:56 am

I've just checked this!

What you described is indeed expected behaviour, and it works the same with 3.2.6.0 as with earlier versions (behaves exactly the same with 3.2.4, for example).

The reason why it behaves that way is quite simple: The CE change condition "change by page of" requires that the corresponding CE really changes to a different element to trigger that condition. Executing a CE action, without changing the CE at the same time, does not count as "change".

Therefore, in your example, you really need CE3 on the playfield to trigger the change action of CE1 (giving the player a shield). Having only CE2 on the playfield does not work here, as it only executes a CE action, but does not perform a CE change to trigger the "change by page of" condition of CE1. (If you also let CE2 change to itself, it would also work with CE2 alone.)

Maybe an additional condition "action by page of" would be useful, which would make it possible to trigger CE changes and actions not only by CE changes of other CEs, but also by CE actions.

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Tue Apr 07, 2009 10:27 pm

OK. :?

I have a question: What is the intended purpose of distinguishing between "change by page of" and "action by page of"?

User avatar
Holger
Site Admin
Posts: 3112
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Tue Apr 07, 2009 10:52 pm

> What is the intended purpose of distinguishing between "change by page
> of" and "action by page of"?

The first condition would require a CE change taking place to trigger, while the second condition would require a CE action to be executed to trigger the change of the corresponding CE that has this condition defined.

This would be a solution for the situation where a CE condition can lead to a CE change, a CE action, or both, while in one of these three cases (only CE action) there would be no CE change to trigger a "change by ..." condition.

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Sat Apr 11, 2009 3:37 pm

Thank you for the explanation. I understand what the difference is.
My question is regarding the purpose of distinguishing between the two.

User avatar
Holger
Site Admin
Posts: 3112
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Wed Apr 15, 2009 2:27 pm

Oops, sorry, I've got that wrong.

The purpose of distinguishing these two conditions would be to be able to use an action on a CE condition triggering another CE without using a CE change.

To use such a CE trigger condition, you would be forced to let the CE change to itself now, for example.

I haven't added such a condition so far, because I think it usually won't be needed (as you could just use the same conditions for both CEs instead of a "change by" condition), but it may be convenient in some cases. Unfortunately, it also may make thinks even more confusing, so I won't add it before many people ask for it... ;-) )

Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. » Fri Apr 17, 2009 11:39 pm

The way I see it, the problem is that if a CE has to change to itself in order to trigger something else, it will lose its current CE value unless "Use last CE value after change" is checked, which has other limitations..

Another limitation to a CE having to change to itself is that any changes waiting for a "CE Delay" get reset.


_________________

Holger wrote:[...] it will be available soon with the upcoming R'n'D 3.2.6.1, which also fixes the crash bug of version 3.2.6.0.
Maybe this version should be called R'n'D 3.2.7.0 to make it clearer that the game crashing bug is gone.

Any further news on when the next version will be released? :)
(the standard question)
Last edited by Daniel H. on Mon Jun 15, 2009 2:00 pm, edited 1 time in total.

Post Reply