OpenBOR v3.0 Build 6330 (Android/PSP/WII/WINDOWS)

hechelion · Jul 18, 2018

White Dragon said:
Thanks for your details.
Unfortunately I can't test on Linux (I work on Windows).
Maybe DC can test.
But.. If I can help you, I can see the code and try to find the issue just with reading and tracing the code but
I need to know the latest working commit or first not working.
Can you compile commits after 6276 and before 6291 to find the first not working?
In this way I can concentrate on right code.

Thanks

Thanks for the reply.
The error appears in the "Commits on Jul 09, 2018".

I was manually adding the changes and found that deleting this line:
Globlas.h -> 71) #define shutdown borShutdown
makes Openbor stop working on Linux

If I apply all the changes of July 9, except delete that line, then Openbor works, but a new problem is generated, I can not close the application normally and I have to kill it.

White Dragon · Jul 18, 2018

It's so strange... Try to restore code relative to exit. Just some rows and tell me if it works.
I have no idea why with shutdown not defined it doesn't work...
Or...
try to add:

Code:

#define appExit exit
#undef exit
#define		exit				borExit
#define		_time				borTimeEx
#define		kill				borKillEx
#define		_pause				borPauseEx
#define		shutdown			borShutdownEx

into globals.h

Try it in latest commit please..or simply.. Try latest commit..

It's strange... can some dev help us?

hechelion · Jul 19, 2018

White Dragon, I solved the problem but not the mystery.

As I said before, if you remove the line
#define shutdown borShutdownEx
from globals.h then OpenBOR stop to work in linux (why? I don't know).

I tried to restore that line (and only that one) in build 6325 and now Openbor works great (including closing normally).

Code:

#include "packfile.h"

////////////////////////////////////////////////// ///////////////////////////

#define shutdown borShutdownEx

#ifndef PP_TEST
#define printf writeToLogFile

--------------------
about the problem that Openbor did not close normally, it was because I was doing the sequence:
make clean-all
make BUILD_LINUX = 1
every time I made a change to the source code, and the "make clean-all" command does not really erase all the files generated by a previous make.

Specifically, this command DOES NOT erase the .o generated inside the SDL directory.
After some tests I found the value "borShutdownEx" inside the file "sdl / control.o"
If I manually delete all the .o files (including those in the SDL directory) and then add the line "#define shutdown borShutdownEx" to "globals.h" then Openbor works and closes normally.

White Dragon · Jul 19, 2018

hechelion said:
White Dragon, I solved the problem but not the mystery.

As I said before, if you remove the line
#define shutdown borShutdownEx
from globals.h then OpenBOR stop to work in linux (why? I don't know).

I tried to restore that line (and only that one) in build 6325 and now Openbor works great (including closing normally).

Code:

#include "packfile.h" ////////////////////////////////////////////////// /////////////////////////// #define shutdown borShutdownEx #ifndef PP_TEST #define printf writeToLogFile

--------------------
about the problem that Openbor did not close normally, it was because I was doing the sequence:
make clean-all
make BUILD_LINUX = 1
every time I made a change to the source code, and the "make clean-all" command does not really erase all the files generated by a previous make.

Specifically, this command DOES NOT erase the .o generated inside the SDL directory.
After some tests I found the value "borShutdownEx" inside the file "sdl / control.o"
If I manually delete all the .o files (including those in the SDL directory) and then add the line "#define shutdown borShutdownEx" to "globals.h" then Openbor works and closes normally.

Wow great help my friend...
I will restore that define... but...
Why this issue? Maybe some Linux C lib conflict?? :-\
Maybe:
https://linux.die.net/man/3/shutdown

msmalik681 · Jul 20, 2018

When a character is loaded in a alternate palette their icon should also load with the remap applied since in most games you would show your characters face picture on the icon. But this is not the normal behaviour at the moment the icon holds the default colour.

I think at the very least we should have a matching icon map but I suggest also have a option for alternateicon so you can set different icons for remaps. for example your icon may have the name billy drawn on it but when you switch to alternate pal red you can load a different icon with jimmy written on it and maybe a different icon pose.

This is a change I would like to make (if I can) just wanted to see if anyone has any objections ?

White Dragon · Jul 20, 2018

msmalik681 said:
When a character is loaded in a alternate palette their icon should also load with the remap applied since in most games you would show your characters face picture on the icon. But this is not the normal behaviour at the moment the icon holds the default colour.

I think at the very least we should have a matching icon map but I suggest also have a option for alternateicon so you can set different icons for remaps. for example your icon may have the name billy drawn on it but when you switch to alternate pal red you can load a different icon with jimmy written on it and maybe a different icon pose.

This is a change I would like to make (if I can) just wanted to see if anyone has any objections ?

If it is so... this is a bug! Icon needs to reload the remap!!

I know that if you use icon {file} 1 (with 2nd param set to 1) the icon is loaded with remapped color and it works well.
Into openbor engine code:
flag for remap is into: newchar->icon.usemap = GET_INT_ARG(2)
sprite is into: newchar->icon.def = loadsprite(value, 0, 0, pixelformat);
alternatepal/remap is into: newchar->colourmap[newchar->maps_loaded]
so Does remap work well but not for alternate palette?

msmalik681 · Jul 20, 2018

So I was missing the parameter 1 after icon and path sorry I thought it was a bug but guess not thanks White Dragon. guessing this is not default behaviour to keep backwards compatibility.

White Dragon · Jul 20, 2018

msmalik681 said:
So I was missing the parameter 1 after icon and path sorry I thought it was a bug but guess not thanks White Dragon. guessing this is not default behaviour to keep backwards compatibility.

I think so..

O Ilusionista · Jul 20, 2018

WD, I've downloaded the source code again to I could make some tests. I just went ahead and run the build.bat and I got this error:

Its on the same folder I was compiling before and worked. I've downloaded the source code of build 6240 and it compiles with no error.

White Dragon · Jul 20, 2018

O Ilusionista said:
WD, I've downloaded the source code again to I could make some tests. I just went ahead and run the build.bat and I got this error:

Its on the same folder I was compiling before and worked. I've downloaded the source code of build 6240 and it compiles with no error.

Redownload the pack from svn. Sure you missing some files or file updates.

I tested and it works.

ABK · Jul 21, 2018

Did anyone notice on lastest 6330 WIN build that default ASD attack keys are still active for player 1 even if you remap player 1 attacks to different keys in input settings ? This could interfere with some configs that use ASD for player 2.
Also nosame 1 is not working and player 2 has the same character on select screen and if i press start for player 3 then openbor is crashing.
Also i cant get this to work:
- added dying optional param {remap2}: dying {remap1} {health1} {health2} {remap2}
{remap2} is valid for {health2}
Is it only for 8 bit mode?

White Dragon · Jul 23, 2018

bWWd said:
Did anyone notice on lastest 6330 WIN build that default ASD attack keys are still active for player 1 even if you remap player 1 attacks to different keys in input settings ? This could interfere with some configs that use ASD for player 2.
Also nosame 1 is not working and player 2 has the same character on select screen and if i press start for player 3 then openbor is crashing.
Also i cant get this to work:
- added dying optional param {remap2}: dying {remap1} {health1} {health2} {remap2}
{remap2} is valid for {health2}
Is it only for 8 bit mode?

Hi bwwd:

1) no conflict with permanent keys (tested)
2) nosame 1 is working well, I tested it many and many times.. See if you have wrong multiple declarations
2) dying remap 2 is working well. Just if you set all 4 params remap2 is for health2.
health1 and 2 are percentages, not natural values.

Code:

                    if(e->dying)    // Code for doing dying flash
                    {
                        if((e->energy_status.health_current <= e->per1 && e->energy_status.health_current > e->per2 && (_time % (GAME_SPEED / 5)) < (GAME_SPEED / 10)) ||
                                (e->energy_status.health_current <= e->per2 && (_time % (GAME_SPEED / 10)) < (GAME_SPEED / 20)))
                        {
                            if(e->energy_status.health_current > 0 )
                            {
                                if(e->dying2 > 0)
                                {
                                    if(e->energy_status.health_current <= e->per1 && e->energy_status.health_current > e->per2)
                                    {
                                        drawmethod->table = model_get_colourmap(&(e->modeldata), e->dying);
                                    }
                                    else if(e->energy_status.health_current <= e->per2)
                                    {
                                        drawmethod->table = model_get_colourmap(&(e->modeldata), e->dying2);
                                    }
                                }
                                else drawmethod->table = model_get_colourmap(&(e->modeldata), e->dying);
                            }
                        }
                    }

For me this latest openbor version is pretty stable..

ABK · Jul 23, 2018

OK im glad issues are on my end , tested with other game and it worked and retested again with previous one and it now works in it too... This is very strange and i didnt delete saves between switch, now it works but it still has the same character for player 1 and player 2 shown when it enters select screen, when you move left to right it switches to other character and you cant go back to previous one, so... it doesnt work in the beginning, works later when you move.
ASD still working despite remapping attacks for player 1 still hapens with other mod.
Im on Win7 if it makes difference.

i just realised dying is LEVEL comand , not entity header one... i should be degraded to noob level 9000 :'(
Dying works great.

O Ilusionista · Jul 23, 2018

Also i cant get this to work:
- added dying optional param {remap2}: dying {remap1} {health1} {health2} {remap2}
{remap2} is valid for {health2}

I can confirm dying remap2 works well - you can see it in action on my Avengers mod.

@Whitedragon It's possible to open this to script? For example, we could set this by script instead of only in level spawn.

health1 and 2 are percentages, not natural values.

Percentage? I use them as values and they work

spawn golem
alias Hydra_Golem
@script void main() {
performattack(getlocalvar("self"), openborconstant("ANI_FOLLOW1"));
} @end_script
boss 1
coords 120 200
health 400
2phealth 600
dying 4 200 100 3
at 1320

i should be degraded to noob level 9000

You are just rusty. Happens with everyone

magggas · Jul 23, 2018

O Ilusionista said:
You are just rusty. Happens with everyone

Come on don't spare him like that. Bwwd is a good guy and deserves to know the truth. Which is.. of course he is a noob ;D

Okay okay, i'm shut up :-X

(Sorry guys, i just could not resist when it comes to my friend bwwd. I know it's persolal, but i really like this guy!)

DCurrent · Jul 23, 2018

Pifft... noob.

DC

ABK · Jul 23, 2018

;D haha
Yes dying is value based, 50 means 50 of life, not 50 percent.
If it would be opened to script, it would be great to use tint instead of sacrificing palette.

White Dragon · Jul 23, 2018

bWWd said:
;D haha
Yes dying is value based, 50 means 50 of life, not 50 percent.
If it would be opened to script, it would be great to use tint instead of sacrificing palette.

Yes sorry

O Ilusionista · Jul 23, 2018

If it would be opened to script, it would be great to use tint instead of sacrificing palette.

For tint, we already have ondrawscript. For palette change, it would be easier.

DCurrent · Jul 23, 2018

O Ilusionista said:
If it would be opened to script, it would be great to use tint instead of sacrificing palette.

Click to expand...

For tint, we already have ondrawscript. For palette change, it would be easier.

I think what he means is, the dying property status. As in, accessing it to know when the the dying state is active. Which, as part of my property access project, will be open. But that said, using ondrawscript without bothering with dying property would still be easier. Just check for a certain life threshold and then use timer to intermittently apply a tint. That's exactly how the hard coded dying effect works already, it just happens to use palettes.

OpenBOR v3.0 Build 6330 (Android/PSP/WII/WINDOWS)

Member

New member

Member

New member

OpenBOR Developer

New member

OpenBOR Developer

New member

Captain 100K

New member

Well-known member

New member

Well-known member

Captain 100K

Active member

Site Owner, OpenBOR Project Leader

Well-known member

New member

Captain 100K

Site Owner, OpenBOR Project Leader