OpenBOR v3.0 Build 4316 (Windows/Wii/Android)

Status
Not open for further replies.
OpenBOR v3.0 Build 4366
https://sourceforge.net/projects/openbor/files/
- Engine is now running on multiple attack and body boxes. By DC (great feature DC, this open openbor to another level!!)
- added new levelorder command: "pauseoffset" (by me)
USAGE:
pauseoffset {font0} {font1} {xpos} {ypos} {font_pause} {xpos_pause} {ypos_pause}
- added model name in debug info (by me)
- improved loading lag (by me)

I post this build to test the lag more than anything else..
 
White Dragon said:
- Engine is now running on multiple attack and body boxes. By DC (great feature DC, this open openbor to another level!!)

Not finished just yet - the engine is supporting multiple boxes internally, but there's no way for authors to define them just yet. I'm currently polishing this up, and the pointer based animation properties too.

Both are coming soon!

It's been a long process as I have to rewrite a lot of basic routines that have been in place since the original BOR. Most of it involves breaking down a lot of rather large functions into smaller ones, and replacing hard coded structures with pointer references. That and being forced to side track myself with entirely new projects - why do you THINK I added a visual collision debug? Can't very well confirm multiple iterations if I can't see them on screen.  8)

It's all slow going, but is coming along and very near completion. :)

DC
 
Guys, I tested the last version:

- the translation doesn't works on "END GAME" (pause menu). This wasn't working on the version I use either (4153), but it works in "CONTINUE". It doesn't works in NEW GAME and LOAD GAME either.

- I can confirm the lag.  My game loads in 9 seconds in version 4153, but tooks 1:14 to load on the 4366.
When I tested the game in 4334, everything runs fine.
 
O' tested translatiorns but it works well!!
You need to change msgstr in the bottom (not above) to translate.

As for the loading lag, I'm going a bit 'groping because I can not test it because I do not know no lag in any game.
I therefore ask you to test these my private builds:
http://www.mediafire.com/file/z7m16sc2kpzfs6f/test_build.rar

then feedback please.
 
I double checked it and you are right - I put the END GAME translation on the wrong line.

About the lag, try to load my game (the version I sent you) in version 4334 then compare with version 4366 and you will notice it.
 
i tested the test build wd provided and the OpenBOR_noavoidcomment.exe crash on loading even if i delete the save files

the second .exe openbornormal take around 5 to 7 minutes to load  like as since 4343 and up on my projects
 
Ok guys! Thanks for your infos!
Your info helped me to fix the loading lag.
I hope the lag is fixed now.
Try new version 4369

Ps. O' did you try the model name on debug? I hope it works well!
 
in this topic i think i can confirm the more than 4 joysticks bug that i reported sometime ago

http://www.chronocrash.com/forum/index.php?topic=3150.msg43046;topicseen#new
 
Hi DC, checked your last update and your attempt to move energycost from struct to pointer.
Well, I restored and fixed (I think, BTW you can test it) your latest update.

You got random crash by a NULL pointer.
Also you forgot to do a check for some functions.

Here your errors:
in int check_energy()
Code:
    s_energycost energycost;

    energycost.cost     = 0;
    energycost.disable  = 0;
   energycost.mponly   = COST_TYPE_MP_THEN_HP;

   if(self->modeldata.animation[ani]->energycost)
    {
        energycost = *self->modeldata.animation[ani]->energycost;
    }

You do a check for a NULL pointer and it's wrong in this way, also you set to default an overwritten var and it's unuseful,
Also the function returns TRUE if there isn't a pointer (NULL) to energycost, because this means that the animation is not a SPECIAL.
You check a NULL pointer with if(self->modeldata.animation[ani]->energycost)...
but then you handle energycost with the new pointer previously declared (s_energycost energycost).
This is a NULL pointer error!

so right code is:
Code:
if(!self->modeldata.animation[ani]->energycost) return TRUE;

then you missing  to check a NULL pointer in functions:
void common_attack_proc()
void player_jump_check()

then for now let's stick to the previous defaults.
Code:
                if (newanim->energycost)
                {
                    newanim->energycost.mponly      = COST_TYPE_MP_THEN_HP;							//MP only.
                    newanim->energycost.disable     = 0;	
                }

is better then
Code:
newanim->energycost = NULL;

because even if newanim-> energycost does not exist then it is already a null pointer, but if there is then we set it to default values.
And that goes for dropframe too.

Be careful with NULL pointer and these big changes. Every move destroys the old logic.
It was hard to guess the return TRUE suggested earlier.


 
White Dragon said:

Thanks for having a look. I knew it was a NULL pointer - that was pretty obvious. I just didn't know WHERE, and didn't have any time left to ferret it out, so I repealed my changes. I had specific reasons for the way I wrote the logic in my first attempt, but if it works now, then no worries.  ;)

DC

*Edit*:

White Dragon said:
You check a NULL pointer with if(self->modeldata.animation[ani]->energycost)...
but then you handle energycost with the new pointer previously declared (s_energycost energycost).
This is a NULL pointer error!

That's not really true. s_energycost energycost is an implied definition. It's perfectly legal to reference, unless you later overwrite it with a NULL. I think the real problem was forgetting the check in void common_attack_proc() and void player_jump_check().
 
nsw25 said:

That's exactly how Stealth is supposed to work, and it's in the manual.

Code:
stealth {stealth} {perception}

The AI can only "see" another entity if its {perception} >= the other entity's {stealth}. Both default to 0, so setting an {stealth} to 1 or higher without doing anything else would logically make that entity invisible. It doesn't have anything at all to do with how far away the entities are.

As for what you are asking for, a perception distance - there is no specific core engine feature for that. There is one in progress, but it requires messing with a lot of core AI routines and is not ready for roll out just yet. You can already replicate that kind of behavior with use of range and built in AI switches anyway, so it's not a high priority.

DC



 
One of my playable characters has counterrange 0 0 2 0 set in anim attack. She can still perform the counter on the first frame, but becomes immune to all damage during the entire attack animation. I'm using build 4376.

sCfzrm3.png
 
Fastattack is depreciated because it's pointless, the engine now allows that effect by default.

DC
 
by default you mean just add more attackboxes in the animation frames? no need more
attack 0 0 0 0 0 too in last frame?
 
Status
Not open for further replies.
Back
Top Bottom