Daimao Cancel System 1.0

[Piccolo]

Updated:
After adjusting the delays and set(data, "switchFrame", X); to lower number,
it is working fine in Build 4.0 without the code below

@script
    if(frame > 0) daimaoCancel();
@end_script

Yeah obviously but it's just a workaround, or a "hack" if you prefer.

Because you changed this the cancel system no longer works properly. You basically disabled the switchFrame feature of this cancel system, which enforce that the cancel doesn't happen until said switchFrame, even if the cancel is registered before (using key script).

Basically you will no longer get "smooth" cancels with this workaround.

So something probably has changed with this from 3.X to 4.X. You can test this using this simple script in an entity header :

@script
drawstring (10, 60, 3, "This is working");
@end_script

OpenBOR 3.X will accept it, but not 4.X. Now I'm aware it might have never been intended to work in 3.x even if it did, but it was actually a very nice feature for stuff like this.

So in the meantime, @Bruce, the real workaround is to put the "problematic" code in the animationscript main function. But beware if you also use this animation script for entity that don't support daimao cancel.

EDIT : you might also need to retrieve "frame" value yourself, because with inline animation script the engine does it automatically.

main(){

    ...
    int frame = getlocalvar("frame");

    if(frame > 0) daimaoCancel();

    ...

}

 

[Bruce]

Yeah obviously but it's just a workaround, or a "hack" if you prefer.

Because you changed this the cancel system no longer works properly. You basically disabled the switchFrame feature of this cancel system, which enforce that the cancel doesn't happen until said switchFrame, even if the cancel is registered before (using key script).

Basically you will no longer get "smooth" cancels with this workaround.

So something probably has changed with this from 3.X to 4.X. You can test this using this simple script in an entity header :

@script
drawstring (10, 60, 3, "This is working");
@end_script

OpenBOR 3.X will accept it, but not 4.X. Now I'm aware it might have never been intended to work in 3.x even if it did, but it was actually a very nice feature for stuff like this.

So in the meantime, @Bruce, the real workaround is to put the "problematic" code in the animationscript main function. But beware if you also use this animation script for entity that don't support daimao cancel.

EDIT : you might also need to retrieve "frame" value yourself, because with inline animation script the engine does it automatically.

main(){

    ...
    int frame = getlocalvar("frame");

    if(frame > 0) daimaoCancel();

    ...

}

I really love this canceling system, and we really appreciate for your hard work. Hopefully you figure a way to make it work in 4.0
Meanwhile I am just going to put it in the animationscript main function,

Thank you very much

 

[Kratus]

As I mentioned to DC : "the inline @script @end_script in char header. Previously it acted as a meta-inline animation script. It would run on all animations."

Hmm I didn't know that, thanks for clarifying. But I would even understand if it was removed during any previous engine rework because it works in a way similar to ondraw/update/think scripts, running all the time.

 

[Bruce]

if(frame > 0) daimaoCancel();

Is it bad performance/bad memory consumption if I use this code in the animation inline that needs this canceling system?
Basically, every frame, it will run the daimaoCancel(), so I am wondering if this is bad for performance...
I know DC said avoid using inline as much as possible, but sometimes we have to use it...

Thank you

 

[Piccolo]

Is it bad performance/bad memory consumption if I use this code in the animation inline that needs this canceling system?
Basically, every frame, it will run the daimaoCancel(), so I am wondering if this is bad for performance...
I know DC said avoid using inline as much as possible, but sometimes we have to use it...

Thank you

Not really, there's a lot of stuff that the engine runs at a much higher frequency than the frame level. Plus the animation script main function already does a whole lot of checks to support all the @cmd and @script that are present within animations. So one more check is really nothing in terms of cost.

The benefit of putting the @script outside of animation (in char header) is mainly to avoid repeating this code in every animation. But it no longer works in 4.0 for now.

Again the best alternative is to put the code manually in the animation script main function. You have to understand that at the end of the day, when the engine run your game, every @cmd and @script in a char file are "translated" and put in animation script main function. So a character animation main function is one big function with a lot of conditional checks that contains all the code that is called within @cmd @script

Basically @cmd is translated into :

if(animation == animation_where_@cmd_was_called && frame == frame_where_@cmd_was_called){
    do the @cmd code
}

Basically @script (with animation) is translated into :

if(animation == animation_where_@script_was_called){
    do the @script code
}

And in 3.xx, the @script in char header was translated into a no-condition block :

do the @script code

Which is why it was really useful to add global animation script stuff directly in char. Now in 4.xx you have to put the code manually in the main function

 

[Piccolo]

Hmm I didn't know that, thanks for clarifying. But I would even understand if it was removed during any previous engine rework because it works in a way similar to ondraw/update/think scripts, running all the time.

Well not exactly, it was just a small part of animation script, which runs on all the frames in 3.xx and 4.xx. So the animation script itself is not removed (because @cmd and @script in animations work), only the ability to add global stuff in it's main function directly from char file. See my previous post for reference