Manual Updates

Added new openborconstants

-- Direction of an entity.
DIRECTION_LEFT
DIRECTION_RIGHT

-- Direction adjustment property for binding and attack hits.
DIRECTION_ADJUST_LEFT
DIRECTION_ADJUST_OPPOSITE -- Force target's direction to opposite of owner's.
DIRECTION_ADJUST_NONE
DIRECTION_ADJUST_RIGHT
DIRECTION_ADJUST_SAME -- Force target's direction to same of owner.
 
O Ilusionista said:
By the way, what is the usage of this? Do anyone have more info about this?
nodropspawn {bi}

~When it is on, the spawn position will be restricted to spawn entry setting.
Click to expand...
Click to expand...

This prevents enemies falling from the top of the screen when spawned and forces them to use their SPAWN animation.  This is a bit of a relic and goes back to the earliest releases of OpenBOR when spawn was first added.
 
Maybe I've just forgotten, but what is forcemode ?  the description is also very vague...

Code: 
forcemode {bi}

    ~Sets whether the mode specified in models.txt is switchable or not.
        0 = the mode can be switched in options menu.
        1 = the mode can't be switched {default}.
 
It allows to change some stuff in options if forcemode is not used, forcemode does not allow some changes in options, i  think it was for stuff like locking hitting other players and you could change it despite using versusdamaGE, so we needed forcemode, it forced probably cheats and all comands below it,I remember using it to not let people change versusdamage, i think it was global openbor option instead of per mod.
 
Last update on June, 06 2018 - by O Ilusionista
*~ Added missing "summonkill" information
Summonkill {type}

Entity header command. Determines behavior of any sub entities on screen that consider this entity as a Parent if this entity is killed.

{type}
    Default: 0
    Behavior type.
    0: Do nothing.
    1: Kill only sub entities spawned with the Summon command.
    2: Kill all sub entities.
Click to expand...
 
Last updated - 2018.09.30 - by O Ilusionista

Added several missing information on both manuals.

- Missing extra values

OTG {bi}
*~This command determines how attackbox affect lying opponent.
** 0 = Attackbox can't hit lying opponent at all
** 1 = Attackbox can hit lying oppoent
** 2 = Attack boxes can only hit down opponents.

icon {path} {bi}
*~The graphic normally shown next to the entity's life bar.
*~Normally a 16 x 16 box with a picture of the entity's head.
*~{path} is the location relative to OpenBoR of the icon's .gif.
~*{bi} controls if the icon will use the entity current palette. Set to 1 to use the same palette.
*~The position of the graphic can be changed in LEVELS.txt.
*~You can use a longer image to change the appearence of your character's lifebar, but remember that the box and shadow around it appear on top if you don't turn them off in LEVELS.txt.
*~Dimensions of the life bar relative to the icon in bbox format (if you haven't changed it in LEVELS.txt): 18 8 103 9
Click to expand...

- MISSING INFORMATION

nokill {bi}
*~ 0 - (default) The attack will kill the target. Useful to turn NOKILL off.
*~ 1 - The attack won't kill the target but will leave 1 HP.

nofadeout {bi}
*~Controls fade out effect for a level
** 0 = (default) Screens fades out when you finish the stage
** 1 = No fade out when the stage finishes

**"nofadeout", - controls if the the screens fades out when you finish the current level
Click to expand...

Corrected a wrong information in both manuals, about NOPASSIVEBLOCK
Explanation by DC:
nopassiveblock {bi}
*~Normally when AI controlled entities block a string of attacks, the odds of blocking each incoming hit are always treated separately. With nopassiveblock set to 1, the AI will behave more like a player and hold the block position if hit while blocking a previous attack.
*~Previous versions of the manual state this property also causes the AI to block "actively", defending itself from attacks that pass close by. This is not true. The AI will never attempt to block an attack that doesn't actually hit.
*~Obviously entity who use this must have block ability.
Click to expand...

Also added some missing old information: SYNC and @INCLUDE

sync
*~Using sync {animation name} will make the two animation synchronize with each other. For exmpale, in a horse riding stage, you can make idle and walk switch seamlessly, with delay timer inherited.
*~Example:
<pre>
anim idle
sync walk
....
anim walk
#sync walk # this can be optional since it is already anim walk</pre>
Click to expand...
http://www.chronocrash.com/forum/index.php?topic=448.msg2983#msg2983

@include
*~ With this tag, you can import another animation text file to the current animation (build 3842+).
*~ For example, save below as "data/chars/a/walk.txt":
<pre>
anim walk
delay 5
bbox 0 0 20 60
frame data/chars/a/1
frame data/chars/a/2
frame data/chars/a/3
frame data/chars/a/4
frame data/chars/a/5 
</pre>
*~ Them call this file using @inlcude:
<pre>
anim walk
@include data/chars/a/walk.txt

anim idle
@include data/chars/a/walk.txt

anim follow1
@include data/chars/a/walk.txt</pre>
Click to expand...
http://www.chronocrash.com/forum/index.php?topic=448.msg2997#msg2997
 
Ah thanks for the update :)

*~Previous versions of the manual state this property also causes the AI to block "actively", defending itself from attacks that pass close by. This is not true. The AI will never attempt to block an attack that doesn't actually hit.
Click to expand...

I have to disagree about that. Enemy with nopassiveblock 1 CAN block even if the attack doesn't hit them. It can happen if the attack happens within defined range of their BLOCK animation
I've just tested that and it's confirmed
 
Correct - the AI cannot block attacks that don't exist. However, it CAN try to block attacks nearby. Sorry for the confusion.
 
In some mods I found "nodrawmethod 1", but the manual does not mention any values associated with this command.
O Ilusionista, could you please add an explanation which numbers are valid and what they do?
 
O Ilusionista said:
Hi there.
There is no such thing. Nodrawmethod accepts no values.
Click to expand...

I see, thanks for clearing that up.
I thought the engine would crash/give an error if you would assign random numbers to commands which don't require any values instead of ignoring it.
 
@Ilu

Can you add this weapon information on the below link to the manual please.  And also mention the weapon should have a bbox so enemies will pick them up and enemies need a "get" animation as I had to figure this out for myself.

http://www.chronocrash.com/forum/index.php?topic=4247.msg59225;topicseen#msg59225
 
msmalik681 said:
@Ilu

Can you add this weapon information on the below link to the manual please.  And also mention the weapon should have a bbox so enemies will pick them up and enemies need a "get" animation as I had to figure this out for myself.

http://www.chronocrash.com/forum/index.php?topic=4247.msg59225;topicseen#msg59225
Click to expand...

Hm.. I'm using weapons on my games for long time now and i remember that i have read all the informations about bbox on weapon items and "get" animations on enemies from the manual. So i'm not sure if at some point all these informations got somehow removed from the manual, but i'm pretty sure i have read back then all this stuff from the manual.
So maybe you guys should check again all the weapon commands documentations before you float the manual with unnecessary double-documentations ("if" that's the case).


Edit:
For example, this is the description of the "GET" animation and in my opinion it's enough.(?) The only mistake is that  it now says it's for players. Like it's only for them which is wrong.

GET {players}

    ~Optional.
    ~Played when the character picks up an item.
Click to expand...
 
You must log in or register to reply here.
Back
Top Bottom