Possible bug on absolute target shifts (solved)

While working on a level I discovered a possible bug in Knytt Stories 1.2.1

When using an absolute target shift, sometimes it doesn't quantize. I've only noticed it when used in combination with ShiftTouch set true. The scenarios I've found are when jumping or falling into a line of square shift objects. Then, I have it shift on touch to a location with a spot shift, sticky, and no-jump. (See image) I'm using Looki's Level Editor Mod to construct the level. The problem has occurred in both the level editor's test and KS 1.2.1. One of my beta testers has reported having the problem. I don't know what version they're using. I've only recently begun using Looki's Mod and the problem has only recently appeared, so there may be a connection.

Here is the code from one location in my level where this has occurred.
[x1000y1048]
ShiftAbsoluteTarget(A)=True
ShiftYMap(A)=1049
ShiftXMap(A)=1000
ShiftYPos(A)=7
ShiftXPos(A)=1
ShiftSound(A)=None
ShiftType(A)=3
ShiftEffect(A)=False
ShiftVisible(A)=False
ShiftTouch(A)=True

[x1000y1049]
ShiftYMap(A)=1
ShiftYPos(A)=2
ShiftSound(A)=None
ShiftEffect(A)=False
ShiftVisible(A)=False

So, who is doing something wrong; me, the editor mod, or the game?

Have you checked the .ini to see if ShiftQuantize(A) is on or off?

By default its turned off. Seeing that its not listed here, that must be the reason.

^ Isn't Quantize actually on by default?

I don't think I can reproduce this bug on regular KS.

It is True by default. I could try declaring it True. That would be an easy fix if it overrides the bug. The problem is, I can't always reproduce it. It just happens some times, but when it happens it continues to. I'll provide the last version I saw this problem in on request. There's a ton of flag checks, flag enables/disables, and thing like that. I might have found some magic combination that breaks the game.

Sorry for the double post, but I figured it out and it's easy to reproduce. The problem comes from the 'sticky'. It doesn't arrest horizontal movement instantly. If you're running when you hit a sticky area you'll stop in a different location than if you're walking. So, If you're moving when you hit a 'shift' that sends you to a 'sticky' you can move far enough after shifting to leave a spot shift zone.

I also noted that shifting into a solid object combined with a sticky appears to arrest horizontal motion immediately.

Oh, at first I thought Juni would stop where she stood before the Shift. Yeah, that I could reproduce; it's not a bug then. It's probably due to how, when you Shift (quantized or not, it doesn't matter), you're not on the ground for an instant (one frame or more) and before the game checks that you're on the ground you can still move.

Using a Sticky by itself after a Shift is never reliable (not even with the NoJump Object, it seems), that's why most people add invisible walls for good measure.

^ Interesting. I tested this out. Juni is a very complex girl indeed.

I made tiles with pixel heights 1 to 12. I put these in the target location to see exactly where Juni shifts to. Then, I tried shifting to a location on the same screen and an identical relative location on another screen. I used different shift shapes. I used absolute shifts and relative shifts. I shifted from locations above, below, and even with the relative target location. I tried shifting while standing still, while running, and while falling. I tried with and without quantizing.

I got so many different results I couldn't keep track of it all. While running into a square shift with absolute targeting, up to 6 pixels on the target location won't cause a swim. Try the same thing with relative targeting and 1 pixel causes a swim. Use absolute targeting again while standing still and 5 pixels causes a swim only part of the time. Disable quantize in this last scenario and she'll still appear up to 5 pixels above 0. (She started at 0.)

At any rate, none of this made the 'sticky' work better. I've already walled her in my level.

Edit: By the way, I agree that it's not a bug. If I used the engine the way it was meant to be used, these fine details wouldn't be an issue.