sounds like a good idea I will look into it.
OpenBOR v3.0 Build 6203 (Android/PSP/WII/WINDOWS)
- Thread starter msmalik681
- Start date
- Status
White Dragon
New member
for your surprise It was my lack from backpain times.
Now I added it!
Here the news:
fixed nosame colour
fixed wall deflect
fixed control key names
added aiflag "rising" and "riseattacking" to script (aiflag property)
new animations:
added backrise and backriseattack
backrises, backriseb, backriseattackb, backriseattacks,
backshock, backburn, backbpain, backspain
I remember you that backpain animations work JUST if you set
backpain 1
into your header entity file
and the attack did not set forcedirection
Enjoy!
Ps. No compiled version yet, so compile by yourself for now..
Now I added it!
Here the news:
fixed nosame colour
fixed wall deflect
fixed control key names
added aiflag "rising" and "riseattacking" to script (aiflag property)
new animations:
added backrise and backriseattack
backrises, backriseb, backriseattackb, backriseattacks,
backshock, backburn, backbpain, backspain
I remember you that backpain animations work JUST if you set
backpain 1
into your header entity file
and the attack did not set forcedirection
Enjoy!
Ps. No compiled version yet, so compile by yourself for now..
Great job white dragon.
O Ilusionista
Captain 100K
Nice, I think those animations makes sense.
There is something we could think for the future - the duck animation. Right now, even we can changing this behaviour with script, the way it works now doens't makes much sense or is efficient.
Because when you are in DUCK animation an executes and attack, it will revert to the DUCK animation after its done - but the DUCK animation had ducking sprits, which makes it look weird. And if you remove those frames, it will looks weird too.
In Mugen, this animation is split into 3 states (states and animations aren't tied in Mugen, but is not the point here, just treat it as animations):
10 Stand to crouch Finite looptime
11 Crouching
12 Crouch to stand Finite looptime
So, my idea would be - on a far future and if DC agrees with it - to add two new animations: DUCKING and DUCKRISE. The first would be trigger BEFORE the DUCK animation and, after its finished, the entity would remaing in DUCK animation. After the DUCKATTACK, the entity would go to DUCK animation again. And when you release the down directional, it would go to DUCKING animation and not IDLE. For sure, all of this should happen only if those animations are available - if not, it would use the DUCK as it use now (kinda the same which happens when you use a BURN type attack but doens't have a BURN animation, instead the engine will use FALL). This would prevent of breaking any old mod.
How hard it would be to implement? I think I will suggest this at GitHub too.
There is something we could think for the future - the duck animation. Right now, even we can changing this behaviour with script, the way it works now doens't makes much sense or is efficient.
Because when you are in DUCK animation an executes and attack, it will revert to the DUCK animation after its done - but the DUCK animation had ducking sprits, which makes it look weird. And if you remove those frames, it will looks weird too.
In Mugen, this animation is split into 3 states (states and animations aren't tied in Mugen, but is not the point here, just treat it as animations):
10 Stand to crouch Finite looptime
11 Crouching
12 Crouch to stand Finite looptime
So, my idea would be - on a far future and if DC agrees with it - to add two new animations: DUCKING and DUCKRISE. The first would be trigger BEFORE the DUCK animation and, after its finished, the entity would remaing in DUCK animation. After the DUCKATTACK, the entity would go to DUCK animation again. And when you release the down directional, it would go to DUCKING animation and not IDLE. For sure, all of this should happen only if those animations are available - if not, it would use the DUCK as it use now (kinda the same which happens when you use a BURN type attack but doens't have a BURN animation, instead the engine will use FALL). This would prevent of breaking any old mod.
How hard it would be to implement? I think I will suggest this at GitHub too.
MaxBeta
Member
I downloaded ver.6212 last night, the latest build from msmalik681 because I cannot get any of the later builds from White Dragon to unrar for some reason.
I tested on Wii and get a black screen as soon as it loads.
I will test build 6203 tonight and make a thread based on Wii builds only based on three different builds.
I will be reporting on the following builds which I consider the most crucial for the Wii at this point;
- 4432 because of stability on windows.
- 4153 because imho it runs many of the more demanding paks on Wii.
- 6203 because it is the most recent release.
I will provide videos to illustrate issues as well.
Hopefully this will make ironing out issues for Wii port more feasible?
Let me know and thank you all for your continued efforts to provide an awesome engine for all to enjoy.
I tested on Wii and get a black screen as soon as it loads.
I will test build 6203 tonight and make a thread based on Wii builds only based on three different builds.
I will be reporting on the following builds which I consider the most crucial for the Wii at this point;
- 4432 because of stability on windows.
- 4153 because imho it runs many of the more demanding paks on Wii.
- 6203 because it is the most recent release.
I will provide videos to illustrate issues as well.
Hopefully this will make ironing out issues for Wii port more feasible?
Let me know and thank you all for your continued efforts to provide an awesome engine for all to enjoy.
OpenBOR v3.0 Build 6291 added to releases.
MaxBeta
Member
Very true but the same issues remained until recent builds, in fact the last most stable build for Wii is 4153, or at least the one that loads most mods that seem to crash on all recent builds. This is why I will report on three different builds to see what can be done about it.nsw25 said:
Sometimes real life gets in the way you know? And I never really make any promises.nsw25 said:
I still haven't been able to find a good vWii loader for OpenBor myself so you are better off just starting the WiiU in vWii mode (Power on the Wii U console and then press and hold down the B Button on the Wii U GamePad, Wii Remote, or Wii U Pro Controller when you see the Wii U logo splash screen.) and then going to vWii Homebrew. Besides, atm it takes about 2 different builds to run many OpenBor mods because most will work on one build (4153) and others will either not work entirely because of Wii memory limitations or just run on build 4432.
Also, not trying to be rude here but youtube is loaded with way better tutorials than any explanation I could have given you at the time. It did take me a while to get everything set up to my liking with WiiU homebrew but I did learn it all from youtube videos. Also, because of the issues that OpenBor has accumulated over the Wii port builds I find it only logical that people have strayed away from it and not passed it over to the WiiU side even as a loader, but yeah, first thing you would need is a good vWii channel and there is none.
Will test Wii port tonight and report back. Thank you.msmalik681 said:
O Ilusionista
Captain 100K
Guys, I got the latest build to test.
While I don't have that sdl error anymore, I am having an issue with the screen on android.
There is a empty area on the lower part of the screen, which covers everything including the buttons. If you try to press the buttons on that area, it doesn't works.
If I try to change to fit to screen, it resizes the screen excluding that empty area
See the gallery https://postimg.cc/gallery/2lit9993w/
It seams that is caused by sdl, and each sdl update always leads to bugs.
Question: was it really necessary to keep update the SDL version?
While I don't have that sdl error anymore, I am having an issue with the screen on android.
There is a empty area on the lower part of the screen, which covers everything including the buttons. If you try to press the buttons on that area, it doesn't works.
If I try to change to fit to screen, it resizes the screen excluding that empty area
See the gallery https://postimg.cc/gallery/2lit9993w/
It seams that is caused by sdl, and each sdl update always leads to bugs.
Question: was it really necessary to keep update the SDL version?
Once i figure out how to compile sdl i will find a more stable build for android.
MaxBeta
Member
So I tested build 6291 last night on Wii and here is what I can report;
- its seems having more than one pak will result in a black screen after the Splash page.
- So basically there is no pak selection menu anymore.
- I tested the same mods that run on build 4153 and most of them either crash or have the same gameplay issues. ( I will elaborate on a separate post this weekend)
Also, could it be possible to implement the libwupc libraries for the Wii U Pro controller to further updates?
They've included the use of the libraries for pretty much every Wii homebrew application and the controller really predates the old Wii nunchuk combo in both practicality and functionality, specially for old school stuff like OpenBOR that doesn't require any kind of motion controls.
The source files for implementation can be found here:
https://gbatemp.net/threads/libwupc-a-wiiu-pro-controller-library-for-wii-homebrew-applications.371574/
Please, this would definitely make a great deal of difference with testing and would no doubt enhance the gameplay factor the engine has to offer. Its just a much better controller in general and doesn't require pesky batteries all the time.
- its seems having more than one pak will result in a black screen after the Splash page.
- So basically there is no pak selection menu anymore.
- I tested the same mods that run on build 4153 and most of them either crash or have the same gameplay issues. ( I will elaborate on a separate post this weekend)
Also, could it be possible to implement the libwupc libraries for the Wii U Pro controller to further updates?
They've included the use of the libraries for pretty much every Wii homebrew application and the controller really predates the old Wii nunchuk combo in both practicality and functionality, specially for old school stuff like OpenBOR that doesn't require any kind of motion controls.
The source files for implementation can be found here:
https://gbatemp.net/threads/libwupc-a-wiiu-pro-controller-library-for-wii-homebrew-applications.371574/
Please, this would definitely make a great deal of difference with testing and would no doubt enhance the gameplay factor the engine has to offer. Its just a much better controller in general and doesn't require pesky batteries all the time.
White Dragon
New member
next openbor needs more memory I think...
sammyrms1
Member
Now I'm having issues with the button mapping on the latest version. When I mapped the controls to a specific button or key, sometimes it would do a wrong command. Also noticed that when I remapped the special button to the "S" key, the default "F" key also triggers the special. (I'm using a keyboard and DS4 via InputMapper)
- Status