OpenBOR v3.0 Build 4432 (Windows/Wii/Android/PSP)

Status
Not open for further replies.
I know this isn't a request thread, but there is any chance to open control over BGSPEED by script? (in changelevelproperty).
This could be cool because it would let us stop autoscrolling stages, for example.

I remember there was a mod by KB which uses some bglayer controls but, if I am not wrong, those controls where removed from the code.
 
It's already in the engine Ilu. :)
Here's an example on how I autoscroll the background step by step to give acceleration effect:
Code: 
@script
    if(frame>0){
      int Speed = getlevelproperty("bgspeed");

      if(Speed==NULL()){
        Speed = 0;
      }

      changelevelproperty("bgspeed", Speed+1);
    }
@end_script
 
Then we have another *GOOD* case of the terrible ITS ON THE ENGINE, BUT NOT ON THE MANUAL.
I really don't understand (and this pisses me off and reduce my motivation to continue working with the engine) why on the blood hell someone develops something but not document it.
It is far beyond my cognitive abilities.

Heck, not even "getlevelproperty" its on the manual...

I really hope DC would make this a rule for the new engine. The coder can be good, god-like, save starving children in Africa...but if no document = no touching on the code.

Edit: btw, bgspeed works (if you have water on the stage, setting bgspeed to 0 won't stop it), but changing "rock" don't:
      changelevelproperty("rock", 0);
Click to expand...

"Level property 'rock' is not supported."

EDIT 2: its ROCKING, not ROCK.  To make it stop moving, you need to set bgspeed AND rocking to 0.
 
Code: 
noshowcomplete {int}
~set 1 you won't display the complete screen after NEXT! useful for custom HUD.
0: display (default)
1: not display
About this new command, is possible set this in secific levels?
Bescause if this is set 1, the complete screen not show anymore in any level.
 
O Ilusionista said:
Then we have another *GOOD* case of the terrible ITS ON THE ENGINE, BUT NOT ON THE MANUAL.
I really don't understand (and this pisses me off and reduce my motivation to continue working with the engine) why on the blood hell someone develops something but not document it.
It is far beyond my cognitive abilities.
...
Click to expand...

Yes, this is one terrible situation but there are even more worse situations/things around here. For example, i was trying to give some advise/help on someone and then another guy was posted that i was wrong(this can happen). Then just to prove myself, i have quoted what the Manual says, which was what i said as well. Then some other people was jump to the topic just to say "magggas you are wrong"(wich is ok for me if so). But what really was pissing me off, was that no one was care about the fact that the Manual says the wrong information (for years now)!!
And then even worse, you personally jumped on the topic too after 3 days, just to tale me to chill out  :o And of course you was not care either about the wrong information on the Manual(and that was all i said).

Now with all this real bullshit above, i'm so pissed off that i have removed all my posts here and all my games from the internet! So i'm just out after all.
 
Guys, don't over-dramatize, this kinda of issues just happen sometimes as we live. We all have our drives and our own perspective that make us overlook and undervalue things that are important to others.

If some issue is not evolving,  it's often that we're not communicating it the right way for it to be solved.
 
I won't wast my time with this thread. I already PMed DC about this.
We were worried about you for long time, even pmed you with no reply.

The original thread is HERE. Anyone can check that nobody attacked Maggas (in fact, it was quite the opposite).

If you have anything to say to the adm/mod, please use pm. Any further attempt will result in warning/mute/ban.

 
Since this community is becoming so fuck'd up from Brazilian/Mugen like mentality, i will not going to explain myself further about obvious things. I'm really don't care about any more, so go ahead and do what you want.
 
Back to what is important, can any of the dev (or any older member) help with the missing info about getlevelproperty?
Take a look: http://www.chronocrash.com/forum/index.php?topic=2022.msg45012#msg45012
 
A lot of great additions, basemap looks very cool and DC's debug is fantastic :)
I didnt find any info about it so i would like to ask... is true colour or 24 bit png supported ? Or would it be possible to suport it , to have alpha channel and blur between character and backgrounds? you know to avoid pixels being visible on edges ?
Also i dont know if someone also has the same problem on android but when i connect usb gamepads then only directions are working in openbor, gamepad buttons arent working at all even during control setup, maybe there's something in openbor's android gamepad code that prevents buttons to be recognized, gamepads work in android and emulators perfectly but in openbor i can only move up,down,left,right and cant jump or punch.
I have generic usb chinese rebranded gamepads :
http://www.instalki.pl/components/com_djcatalog/images/8d1c5ba6805e3df6f1966a6e13f6ddec2013-11-29_155210.jpg

I know there are apps that can do  the work but its quite a bit of work and i was wondering why gamepads dont work on openbor when they do work in emulators or android, there is some info about gamepads on android here but i dont know if its any help :
https://developer.android.com/training/game-controllers/multiple-controllers.html
I can get one gamepad to work using other IME apks but it would be great to use 4 gamepads on android its its possible :)

 
I remember someone said that 24bit png works for BG, but I never tried it. But you can use the RGB trick to simulate it.
About the edges, if I am not wrong, you can use alphamask (something very powerful but pretty much ignored) for bglayers and fglayers (dunno if it works with layers).

I have 3 questions about the engine:

1- Do you guys plan to take a look at chargeattack? Actually, its detection is pretty much broken, even if you reduce the charge time. It simple fails kinda like 80% of the time. The only way to get it done right (and its not 100%) is to hold the attack button while you execute a jumpattack and release the button once you touch the ground.

2- Do you guys have any plans to support native offset loop in .ogg? I know uTunnels explained a method for that (which includes calculating the file header size, among other things) but that method isn't too much user friendly. OGG supports native looping points, so if you set it using a audio tool (which is WAY easier), it stores this information on the file.

3- Any plans to fix the issue with REMIX.BOR? I reported it back at 2013 .
But I remember there is a required music: remix.bor. If you put a remix.ogg it will play, but when you go back to the title, it will play the .bor version instead.

Thanks.
 
i noticed the chargeattack have different behaviors when using joystick and when using keyboard,  in my tests using joystick works all the time but with keyboard sometimes it fails
 
I noticed that some getentityproperty or changeentityproperty aren't working.

For example, if I try to change the entity facing
Code: 
	void self = getlocalvar("self");
        changeentityproperty(self, "facing", 1);

I get a compile error:
Script compile error in 'animationscript': changeentityproperty
Click to expand...

The same type of error happens with weapon:
Code: 
ondrawscript @script
void main()
{
void self = getlocalvar("self");
int Map = getentityproperty(self, "map");
int Weap = getentityproperty(self, "weapon");
    if(Map>2 && Weap==1){
    changeentityproperty(self, "weapon", 2);
}
}@end_script
If I try to check which weapon I am using, the engine closes saying "Script function 'getentityproperty' returned an exception, check the manual for details."

Seams that those things aren't finished yet, so we should explain this on the engine manual.
 
O Ilusionista said:
I noticed that some getentityproperty or changeentityproperty aren't working...
Click to expand...

There's no "facing" property for entities. It's "direction", and always has been. I'm pretty sure it's in the script manual. Also, don't use magic numbers if you don't have to - recently I added constants DIRECTION_LEFT and DIRECTION_RIGHT, so use those instead. Oh, and before someone jumps my case, that was and is documented in the release notes, just like ALL of my changes.  :)

Code: 
void self = getlocalvar("self");
        changeentityproperty(self, "direction", openborconstant("DIRECTION_LEFT"));

The same type of error happens with weapon...
Click to expand...

Similar to facing, I think you're mistaking text commands with script. In script there is no such thing as "weapon". Weapons are actually made up of several properties. Remember, a single text command might affect several properties all at once, and on top of that, adjusting or sanitizing your input to something computer readable. That's what makes text simple and easy. With script, you assume direct, granular control of one property or attribute at a time - that's what makes it versatile and powerful. But it also at times necessitates script use very different naming compared text commands.

Here for example is the engine code that "gets" weapon properties and returns it to script for you:

Code: 
... 
   case _ep_weapent:
    {
        ScriptVariant_ChangeType(*pretvar, VT_PTR);
        (*pretvar)->ptrVal = (VOID *)ent->weapent;
        break;
    }
    case _ep_numweapons:
    {
        ScriptVariant_ChangeType(*pretvar, VT_INTEGER);
        (*pretvar)->lVal = (LONG)ent->modeldata.numweapons;
        break;
    }
    case _ep_weapnum:
    {
        ScriptVariant_ChangeType(*pretvar, VT_INTEGER);
        (*pretvar)->lVal = (LONG)ent->modeldata.weapnum;
        break;
    }
    case _ep_weaploss:
    {
        ScriptVariant_ChangeType(*pretvar, VT_INTEGER);
        if(paramCount >= 3)
        {
            if(FAILED(ScriptVariant_IntegerValue(varlist[2], &ltemp)))
            {
                printf("You must specify the flag value.\n");
                *pretvar = NULL;
                return E_FAIL;
            }

            if (ltemp == 0) (*pretvar)->lVal = (LONG)ent->modeldata.weaploss[0];
            else (*pretvar)->lVal = (LONG)ent->modeldata.weaploss[1];
        }
        else (*pretvar)->lVal = (LONG)ent->modeldata.weaploss[0];

        break;
    }
...

You're probably looking for "weapnum". Give that a try and you should get better results.

HTH,
DC
 
There's no "facing" property for entities. It's "direction", and always has been. I'm pretty sure it's in the script manual.
Click to expand...

Hi DC, take a look: http://dcemulation.org/?title=OpenBORManual#Entityproperty

Entityproperty
getentityproperty(entity, propname) / changeentityproperty(entity, propname, values)

~Get an entity's property by name.
~'entity' is the handle of that entity.
~'propname' is the property's name.
~'value' is new value you want to set.
~Property names:
"a" - Altitude (deprecated)
(...)
"exists" - Well, whether the entity is a valid one.
"facing" -
"falldie" -
Click to expand...

If this information is wrong at the manual, we need to fix it. Or it will have no point in having a manual. Even worse - It won't have any point to have an engine without a manual, if we can't use it properly because...there is no such info.

Similar to facing, I think you're mistaking text commands with script. In script there is no such thing as "weapon".
Click to expand...
Falls on the same example of above:

"weapnum" - Set/get the weapon index
"weapon" - Set/get the weapon index but it accepts a second param, anim_flag: if set to 1 for scripted midair weapon changing, default 0
Click to expand...
Why WEAPON is listed on entity property?

Thanks for your help.

 
O Ilusionista said:
...
Click to expand...

I can't answer why that stuff is in the manual (or not in it). I have absolutely nothing to do with those.

I had us a proper Wiki going with up to date information that the community could edit, but for all the big talk about wanting such a thing, the community at large completely ignored it in favor of the outdated list style manuals. So when it went down due to technical issues, I've had 0 cause to bother fixing it.

All I can do is document my own developments, which I have always done, enforce other developers going forward to do the same, and answer technical questions.

What happens after that is out of my hands.

DC
 
Any chance somebody could compile a Wii U port since the Wii one is kind of obsolete?

Wii U has more memory and I'd be willing to bet that it could run any and all pak files regardless of their file/script size.

Info and files needed for compiling a Wii U build are here:
https://gbatemp.net/threads/wiiu-homebrew-development.391050/

I would be willing to test and provide any needed feedback.
 
dantedevil said:
Code: 
noshowcomplete {int}
~set 1 you won't display the complete screen after NEXT! useful for custom HUD.
0: display (default)
1: not display
About this new command, is possible set this in secific levels?
Bescause if this is set 1, the complete screen not show anymore in any level.
Click to expand...

Hi Dante! You can set it via openborvariant by script  ;)
 
Status
Not open for further replies.
Back
Top Bottom