OpenBOR Test Build 6392

Kratus

Kratus

OpenBOR Developer
Staff member
Hey guys!
I'm happy to launch my first contribution for the engine. This is a test build only, it would be good if everyone can test and bring feedback. The update contains the following fixes:

- Fixes some controller issues and improve button detection

- Fixes the "multihit" glitch when two or more characters are hitting the same opponent. Added a new option in the cheat menu to enable/disable it. If modders are using it as a feature of your games, I can think about making it optional by creating a new script function

- Added a new script function "backtotitle(flag)". As the name says, this function instantly bring you back to the Title Screen with the same effect as the "ESC" key. It's similar to the "gotomainmenu" but you don't need to confirm the character selection and wait until the first level is loaded. You can use "flag 1" to enable or "flag 0" to disable. Currently, it works only on the Select Screen as a experimental feature and you can use it together with the "playerkeys" function.

This build is using the 6391 as base. In addition, after some tests I discovered that an important fix was made in the "juggle" feature to avoid negative numbers, thanks to msmalik681
Now if an "atbox" has the "jugglecost" function declared, every entity that can be hit in the air need to have the "jugglepoints" declared too, otherwise the collision is disabled. 

It helped me a lot to adapt SOR2X to the build 6391 and I hope it can help other modders too.

Here's the test build:
https://1drv.ms/u/s!AnTXKPMHlONnhNdMWJAzM17ux7TZ2A?e=TQn0iY
 
Nice, buddy. Its good to see that you decided to keep this project.

Now if an "atbox" has the "jugglecost" function declared, every entity that can be hit in the air need to have the "jugglepoints" declared too, otherwise the collision is disabled.
Click to expand...
Can you give more info about this?
 
O Ilusionista said:
Nice, buddy. Its good to see that you decided to keep this project.

Now if an "atbox" has the "jugglecost" function declared, every entity that can be hit in the air need to have the "jugglepoints" declared too, otherwise the collision is disabled.
Click to expand...
Can you give more info about this?
Click to expand...

Thanks buddy!

About the juggles, in the 6330 I had some problems during the OTG development in SOR2X because this build allows negative jugglepoints when it reaches 0. After testing the 6391, I could see that this did not happen. I discovered this new change a few weeks ago when I compared the commits between builds 6330 and 6391, and then I saw this "juggle" fix.

I never jumped to the 6391 due to some collision problems when the characters are in the air. For example, if an enemy throws a knife against you, SOR2X allows the player to hit thrown weapons in mid-air but never worked in the 6391.
Another example is the same as the video I posted. Once the Bulldozer hits the column at the end of the stage 3 in SOR3 route, a barrel will drop and hit Donovan's head. If you look at the positions, it's possible to see that this Donovan is 16 pixels above the ground.

Then I replaced the Donovan by a normal character and it strangely worked. After to connect the facts, I could see that the only difference is just the "jugglepoints" that this specific Donovan version doesn't have.
After doing more tests I could confirm that if a animation has "atboxes" and there's a juggle "cost" on it, your opponent needs to have the "jugglepoints" function declared in your header to subtract if get hit in the mid-air, otherwise the collision will be disabled.

The same does not happen in 6330, an entity can hit another in the mid-air even if he doesn't have the "jugglepoints" function declared.
There's some exceptions, for example if you declare the "jugglecost" function but the value is 0, it will hit normally even if the target doesn't have the "jugglepoints" function in your header.

Conclusion: in the build 6391 (and above I think), the "jugglepoints" is a mandatory function if you are planning to use the "jugglecost" function in all character's "atboxes".

Juggle points test
https://www.youtube.com/watch?v=KiiWJYDsQ_M

And here's a demo of the "multihit" glitch:
https://www.youtube.com/watch?v=_VUOfO0PEVc
 
Avast is making a fuss about openbor.exe, why is that ? ITs fhe first time even i have such warning
 
awsome, controler issues was the thing preventing 6391 from being almost perfect, will test later on and let you know if i encounter any bug.
 
Great work Kratus but the juggle system is not really broken if a hit has a juggle cost the enemy must have enough juggle points to take that hit or it should miss.  If a game has juggle attacks all enemies should have juggle points.

Gotomainmenu(3); will get you back to the title screen!

I agree with the mutihit glitch join the development team and run the updates over with DC to get the updates into the official builds.
 
msmalik681
Thanks man!

the juggle system is not really broken if a hit has a juggle cost the enemy must have enough juggle points to take that hit or it should miss.  If a game has juggle attacks all enemies should have juggle points
Click to expand...
Sorry, maybe I don't explain myself very well. I didn't say that the juggle system is "broken", I said that you fixed it and from 6391 and above it works correctly. In fact it's broken in the 6330 build.

Gotomainmenu(3); will get you back to the title screen!
Click to expand...
Yeah, I know that, but using this function you need to wait until the first level is loaded. In the new function I added it has the same effect as the "ESC" key and you will instantly go back to the title screen.
I created this function because the Windows build doesn't have access to the "ESC" key from joystick.

bWWd
Strange, I tested in another PC using the Avast and it really warned. It did not happens in other antivirus programs.
I will do more tests, thanks for the repport.

nsw25 and Gurtag
Thanks, I will await for your feedbacks  :)
 
msmalik681 said:
Ok sorry I miss understood.
Click to expand...
No problem buddy, it was my fault to not explain some details.
Thank you by doing this juggle fix and for all tutorials too :)
 
nsw25 said:
Bad news the android version crashes and freezes with webm
Click to expand...
Hmm maybe our games has some differences. My games are playing webm videos in Android normally.
Are you playing webm by script or by cutscene files?

Edit: Can you post the log? Below is a video showing the webm files working on Android.

https://www.youtube.com/watch?v=WKSYBQRig7s
 
I see that You enabled gyroscope on android ? Id suggest to disable it, i have gamepad gamesir x2 which makes portable console from phone, usb c and no latency but when i use it with openbor then player 2 is joining the game becaxuse default openbor setup for player2 inputs are axis for gyroscope, so when i move my phone during playing then player2 joins.
currently i workaround that and map player2 attack into some unused button and player2 up/down to something else cause it also screwsup menu and registers up/down movement when you dont want to.
In older versions gyroscope doesnt work, i remember whitedragon enabled and disabled it , it should be off definitely, no one would play fighting game using gyroscope in phone.
 
bWWd

Thanks for the feedback. In fact I didn't enabled the gyroscope on android, it's because I used the build 6391 as base and in this version the gyroscope is already enabled.
However, I will check if it's possible to create a new option to disable it in the menu.

nsw25

No problem, thanks for your feedback. The controllers update is the most important change in this version and I hope everything go well.
If you encounter any problem, I can check out and try to fix it in the source code.
 
another solution would be to change player 2 default contrls in sourcecode sonit wont use joystick axis but keyboard letters
 
I may be out of subject but adding an option in android port, for those who use a gamepad, to have no buttons on screen (fully transparent buttons) could be great.
 
kimono said:
I may be out of subject but adding an option in android port, for those who use a gamepad, to have no buttons on screen (fully transparent buttons) could be great.
Click to expand...
This is a good idea. At present, the transparency of the Android buttons cannot be changed. I also support the hope that the button transparency settings can be added in subsequent versions (the values can be 25% 50% 75% 100%), similar to the "jugglepoints" switch setting you just added. Kratus

I thought about setting this feature a long time ago.
 
Im not sure what you mean guys ? Buttons disappear when you dont touch the screen for like 5 seconds, it works great with gamepad but i would add something to clean all inputs in menu or something and set them to NONE but not all at once, separately for each player .
Why? cause i have  a lot of buttons to map these player2 axis defaults so it doesnt interfere and join the game.
Currently i have to map attack,special,start and jump to some unused physical buttons on gamepad, because if i dont then eveyrtime i move my phone it will register random gyroscope input and player2 will join the game.
Currenlty android port is not really fully playable when your gamepad is connected because of it, in my opinion key input mappings for player 2,3,4 should stay the same as on pc when you connect gamepad, currently they change for whatever reason, i checked with and without gamepad on android and key mappings are different when openbor runs with gamepad connected like if it tries to dedect gamepad and map its inputs partially for player 2 but it fails.

So... for now i went back to my own build that was made from msmalik branch , it works fine and gyroscope is not registered when i move my phone randomly unlike this new version, which even with my temporary workaround goes back to its default remapping for player2( yeah i setup player2 uinputs , save them and after awhile they go back to default ones and gyro is affecting my gameplay) i just dont have time to figure oyut why it keeps resetting player2 inputs to axis of the gyro...
 
Maybe this is from the Sdl updates i did bWWd this sounds like a serious issue that needs fixing i will look into it.
 
bWWd said:
Im not sure what you mean guys ? Buttons disappear when you dont touch the screen for like 5 seconds, it works great with gamepad but i would add something to clean all inputs in menu or something and set them to NONE but not all at once, separately for each player .
Why? cause i have  a lot of buttons to map these player2 axis defaults so it doesnt interfere and join the game.
Currently i have to map attack,special,start and jump to some unused physical buttons on gamepad, because if i dont then eveyrtime i move my phone it will register random gyroscope input and player2 will join the game.
Currenlty android port is not really fully playable when your gamepad is connected because of it, in my opinion key input mappings for player 2,3,4 should stay the same as on pc when you connect gamepad, currently they change for whatever reason, i checked with and without gamepad on android and key mappings are different when openbor runs with gamepad connected like if it tries to dedect gamepad and map its inputs partially for player 2 but it fails.

So... for now i went back to my own build that was made from msmalik branch , it works fine and gyroscope is not registered when i move my phone randomly unlike this new version, which even with my temporary workaround goes back to its default remapping for player2( yeah i setup player2 uinputs , save them and after awhile they go back to default ones and gyro is affecting my gameplay) i just dont have time to figure oyut why it keeps resetting player2 inputs to axis of the gyro...
Click to expand...
bWWd
In the Android I'm playing with touchpad, but I will do some tests with additional controllers.
In fact the changes I did are focused on Windows issues, not Android.

kimono / pudu
Changing the transparency value can be a good idea, but I think that currently it can be changed by replacing the default button images by a new one.
Pudu made it before.

EDIT:
Tested with PS4 controller in the Android phone and I can confirm that the gyroscope really have some issues.

EDIT2:
After more tests, I see that the same problem happens in the original 6391 build. So, this gryroscope problem is not related to the latest changes made in the 6392, it is a problem carried from the 6391.
Nothing was changed in the Android source code, I'm using the latest master-build folder. But I will continue trying to find a solution for this.

msmalik681
I compiled the Android build using the latest master branch, exactly where the gyroscope code is. I'm wonder if there's too much differences between malik-branch and master-branch related to the gyro
 
Hello Kratus

the controller issues seem to be gone, but the other comments about the gyro are correct, in the PC i have a really hard time mapping wiimotes because the engine detects x & y axises, so a similar issue happens with cell phone gyro (only solution is to hold the phone in neutral position)

I see the elevator issue  is still there tho, & it seems extrange since streets of rage "needs" the elevators to go up (well, at least the one in streets of rage one)

at the moment i ran out of batteries on the wiimote, i wanted to test if the continue countdown bug was still there

test hardware:

wiimote
xbox 360 usb
adaptoid (n 64 controller)
sabrent usb

 
Hello oldyz

the controller issues seem to be gone
Click to expand...
Good! This is the main goal of the update, specific for the Windows build

but the other comments about the gyro are correct
Click to expand...
Yeah, I can confirm that. I'm looking for a solution, this problem was carried from the previous build

I see the elevator issue  is still there tho, & it seems extrange since streets of rage "needs" the elevators to go up (well, at least the one in streets of rage one)
Click to expand...
What is exactly this problem, do you have any video to show us an example? If it's related to moving platforms, nothing was changed in this aspect

i wanted to test if the continue countdown bug was still there
Click to expand...
Nothing was changed in this aspect too. I made very small updates because this is my first time editing the engine. The only changes are related to the controllers and the atboxes (to solve the multihit issue)

Thanks for your feedback  :)
 
You must log in or register to reply here.
Back
Top Bottom