Trying to develop XOR for RnD

[Zomis]

OK. thanks. With your pointers, I should be able to write the converter.

BTW, is it possible to load the levelsketch format (*.lsk files) directly in R'n'D?

The code for loading and saving is a bit painful to learn, however. Since you only need to save RnD files, and not load RnD files (and especially, not all old kinds of RnD files), you save a lot of work.

Once you get the hang of the different chunks, and learn the different microchunks for CE elements (and maybe also for other chunks as well), it's a bit easier. A look or two in files.c is what you need.

As an alternative, you can use RnD Scripter (Beta 3, but fully functional so it should actually be a release candidate), which also is capable of setting up CEs just as you want them and save it to an RnD file (It's compatible with RnD 3.2.0 or something... don't exactly remember). See http://www.zomis.net/rnd/rndce/ if you're interested.

I don't think I really understand all your other problems with the CEs, example levels would be really good. Or maybe I'm just confused.

[r0lZ]

I will have a look at the scripter. It might be easier to use than the GUI to do complex worlds.

Don't worry too much about my previous posts. With your help, I have solved almost all problems. However, I have noticed a new problem for something that worked before. I don't understand why that doesn't work any more. Currently, I try to reorganize the CEs in a more elegant way. Maybe I forgot to change a referenced element. I will still try to solve that problem myself, and, if necessary, I will prepare a demo level for you.

[r0lZ]

I'm still stuck with an important problem.

The falling rocks (reprogrammed) and the zeppelins (now spaceships) should kill the player when they fall on him, but I cannot program the CE of those elements properly, as it seems that the player is not taken into account in the "hitting element [player]" condition. Is it a known limitation or bug? Do you know a walkaround?


I have also some minor troubles with the two players (using a slightly modified SwapChars method.) But I haven't really tried to find a solution to those problems yet.

When the real player is killed by something, the fake player should be replaced automatically by the real player. How could I do that? I haven't found a "when player dies" condition.

On the other hand, when the fake player is killed, the real player stays frozen, because the CE actions to freeze the real player when something is moving is in the fake player CE, and it is destroyed. I can probably replace the dead fake player by another CE with the speed control actions only, but I don't like that solution too much, because if the CE is hidden and walkable, it constitutes an invisible obstacle to the moving elements, and it it is visible, that's not the normal behavior of XOR. Furthermore, it has to be indestructible.

It is probably acceptable to kill also the other player when one of them is killed, as it's programmed in the original SwapChars level, but normally, in XOR, only one player must escape to complete the level.

You can download a simple demo level here. I have added 4 envelopes to explain what to do to check the problems.

If you want to edit the level, note that the elements normally placed directly in the playfield are the yellow player, the empty space, the steel exit and the first 16 CEs. The other CEs are never used directly. Two control CEs (the "!" and the player outline) and the fake (green) player must normally be present in each level.

[r0lZ]

I have now converted 33 original XOR levels, and I have played some of them in R'n'D. Let me know if you want them (but most of them are still not playable.)

I have still the big "hitting element [player]" problem explained above. Someone can confirm the limitation or bug? If I can't find a solution, I will be forced to abandon.
IMO, the player should be considered exactly like all other elements, and should be detected.


I have also another problem that I haven't thought at before. For example, in this situation:



when the player pushes the top spaceship (zeppelin) in the vertical tube, the tube disappears, and the pushed zeppelin should replace it. But the zeppelin at the right moves to the left as soon as the tube disappears, and it is not possible to complete the level.

The result should be:



but it is currently:




Currently, the spaceship (CE1) is replaced by another spaceship (CE2) when it is pressed by the player at the top or bottom side. The tube CE has a condition that detects if it is touched by the spaceship CE2 at the top or bottom side, and it is changed to the empty space if the condition is true. Since the spaceship CE2 is pushable, it should move in the new empty space. Some frames later, the spaceship CE2 is replaced again by the CE1.

Is it another solution?
Is it possible to define something so that an element (here the spaceship) can be pushed in or over another element (the tube)?

I think that it should be possible to replace all spaceships except the one that is pressed by a static element, during some frames, to leave enough time for the user to push the spaceship. How can I archive that easily?

Let me know if you want a demo level.

[Zomis]

I've probably forgot one or more of your ideas, so let me know if I've forgot something.

Change when player dies:
Use the "Explosion of <player 1>" change condition.

Hitting element <player>:
Seems to not work as expected. Seems to be a limitation in the engine, I agree with you that this should be possible. And I have only one name to say: Holger!

I think that it should be possible to replace all spaceships except the one that is pressed by a static element, during some frames, to leave enough time for the user to push the spaceship. How can I archive that easily?

Well, I thought it would be possible using another approach (with the "Can dig" setting on Config page 2), but I didn't succeed (it fails when the CE is next to the thing it should dig, as in your example). But thanks to that thought of yours, it probably would work if you use: (Let CE1 be the pushable element)
CE1 changes to <whatever> when pressed by player
CE1 changes to CE2 when player presses element <CE1>
CE2 changes to CE1 after delay x frames

This will change the CE1 you press to <whatever> when you press it. While all other CE1s are changed to CE2, and CE2 is changed to CE1 after a delay for some frames. I hope that will work for you.

Did I forgot anything??

[r0lZ]

Thanks for the confirmation about the bug. I will report it in the Bugs forum.

I have just checked my method to solve the previous problem, and it works fine. However, there are many CEs in the game, and it is not obvious to build all interactions. When I change something in the current logic, there is always a risk that something doesn't work any more. I will test if everything works fine now.

Using a similar logic, I will try to kill the player when the rock is falling or when the spaceship is running to the left by replacing those elements by a CE that is deadly then touched. But I think they will kill the player if they pass just along him, and unfortunately that's not acceptable.

I'm not sure you have answered all my questions, but anyway, I continue to develop the logic, and some of the problems reported here have been solved. I will certainly post here later when I will need some more help.

I have also tried your scripter. Nice work! I think it might be really useful in many situations, but I haven't used it yet.

BTW, to convert the XOR levels, I have written a little Tcl script to build the BODY part of the level, and I have replaced it (as well as the level title and the number of jems) directly in a template level. Since all XOR levels have the same dimensions, that was the easiest method.

[Zomis]

Using a similar logic, I will try to kill the player when the rock is falling or when the spaceship is running to the left by replacing those elements by a CE that is deadly then touched. But I think they will kill the player if they pass just along him, and unfortunately that's not acceptable.

Try using the "deadly when colliding with" option (just change the dropdown list from "touching" to "colliding with".)

I have also tried your scripter. Nice work! I think it might be really useful in many situations, but I haven't used it yet.

Thank you very much I've received very few comments about the scripter, so I appreciete every feedback I get The more feedback I get, the more motivated I will be to keep working on it. (I still have much work to do, better documentation and better user interface, and an update so it supports new RnD options, etc.).

BTW, to convert the XOR levels, I have written a little Tcl script to build the BODY part of the level, and I have replaced it (as well as the level title and the number of jems) directly in a template level. Since all XOR levels have the same dimensions, that was the easiest method.

It indeed sounds easiest. Then to make the CEs you can use CE templates, or simply copy some hexadecimal code in the level files (the method I've used when wanting to copy CEs from one level to many others, or I've made it a script for RnD Scripter of course...)

[r0lZ]

Using a similar logic, I will try to kill the player when the rock is falling or when the spaceship is running to the left by replacing those elements by a CE that is deadly then touched. But I think they will kill the player if they pass just along him, and unfortunately that's not acceptable.

Try using the "deadly when colliding with" option (just change the dropdown list from "touching" to "colliding with".)

I've already tried that, but that doesn't work neither. It seems that "colliding with" means that the player must collide with the element. In my case, it's the opposite.
I'm almost sure now that it's a dead end, until Holger fixes the bug.

Oh, also, currently, checking if the player is hit by something in a specific way (for example at a specific side) is not possible. You have to check if something hits the player. It's harder to do (and currently impossible with this nasty bug.) I think that it should be nice to have change pages in the four players like in the CEs. Or it should be possible to copy the player in a CE to modify its standard behaviour. This way, it should be easy to program what I need in the reverse way. But it's probably not easy to do, and I guess Holger has many other things in his todo list!

I have also tried your scripter. Nice work! I think it might be really useful in many situations, but I haven't used it yet.

Thank you very much I've received very few comments about the scripter, so I appreciete every feedback I get The more feedback I get, the more motivated I will be to keep working on it. (I still have much work to do, better documentation and better user interface, and an update so it supports new RnD options, etc.).

I know what you mean! It is very difficult to have some success with programming tools like your scripter. (BTW, I'm the author of PgcEdit, a tool to edit and reprogram the DVD-Video logic. It's the opposite of a "one-click backup solution" and very few ppl are able to understand it! But the guys who have learned how to use it become usually fanatic! I guess that in some time, your tool will be much appreciated by a group of connoisseurs.)
BTW, one remark. In your 4 example scripts available on the net, can you add a comment or a readme to explain what they do?

[r0lZ]

I have solved many problems now, but unfortunately I've just found a new one.

Remember. At the beginning of this thread, I was stuck with this situation, because when the player takes the gem and then moves down, the rock was falling to his head. It was necessary to move the zeppelin first so that the rock was not falling any more.



The solution was to use the reverse scan mode. That works as expected in this example. Unfortunately, in other cases, that doesn't work.

For example:



In this case, when the player takes the diamond and moves up, in XOR, here is what happens:

1. Starting position. The zeppelin to the right of the empty space can now move left.




2. The zeppelin has moved. The zeppelin that is now to the right of the empty space can move left.




3. The rock prevents the zeppelin to its right to kill the player.



The player can now move up, and then push down the zeppelin to the right of the rock, and take the last diamond safely.

But, when reverse scan mode is activated in R'n'D, here is what happens:

1. Starting position. The zeppelin to the right of the empty space can now move left.




2. The zeppelin has moved. Good. The second zeppelin should move now, but...




3. Here is the problem!



The zeppelin doesn't move and the rock falls in the empty space.
Therefore, the zeppelin at the top is now free to move, and it kills the player.

However, as you can see in step 2, the situation is almost identical than in the first example in this post. The zeppelin should therefore move before the rock. I guess that it doesn't move because the evaluation of the events continues from right to left and then from bottom to top, and reaches the rock before the second zeppelin.

Note that using normal scan mode works fine! But since I cannot guess what scan mode I need before starting an action, I cannot toggle it when needed. Anyway, it is probably very difficult to do that correctly. And I've read in another thread that the scan is always completed, and if it has been toggled, the toggle happens only during the next full screen scan.

Seems that in XOR, the order of the events is not based on the L/R and D/U directions, but rather on the type of the elements. The zeppelins move always first when they can.

I have envisaged two solutions to this problem.

1. When something moves, the game should pause at least during 30 frames so that a new scan of the entire screen happens. Unfortunately, if I do that, the logic that freezes the player during the moves will not work any more. Furthermore, the game will be very slow! Also, I think that that will not work if an element has a long way to do before being stopped. During its movement, the other elements will start to move. And I'm even not sure it's possible to do!

3. I could block all rocks when a zeppelin starts moving during a very short moment (1 frame?) Maybe it's sufficient to force all zeppelins to move before the rocks. Honestly, I haven't tried that yet, mainly because I don't know how to do that.

Ideally, the scan mode should be from left to right and bottom to top. I think (although I'm not sure) that that could work in all situations. But as far as I know, this combination is not possible.

Any idea?

This level demonstrates the problem.

[Aunty_Spam]

What if the spaceship left behind a CE. This CE is diggable only by other spaceships, and turns to space after 8 frames (maybe 1 frame is enough). This should block any boulders and give the spaceships priority.

Spaceship leaves behind CE1




The boulder can't pass it, but other spaceships can dig it




Here's one with no spaceships to the right to dig the CE




Which then turns to space after 8 frames letting the boulder pass




When its all working (if it does work) make the CE black.

[r0lZ]

Interesting idea! I will try it immediately.

I had also another idea, but less easy to implement. Since, in XOR, there are only spaceships running from right to left (and no automatic elements running in the opposite direction) I can probably invert everything, and change the spaceship element so that it runs from left to right. Mirroring the original XOR levels when they are converted is easy. This way, the inverse scan mode should be exactly what I need.

But I will try your idea first. It's less work! Thanks!

[Zomis]

I've also got another idea, similar to the problem you had for disabling user input for a while, until all movements is done. I'm not sure how this will work though...

Boulder changes to "frozen boulder" when move of Zeppelin
Frozen Boulder changes to boulder when delay (some) frames.

I'm not sure how that would work if you have



What should the situation be like in this case,


or


?

[Zomis]

I know what you mean! It is very difficult to have some success with programming tools like your scripter. (BTW, I'm the author of PgcEdit, a tool to edit and reprogram the DVD-Video logic. It's the opposite of a "one-click backup solution" and very few ppl are able to understand it! But the guys who have learned how to use it become usually fanatic! I guess that in some time, your tool will be much appreciated by a group of connoisseurs.)
BTW, one remark. In your 4 example scripts available on the net, can you add a comment or a readme to explain what they do?

If I were using DVD-video logic much, I might have downloaded your program and used it. But unfortunately, I rarely use DVD-video.

However, yes. I can add a comment or a readme. Wouldn't probably be too hard.
First of all I can say that none of those scripts makes any changes to the levels they're executed on.

And a short description for each of them is:
countels - Scans the level and outputs the number of elements used of the different kinds.
is_sokoban - Scans a level to see if it's made to be Sokoban-style. Also checks if it's possible to be solved by Sokoban rules. Se below "code"

Code: Select all

A standard Sokoban level must follow these rules:
- There can be just one player;
- The number of SB Objects must match the number of SB Fields;
- Only the standard steel wall and the invisible steel wall can be used to build the map;
- There can't be any element other than those mentioned above - no sand, no exit door, no gems, no rocks and so on.

levelsketch - Scans a level and outputs forum levelsketch code for the layout
rndscripter - Includes some functions and constants, most of which are found in the RnD source file 'main.h'

Do you want a more detailed description, about what each part of the script code does?

[r0lZ]

Thanks for your delay idea. I thought at something similar too, but, as you said, it is difficult to control all timings precisely. (BTW, I have still some minor problems related to timings to solve.)

Anyway, Aunty_Spam's idea works flawlessly! (Aunty_Spam, a delay of 1 frame seems to be sufficient.) It turned out to be relatively difficult to implement, as I have many elements that are interacting with each other, but now it works! Thanks to you two!

I have now played the first four levels w/o problem (except that the player isn't killed when he is hit by a rock or a zeppelin because of the nasty bug reported earlier.) I have still some things to do (especially with the "dolly" element that I haven't tested so far) and a first draft should be available.


I think I've found another R'n'D bug. I forgot a "Set scan mode = normal" action somewhere after a test, and that caused some problems. I've finally found and removed it. No problem so far. But the strange thing is that the action checkbox was not ticked! So, it seems that the action is executed even if it is not enabled. The only way to disable it completely is to set it to "No action". No big deal, but that's strange. Maybe removing the checkbox is a good idea.


Thanks for the script comments. And yes, it's sufficient for me. I had understood more or less what your scripts do when I have looked at the code. But anyway, I think a remark at the beginning is good (especially for newbies) so that you haven't to read and understand the code to decide to try it.

I will modify one of your script (probably is_sokoban) to search a levelset for multiplayer levels. That's a feature that is missing in the game GUI. But I'll do that later, as I have enough to do with XOR!

BTW, I had another idea for a script. It should be useful to searches the CEs and GEs for their cross-references. For example, I have now a lot of CEs that I have developed to test various ideas, but that are not used any more. I would like to remove them to clarify the situation. But it is dangerous to delete them without being sure that they are not indirectly used by other elements. Is it possible to do that with the scripter? I suppose so, but honestly I haven't analysed the data structures yet.

Oh, and the opposite of levelsketch would be really nice. I don't know if it is already possible to convert a levelsketch to a standard level (without CEs of course), but your tool might be perfect to do that. And if that idea is possible, it should be also possible to write a script to convert the standard ASCII sokoban format. There are many things to do!

[Aunty_Spam]

Good to hear it worked.

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

Anyway, I've sprinkled enough pixie dust here.