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

Status
Not open for further replies.
White Dragon said:
magggas said:
...
Click to expand...

OK I need to rewrite the nosame function...
Click to expand...

By the way about the second issue with the color map, this is happening even with 2 players as well and if:
1. there are weapons in game to pickup
2. players are allowed to use the same character.
3. when player 2 is starting the game and player 1 joins later. Then when player 2 loses his first credit everything comes back to normal again.

Should i still post it on github as reminder for later look on it or i don't need it anymore?

 
White Dragon said:
Magggas explain me why the bug of set weapon is related to nosame?
Click to expand...

I did not say anything like that. I'm talking just about nosame it self. It is just that the color palette swapping issue happening when the player 2 picks up a weapon.

To explain it better how and what happens.
When you set NOSAME 0 2 or NOSAME 0 1 it means you can select the same character but not the same color palette. Then with this setup the color palette swapping issue is triggered only if:
The player 2 is starting the game and player 1 joins later. Then the color palette swapping is happening when player 2 picks up a weapon.

Here  you can see it in action and how everithing is coming back to normal after player 2 is loosing the first credit:
If you guys still need more information or explanation, just tell me. I'm trying to explain it as best as i can.
 
White Dragon said:
And with nosame unset (nosame 0), is it OK?
Click to expand...

Yes, i tested this as well right now and with nosame 0 0 the same character can have the same color palette no matter which player starts the game. So this is the normal behavior as expected with nosame 0 0.
 
magggas said:
White Dragon said:
And with nosame unset (nosame 0), is it OK?
Click to expand...

Yes, i tested this as well right now and with nosame 0 0 the same character can have the same color palette no matter which player starts the game. So this is the normal behavior as expected with nosame 0 0.
Click to expand...

ok, so if the player changes to weapon the colourmap remains 2 if the original is 2 for example (billy remains billy after change and jimmy remains jimmy).
just to be sure that the issue is related to NOSAME
 
White Dragon said:
ok, so if the player changes to weapon the colourmap remains 2 if the original is 2 for example (billy remains billy after change and jimmy remains jimmy).
just to be sure that the issue is related to NOSAME
Click to expand...

I have made some more tests to cover all situations. So yes i case of nosame 0 0 no colourmap swapping happens when picking up a weapon. The colourmap swapping is only happening when nosame is active like nosame 0 1 or nosame 0 2, and then only if p2 started first the game and then when p2 picks up a weapon. Yeah, crazy thing!

But you know what? Aside all this above, the nosame 0 1 or nosame 0 2 is not working correctly in first place anyways, since you can still choose the same colourmap for the same char in select screen or in game, even if this command should not allow it!
 
O Ilusionista said:
Dunno if this helps, but the last build which changed this function was 4183
http://www.chronocrash.com/forum/index.php?topic=3077.0
Click to expand...

All the nosame bugs i posted are there even on build 4107.
I will try to hunt and test on may older versions to see when started and i will post the results later today.
 
BIG thanks guys!!
Sorry DC but I rewritten nosame related functions.
After some tests it seems all ok!!
You guys are a valid help for this wonderful engine!!
Really thanks!!  ;)

PS. DC you like you can  or adjust or improve my funcs!!
I know well nosame and so I can write the right funcs.

Byeee
 
I have finished my tests with some interesting results.
The last build where the first flag(no same char) of the nosame command was working normally was the OpenBOR_v3.0_Build_3842. Then it stopped doing so since OpenBOR_v3.0_Build_3846.

The second flag of  the nosame command about no same colormap, was never actually worked i would say, because i have tested down to OpenBOR v2.2068 and the same chars could still choose the same colormap even if the command should not allow it.
So this one was a really ancient bug of which i could not find exactly when it started.

Yeah, at this point i would say rewrite the nosame function is not a bad idea  ;D
 
magggas said:
I have finished my tests with some interesting results.
The last build where the first flag(no same char) of the nosame command was working normally was the OpenBOR_v3.0_Build_3842. Then it stopped doing so since OpenBOR_v3.0_Build_3846.

The second flag of  the nosame command about no same colormap, was never actually worked i would say, because i have tested down to OpenBOR v2.2068 and the same chars could still choose the same colormap even if the command should not allow it.
So this one was a really ancient bug of which i could not find exactly when it started.

Yeah, at this point i would say rewrite the nosame function is not a bad idea  ;D
Click to expand...

OK magggas big thanks!!
If you can compile I committed the new working (I hope) nosame!
 
Sorry but i can't compile by myself, i have no idea how all this works  :-[
So i will be able to test the new nosame once someone else will compile the new update.
 
Status
Not open for further replies.
Back
Top Bottom