Damned! I think I forgot to look in the File menu!Aunty_Spam wrote:Yes you can save level sketches to basic RnD levels.
Trying to develop XOR for RnD
Moderators: Flumminator, Zomis
New problem with "dolly" element, when pushed into
I am currently trying to design the last element I need to complete the XOR world, but I can't do what I need.
The element is a "dolly". The dolly can move in all directions when pushed by the player, and it must stop when it hits something. That's really easy to do with a pushable CE that can move when pushed. That CE stops when it hits something, as it should. Fine.
But, in XOR, the dolly can also be pushed over the horizontal tube (when pushed horizontally) or over the vertical tube (when pushed vertically.) When it is pushed over a tube, the tube disappears and is replaced by the dolly. If there is something else (including another tube) beneath the tube, the dolly stops immediately. Otherwise, it should continue to move in the same direction until it hits something. Of course, the player must follow the dolly when he pushes it. Here is an example, where the dolly is
1. Starting position:
2. After the player has pushed the dolly to the right, over the tube:
3. Now, since there is nothing to the right side of the dolly, it continues to move to the right:
Unfortunately, in RnD, it is impossible to push an element over another one, even if the target element is diggable by the source element.
So, I have tried to define the dolly as not pushable and immobile, and to replace it by another CE that moves when it is pressed. That method turned out to be relatively difficult, as I have to program each direction independently. But, more importantly, that doesn't work neither, because, IMO, there are some important limitations in the RnD engine.
Here is finally what I did. (The numbers are the CEs.)
The dolly (
) is pushable, and changes to CE2 when pushed by the player at left size. (It changes also to other CEs when pushed in the other directions, but for clarity I explain here only the left to right direction.)
CE2 (
) can move right automatically. It changes to CE3 when it touches the horizontal tube at the left side. It changes also to CE1 when it touches any other element.
CE3 (
) is walkable from left. It changes to extended change target
(replace when destructible) when it is entered by the player.
Here is an example in action:
When pushed, CE1 is replaced by CE2, that moves right until it hits the tube.
Now, CE2 is replaced by CE3.
CE3 can now be entered by the player from its left side:
(CE3 is under the player)
CE3 changes now to its extended change target, and therefore the tube is replaced:
Since CE2 can move right, it moves if there is nothing to its right side.
That's almost what I need. But there are several problems.
1. Although that method seems to work well in the example above, consider this situation:
CE1 cannot be pushed from its left side, because there is something beneath it. IMO, that's a limitation in the game engine. An element should be pushable and replace another element, exactly like when it can dig an element.
2. CE3 must be entered instead of pushed to move and replace the tube. I did that this way because if I define it as pushable from the left, it cannot be pushed because there is another element to its right side. (Again, I'm blocked by the RnD limitation.)
Also, if I use the "pressed from the left" condition (or "switched" - BTW, what's the difference?) the player doesn't have to move to the right, if the player presses CE3 during a short time. That's unacceptable in XOR.
OK, the method works, but it is visually strange, as the replacement of the tube by CE1 takes place abruptly.
3. CE3 must also be pushable from the top or bottom, and should behave exactly like CE1 in those conditions. OK, I could add a change page so that CE3 is replaced by CE1 when it is pressed, but if the user presses it shortly, then CE1 replaces CE3 for ever, and the user can not enter it from its left side any more. We are back to the problem 1.
Programming CE3 so that it behaves like CE1 when it is pressed from the top or bottom side is probably possible, but that's even more complex to do.
4. When there is something beneath the tube, like in this example,
when the player enters CE3, it is replaced by CE2 that can move to the right automatically:
Now, if the player takes the diamond, CE2 moves to the right. However, when the dolly is stopped by the presence of another element, it should move again only when it is pushed again by the player.
It is perhaps possible to test if CE2 touches another element and change it automatically back to CE1 in this case, but I am unable to program that. Maybe it's because the scan occurs in reverse order. (See next post for more info on this problem.)
So, that method doesn't work.
I have tried a totally different method that I'll explain in the next post.
The element is a "dolly". The dolly can move in all directions when pushed by the player, and it must stop when it hits something. That's really easy to do with a pushable CE that can move when pushed. That CE stops when it hits something, as it should. Fine.
But, in XOR, the dolly can also be pushed over the horizontal tube (when pushed horizontally) or over the vertical tube (when pushed vertically.) When it is pushed over a tube, the tube disappears and is replaced by the dolly. If there is something else (including another tube) beneath the tube, the dolly stops immediately. Otherwise, it should continue to move in the same direction until it hits something. Of course, the player must follow the dolly when he pushes it. Here is an example, where the dolly is
1. Starting position:
2. After the player has pushed the dolly to the right, over the tube:
3. Now, since there is nothing to the right side of the dolly, it continues to move to the right:
Unfortunately, in RnD, it is impossible to push an element over another one, even if the target element is diggable by the source element.
So, I have tried to define the dolly as not pushable and immobile, and to replace it by another CE that moves when it is pressed. That method turned out to be relatively difficult, as I have to program each direction independently. But, more importantly, that doesn't work neither, because, IMO, there are some important limitations in the RnD engine.
Here is finally what I did. (The numbers are the CEs.)
The dolly (
) is pushable, and changes to CE2 when pushed by the player at left size. (It changes also to other CEs when pushed in the other directions, but for clarity I explain here only the left to right direction.)CE2 (
) can move right automatically. It changes to CE3 when it touches the horizontal tube at the left side. It changes also to CE1 when it touches any other element.CE3 (
) is walkable from left. It changes to extended change target(replace when destructible) when it is entered by the player.
Here is an example in action:
When pushed, CE1 is replaced by CE2, that moves right until it hits the tube.
Now, CE2 is replaced by CE3.
CE3 can now be entered by the player from its left side:
(CE3 is under the player)
CE3 changes now to its extended change target, and therefore the tube is replaced:
Since CE2 can move right, it moves if there is nothing to its right side.
That's almost what I need. But there are several problems.
1. Although that method seems to work well in the example above, consider this situation:
CE1 cannot be pushed from its left side, because there is something beneath it. IMO, that's a limitation in the game engine. An element should be pushable and replace another element, exactly like when it can dig an element.
2. CE3 must be entered instead of pushed to move and replace the tube. I did that this way because if I define it as pushable from the left, it cannot be pushed because there is another element to its right side. (Again, I'm blocked by the RnD limitation.)
Also, if I use the "pressed from the left" condition (or "switched" - BTW, what's the difference?) the player doesn't have to move to the right, if the player presses CE3 during a short time. That's unacceptable in XOR.
OK, the method works, but it is visually strange, as the replacement of the tube by CE1 takes place abruptly.
3. CE3 must also be pushable from the top or bottom, and should behave exactly like CE1 in those conditions. OK, I could add a change page so that CE3 is replaced by CE1 when it is pressed, but if the user presses it shortly, then CE1 replaces CE3 for ever, and the user can not enter it from its left side any more. We are back to the problem 1.
Programming CE3 so that it behaves like CE1 when it is pressed from the top or bottom side is probably possible, but that's even more complex to do.
4. When there is something beneath the tube, like in this example,
when the player enters CE3, it is replaced by CE2 that can move to the right automatically:
Now, if the player takes the diamond, CE2 moves to the right. However, when the dolly is stopped by the presence of another element, it should move again only when it is pushed again by the player.
It is perhaps possible to test if CE2 touches another element and change it automatically back to CE1 in this case, but I am unable to program that. Maybe it's because the scan occurs in reverse order. (See next post for more info on this problem.)
So, that method doesn't work.
I have tried a totally different method that I'll explain in the next post.
In my second method, I have tried to take the problem in the opposite direction. If I can't program the dolly properly, maybe I can program the tube. Unfortunately, there are still serious problems.
The dolly is here extremely simple. It is a CE that is pushable, and can move in any direction when pushed. It has also a change page that changes it to itself after a relatively short delay. (I need that change page to force the engine to recompute the interactions between the elements. You will understand why later.)
However, I need also 4 other CEs to represent the dolly then it touches the tubes, one for each direction.
On the other hand, the tubes are more complex. Again, I will explain the logic for the right to left moves of the dolly only.
The horizontal tube is a CE that changes to extended change target
(replace when destructible) when it is touching the dolly at the right side.
The arrow is one of the four dolly CEs. It is similar to CE3 in the previous method. That it, it can be entered from its left side, and replaces the tube in this case.
So, in this example, everything works well:
When the player pushes the dolly to the left, it moves until it hits the tube, where it stops. The tube is then changed to its extended change target. So, the situation is now:
The player can enter the dolly, and produce:
That's fine.
To be sure that the dollies are always converted to the arrows when necessary, I've added the change page in the tube to force the engine to recompute everything at regular intervals. That works fine.
But there are still many problems. Some of the problems of the previous method are still present with this method. For example, I still need to enter the dolly instead of push it. But there are even more problems.
For example:
Here, both dollies must be converted like that:
Well, it's still possible, but it takes two cycles to refresh everything. Not a big deal.
But consider this situation:
Here, the dolly should be converted to the CE because it touches the horizontal tube AND to the down arrow (i can't find its sketch representation!) because it touches the vertical tube too. So, I have to convert it to another CE that can be used in the two situations. That's probably possible, but I haven't tried that yet, as the complexity is exponential. Take in mind that I need a different CE for each possible combination! There are a lot of them.
And I'm even not sure that it is possible to do that. For example, during the scan (in reverse mode) the vertical tube will be encountered first. It will therefore change the dolly to the down arrow. But when the horizontal tube is reached by the scan, it will do nothing, as it's not the normal dolly CE that touches it. So, I have to program the tube to take all incarnations of the dolly into account. That cannot be done with a GE, as I have to check exactly which dolly CE touches the tube to replace it with the right element. For instance, in my example, the right arrow CE must be replaced by a CE that can be entered from the top AND the left side, and I have to know from which side it has been entered by the player to program the change pages correctly.
I have tried to do that, but it's incredibly complex, and I have almost abandoned that method. Therefore, I'm stuck!
Someone has a simple, clear and brilliant idea to solve all problems magically?
The dolly is here extremely simple. It is a CE that is pushable, and can move in any direction when pushed. It has also a change page that changes it to itself after a relatively short delay. (I need that change page to force the engine to recompute the interactions between the elements. You will understand why later.)
However, I need also 4 other CEs to represent the dolly then it touches the tubes, one for each direction.
On the other hand, the tubes are more complex. Again, I will explain the logic for the right to left moves of the dolly only.
The horizontal tube is a CE that changes to extended change target
(replace when destructible) when it is touching the dolly at the right side.
The arrow is one of the four dolly CEs. It is similar to CE3 in the previous method. That it, it can be entered from its left side, and replaces the tube in this case.
So, in this example, everything works well:
When the player pushes the dolly to the left, it moves until it hits the tube, where it stops. The tube is then changed to its extended change target. So, the situation is now:
The player can enter the dolly, and produce:
That's fine.
To be sure that the dollies are always converted to the arrows when necessary, I've added the change page in the tube to force the engine to recompute everything at regular intervals. That works fine.
But there are still many problems. Some of the problems of the previous method are still present with this method. For example, I still need to enter the dolly instead of push it. But there are even more problems.
For example:
Here, both dollies must be converted like that:
Well, it's still possible, but it takes two cycles to refresh everything. Not a big deal.
But consider this situation:
Here, the dolly should be converted to the
CE because it touches the horizontal tube AND to the down arrow (i can't find its sketch representation!) because it touches the vertical tube too. So, I have to convert it to another CE that can be used in the two situations. That's probably possible, but I haven't tried that yet, as the complexity is exponential. Take in mind that I need a different CE for each possible combination! There are a lot of them. And I'm even not sure that it is possible to do that. For example, during the scan (in reverse mode) the vertical tube will be encountered first. It will therefore change the dolly to the down arrow. But when the horizontal tube is reached by the scan, it will do nothing, as it's not the normal dolly CE that touches it. So, I have to program the tube to take all incarnations of the dolly into account. That cannot be done with a GE, as I have to check exactly which dolly CE touches the tube to replace it with the right element. For instance, in my example, the right arrow CE must be replaced by a CE that can be entered from the top AND the left side, and I have to know from which side it has been entered by the player to program the change pages correctly.
I have tried to do that, but it's incredibly complex, and I have almost abandoned that method. Therefore, I'm stuck!
Someone has a simple, clear and brilliant idea to solve all problems magically?
Thanks for the proposition. But wait a bit before beginning! I've just noticed that in the relatively recent clone of XOR for Windows, the dollies cannot "dig" the tubes when they are pushed. That's considerably easier to program! In fact, that the easiest solution, where I need only one pushable CE that can move in any direction when pushed, and that stops when hitting anything. Dot.Francesco wrote:I could dig the problem a bit, but I cannot promise about.
But the Windows version of XOR is really bad, and I'm not sure all levels are playable. I will try that, and see if it's sufficient. If that works, there is no need to worry!
I will report my findings here later...
Hey r0lz,
It's very interesting to see your attempts, but now I think we're making things way to complicated. Could you please explain with pictures how it SHOULD work (as in XOR?). I have an idea for a solution, but I'd like to see an example of how it SHOULD work to see if my solution can work.
There is only graphics for left-and-right arrows of the text-type. for all 4 directions, try these:
(Level sketch codes 113-116)
Many thanks for the RnD Scripter feedback, even more is appreciated
I have built a script for checking which CEs that are used and so on (to find out if it's possible to delete anyones), I'll see if I can find it.
It's very interesting to see your attempts, but now I think we're making things way to complicated. Could you please explain with pictures how it SHOULD work (as in XOR?). I have an idea for a solution, but I'd like to see an example of how it SHOULD work to see if my solution can work.
There is only graphics for left-and-right arrows of the text-type. for all 4 directions, try these:
(Level sketch codes 113-116)
I'm not sure which program you're talking about here, but I guess it's Level Sketch 2 or Rocks'n'Diamonds. But I don't think RnD itself can convert level sketch -> .level file. Level Sketch 2 however, can do so. And RnD Scripter can do so as well - if you write the script for it.Aunty_Spam wrote:Yes you can save level sketches to basic RnD levels. It also extracts sketches from html source (off the forum). It wasn't written by Zomis btw
Many thanks for the RnD Scripter feedback, even more is appreciated
I have built a script for checking which CEs that are used and so on (to find out if it's possible to delete anyones), I'll see if I can find it.
-
Aunty_Spam
- Posts: 7
- Joined: Mon Oct 22, 2007 10:33 pm
I've made elements that can move over others when pushed (and leave behind the tube). Not sure about Xor's rules and such, but this should help you get started.
http://www.zomis.net/rnd/download.php?id=693
This lets you push a dolly through a horizontal or vetical tube (and the tube can be any length). I only made this very quickly since I'm a bit short for time (sorry!), the only bug in it is:- if the tube is blocked the dolly breaks. It isn't hard to fix and I'm sure you'll crack it.
*edit*
I've made a mistake, but only a graphic one! The CE "Vertcal tube - diggable" should use the graphics of the blue vertical tube, not the horizontal one.
http://www.zomis.net/rnd/download.php?id=693
This lets you push a dolly through a horizontal or vetical tube (and the tube can be any length). I only made this very quickly since I'm a bit short for time (sorry!), the only bug in it is:- if the tube is blocked the dolly breaks. It isn't hard to fix and I'm sure you'll crack it.
*edit*
I've made a mistake, but only a graphic one! The CE "Vertcal tube - diggable" should use the graphics of the blue vertical tube, not the horizontal one.
A bit off topic eh?Many thanks for the RnD Scripter feedback, even more is appreciated
I have built a script for checking which CEs that are used and so on (to find out if it's possible to delete anyones), I'll see if I can find it.
Silence is golden, ducttape is silver.
>I've made elements that can move over others when pushed (and leave
>behind the tube). Not sure about Xor's rules and such, but this should
>help you get started.
>http://www.zomis.net/rnd/download.php?id=693
>This lets you push a dolly through a horizontal or vetical tube (and the
>tube can be any length). I only made this very quickly since I'm a bit
>short for time (sorry!), the only bug in it is:- if the tube is blocked the
>dolly breaks. It isn't hard to fix and I'm sure you'll crack it.
The biggest problem I see with this approach is that you actually have to push first and then walk. I guess r0lz is looking for a technique to walk next to the object while pushing it. And then there's problems.
>A bit off topic eh?
Yep. Correct. Sorry about that.
>behind the tube). Not sure about Xor's rules and such, but this should
>help you get started.
>http://www.zomis.net/rnd/download.php?id=693
>This lets you push a dolly through a horizontal or vetical tube (and the
>tube can be any length). I only made this very quickly since I'm a bit
>short for time (sorry!), the only bug in it is:- if the tube is blocked the
>dolly breaks. It isn't hard to fix and I'm sure you'll crack it.
The biggest problem I see with this approach is that you actually have to push first and then walk. I guess r0lz is looking for a technique to walk next to the object while pushing it. And then there's problems.
>A bit off topic eh?
Yep. Correct. Sorry about that.
Well, I've tried to explain that at the beginning of the first post about the dolly:Zomis wrote:Could you please explain with pictures how it SHOULD work (as in XOR?). I have an idea for a solution, but I'd like to see an example of how it SHOULD work to see if my solution can work.
So, to summarizes, the dolly moves freely in one direction when it has been pushed to that direction. It stops when it hits something. It can also be pushed "in" a tube, and replaces it. When it has replaced the tube, it continues to move in the same direction if there is nothing else beneath the tube. Otherwise, it stops.The element is a "dolly". The dolly can move in all directions when pushed by the player, and it must stop when it hits something.
[...] the dolly can also be pushed over the horizontal tube (when pushed horizontally) or over the vertical tube (when pushed vertically.) When it is pushed over a tube, the tube disappears and is replaced by the dolly. If there is something else (including another tube) beneath the tube, the dolly stops immediately. Otherwise, it should continue to move in the same direction until it hits something. Of course, the player must follow the dolly when he pushes it. Here is an example, where the dolly is
1. Starting position:
2. After the player has pushed the dolly to the right, over the tube:
3. Now, since there is nothing to the right side of the dolly, it continues to move to the right:
And yes, the player must follow the dolly when he pushes it. This is probably important, as XOR is a game of logic, and if the player can push the dolly without moving, some caves may become too easy. But again, I'm not sure that's so important. I need to play all levels (and that's not really easy) to be sure...
Thanks for the thanks about your scripter!
I agree that this threat id becoming more and more out of topic, and IMO the original subject of the thread needs to be changed. I did it.
Well, I have had a quick look at your level. I haven't analysed how you did it yet, but I can guess the basic principle. However, it's not exactly what I need. To explain the differences, here is an example:
When the player pushes the top dolly to the right, the dolly must move freely until it hits the wall. Also, the player should move during the push operation. Therefore, after one keyperss to the right, the situation should be:
Now, the player can move above the dolly and push it to the bottom. Again, the player should replace the dolly when he pushes it, and the dolly should fall down and stop when it hits the vertical tube, like that:
At this time, the player moves above the dolly, and pushes it to the bottom.
The dolly should smash the tube, that disappears completely, and since there is nothing below it, it can fall down freely until it hits the horizontal tube. So, after only one press of the down key, the situation should be:
The dolly cannot be pushed any more to the bottom, because the tube is horizontal. It cannot be pushed neither up, because the player cannot move below it. But it can be pressed to the right or the left. It should then move freely until it hits the external border of the board.
Now, let's see the horizontal tube.
When the dolly is pressed to the left, it moves to the left until it hits the first non-empty element. Again, the player must move during the push:
If the player pushes it again, it should be replaced by the player, and it should replace definitively the first tube element, like that:
That can be repeated until this position is reached:
At this time, if the user pushes the dolly again, it destroys the last tube, but doesn't stop since there is nothing to stop it at the right side of the tube. The final position is therefore:
I think you will find that largely more complicated than what you did.
The important difficulty with this element is that it behaves completely differently when there is a tube beneath it, or nothing. In the first case, your solution, a little bit modified, should work. In the second case, a simple dolly that is pushable and that can move in any direction when pushed works well. The difficulty is to mix the two solutions together, so that the correct one is used when it is needed.
Also, in your solution, I guess you have used presses instead of pushes. I have tried that too, and it's more flexible, but the drawbacks are that the player doesn't have to move when he pushes the dolly, and that there is no "press delay". I guess it is possible to force the player to move if the dolly leaves behind a "tail" made of the player element. But this tail must be created only when the dolly is pressed, and not when it moves freely, as the user must not follow the dolly in this case.
I did something similar with success, using an extended change target, but the player moves abruptly as soon as he presses the element, due to the absence of a press delay, and because the animation of the player pushing the element is totally skipped. It's something I would like to avoid, as normally, the dolly must be pressed during some time before it moves. That's visually more elegant and, more importantly, the push delay is necessary so that the user cannot push the dolly by mistake just because the player kept the key pressed a little bit too long. But if it's not possible, the "press" solution is acceptable.
Thanks anyway for your help!
When the player pushes the top dolly to the right, the dolly must move freely until it hits the wall. Also, the player should move during the push operation. Therefore, after one keyperss to the right, the situation should be:
Now, the player can move above the dolly and push it to the bottom. Again, the player should replace the dolly when he pushes it, and the dolly should fall down and stop when it hits the vertical tube, like that:
At this time, the player moves above the dolly, and pushes it to the bottom.
The dolly should smash the tube, that disappears completely, and since there is nothing below it, it can fall down freely until it hits the horizontal tube. So, after only one press of the down key, the situation should be:
The dolly cannot be pushed any more to the bottom, because the tube is horizontal. It cannot be pushed neither up, because the player cannot move below it. But it can be pressed to the right or the left. It should then move freely until it hits the external border of the board.
Now, let's see the horizontal tube.
When the dolly is pressed to the left, it moves to the left until it hits the first non-empty element. Again, the player must move during the push:
If the player pushes it again, it should be replaced by the player, and it should replace definitively the first tube element, like that:
That can be repeated until this position is reached:
At this time, if the user pushes the dolly again, it destroys the last tube, but doesn't stop since there is nothing to stop it at the right side of the tube. The final position is therefore:
I think you will find that largely more complicated than what you did.
The important difficulty with this element is that it behaves completely differently when there is a tube beneath it, or nothing. In the first case, your solution, a little bit modified, should work. In the second case, a simple dolly that is pushable and that can move in any direction when pushed works well. The difficulty is to mix the two solutions together, so that the correct one is used when it is needed.
Also, in your solution, I guess you have used presses instead of pushes. I have tried that too, and it's more flexible, but the drawbacks are that the player doesn't have to move when he pushes the dolly, and that there is no "press delay". I guess it is possible to force the player to move if the dolly leaves behind a "tail" made of the player element. But this tail must be created only when the dolly is pressed, and not when it moves freely, as the user must not follow the dolly in this case.
I did something similar with success, using an extended change target, but the player moves abruptly as soon as he presses the element, due to the absence of a press delay, and because the animation of the player pushing the element is totally skipped. It's something I would like to avoid, as normally, the dolly must be pressed during some time before it moves. That's visually more elegant and, more importantly, the push delay is necessary so that the user cannot push the dolly by mistake just because the player kept the key pressed a little bit too long. But if it's not possible, the "press" solution is acceptable.
Thanks anyway for your help!
I followed your attempts to emulate the XOR engine with great interest!
As I can see, solving the "dolly and tube" elements in the R'n'D engine is not easy, and may be very tricky to do, because it is not possible to push one element over another in the R'n'D engine.
But it is possible to let one CE dig/collect/destroy another CE while moving (like a Pac Man that is moving and that is eating all pills that come to its way).
Therefore, if a CE is configured to be able to "dig" a specified element when moving, it seems logical to also allow this "digging action" when the CE is not moving by itself, but when it is pushed by the player. I've extended the game engine accordingly, and it seems to work fine.
Still, the "dolly and tube(s)" scenario needs some further tweaking, as the dolly cannot only be pushed, but it also can move when pushing, but is not allowed to dig those elements (tube) that it is allowed to dig when being pushed. As it seems, this can be accomplished by changing the dolly CE to itself when it hits something, which stops the movement action that was triggered by being pushed by the player before.
So far it looks as if this dolly, build by a single CE, works fine (in conjunction with another CE that builds the tube and that can be digged by the dolly CE).
I will try to provide you with a beta/test version of R'n'D with this extended game engine very soon (by posting a download link in this forum)!
As I can see, solving the "dolly and tube" elements in the R'n'D engine is not easy, and may be very tricky to do, because it is not possible to push one element over another in the R'n'D engine.
But it is possible to let one CE dig/collect/destroy another CE while moving (like a Pac Man that is moving and that is eating all pills that come to its way).
Therefore, if a CE is configured to be able to "dig" a specified element when moving, it seems logical to also allow this "digging action" when the CE is not moving by itself, but when it is pushed by the player. I've extended the game engine accordingly, and it seems to work fine.
Still, the "dolly and tube(s)" scenario needs some further tweaking, as the dolly cannot only be pushed, but it also can move when pushing, but is not allowed to dig those elements (tube) that it is allowed to dig when being pushed. As it seems, this can be accomplished by changing the dolly CE to itself when it hits something, which stops the movement action that was triggered by being pushed by the player before.
So far it looks as if this dolly, build by a single CE, works fine (in conjunction with another CE that builds the tube and that can be digged by the dolly CE).
I will try to provide you with a beta/test version of R'n'D with this extended game engine very soon (by posting a download link in this forum)!
Great news! I can't wait for the beta! A million thanks for your effort!
I've just posted a note in a bug report thread about my need of a new condition similar to "pushed by player" but seems I will have a better solution soon!
However, let me explain why a new condition could be useful.
If you define a pushable CE, that CE cannot interpret the "pressed" condition, because an element cannot be pressed and pushed at the same time. That's normal. But there are situations where the pushable CE is blocked by another element, and therefore cannot be pushed. In that condition, it is currently impossible to know if the player is trying to push it anyway. In some circumstances, it might be necessary to receive a signal saying that the user pushes the element, but that the push is unsuccessful. Indeed, I needed that also for XOR so that the rocks, zeppelins and bombs can be pushed in the tubes. I have managed to simulate that with the "pressed by player" condition. That's considerably simpler to do than for the dolly, because those elements can move freely only in one direction, and they dig the tubes immediately, without stopping first. But the result is not as good as it could, as the presses behave differently than the pushes, especially because there is no "press delay" and because the player stays at its original position. I've found a solution for those problems, but the gameplay is ugly.
I had the intention to ask you to be able to receive the "pressed" condition when the user tries to push a pushable element that is blocked by something, but that could perhaps cause some compatibility issues with old levels (although, normally, the "pressed by player" condition is useless when the CE is defined as pushable, and therefore should not be used.) Anyway, I think that a new condition like "unsuccessfully pressed by player" or whatever you like to name it could be useful.
Of course, with your new method, it should be possible to push the elements everywhere where they are pushable, including in the tubes, but I can imagine several situations where that new condition could be useful, even if I don't need it anymore for XOR, thanks to your new modification.
I've just posted a note in a bug report thread about my need of a new condition similar to "pushed by player" but seems I will have a better solution soon!
However, let me explain why a new condition could be useful.
If you define a pushable CE, that CE cannot interpret the "pressed" condition, because an element cannot be pressed and pushed at the same time. That's normal. But there are situations where the pushable CE is blocked by another element, and therefore cannot be pushed. In that condition, it is currently impossible to know if the player is trying to push it anyway. In some circumstances, it might be necessary to receive a signal saying that the user pushes the element, but that the push is unsuccessful. Indeed, I needed that also for XOR so that the rocks, zeppelins and bombs can be pushed in the tubes. I have managed to simulate that with the "pressed by player" condition. That's considerably simpler to do than for the dolly, because those elements can move freely only in one direction, and they dig the tubes immediately, without stopping first. But the result is not as good as it could, as the presses behave differently than the pushes, especially because there is no "press delay" and because the player stays at its original position. I've found a solution for those problems, but the gameplay is ugly.
I had the intention to ask you to be able to receive the "pressed" condition when the user tries to push a pushable element that is blocked by something, but that could perhaps cause some compatibility issues with old levels (although, normally, the "pressed by player" condition is useless when the CE is defined as pushable, and therefore should not be used.) Anyway, I think that a new condition like "unsuccessfully pressed by player" or whatever you like to name it could be useful.
Of course, with your new method, it should be possible to push the elements everywhere where they are pushable, including in the tubes, but I can imagine several situations where that new condition could be useful, even if I don't need it anymore for XOR, thanks to your new modification.
> I will try to provide you with a beta/test version of R'n'D with this extended game engine very soon
OK, have a look at this:
http://www.artsoft.org/RELEASES/win32/r ... 071030.zip
(Just copy the *.exe and the additional *.pcx file to their appropriate locations in the game's installation directory.)
OK, have a look at this:
http://www.artsoft.org/RELEASES/win32/r ... 071030.zip
(Just copy the *.exe and the additional *.pcx file to their appropriate locations in the game's installation directory.)