The Player element cannot be used in a CE condition

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

Moderators: Flumminator, Zomis

Post Reply
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

The Player element cannot be used in a CE condition

Post by r0lZ »

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!
Aunty_Spam
Posts: 7
Joined: Mon Oct 22, 2007 10:33 pm

Post by Aunty_Spam »

something like this has been reported already
viewtopic.php?p=9774&highlight=#9774
Silence is golden, ducttape is silver.
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

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.
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

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).
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

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?
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

> 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... :-/
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

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?
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

> 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... :-/
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

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.
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

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 ).
Post Reply