OpenBOR 4.0 4.0 Build 7735
- Thread starter DCurrent
- Start date
No issues at all with Boss I am aware of, and that part of the code was not changed. You'll need to be more specific please.
DC
kimono
Well-known member
As I mentioned in the Golden Axe Remake thread, both Bad Brothers died during the first boss encounter. The game continues, doesn't advance to the next level, and it's impossible to exit via the menu. I only have this problem in version 7735; I didn't have it before in version 3.0 6412. I can upload an archive for testing.
I haven't seen those posts. I'll take a look when I can - am currently very busy on another project.
DC
That statement doesn't make sense @kimono, I think there might be a language barrier issue. Are you saying they play a block animation, or that they are trying but can't get past the wall?
If its the latter, you need to adjust the jump ranges, which you should be doing anyway. 3.0 had very over generous ranges that were sub-optimal. 4.0 tightens them up quite a bit, and Golden Axe sprites are not sized for what the defaults are meant for.
DC
kimono
Well-known member
Enemies and NPCs advance towards a wall and become stuck in front of it, remaining indefinitely in an anim block.
I can make a video of this phenomenon.
Last edited:
I have said this before: I highly recommend never using Victory. I did not add that feature, and the way it works internally is very lazy and very unstable. Essentially, Victory is a pain animation - the dead boss hits players with a full screen attack that triggers the "Victory". It doesn't take much thought to realize that set up is easily broken by a variety of in game conditions.
It's one of many reasons that person is no longer on the development team. I only left the functionality there as is for backward comparability. Since the policy post 4.0 release is no longer keeping backward compatability for its own sake, I will likely depreciate or change the way it works.
Until then, If you want a victory animation, you are far better off scripting one. It's not complex at all to set up.
Yes. All documented here. Compared to 3.0, OpenBOR 4.0 changes the following:
Default ranges are more tuned. Specfically, the default X axis for jumps is 50 and 60 in both, but in 3.0 the Base axis range is -1000 to 1000. In 4.0 it is calculated with a forumla similar to the other axes
3.0 - Basically says "F*** it" and uses an absurdly huge area for Y and Base axis:
4.0 - Defaults are much tighter and therefore more optimal:
In both cases, they are tuned for typical KOF/Street Fighter sized sprites and platforms, since that's the vast majority of use cases. You'll need to set your own ranges for Golden Axe.
4.0 also adds the air control property and allows you to adjust the global jump height. Everything else is identical to 3.0:
Jumping – OpenBOR Wiki
chronocrash.com
HTH,
DC
kimono
Well-known member
Thanks Damon, your posts are always very detailed and interesting.
I'm going to think about writing a script that checks if any enemy entities remain in the level.
I'll admit that I wouldn't mind if an animation victory were included later under a less intrusive mechanic; if it's not planned, I'll manage
I'll do some tests regarding the range in that case, thank you!
I'm going to think about writing a script that checks if any enemy entities remain in the level.
I'll admit that I wouldn't mind if an animation victory were included later under a less intrusive mechanic; if it's not planned, I'll manage
I'll do some tests regarding the range in that case, thank you!
For people dropping negative reviews on the engine due to port problems - ports have NOTHING to do with the engine or its codebase, and those reviews are removed on sight. Just one more reason I am against porting the engine to consoles.
Many of those ports are not even made by by us. Also, I agree with @O Ilusionista from earlier in the thread. At this point, the Wii port is nothing but an albatross making us look bad. Next official release, it's gone.
DC
Many of those ports are not even made by by us. Also, I agree with @O Ilusionista from earlier in the thread. At this point, the Wii port is nothing but an albatross making us look bad. Next official release, it's gone.
DC
Sorry, I was too fast with my raw review, I didn't want to discredit your great work! I'm glad to see that the Wii platform is supported again, but what a pity that the latest release 7735 do not start games, is there an memory check that prevents games from loading?
Thats not an albatross, it is a fine gem that the Wii is supported and there is still a big gamer community behind the Wii.
It would be sorrowful if you drop the Wii support :-(
Thats not an albatross, it is a fine gem that the Wii is supported and there is still a big gamer community behind the Wii.
It would be sorrowful if you drop the Wii support :-(
Last edited:
O Ilusionista
Captain 100K
That is the point.
It's not a problem with the engine itself, but rather with how much RAM the Wii has (88MB, if I am not wrong). Unless a game developer designed it specifically for the Wii, there's no guarantee that a game developed in OpenBOR will work on the Wii.
First, because you need to use the same version and build used for development. Second, the console may simply not have enough memory to run a game that was never initially intended to run on it.
That's exactly why the PSP version was discontinued and the Wii version will follow the same path – and it's about time.
Anyone who wants to continue developing OpenBOR games that run on these legacy platforms can simply use legacy versions.
I appreciate the comment - no worries. Still, my decision stands.
To be clear, it would be more accurate to say the Wii port is already dropped, and has been for quite some time. All I would do now is make it official and remove the remnants.
The issue is maintenance. The developers who originally handled the Wii work are long gone, and I have no practical way to support it. I did not write a single line of code for the Wii. For me to support it now, I would have to buy a Wii to test on, rebuild my dev environment, and learn an entirely unfamiliar toolchain and platform-specific APIs. That is a completely unjustifiable investment of time, effort, and resources for hardware released in 2006, with a comparatively minuscule user base and limited system resources.
About build 7735 not loading games - I do not believe it is a deliberate “memory check” meant to block anything. There certainly isn't any such thing in the core engine. It is far more likely the Wii code path has simply rotted over time as the engine evolved, so newer changes are incompatible or untested on that platform. Since I cannot test or maintain it, I cannot responsibly debug it.
So, yes - Wii support is effectively gone, and I am not going to maintain it going forward. Sorry.
DC
@kimono,
Don't post errors without context. That has nothing to do with OpenBOR 4.0. The only "bug" is that the error is poorly worded, and it's same across all versions. You made a specific error in your module. I can't recall off the top of my head what causes that particular message, but it's an easy fix. @O Ilusionista and @Kratus, do you remember? I just can't seem to pull it out of my skull.
DC
Don't post errors without context. That has nothing to do with OpenBOR 4.0. The only "bug" is that the error is poorly worded, and it's same across all versions. You made a specific error in your module. I can't recall off the top of my head what causes that particular message, but it's an easy fix. @O Ilusionista and @Kratus, do you remember? I just can't seem to pull it out of my skull.
DC
O Ilusionista
Captain 100K
I think is this error: [SOLVED] Strange error never seen before@O Ilusionista and @Kratus, do you remember? I just can't seem to pull it out of my skull.
its an invalid weapon name
Last edited:
kimono
Well-known member
I'm sorry DC, if I had more details in the Openborlog, I certainly would have sent it.@kimono,
Don't post errors without context. That has nothing to do with OpenBOR 4.0. The only "bug" is that the error is poorly worded, and it's same across all versions. You made a specific error in your module. I can't recall off the top of my head what causes that particular message, but it's an easy fix. @O Ilusionista and @Kratus, do you remember? I just can't seem to pull it out of my skull.
DC
And yes, it's a weapon model issue, thanks for the feedback
maxman
Well-known member
Those sound cool for faster movement as an idea, but as a plugin, I have doubts about installing light-gun and mouse controls since each controller requires specific moving keys, as well as action ones. For a mouse, it's just 2 clicks. For light gun, just one action button, but the problem is this: Where are the directional keys for moving the gun? The player indexing assignment for specific keys is a problem when it comes to unusual controllers (e.g. light gun, mouse) that are quite different from a joystick or a regular controller. This is like using the NES light gun to play Super Mario Bros. instead of Duck Hunt.