Help with a visual glitch?

[edderiofer]

http://www.puzzlescript.net/editor.html?hack=06c93da9bf0e24c5dad50b997893e66f

The box slides along the ice, as expected, but then skips over one of the tiles of ice straight onto the button. I can't figure out why this is or should be the case.

[Jamie Perconti]

Hi Edderiofer,

I'm not sure of all the details of how it results in this behavior, but it looks like the general cause is the place where you "shortcut" the movement system. Most of the movement you have is done by marking intentions (>, up, right, etc), but your ice rule skips that and manually repositions blocks before normal movement is executed:

[> block | ice] -> [ | block ice marker] again

as opposed to

[> block | ice] -> [> block | ice marker] again

Switching to the second version seems to resolve the glitch. Here is the complete ruleset I ended up with after playing around with your file. It also simplifies the way you were handling the win condition:

======
RULES
======

[> player | move] -> [> player | > move]

[stopu move] -> [up move]
[stopd move] -> [down move]
[stopl move] -> [left move]
[stopr move] -> [right move]

up [> move | ice] -> [> move | ice stopu] again
down [> move | ice] -> [> move | ice stopd] again
left [> move | ice] -> [> move | ice stopl] again
right [> move | ice] -> [> move | ice stopr] again

==============
WINCONDITIONS
==============

all button on block

Hope this is helpful!

Jamie

,

On Sat, Nov 12, 2016 at 5:50 AM, edderiofer <edder...@gmail.com> wrote:

http://www.puzzlescript.net/editor.html?hack=06c93da9bf0e24c5dad50b997893e66f

The box slides along the ice, as expected, but then skips over one of the tiles of ice straight onto the button. I can't figure out why this is or should be the case.

--
You received this message because you are subscribed to the Google Groups "PuzzleScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puzzlescript+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[edderiofer]

As it is, I experimented a little and found that the cause of the glitch wasn't the ice rule, but the win condition; merely changing the win condition to the way you did it fixed the problem, and merely changing my ice rule to yours didn't.

I have no idea why this should be the case either. Maybe PuzzleScript does all the rules first (and renders the win state if there's a win), then renders the beginning of the turn, and then finally checks for win conditions (and renders the win state if there's a win)? That would be really weird...

To unsubscribe from this group and stop receiving emails from it, send an email to puzzlescript...@googlegroups.com.

[Alan Hazelden]

Could it be because the "win" rule is triggered from an "again" turn?

To unsubscribe from this group and stop receiving emails from it, send an email to puzzlescript+unsubscribe@googlegroups.com.

[edderiofer]

Could very well be? I can't exactly see why this should matter though.

I notice that if, in my original code, I comment out "late [winning] -> win" and put "some winning" in the WinConditions, that seems to fix it. I think I'll use that instead.

[edderiofer]

Oh dear, it looks like putting "some winning" in WinConditions is actually screwing up a different part of my game (in that my game will also have ice blocks, and an ice block sliding over a button shouldn't stop on it, but putting "some winning in WinConditions can cause the iceblock to stop on the button and win the level). Anyone have any other ideas?

[Jamie Perconti]

Depends how your ice blocks are implemented, and what you plan to have influencing the win condition besides pressing all the buttons. If it's just the latter, and if you have an object name in your legend that matches all the stationary blocks, you could just make your win condition "all button on" that object.

Jamie

,

To unsubscribe from this group and stop receiving emails from it, send an email to puzzlescript+unsubscribe@googlegroups.com.