Failing to get a variable using animationscript

O Ilusionista

Captain 100K
I'm using an old @Bloodbane code to simplify branches, which takes the entity's alias and uses it as a value for a jumptobranch.

The problem is: after several reports, I realized that this happens exactly at the stage where I use this branch - a "silent crash", which doesn't generate any log entry, the engine just closes.

From my experience with OpenBOR, the only causes that generate this are:

  1. Declaring an invalid image as alternatepal - strangely, this doesn't happen if you declare it as "palette", because the engine returns this error in the log. This was already report on dev area, but I will open a github ticket soon.

  2. Using a weapon (alternate model) that wasn't loaded

  3. - A "Null point" - referring to a point in memory that doesn't exist. (Which is what happens in the options above in fact).
I currently use the following code:

Idle, with followanim and follow cond:

Code:
anim    idle
    loop    1
    delay    6
    followanim    10
    followcond    1
    attack    25 30 30 30 0 0 1 1 0 30
    hitfx data/sounds/silent.wav
    noreflect    1
    offset    40 60
    frame data/chars/misc/branch/arrow_r.gif
    offset    41 60
    frame data/chars/misc/branch/arrow_r.gif
    offset    40 60
    frame data/chars/misc/branch/arrow_r.gif
    offset    39 60
    frame data/chars/misc/branch/arrow_r.gif

Follow animation with inline code:

C-like:
anim    follow10
@script
    void self = getlocalvar("self");
    char Name = getentityproperty(self,"name");
    if(frame == 1){
      jumptobranch(Name, 1);
    }
    @end_script
    delay    10
    offset    27 27
    frame    data/chars/misc/empty.gif
    frame    data/chars/misc/empty.gif
    frame    data/chars/misc/empty.gif
    frame    data/chars/misc/empty.gif

My question is: is there any disadvantage in using this via animationscript and would it be better to use it via didhitscript?
The code already does this only on frame 1 (to avoid the case of the update not being completed on frame 0).

And maybe it would be good to put a safe check in case, for some reason, the "name" variable was not populated with the correct value and use a finishlevel()

Edit: I've added a safe check and log to catch the errors:

C-like:
@script
    void self = getlocalvar("self");
    char Name = getentityproperty(self,"name");
    if(frame == 1){
           if (Name){// safe check
            log("\n\t ========= Branch Name: " + Name + "========= \n");
            jumptobranch(Name, 1);
        } else { // empty name variable
            log("\n\t ========= Invalid branch name ========= \n");
            finishlevel();
        }
    }
    @end_script
 
Last edited:
I'm using an old @Bloodbane code to simplify branches, which takes the entity's alias and uses it as a value for a jumptobranch.

The problem is: after several reports, I realized that this happens exactly at the stage where I use this branch - a "silent crash", which doesn't generate any log entry, the engine just closes.

From my experience with OpenBOR, the only causes that generate this are:

  1. Declaring an invalid image as alternatepal - strangely, this doesn't happen if you declare it as "palette", because the engine returns this error in the log. This was already report on dev area, but I will open a github ticket soon.

  2. Using a weapon (alternate model) that wasn't loaded

  3. - A "Null point" - referring to a point in memory that doesn't exist. (Which is what happens in the options above in fact).
I currently use the following code:

Idle, with followanim and follow cond:

Code:
anim    idle
    loop    1
    delay    6
    followanim    10
    followcond    1
    attack    25 30 30 30 0 0 1 1 0 30
    hitfx data/sounds/silent.wav
    noreflect    1
    offset    40 60
    frame data/chars/misc/branch/arrow_r.gif
    offset    41 60
    frame data/chars/misc/branch/arrow_r.gif
    offset    40 60
    frame data/chars/misc/branch/arrow_r.gif
    offset    39 60
    frame data/chars/misc/branch/arrow_r.gif

Follow animation with inline code:

Code:
anim    follow10
@script
    void self = getlocalvar("self");
    char Name = getentityproperty(self,"name");
    if(frame == 1){
      jumptobranch(Name, 1);
    }
    @end_script
    delay    10
    offset    27 27
    frame    data/chars/misc/empty.gif
    frame    data/chars/misc/empty.gif
    frame    data/chars/misc/empty.gif
    frame    data/chars/misc/empty.gif

My question is: is there any disadvantage in using this via animationscript and would it be better to use it via didhitscript?
The code already does this only on frame 1 (to avoid the case of the update not being completed on frame 0).

And maybe it would be good to put a safe check in case, for some reason, the "name" variable was not populated with the correct value and use a finishlevel()

Edit: I've added a safe check and log to catch the errors:

C-like:
    @script
    void self = getlocalvar("self");
    char Name = getentityproperty(self,"name");
    if(frame == 1){
           if (Name){// safe check
            log("\n\t ========= Branch Name: " + Name);
          jumptobranch(Name, 1);
        } else { // empty name variable
            log("\n\t ========= Invalid branch name");
            finishlevel();
        }
    }
    @end_script

@O Ilusionista,

Generally, it's always better to place code into dedicated events when that option is available. That’s not unique to OpenBOR - it’s just a solid best practice overall. Will it matter in this particular case? Honestly, that’s splitting hairs. But it’s like learning to drive: you don’t try to make judgment calls about when to use your turn signal - you develop the habit of always using it so there’s never any question.

Moving the code to an event won’t improve crash safety. When it comes to NULL pointers, that's not specific to OpenBOR either. There’s no practical way for the application to catch those gracefully, so it’s on you to handle them. Welcome to coding. :cool:

That said, sticking to proper event hooks will pay off in a lot of small, meaningful ways over time.

DC
 
Solved: It was caused by the duplicate use of the infamous SKIPSELECT. According to @Kratus this command resets some internal variables and it seems that if you use it repeatedly (I thought you had to put this before each select), the command ends up resetting important variables in the game - for example, if you played as P2 only, there was a time when the engine would close claiming that it could not find the player " ".
After I removed this, everything worked.

I will add this information at the manual: you just need to use SKIPSELECT once, and all "select" commands you use after that will use the select file you specificed, not the default one.
 
Back
Top Bottom