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 4.0 Build 7735
- Thread starter DCurrent
- Start date
O Ilusionista
Captain 100K
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 100K
@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 100K
Probably. Its funny that it happens once the entity rebounds on the floor.
O Ilusionista
Captain 100K
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.
@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 100K
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 100K
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:
O Ilusionista
Captain 100K
@DCurrent I am chating with @Kratus at discord and we saw something:
If you use an script to change from the IDLE landframe to a follow animation, it works.
But if you use the legacy ATTACK1 animation (which I do), once it bounces, it flies away.
But even if you use a script to change to a follow animation, there is something wrong in the gravity for sure: pay attention how the grenade falls slower and close to Leo (OB3) but faster, jumps higher and falls near the wall (OB4)
I can send you the game if you need it.
If you use an script to change from the IDLE landframe to a follow animation, it works.
But if you use the legacy ATTACK1 animation (which I do), once it bounces, it flies away.
But even if you use a script to change to a follow animation, there is something wrong in the gravity for sure: pay attention how the grenade falls slower and close to Leo (OB3) but faster, jumps higher and falls near the wall (OB4)
I can send you the game if you need it.
Sorry, I'm a little confused at what you mean here. Let's tackle these one at a time...
Mind posting the projectile code?
DC
Oh, @O Ilusionista, something that can help and you might not have seen in the notes. Try the new
DC
get_entity_property(<entity>, <property constant>) with openborconstant("PROPERTY_ACCESS_DUMP"). Then check the log to see what happens.
C:
void acting_entity = <some entity>;
get_entity_property(acting_entity, openborconstant("PROPERTY_ACCESS_DUMP"));DC