OpenBOR

OpenBOR 4.0 4.0 Build 7735

No permission to download
Overview Updates (5) Reviews (8) History Discussion
Bruce said:
Notice: I have seta 500 to make the Phoenix looks like it's floating. Its auto attack is throwing fireball down within the range and range z
Maybe this one is causing the problem in v4.0
Click to expand...
Exactly, this is where the problem is. For flying characters, in addition to the range/rangez, I suggest to fill both rangea/rangeb in order to make a.i. controlled characters targeting opponents above and below.

Considering that the "seta" command also changes your current base, it makes sense if the engine does not identify any opponent if only the X/Z range are declared since it will scan for any entity that is on the same ground as you. If there's some difference between v4 and v3, I think it's not a bug but just requires a more accurate range configuration.

1737088107071.png

Usually I put rangea/rangeb in all my Jet character attacks.

Code: 
anim attack1 #GRAB/LONG RANGE CHARGE
    range -48 480
    rangea -999 999
    rangeb -999 999
    rangez -48 48
    fastattack 1
    jugglecost 0
    forcedirection 0
    otg 1
    loop    0
    delay    4
    offset    158 181
    bbox    145 109 24 74
    @cmd hitfx "data/sounds/none.wav"
    @cmd hole 0
    @cmd leaper 0 -1 0
    frame    data/chars/bosses/jet/sor2/a100.png
    frame    data/chars/bosses/jet/sor2/a101.png
    frame    data/chars/bosses/jet/sor2/a100.png
    @cmd landFrame 2
    frame    data/chars/bosses/jet/sor2/a101.png
    attack 145 109 40 74 0 0 1 1 0 12
    noreflect 1
    frame    data/chars/bosses/jet/sor2/a100.png
    @cmd aniChange 2 openborconstant("ANI_FOLLOW2")
    frame    data/chars/bosses/jet/sor2/a101.png
 
Kratus said:
Exactly, this is where the problem is. For flying characters, in addition to the range/rangez, I suggest to fill both rangea/rangeb in order to make a.i. controlled characters targeting opponents above and below.

Considering that the "seta" command also changes your current base, it makes sense if the engine does not identify any opponent if only the X/Z range are declared since it will scan for any entity that is on the same ground as you. If there's some difference between v4 and v3, I think it's not a bug but just requires a more accurate range configuration.

View attachment 10042

Usually I put rangea/rangeb in all my Jet character attacks.

Code: 
anim attack1 #GRAB/LONG RANGE CHARGE
    range -48 480
    rangea -999 999
    rangeb -999 999
    rangez -48 48
    fastattack 1
    jugglecost 0
    forcedirection 0
    otg 1
    loop    0
    delay    4
    offset    158 181
    bbox    145 109 24 74
    @cmd hitfx "data/sounds/none.wav"
    @cmd hole 0
    @cmd leaper 0 -1 0
    frame    data/chars/bosses/jet/sor2/a100.png
    frame    data/chars/bosses/jet/sor2/a101.png
    frame    data/chars/bosses/jet/sor2/a100.png
    @cmd landFrame 2
    frame    data/chars/bosses/jet/sor2/a101.png
    attack 145 109 40 74 0 0 1 1 0 12
    noreflect 1
    frame    data/chars/bosses/jet/sor2/a100.png
    @cmd aniChange 2 openborconstant("ANI_FOLLOW2")
    frame    data/chars/bosses/jet/sor2/a101.png
Click to expand...
Whoa, I added rangea, and rangeb, and it worked! Thank you so much for your help
 
If there's some difference between v4 and v3, I think it's not a bug but just requires a more accurate range configuration.
Click to expand...

This is correct. Vertical range defaults are now based on the model's jump height setting. This is for optimization purposes, as you almost never need huge ranges except in special circumstances, and it adapts seamlessly with the model's jumping capability.

C: 
/*
                * Other than Min X, default ranges are
                * based on jump height or grabdistance.
                * This is partially for legacy compatibility.
                * It works well enough that beginners won't
                * know the difference and advanced creators
                * will always want to adjust for their specific
                * needs.
                */

                const int range_default_grabdistance = (int)newchar->grabdistance / 3;
                const int range_default_jumpheight_max = (int)newchar->jumpheight * 20;
                const int range_default_jumpheight_min = (int)newchar->jumpheight * 10;

                newanim->range = (s_range){
                    .base = {.max = range_default_jumpheight_max, .min = -range_default_jumpheight_min },
                    .x = {.max = range_default_jumpheight_max, .min = (newanim->range.x.min) ? newanim->range.x.min : -10 },
                    .y = {.max = range_default_jumpheight_max, .min = -range_default_jumpheight_min },
                    .z = {.max = range_default_grabdistance, .min = -range_default_grabdistance }
                };

Default grab distance is 36.0, and default jump height is 4.0. So, assuming those are left alone, your default ranges are as follows:
  • Base: -40 to 80
  • X: -10 to 80
  • Y: -40 to 80
  • Z: -12 to 12
Some animations (like Upper) have their own static defaults, but the vast majority use the formula above.

DC
 
Hi everyone, how can i build it to wii? I'm a bit lost, already cloned the git but everything i tried get errors and messages about sld. Tried to bash build-all.sh but no success. Any help?
 
Last edited:
DarthMotzkus said:
I`m getting this after run .bat:
View attachment 10070
Click to expand...

I was afraid of that. We recently had one of the older (and FAR more knowledgeable than myself) devs show up (@SX), and he tried to modernize the compiling. problem is, none of us could ever get it to work even with his help. Supposedly the original batch build would still run as a fallback, but I guess not. I took a bit of time off after the 4.0 release to work on my own projects and haven't messed with it any. I'll have to go in and revert those changes (I'll put them into another branch so they won't be gone), and see if I can get the batch build going again. It won't be this week though, I'm kind of buried in some post grad work ATM.

DC
 
Tried to build
DCurrent said:
I was afraid of that. We recently had one of the older (and FAR more knowledgeable than myself) devs show up (@SX), and he tried to modernize the compiling. problem is, none of us could ever get it to work even with his help. Supposedly the original batch build would still run as a fallback, but I guess not. I took a bit of time off after the 4.0 release to work on my own projects and haven't messed with it any. I'll have to go in and revert those changes (I'll put them into another branch so they won't be gone), and see if I can get the batch build going again. It won't be this week though, I'm kind of buried in some post grad work ATM.

DC
Click to expand...
I've tried to build with linux bash build.sh, that's the output:

1737555803253.png
1737555984845.png
 
You must log in or register to reply here.
Back
Top Bottom