for 1. zl compare 0 0 Sorry, slow brain...

yeah, zl compare in conjunction with [abs] should allow you to test for all these cases.

Thanks, i forgot to mention that x can be positive or negative.

Hum, i guess i just need to multiply both numbers by -1, pack the results, and compare the two lists...

This is pretty brute force, but it works. Best, Jeremy

Thank you very much Jeremy. Unfortunately it doesn't really work. Maybe because you're assuming that x is a positive number ? I've made this with only zl compare, it behaves as expected (never go backwards, never stays unmoved) but from time to time, it draws a double segment. Can't figure out why... need a rest i guess.

Well, a few minutes clicking showed me that my method is also buggy. i guess i just need to leave it until tomorrow. Feel free to take a look though !

how about this one:

Thank you. It does work indeed. As this one (even with 0 0)

So this is not a problem with spotting the unwanted lists. It's a patching problem... So if anyone could look at what's wrong in the 'p chemin' ?

@Andrzej : for some reason, using your approach in my patch leads to even more 'double' (or even triple and quadruple) segments... i'm lost.

my advice: clean up your patches. It's hard to tell what's going on looking at messy patchers. I did some cleanup for you, and look at blue [pack] – you don't filter out wrong coordinates, everything goes to (line) message. If your algorithm detects wrong data it draws next values (X/Yoffset), and they also can be wrong... but everything is drawn on LCD. Forth and back.

Thank you very much... I've come to a totally different approach. This is much clearer. No double segment anymore, but still goes a step backwards from time to time. I now need to find a way to fix it in the 'p segment' : on the random output, i need to avoid 2 when previous was 1, 1 when previous was 2, 4 when previous was 3, 3 when previous was 4.

yet another way [p segment]:

and regarding your last question

Wow, thank you very much ! i really need to learn these logical expressions. It's getting much better. Although my algorithm is not perfect : it still goes backwards from time to time, when after a bang to re-pick a random number, it choses the same again. I think i can live with it, it adds a 'mistake' factor in the maze. Thank you again. louis

When it is the case that the limitations are larger then the (random) possibilities, it might be much easier to describe those possibilities (requiring much less programming). The problem can basically be reduced to: given the previous step, there are either four or five choices for the next step. There is not much required to put this in a probability table. You might want to take a look at the prob object.

for sure i will! thanks for the advice. Amazing how an apparently 'simple' thing can require a lot of knowledge and wisdom. Developing programming skills is a very long process i think.