Rocks'n'Diamonds

This is the most important bug (or limitation) I have discovered so far.

If you use the player (or the Player Triggering Change ref) in a condition of a CE, it is not taken into account.

For example, define an element that can move.
Then, create a change page so that if it hits player 1, it explodes:

[v] Element changes to [ ] when
[v] [Hitting] element [Player1]
[v] Explode instead of change

That doesn't work.

I need absolutely a solution for this problem, because I'm stuck in my tentative to adapt XOR to R'n'D. (I can't use the "Deadly when..." property, because I have to control exactly on which side the hit occurs.)

Thanks for looking at that problem!

something like this has been reported already
viewtopic.php?p=9774&highlight=#9774

Yes, it's similar, but not exactly identical. Here, it's player 1 itself that is used, not a reference element. That mean that the players are not exactly normal elements, as stated by the documentation.

BTW, I have noticed the problem with the ref elements too.

Yes, this currently does not work. The reason is that the player is not treated as a "normal" element. (This is because there can never be two elements on the same tile, but the player can -- therefore, the player has to be handled differently.) Therefore using one of the player elements as an element in CE definitions does not work as expected in most cases.

The other bug is different -- here the reference elements are just not treated right. This bug should be easier to fix.

About using the player as an element like in "hitting element <player x>", I may be forced to handle this as a special case. I'll check what I can do about this without affecting the current game engine too much (as it tends to easily break existing levels when applying certain changes without a lot of extra thinking).

Thanks, Holger! I really would like to have a solution for this problem, as my current work on XOR depends of that.

BTW, could we expect a new release or beta soon?

> I really would like to have a solution for this problem, as my current work on
> XOR depends of that.

I will check if I can add this without too much effort (and too big danger of adding engine bugs or incompatibilities) at least for the case(s) you need for XOR.

> BTW, could we expect a new release or beta soon?

Theoretically yes -- the current "R'n'D jue" special edition contains most of the next version 3.2.5 (but no new engine features compared to 3.2.4). Practically, things always tend to take much longer than expected, and I can't always foresee the time I can spend on R'n'D. I have planned something like an automated "R'n'D nightly build" for many years... :-/

OK, thanks.

Maybe you could add an option to enable the new features, disabled by default, or extend the choice of the game engine in the level settings?

> Maybe you could add an option to enable the new features, disabled by default,

Well, new features can also be enabled -- if there are bugs or incompatibilities, it's best to let them show up as quick as possible. :-)

Even if only _you_ would use them, it would then be _your_ levels that would either break or need compatibility code to work after newly introduced bugs have been fixed. So it doesn't really matter much... ;-)

> or extend the choice of the game engine in the level settings?

Better not, as this would be too crazy: Having several only slightly different R'n'D game engines available would only add confusion (and they would have to be explained somewhere, as they wouldn't be as obvious as "Emerald Mine" and "R'n'D" (and even this isn't obvious for many people)). If all else fails, it's better to add switches like the "use spring bug" option on the "spring" config page... :-/

OK, I agree totally. Adding too many compatibility options or variations in the game engine is difficult. I was just trrying to find a solution so that only my levels are affected by the changes.

BTW, I would like also a new change page condition similar to the current "when pushed by player", but I'll start a new thread on this subject.

[EDIT] I've changed my mind. That new option will probably not be necessary, at least to develop XOR, so I have not started a new thread on this subject. However, that idea is explained in a post here.

Just noticed this bug report -- this should be fixed with the next stable release of R'n'D, as stated in the "XOR" thread (this one: viewtopic.php?t=1523 ).