• All, Gmail is currently rejecting messages from my host. I have a ticket in process, but it may take some time to resolve. Until further notice, do NOT use Gmail for your accounts. You will be unable to receive confirmations and two factor messages to login.

Documentation Project

Something to improve documentation: changelevelproperty

According to manual, it can be:

changelevelproperty(name, propertyvalue)

Change a property value of current level, this function is not quite completed.
name can be:       
"rocking", the given value must be an interger value or numeric value that can be converted to integer value. The rule is same as rock command in level file, check the manual for details.

But there are more than that. Actually, you can change all those level properties:

"basemap",
"bgspeed",
"cameraxoffset",
"camerazoffset",
"gravity",
"hole",
"maxfallspeed",
"maxtossspeed",
"quake",
"rocking",
"scrollspeed",
"type",
"vbgspeed",
"wall",

Basemap has additional values:
        "map",
        "x",
        "xsize",
        "z",
        "zsize",

Walls and holes has additional values:
        "depth",
        "height",
        "lowerleft",
        "lowerright",
        "type",
        "upperleft",
        "upperright",
        "x",
        "z",
Yes, you can change a wall/hole/basemap on the fly using script (I remember that, at least, wall code is completed because I already tested it on the past)
 
Anytime to update some such as skiptoset and getmodelproperty in the manual now that we got them covered? I only can see skiptoset is part of openborvariant there. You can change the certain difficulty or mode to skip select screen for a level.
 
For skiptoset, I think not. I forgot it lacks information. (I could be wrong.) For getmodelproperty, I do believe it's confirmed after it was posted here but I'm not sure of its confirmation. Now I see why it's not in the manual yet.

You don't have to take my word on skiptoset. skiptoset is used for skipping the title screen to a certain difficulty level or game mode. The value represents a certain difficulty level or a game mode. For example, there are three modes: Arcade, Versus, and Training. If 0 is set from skiptoset, it skips to only the first mode which is the Arcade mode. 1 skips to the second.
 
Does anybody know about the use for openborconstant ("MIN_INT") and ("MAX_INT"), as well as clearspriteq? I found them in the small screen demo which utunnels made years ago. Wonder if they are currently in the source code.
 
  1. clearspriteq() clears out all content you have placed into a screen. You usually run it right after you draw the screen. See any zoom, motion trail, or inset picture in picture script across a least half a dozen released modules for an example.
  2. MIN_INT and MAX_INT are both in the current source code. I don't recall if they are in the last official build but I believe so. They're just references to the basic numeric range you can use in OpenBOR (same as most 32bit app integers): -2,147,483,648 to 2,147,483,647.
 
Why are some of these parts in running not documented in the manual? We're missing some information here that we forget.

{move} is a binary value.

0 - can't run up/down
1 - can run up and down diagonally
2 - can start running by inputing uu or dd
4 - can turn 90 degrees while running (like in some capcom games)
3 = 1 + 2
7 = 1 + 2 + 4
 
Why are some of these parts in running not documented in the manual? We're missing some information here that we forget.
Because in that case, those were unwanted additions that I have to break in order to expand running features in the next release.

DC
 
Why are some of these parts in running not documented in the manual? We're missing some information here that we forget.
@Kratus looks like there is a native way to turn around while running, take a look.

---

We need to add finditem() to the manual:
 
Because in that case, those were unwanted additions that I have to break in order to expand running features in the next release.

DC
That makes sense. 0 and 1 are still official, yes. I tried using any of those other than the official two, and thought it was nicely done. But somehow, when I run downwards and press jump, the character only runjumps straight in a single z plane instead of runjumping laterally.

@Kratus looks like there is a native way to turn around while running, take a look.

---

We need to add finditem() to the manual:
I didn't know finditem exists until I found one from Bloodbane's sample script in one of the help topics. I don't know what finditem is like.
 
I didn't know finditem exists until I found one from Bloodbane's sample script in one of the help topics.
Me neither. Kratus had found it.

Digging in the source code, I found that finditem() and pickup() are there since... 2011, added by uTunnels.
He was pretty good at coding new stuff, but not as good documenting then, lol.

edit: I've found an old topic where I was trying to realize what adjustwalkanimation() function does.
Looks like its related to the AI code

C:
// complex, so make a function for ai
// adjustwalkanimation(ent, target);
HRESULT openbor_adjustwalkanimation(ScriptVariant** varlist , ScriptVariant** pretvar, int paramCount){


    entity* e, *t, *temp;


    *pretvar = NULL;


    if(paramCount<1) e = self;
    else if(varlist[0]->vt==VT_PTR) e = (entity*)varlist[0]->ptrVal;
    else goto adjustwalkanimation_error;


    if(paramCount<2) t = NULL;
    else if(varlist[1]->vt==VT_PTR) t = (entity*)varlist[0]->ptrVal;
    else if(varlist[1]->vt==VT_EMPTY) t = NULL;
    else goto adjustwalkanimation_error;


    temp = self;


    self = e;
    adjust_walk_animation(t);
    self = temp;


    return S_OK;
adjustwalkanimation_error:
    printf("Function adjustwalkanimation(entity, target), both parameters are optional, but must be valid.");
    return E_FAIL;
}
 
Last edited:
Some other functions to documment:

settexture
setvertex
trianglelist
aicheckwarp
aichecklie
aicheckgrabbed
aicheckgrab
aicheckescape
aicheckbusy
aicheckattack
aicheckmove
The first 3 are related to screens, as far as I can get. The other ones are related to AI routines.
 
I forgot that pickitem exists after looking at the link. I didn't take a close look at it (until I clicked it). Hahah.
 
Digging into the source code I've found some more information that, once confirmed, we can add to the manual:

Biker:
• The Rider is spawned at Y+10 from the parent.

• Rider won't copy the map from the Biker entity neither there is a way the change it's palette by native means (until 6931 at least) - Coinfirmed

• The manual says "Bikers should normally be spawned further out than other enemies. You'll probably want around 400 or -80 (But not more than -200 or 520, or they'll die)" but, from what I saw at the code, one of the values is wrong:

C:
// for old bikers
int biker_move()
{


if((self->direction == DIRECTION_RIGHT) ? (self->position.x > advancex + (videomodes.hRes + 200)) : (self->position.x < advancex - 200))

Unless I am mistaken, they are spawn either at -200 or (video horizontal resolution +200) - confirmed

SUBTYPE BIKER is called with the following settings:

Code:
subject_to_hole                                = 1;
        subject_to_gravity                             = 1;
        subject_to_basemap                             = 0;
        subject_to_wall                                = 0;
        subject_to_platform                            = 0;
        subject_to_screen                              = 0;
        subject_to_minz                                = 1;
        subject_to_maxz                                = 1;
        no_adjust_base                                 = 0;

I know each type has a group of default settings aplied by default and here are the default values as I could get from the source:

TYPE PLAYER

Code:
chainlength            = 4;
        bounce                 = 1;
        subject_to_basemap     = 1;
        subject_to_wall        = 1;
        subject_to_platform    = 1;
        subject_to_obstacle    = 1;
        subject_to_hole        = 1;
        subject_to_gravity     = 1;
        subject_to_screen      = 1;
        subject_to_minz        = 1;
        subject_to_maxz        = 1;
        no_adjust_base         = 0;


TYPE ENEMY

Code:
        bounce                 = 1;
        subject_to_basemap     = 1;
        subject_to_wall        = 1;
        subject_to_platform    = 1;
        subject_to_hole        = 1;
        subject_to_obstacle    = 1;
        subject_to_gravity     = 1;
        subject_to_minz        = 1;
        subject_to_maxz        = 1;
        no_adjust_base         = 0;

TYPE ITEM

Code:
        subject_to_basemap     = 1;
        subject_to_wall        = 1;
        subject_to_platform    = 1;
        subject_to_hole        = 1;
        subject_to_obstacle    = 1;
        subject_to_gravity     = 1;
        subject_to_minz        = 1;
        subject_to_maxz        = 1;
        no_adjust_base         = 0;

TYPE OBSTACLE
That is a curious one - I can't understand the NOATTACK part.

Code:
        aimove |= AIATTACK1_NOATTACK;
        subject_to_basemap     = 1;
        subject_to_wall        = 1;
        subject_to_platform    = 1;
        subject_to_hole        = 1;
        subject_to_gravity     = 1;
        subject_to_minz        = 1;
        subject_to_maxz        = 1;
        no_adjust_base         = 0;

TYPE STEAMER
Code:
offscreenkill = 80;

TYPE PSHOT
Code:
aimove = 0;
        subject_to_hole                = 0;
        subject_to_gravity             = 1;
        subject_to_basemap             = 0;
        subject_to_wall                = 0;
        subject_to_platform            = 0;
        subject_to_screen              = 0;
        subject_to_minz                = 1;
        subject_to_maxz                = 1;
        subject_to_platform            = 0;
        no_adjust_base                 = 1;

TYPE TRAP
Code:
        subject_to_basemap     = 1;
        subject_to_wall        = 1;
        subject_to_platform    = 1;
        subject_to_hole        = 1;
        subject_to_gravity     = 1;
        subject_to_minz        = 1;
        subject_to_maxz        = 1;
        no_adjust_base         = 0;

TYPE TEXT
Code:
        subject_to_gravity     = 0;
        subject_to_minz        = 1;
        subject_to_maxz        = 1;

TYPE ENDLEVEL
Code:
        subject_to_basemap     = 1;
        subject_to_wall        = 1;
        subject_to_platform    = 1;
        subject_to_hole        = 1;
        subject_to_obstacle    = 1;
        subject_to_gravity     = 1;

TYPE NPC
Code:
        bounce                 = 1;
        subject_to_basemap     = 1;
        subject_to_wall        = 1;
        subject_to_platform    = 1;
        subject_to_hole        = 1;
        subject_to_obstacle    = 1;
        subject_to_gravity     = 1;
        subject_to_minz        = 1;
        subject_to_maxz        = 1;
        no_adjust_base         = 0;

TYPE PANEL
Code:
        antigravity            = 1.0; //float type
        subject_to_gravity     = 1;
        no_adjust_base         = 1;
 
TYPE OBSTACLE
That is a curious one - I can't understand the NOATTACK part.

That's because the AI flags use bitwise logic. The individual bits in a variable are each used as a flag instead of the whole value. Just wait till you see the new source code. All those "subject to" flags... now they use bitwise logic too, so all those individual flags are gone. Poof, don't exist. There's now a single value that stores all of them using bit logic.

I've done a ton of stuff like this. I'd guesstimate the current source code has ~20% fewer variables in it compared to 0691.

DC
 
Is there a full list of "aiflag" sub-properties such as "idling", "walking", "jumping",etc.? I can see there are so many sub-properties in the list, but some of them have yet confirmed to be workable/tested or not. We need to test some of the unconfirmed ones. I assume some may crash or get risky but I dunno since they're not tested.
 
No, and honestly there's no point. That stuff all works differently now, and in addition to the code I've already documented it. When released, the documentation will be linked as well.

DC
 
Back
Top Bottom