Bug regarding move transition and z-order - new in 6.11

[Jake]

I've been trying to pin down a bug in my battle engine for a couple of weeks now, in which a fighter sometimes moves correctly, sometimes skips directly to the end position and pauses there for as long as it would have taken them to normally complete the move. I was half-sure it was probably something I was doing wrong with the composition of transforms... and now I've worked out what the precise conditions under which the bug occurs are, I'm kicking myself for not having noticed what it was earlier.

Basically, when a Displayable moves 'past' another Displayable in the Z axis, the normal move transition doesn't occur and the moving Displayable just jumps immediately to its final position.

I've double-checked in 6.10.2, and it all works fine there - the bug seems to have been introduced in 6.11, which I guess makes sense since I understand there were some big changes in that area in 6.11.

I've run out of time in my lunch break to come up with a bit of demonstration code, hopefully the description above is all that's needed anyway... the precise situation I'm working with actually has the zorder parameter to renpy.show for displayable A go from <less than B zorder> to <equal to B zorder> (which shows the transition fine) and then to <greater than B zorder> (which doesn't show the transition), if it's that specific. I'll work on a repeatable demo when I get the chance, just to be on the safe side.

[Jake]

I'll work on a repeatable demo when I get the chance, just to be on the safe side.

This did actually take me longer than expected, 'cause it turns out that it's only an issue in one direction - at least, I could only reproduce it in one direction. If moving from a greater Z than another displayable to a lesser Z, then it skips; moving from a lesser Z to a greater one doesn't.

Anyway, here's a reproduction:

Code: Select all

init:
    image sprite = Text('Sprite')
   
    image bg = Solid("#000")
    
init python:
    x = config.layers.index('transient')
    
    config.layers = config.layers[:x] + ["testlayer"] + config.layers[x:]
    
    define.move_transitions("testmove", 0.5, layers=["testlayer"])
    
    a = Transform(xanchor=0.5, yanchor=0.85)
    

# The game starts here.
label start:
    
    scene bg

    python:
        
        
        l = "testlayer"
        
        num11 = Text("11")
        renpy.show("num11", what=num11, at_list=[Transform(xpos=300, ypos=280)], zorder = 11, layer=l)
        
    "The displayable '11' here is shown with zorder=11."
    
    "First, we'll show a 'Sprite' displayable with zorder=20, and move it to another position with zorder=20:"
    
    python:
        renpy.transition(testmove)
        renpy.show("sprite", at_list=[Transform(xpos=500, ypos=100)], zorder=20, layer=l)
        renpy.pause(0.5)
        
    "Next we'll move it to a new position, zorder=15"
        
    python:
        renpy.transition(testmove)
        renpy.show("sprite", at_list=[Transform(xpos=500, ypos=200)], zorder=15, layer=l)
        renpy.pause(0.5)
        
    "That move completed fine as well."
    "Now we'll move it to a new position with zorder=10; note that this moves it 'past' the existing displayable in the Z-axis."
    
    python:

        renpy.transition(testmove)
        renpy.show("sprite", at_list=[Transform(xpos=500, ypos=300)], zorder=10, layer=l)
        renpy.pause(0.5)
     
    "When we moved 'past' the other displayable in Z, the move transition didn't work properly, and the sprite 'jumped' instead."
    "Now we'll move it from zorder=10 to zorder=5:"
    
    python:
    
        renpy.transition(testmove)
        renpy.show("sprite", at_list=[Transform(xpos=500, ypos=400)], zorder=5, layer=l)
        renpy.pause(0.5)

    "Which worked fine."
    "Next, the other way around - we'll move to zorder=15 again:"
    
    python:
        renpy.transition(testmove)
        renpy.show("sprite", at_list=[Transform(xpos=500, ypos=200)], zorder=15, layer=l)
        renpy.pause(0.5)

    "Which works - we get the transition going one way in Z, but not the other."

- The bg isn't strictly necessary, but it makes it easier to see.
- The displayables don't have to be Text, I've seen this issue with images and animations as well. Text just means the example is self-contained.
- Originally I thought this bug was introduced in 6.11, because my BattleEngine started to exhibit the problem then, and running the same code in 6.10.2 and 6.11 didn't break and broke respectively. However, running the above example code in 6.10.2e (under OSX, if it makes any difference) also breaks.

[DaFool]

I've experienced something that could be related.

After extended period of testing on a scrolling map, all of a sudden the walking motions of the characters all but disappeared (I only saw blips here and there). Their standing motions remained fine.

Thinking it was because my laptop was in power-saving mode, I checked the integrated graphics settings and they remained in full acceleration. Even if I quit and start a game (or reboot the computer), the same behavior applied. This situation did not happen in non-panning maps.

To get the situation rectified (for now), I loaded the original panning map demo (with the white marshmallow-like guy) which worked smoothly. Then I reloaded my panning work in progress and it worked as before (including the slight jumping of positions)

[PyTom]

I've finally gotten the courage to look into Jake's problem. MoveTransition was never expected to deal with changes of zorder (or of order in general, apart from simple insertions or deletions), so this was a little tricky, and required a rewrite of MoveTransition to solve.

The new MoveTransition works in the following way:

* A list is created, preserving the relative ordering of all the entering and moving images.
* Each leaving images is added to the list such that it is at the lowest possible position that is above all of the images that were beneath in in the old scene.
* The list is sorted by zorder.

This should yield correct results in most cases.

[Jake]

This should yield correct results in most cases.

That's pretty cool to hear - sorry for coming up with awkward bugs, and thanks a lot! I'll look forward to the next Ren'Py release with anticipation! ;-)