That's an oversight I didn't mean to keep. In fact it may already be fixed. I'll need to take a look.
OpenBOR 4.0 7556
- Thread starter DCurrent
- Start date
O Ilusionista
Captain 80K
Thanks. There is an explanation on the wiki talking about the legacy mode not having an index. But for sake of clarity, I really think it will be better to attack2 trigger pain2.
Dunno about what to do about type 0 though.
i think attack 0 and attack1 is just a typo in excel sheet, obviously theres no attack 1 and 0 , its just attack, even if its attack1 i think it should be treated as attack anyways to not break everything there is released up to date.
All the things look interesting but from our perspective nothing major was upgraded, its mosty internal callling /names getting rehash which in result is more work left for devs to make current projects or past projects compatible so... from that perspective it does not look so bright.
If it was up to me, id leave legacy commands intact but still introduce new more detailed ones.
Sure the engine would take up now like 5mb instead of 3.5mb but that is non issue, i get that it will be an issue for a dev to maintain all legacy and new commands but a total break of most mods of the past is pretty huge price.
For me personally, if V4 will support custom main menu placements,total custom select screen like actual level, hiding of the hud by script and 32bit png support then ill start using it right away , heck ill even rewrite what i already started on current v3 build.
Cause now even in v4 we cant disable credits in main menu or change main menu postition, and we cant have simpe 32bit png anywhere in game , and its a thing for like 20 years now, can you imagine ? 20 years and we still cant change such basic thing, we get super advanced script access to stuff but somehow very first thing that appears in the game gets overlooked for 20 years....
Yes i do have custom main menu but its scripted, not for everyone - not for newcomers, you have to be pretty deep into scripting to use it.
So ill stick with v3 for now cause theres quite a bit of work to be done if i want to use v4 now and it does not yet offer things that can really change the aesthetics of our games.
With that being said I think newcomers should use v4.
I am glad that engine has been cleaned up, its a big step forward.
All the things look interesting but from our perspective nothing major was upgraded, its mosty internal callling /names getting rehash which in result is more work left for devs to make current projects or past projects compatible so... from that perspective it does not look so bright.
If it was up to me, id leave legacy commands intact but still introduce new more detailed ones.
Sure the engine would take up now like 5mb instead of 3.5mb but that is non issue, i get that it will be an issue for a dev to maintain all legacy and new commands but a total break of most mods of the past is pretty huge price.
For me personally, if V4 will support custom main menu placements,total custom select screen like actual level, hiding of the hud by script and 32bit png support then ill start using it right away , heck ill even rewrite what i already started on current v3 build.
Cause now even in v4 we cant disable credits in main menu or change main menu postition, and we cant have simpe 32bit png anywhere in game , and its a thing for like 20 years now, can you imagine ? 20 years and we still cant change such basic thing, we get super advanced script access to stuff but somehow very first thing that appears in the game gets overlooked for 20 years....
Yes i do have custom main menu but its scripted, not for everyone - not for newcomers, you have to be pretty deep into scripting to use it.
So ill stick with v3 for now cause theres quite a bit of work to be done if i want to use v4 now and it does not yet offer things that can really change the aesthetics of our games.
With that being said I think newcomers should use v4.
I am glad that engine has been cleaned up, its a big step forward.
Last edited:
Happy New Year and thank you for this new version!
So far, I have only one problem with some misc entities in my mod (subject_to_gravity = 0 is not working now so I suppose I must declare every move_constraints flag for an entity (it's a misc entity for a heart effect that falls down to the floor instead of staying in air) to fix it), but it's perfectly compatible with the previous version! I will try to migrate my code to the new version and if I find some error I will let you know. Thanks again!
So far, I have only one problem with some misc entities in my mod (subject_to_gravity = 0 is not working now so I suppose I must declare every move_constraints flag for an entity (it's a misc entity for a heart effect that falls down to the floor instead of staying in air) to fix it), but it's perfectly compatible with the previous version! I will try to migrate my code to the new version and if I find some error I will let you know. Thanks again!
Odd, I didn't remove the old commands. In fact I spent a lot of time ensuring they work.
What happens under the hood is if you use the old one, the engine reads it and assigns appropriate value to the new style property. Maybe I overlooked subject_to_gravity. I'll take a look and make sure it's working.
Still, it's best to use the new way, and it will give you a lot more options.
DC
Last edited:
O Ilusionista
Captain 80K
I disagree with you on this, with the due respect. It's not a simple name change, there are some very useful things like control projectiles colors, riders using the same color of bikers and A LOT OF THINGS now are open to script. The open to script thing alone is a big change.
Which ones? the closing credits?
Yes you can. @Kratus made a code for that.
I understand what you say and I even agree with some points - I do think some points could be looked before others. But keep in mind that a lot of coding optmizing were done. Like a lot. If you compare the code count from one version from another, you will see it.
Plus, the dev team is small. And they were cleaning some coding that should never been there in the first place, like undocumented stuff or spaguetti-logic cases.
And while Kratus had helped a lot on this update, the biggest load was over DC shoulder alone. It's an Herculean task.
In other words, they need help. I did what I could, even it wasn't much (I've commited one single change if I am not mistaken). I wish I could had helped more...
About the custom menu, I remember Plombo was working on something like a XML version long time ago.
---
Would I prefer OpenBOR would work like Mugen does with legacy stuff (where once you put one tag, the engine will run the legcay code using legacy code, so you can mix different versions of Mugen coding into the same game)? Of course. But maybe this would turn into a nightmare to handle.
So do I. My only concern, from a quick test I did, it's to face the same thing I faced back in Flash days, where jumping from Actionscrip 2 to Actionscript 3 was pretty damn hard, while it was easier to simply learn it from scratch (for new users) or move to another engine (to old users). I had friends who managed to update to AS3, but I didn't and I ending moving to a new engine back in the day.
With that being said, I do plan to use 4 someday - I just can't do it right now.
I am working on 5 different games (3 are public, 2 private) so if I change one, I would need to change all of them - since they share the sabe code libary.
O Ilusionista
Captain 80K
@DCurrent I can confirm something is going on with the gravity.
I've recorded a video showing what is going on - once the grenade bounce into the floor, it will fly away
Info:
- I am tossing the grenade using TOSS function
@cmd toss "mgren" 22 42 -1
Grenade header:
Grenade attack1 animation (which happens when it lands on the ground)
I've recorded a video showing what is going on - once the grenade bounce into the floor, it will fly away
Info:
- I am tossing the grenade using TOSS function
@cmd toss "mgren" 22 42 -1
C-like:
void toss(void Bomb, float dx, float dy, float dz)
{ // Tossing bomb
void self = getlocalvar("self");
int Direction = getentityproperty(self, "direction");
int x = getentityproperty(self, "x");
int y = getentityproperty(self, "a");
int z = getentityproperty(self, "z");
if (Direction == 0){ //Is entity facing left?
dx = -dx; //Reverse X direction to match facing
}
projectile(Bomb, x+dx, z+dz, y+dy, Direction, 0, 1, 0);
}Grenade header:
Grenade attack1 animation (which happens when it lands on the ground)
It may be related to the subject_to_gravity backward compatibility code @afhc2x17 brought up. I will have a look at all that in next day or so.
DC
Yeah did you seen that custom menu code, its horrifying to look at, very complex, and it could of been hardcoded command with such simple syntax like - OPTIONS 400 200 , and thats it, yeah i have it but the amount of work required to just shift one simple text on main menu...
I appreciate opening stuff to script and all but there are some fundamental blockades since 20 years that i would like to see addressed one day... well maybe it will happen when im 60 who knows.
I mean we dont really need THAT much, giving access to all existing properties byt script at all times would be nice and a little more support for basics that got lost since bor was released, i still remember pushing for run animation to be included in the engine way way back and it was this one feature that pretty much flipped the coin and i decided to use the engine , im 10000000% sure people have that with 32bit pngs and openbor , if its not in the engine - they dont even bother.
I guess what i want to say all this time that there are IMO more important things to address than if we should use attack 100 80 40 50 or attack.size.x , y and all... cause players they dont care at all, me as dev i dont care at all i just prefere to type less, the names are way way way waaaaaaaaaaaaaay toooooooo long.
And yes its up to each dev what he spends his time on, ultimately we all do things that benefit us so obiously all this was done to make maintenance easier but if it will really be easier, not sure cause the code is pretty much untested and the real test is public release.
You can always make the code better, more compact, each new feature is a reason to rehash tons of others around it and its neverending story but in the end players dont care about this all at all , they just want to see nice looking game with pretty pics and good mechanics and thats why i complain about 32bit pngs and other basics.
Its not like i dont respect the time DC put into the release , sure i can sound like the entitled dood who just wants to see his ideas in the engine but i really think i suggest very basic stuff and it does bother me that theyre still not in the engine.
I appreciate opening stuff to script and all but there are some fundamental blockades since 20 years that i would like to see addressed one day... well maybe it will happen when im 60 who knows.
I mean we dont really need THAT much, giving access to all existing properties byt script at all times would be nice and a little more support for basics that got lost since bor was released, i still remember pushing for run animation to be included in the engine way way back and it was this one feature that pretty much flipped the coin and i decided to use the engine , im 10000000% sure people have that with 32bit pngs and openbor , if its not in the engine - they dont even bother.
I guess what i want to say all this time that there are IMO more important things to address than if we should use attack 100 80 40 50 or attack.size.x , y and all... cause players they dont care at all, me as dev i dont care at all i just prefere to type less, the names are way way way waaaaaaaaaaaaaay toooooooo long.
And yes its up to each dev what he spends his time on, ultimately we all do things that benefit us so obiously all this was done to make maintenance easier but if it will really be easier, not sure cause the code is pretty much untested and the real test is public release.
You can always make the code better, more compact, each new feature is a reason to rehash tons of others around it and its neverending story but in the end players dont care about this all at all , they just want to see nice looking game with pretty pics and good mechanics and thats why i complain about 32bit pngs and other basics.
Its not like i dont respect the time DC put into the release , sure i can sound like the entitled dood who just wants to see his ideas in the engine but i really think i suggest very basic stuff and it does bother me that theyre still not in the engine.
Last edited:
O Ilusionista
Captain 80K
Probably. Its funny that it happens once the entity rebounds on the floor.
Well, since there's not an engine on this planet that accepts raw 32bit png files, I wish them luck.
24bit + an alpha mask is a possibility and I'm already working on 24 bit for sprites and layers.
As for all that other stuff, I was there too, and you all got what you asked for. Back then it was all about Dreamcast. Every ##%&@@ post. DC this. DC that. Half the community were so obsessed they named themselves DCwhatever as their handles (funny to me since those are my real initials).
Part of that was climbing all over SX to make the DC port priority, and he did. Want to know why the select screen is so spartan? THAT. It's leftover cruft from SX breaking his back to make games run on that plastic toaster... and it was written in a way you can't touch it without absolutely wrecking backward compatibility. Only thing to do is replace and bypass it outright.
Also, I totally removed the credits, so I don't know where you got the idea they are in your way.
DC
Last edited:
O Ilusionista
Captain 80K
oh...so you are a Sega spy?
I don't want to sound a dick, but both Unity and Unreal accepts 32bit images (Godot don't).
For me, Its something we could have in the future? yes. Its something which should have top priority now? No.
I made sure to check on that before I posted, they really don't. They can use 32 bit textures (which they strongly advise you don't do), but not raw assets. It's not even a weakness. There's good reason for it. Same principle as why you always use indexed colors for sprites. It's just smarter to keep the mask and bitmap in separate files.
I happen to agree with them. There's no sensible reason to take 32 bit .png files when you can have 24 bit and a separate mask. Heck, it's a bit of an ordeal to even save as a 32 bit .png (I can't speak for Gimp, but AFAIK Photoshop won't do it on its own).
Unfortunately I can't add the masks short term, but it probably won't take me too long to add general 24bit support. I'll start with layers, then have a look at models.
DC
Last edited:
@O Ilusionista Buddy, what does this
@cmd velo001 function do? I added all your bomb header and script to my grenades but the issue does not happen.
O Ilusionista
Captain 80K
Pretty much the same of @cmd dasher
void velo001(float fX, float fZ, float fY){
C-like:
//velo001
//Damon Vaughn Caskey
//05/06/2007
//
//Replicates movement effect.
//
//fX: X axis speed.
//fZ: Z axis speed.
//fY: Y axis speed.
void vSelf = getlocalvar("self"); //Get calling entity.
if (getentityproperty(vSelf, "direction")==0){ //Is entity facing right?
fX = -fX; ////Reverse X direction to match facing.
}
changeentityproperty(vSelf, "velocity", fX, fZ, fY); //Apply movement.
}I can send you the game if you want to check.
Edit: sent through Discord.
all engines i tried accept pngs with alpha just fine.
I get it about psp, im sure android port will get rekt in the future as well but were here and adnroid platform is one of the main ones, id love to have ability to have ads available on android port like with actual games .
I dont know how many guys here did some paid projects for people with openbor, i did a couple of those and i hear about jaggies around characters often, and then it becomes a situation where you might lose a job opportunity... so thats why i push for alpha on pngs support without bothering with alphamask that has quirks with background type.
Even inputting paths to alphamask is just pain in the butt, i really wish there was automatic way to just have a alphamask in folder and if the frame name matches and alpha image is in folder then engine will use it , simple as that, i dont want to clutter my animations with 2 paths to images per frame, i already wrote a gui that generates the paths cause i simply cannot be bothered with all the typing.... compact is always better IMO, always.
So this @script void self = getlocalvar("self"); changeentityproperty(self, "velocity", (getentityproperty(self, "direction") == 1) ? 3 : -3, 0, 0);@end_script
Vs this crap:
@script
void self = getlocalvar("self");
if ((getentityproperty(self, "direction")==1)&&(frame == 1)){
changeentityproperty(self, "velocity", -2, 0, 0);
}
if ((getentityproperty(self, "direction")==0)&&(frame == 1)){
changeentityproperty(self, "velocity", 2, 0, 0);
}
@end_script
I get it about psp, im sure android port will get rekt in the future as well but were here and adnroid platform is one of the main ones, id love to have ability to have ads available on android port like with actual games .
I dont know how many guys here did some paid projects for people with openbor, i did a couple of those and i hear about jaggies around characters often, and then it becomes a situation where you might lose a job opportunity... so thats why i push for alpha on pngs support without bothering with alphamask that has quirks with background type.
Even inputting paths to alphamask is just pain in the butt, i really wish there was automatic way to just have a alphamask in folder and if the frame name matches and alpha image is in folder then engine will use it , simple as that, i dont want to clutter my animations with 2 paths to images per frame, i already wrote a gui that generates the paths cause i simply cannot be bothered with all the typing.... compact is always better IMO, always.
So this @script void self = getlocalvar("self"); changeentityproperty(self, "velocity", (getentityproperty(self, "direction") == 1) ? 3 : -3, 0, 0);@end_script
Vs this crap:
@script
void self = getlocalvar("self");
if ((getentityproperty(self, "direction")==1)&&(frame == 1)){
changeentityproperty(self, "velocity", -2, 0, 0);
}
if ((getentityproperty(self, "direction")==0)&&(frame == 1)){
changeentityproperty(self, "velocity", 2, 0, 0);
}
@end_script
If I understand correctly you are trying to simulate the bounce effect, right? I suggest trying to replace the velocity by tossentity because the first one will apply constant linear velocity, same as happening in your video.
I made the same with my dasher/leaper, the first uses velocity for linear projectiles like stars, and the second I'm using for grenades that moves in an arc.
O Ilusionista
Captain 80K
Yes, I am simulating the bounce effect - I know you would ask why I am not using bounce effector for that, that is because if we have many entities bouncing on ground, the bounce sound effect starts to get priority over over sound effects, cutting them. So I just use bounceeffect in cases where I will have only few entities.
If you wanna see it in action, go to the glass breaking bonus game in my Avengers game with Captain America and use his runnattack to break all the glasses - some sound effects will get cut.
About the replacing velocity by toss velocity, the question is why. Looks more the case of subject_to_gravity legacy code isn't being used correctly by the new version.
That's a pretty good idea actually, and I'll see if I can do something with it.
On ports, my personal feelings are screw them all and run PC only, but of course that's not practical. We'd be foolish to ignore Android, it's not going anywhere until some massive disruption comes along. Much as I hate Apple products, an official iPhone port would be great too, it's just not feasible at the moment.
Even the PSP was logical at the time. It did something a PC couldn't - put OpenBOR in your hand.
But the Dreamcast? That never made a lick of sense, but it's water under the bridge now.
DC
@afhc2x17 and @O Ilusionista
I just reviewed the code, and I don't see any issues with subject_to_gravity. All the values are as they should be. @Kratus, have you had any issues with gravity in SORX? Maybe a fresh pair of eyes will see something I missed.
Applying legacy input - If legacy subject_to_gravity input is > 0, then we set the bit flag for gravity to move_constraints member. If <= 0, we make sure the bit flag is unset:
Applying gravity - If the animation's move_config flag for gravity is set, we calculate a gravity value. Right below that, we check the model level move_config for its gravity flag, and if the gravity flag is set, we apply the calculated gravity value to velocity:
Unless I am missing something, this matches up with the legacy manual entry for subject_to_gravity:
Just for posterity, I also ran this post through ChaGPT - it's actually a really good debug tool, but it too comes up empty:
DC
I just reviewed the code, and I don't see any issues with subject_to_gravity. All the values are as they should be. @Kratus, have you had any issues with gravity in SORX? Maybe a fresh pair of eyes will see something I missed.
Applying legacy input - If legacy subject_to_gravity input is > 0, then we set the bit flag for gravity to move_constraints member. If <= 0, we make sure the bit flag is unset:
C:
case CMD_MODEL_SUBJECT_TO_GRAVITY:
/* Legacy code allowed -1 or 0 for False. */
if (GET_INT_ARG(1) > 0)
{
newchar->move_config_flags |= MOVE_CONFIG_SUBJECT_TO_GRAVITY;
}
else
{
newchar->move_config_flags &= ~MOVE_CONFIG_SUBJECT_TO_GRAVITY;
}
break;Applying gravity - If the animation's move_config flag for gravity is set, we calculate a gravity value. Right below that, we check the model level move_config for its gravity flag, and if the gravity flag is set, we apply the calculated gravity value to velocity:
C:
// gravity, antigravity factors
self->position.y += self->velocity.y * 100.0 / GAME_SPEED;
if(!(self->animation->move_config_flags & MOVE_CONFIG_SUBJECT_TO_GRAVITY))
{
gravity = 0;
}
else
{
gravity = (level ? level->gravity : default_level_gravity) * (1.0 - self->modeldata.antigravity);
}
if(self->modeldata.move_config_flags & MOVE_CONFIG_SUBJECT_TO_GRAVITY)
{
self->velocity.y += gravity * 100.0 / GAME_SPEED;
}Unless I am missing something, this matches up with the legacy manual entry for subject_to_gravity:
Rich (BB code):
subject_to_gravity {bi}
- This command determines how gravity effect entity.
- 0 = Gravity don’t have any effect.
- 1 = Gravity have effects. Default for most entities.
Just for posterity, I also ran this post through ChaGPT - it's actually a really good debug tool, but it too comes up empty:
The code snippets and the explanation in the post seem consistent with the described functionality. Let's break down the code and compare it to the provided information:
case CMD_MODEL_SUBJECT_TO_GRAVITY:
if (GET_INT_ARG(1) > 0)
{
newchar->move_config_flags |= MOVE_CONFIG_SUBJECT_TO_GRAVITY;
}
else
{
newchar->move_config_flags &= ~MOVE_CONFIG_SUBJECT_TO_GRAVITY;
}
break;
This code is consistent with the description in the post. If GET_INT_ARG(1) (presumably an argument from some input source) is greater than 0, it sets the MOVE_CONFIG_SUBJECT_TO_GRAVITY flag in newchar->move_config_flags. Otherwise, it ensures the flag is unset.
self->position.y += self->velocity.y * 100.0 / GAME_SPEED;
if(!(self->animation->move_config_flags & MOVE_CONFIG_SUBJECT_TO_GRAVITY))
{
gravity = 0;
}
else
{
gravity = (level ? level->gravity : default_level_gravity) * (1.0 - self->modeldata.antigravity);
}
if(self->modeldata.move_config_flags & MOVE_CONFIG_SUBJECT_TO_GRAVITY)
{
self->velocity.y += gravity * 100.0 / GAME_SPEED;
}
This code aligns with the explanation. It calculates the gravity based on certain conditions. If the animation's move_config_flags for gravity is not set, it sets gravity to 0. If the model's move_config_flags for gravity is set, it applies the calculated gravity to the entity's velocity.
Overall, based on the information provided, the code snippets appear to be correctly implementing the described logic for applying gravity and the legacy input for subject_to_gravity.
Applying Legacy Input (CMD_MODEL_SUBJECT_TO_GRAVITY):
ccase CMD_MODEL_SUBJECT_TO_GRAVITY:
if (GET_INT_ARG(1) > 0)
{
newchar->move_config_flags |= MOVE_CONFIG_SUBJECT_TO_GRAVITY;
}
else
{
newchar->move_config_flags &= ~MOVE_CONFIG_SUBJECT_TO_GRAVITY;
}
break;
This code is consistent with the description in the post. If GET_INT_ARG(1) (presumably an argument from some input source) is greater than 0, it sets the MOVE_CONFIG_SUBJECT_TO_GRAVITY flag in newchar->move_config_flags. Otherwise, it ensures the flag is unset.
Applying Gravity:
cself->position.y += self->velocity.y * 100.0 / GAME_SPEED;
if(!(self->animation->move_config_flags & MOVE_CONFIG_SUBJECT_TO_GRAVITY))
{
gravity = 0;
}
else
{
gravity = (level ? level->gravity : default_level_gravity) * (1.0 - self->modeldata.antigravity);
}
if(self->modeldata.move_config_flags & MOVE_CONFIG_SUBJECT_TO_GRAVITY)
{
self->velocity.y += gravity * 100.0 / GAME_SPEED;
}
This code aligns with the explanation. It calculates the gravity based on certain conditions. If the animation's move_config_flags for gravity is not set, it sets gravity to 0. If the model's move_config_flags for gravity is set, it applies the calculated gravity to the entity's velocity.
Legacy Manual Entry for subject_to_gravity:
The provided manual entry for subject_to_gravity:- 0: Gravity doesn't have any effect.
- 1: Gravity has effects. Default for most entities.
Overall, based on the information provided, the code snippets appear to be correctly implementing the described logic for applying gravity and the legacy input for subject_to_gravity.
DC
Last edited: