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

Status
Not open for further replies.
Tried build 4335, all my platforms no longer work. Everything just falls through them as if they weren't there:

Build 4328:
Sanctuary%20of%20Illusion%20-%200020.png


Build 4335:
Sanctuary%20of%20Illusion%20-%200018.png


 
checking holes in z axis fixed.
tomorrow I'll see the Viper Snake bug.
please try:
https://sourceforge.net/projects/openbor/files/OpenBOR_v3.0_Build_4334.rar/download
https://sourceforge.net/projects/openbor/files/OpenBOR_v3.0_Build_4332.rar/download
https://sourceforge.net/projects/openbor/files/OpenBOR_v3.0_Build_4330.rar/download
 
Tried builds 4330, 4332, and 4334. Platforms still broken. I went back and tried build 4329 as well, this is the build where it becomes broken.
 
Ok, guy I'm updating the engine.
I want to convey to you what the issue is.
It is not a bug.

Well, in previous build there were issues on holes/walls/platform detect logic.
Issue of JUST 1 pixel.
I fixed them, but to come to aiutodi Magggas, I tried to find a compromise.
Unfortunately guys like Magggas, have worked on the wrong logic. It is not your fault. Only there in Engine things were not correct. That's what.
To detect walls et similia, once you have defined the edges, you need to compare entity coords with wall coords, right?
How do you know if the entity is impacting a wall?
x_entity >= x_walls && x_entity <= x_walls+wall_width etc..
Now prev build had issues like not >= or <= but just > (that it means that you are inside wall yet -ISSUE-)
I fixed it but Magggas find bugs in his game because he worked based on that engine issue.
Unfortunately it is not the engine that has to adapt to modders, but the opposite.

Now someone is wondering: Because first worked with everyone?
Because there were mixed > and >= withou criteria. Just all > or all >=.
But the right definition is >=

So, moral of the story, I'm sorry Magggas but the correct definition is >= and not just > and so you will find a bug in your game thats is the climbing issue,
For you will be easy to fix it. From what I understand It will be sufficient to move further down (z axis) the ladders of just 1 pixels.
In this way all issue will be solved.
I'm sorry but you can not have issues in Engine to have for compatibility with all games. It is not fair for those who (like Viper Snake) create scripts with the right logic.
Simply, now that the errors are corrected, just update their scripts.
I hope you all agree.

Ps.nws25 Thanks to test wii version. I hope to fix it in the future
 
White Dragon said:
To detect walls et similia, once you have defined the edges, you need to compare entity coords with wall coords, right?
How do you know if the entity is impacting a wall?
x_entity >= x_walls && x_entity <= x_walls+wall_width etc..
Click to expand...

When there are conflicting issues, this is where I have to step in and make the final call.

In this case, White Dragon is correct. Looking at the code, the logic should have been ...>= && <=... all along. Otherwise, your wall coordinates vs. the engine's wall detection will be off by a pixel. Doesn't sound like much, but it's a big problem long term that had to be corrected.

It's not really a matter of "who did it right way" vs. "who did it wrong", it's what is the proper solution to have the least headaches going forward.

If there are any further wall issues, please bring them to our attention and we'll advise.

DC
 
OpenBOR v3.0 Build 4342
https://sourceforge.net/projects/openbor/files/OpenBOR_v3.0_Build_4342.rar/download
-fixed hole (no height check) in z axis too
-another little retouch to debugging...
-cleaner code, and more friendly memory trap. If we don't have enough, just don't print the text.
-refixed logic for test hole/wall/platform
-another improvement for new animationscript
-now allowed boolean NOT operator ! for constants too

just a little focus on NOT boolean operator !

in prev builds:
int a = 0;
!a = 1
it's right.

but in you define...
#define  a 0
!a = 0 // WRONG!!!

so now NOT boolean operator accepts constants!
 
-There is a issue with engine now identifying something as a invalid animation name, more info available here:
Click to expand...
Sorry, but this is not an engine bug - its a bug in your codes. As I replied there, I have THE SAME code and it works and I even tested it on the newest build and it WORKS.

Here is a video proof (build 4334)
https://www.youtube.com/watch?v=vEBqMewAuug
 
nsw25 for crashes I think that is a bug in DC code.
build 4297 works in xtreme mode and 4298 crashes.
this is a DC update on new collision attacks.
Advice you to send your mod to DC to test it in xtreme mode.

DC please check the update in 4298. It causes a crash.
 
White Dragon said:
DC please check the update in 4298. It causes a crash.
Click to expand...

It will be tomorrow afternoon before I can really look into the code again, but  I suspect it's a NULL pointer slipping through.

DC
 
I found that the anim BLOCK (in chikaNPC)
use
range 0 300
rangez -30 30
if I delete it works well

nws25 check your code and see well what cause the crash.
try to edit your level deleting and re-adding entity to traced back to the issue,
then feedback.
 
I confirm, after DC update at build 4298 (4297 and before working well)
anim block seems to be compromised.
when engine read anim block crashes.
also with anim block without range or other properties.
I noticed that with prop in anim block (like spawn subentity etc..) I get more crashes
 
Thanks, soon as I'm done with my meetings in a couple of hours I'll dive in. I'm almost certain the engine is trying to reference a NULL pointer.

DC

**Edit** Please send much detail as you can about reproducing. Even after I cleaned it up some that section of the source code is a spaghetti nightmare.
 
Fixed I think.

see here:
Code: 
           collision_attack = attacker->animation->collision_attack[attacker->animpos]->instance[instance];

            if( attacker->exists && attacker != self //cant target self
                && (attacker->modeldata.candamage & self->modeldata.type)
                && (anim < 0 || (anim >= 0 && check_range(self, attacker, anim)))
                && !attacker->dead && attacker->attacking//must be alive
                && attacker->animation->collision_attack && (!collision_attack
                    || collision_attack->no_block == 0)
                && (diffd = (diffx = diff(attacker->position.x, self->position.x)) + (diffz = diff(attacker->position.z, self->position.z))) >= min
                && diffd <= max
                && (attacker->modeldata.stealth.hide <= iDetect) //Stealth factor less then perception factor (allows invisibility).
              )
            {

fixed with:
Code: 
            if( attacker && attacker->exists && attacker != self //cant target self
                && (attacker->modeldata.candamage & self->modeldata.type)
                && (anim < 0 || (anim >= 0 && check_range(self, attacker, anim)))
                && !attacker->dead && attacker->attacking//must be alive
                && attacker->animation->collision_attack && attacker->animation->collision_attack[attacker->animpos] && attacker->animation->collision_attack[attacker->animpos]->instance
                && ( !attacker->animation->collision_attack[attacker->animpos]->instance[instance] || (attacker->animation->collision_attack[attacker->animpos]->instance[instance] && attacker->animation->collision_attack[attacker->animpos]->instance[instance]->no_block == 0) )
                && (diffd = (diffx = diff(attacker->position.x, self->position.x)) + (diffz = diff(attacker->position.z, self->position.z))) >= min
                && diffd <= max
                && (attacker->modeldata.stealth.hide <= iDetect) //Stealth factor less then perception factor (allows invisibility).
              )
            {

bug was NULL pointer on attacker.
You first declare
collision_attack = attacker->animation->collision_attack[attacker->animpos]->instance[instance];

then you check the attacker existence (here NULL pointer)
 
Not At All! !
And with New Version You Can Spawn Entities Everywhere. In main menu In Option MeNu And in Select Screen. . . Everywhere!
 
For Wii build not running games, its not about the size of the game per se, but about the memory allocation each standalone game relies upon in order to succesfully run all scripts, because Wii is very limited in memory.

Games like Double Dragon Reload by Maggas is only about 100mb but will not run on Wii after the loading screen because it depends on running many different scripts and the Wii cannot allocate all that memory and ends up crashing.

I'm still surprised I came across an actual version of Nighslashers X that actually runs on Wii from start to finish, albeit an issue with left grapples and running attacks.
 
White Dragon said:
Not At All! !
And with New Version You Can Spawn Entities Everywhere. In main menu In Option MeNu And in Select Screen. . . Everywhere!
Click to expand...

ahhh. Don't spoiler the surprise. I will make a tutorial about it later today :)
 
I can confirm sound issues still in the latest Wii build, but somehow mods that did not load before now load???

Tested on Double Dragon Reload by Maggas, and the ladder issue is still there.

Build 4344
 
MaxBeta said:
I can confirm sound issues still in the latest Wii build, but somehow mods that did not load before now load???

Tested on Double Dragon Reload by Maggas, and the ladder issue is still there.

Build 4344
Click to expand...

Yes! I rote yet. Not a bug, the engine works perfect now!!
Magggas wrote a script based on an old engine issue.
Magggas has to improve/update his script.

For wii build. We asking to plombo (wii programmer) to check his code.
For memory limit... unfortunately for how  the engine is made I am afraid that there is little you can do ...
 
Status
Not open for further replies.
Back
Top Bottom