Applying Scripts

[Orochi_X]

Ahh..Right. I thought I needed the extra check because I always want to press the opposite direction to what the character is facing + attack 

[Damon Caskey]

OX, I have to retract what I told you about the double key check. The method is correct as I posted, but it is bugged and doesn't work.

Your method won't work either though, and on top of that, in the latest update the engine has aquired an annoying trait of "remembering" key inputs until you do something different in a given situation. By that I mean, let's say you use "@cmd ani001" to switch to "follow1" for a double jump if the player presses UP while jumping. It will work, but the next time the player presses jump, the double jump will happen automatically unless the player enters a different command like forward, down, or whatever.

The long and short is that captuing playerkeys is a handy and powerful ability, but as yet very buggy and a royal pain to work with. Unfortunatly, I don't think things are likly to change either, as UT has dropped off the earth without any explination.

DC

[Orochi_X]

I noticed that bug too....I thought it was just me.

I think UT is still around as I've noticed he checked in some code changes quite recently , although he hasn't visited the forum for a while.

I can wait , though. It just gets frustrating when our creative minds are one step ahead of the engine lol

[Damon Caskey]

I also found an undocumented (but useless) feature: You can create scripts called key#.c that will trigger when a player (# 1-4) presses a key. The uselss part though comes from three issues.

1. The script triggers both on press AND release of a key, and there is no method for capturing which event is occurring. The good news though is that is isn't a bug; it's quite intentional (why I have no idea) and a super easy fix; removing about 5 characters from one line in the engine code will correct it.

2. This is the real killer. While it is easy enough to get the player index and entity, the script itself doesn't provide any way to actually get the key that was pressed (and no, using playerkeys won't work). Fixing this problem is possible I think, but its a bit more advanced and I haven't made an attempt yet.

3. Since include tags don't work, you'd have to duplicate a lot of script even if everything else was fixed.

Were those three issues to be cracked (especially the 2nd) we would have the ultimate key capture system.

*Edit: Issue 1 and 2 solved! See below.*

DC

[Bloodbane]

I've read this thread seriously and realized that scripting is simpler than I though. I have studied basic coding before and it helps me understand the code above... eh in first page. I have tried it and it works great! Thanks DC!
 I have problem regarding it though. I've made a script based on your example to make heroes able to dodge away while rising. It works great, while rising, if I press up, Athena rolls up and if I press down, Athena rols down. Problem is if I don't press anything, she still rolling while rising as if I've press a button. She stops rolling in any case though so I only need to ask how to fix the script so if I don't press anything while hero is rising, he/she will rise normally?
 Oh I removed variables that I don't use in voidani001 BTW. I also have made my own riseattack . Yes, I know OpenBoR supports it but this one uses special button.

 Outside from that I have 3 questions:

1. I fail to understand what 'Frame' in your example for (the one used by voidani001). I'm confused, is it frame from animation where @cmd is declared or from declared animation?
 BTW Frame = 0 means 1st frame right?

2. Can scripts alter default settings?

3. What should I do if I want to have new animations? I want to use ANIM other than 'follow#'. I know that they are unlimited but just courious if it's possible to have my own animations.

 I have new plans for this .

[Damon Caskey]

True Key Captures

Happy Independence Day (at least to those in the states)!

Before we head out, I have a quick addition: It's keystroke grabbing time! After some digging around I found an obscure post from UT that did explain how key scripts worked after all. Here's the deal, they must in the scripts folder (see first post) and they have to be named "key#.c" where "#" is the player number (1-4) whose keys will be captured. Whenever a player presses or releases a key the corresponding script runs.

Next step is to capture the keys and perform the actions you want. To do this use the playerkeys function:

playerkeys {index} {newkey} {key} - Returns 1 if conditions are met.

Index -This is the player index. It's a 0 index, meaning player 1 is 0 and player 4 is 3. most of the time you are going to just match this up to the keyscript number (remembering the script name is not 0 indexed and index is), but you could check another player's keys for making team up moves.

Newkey - Ok, this is one is a little tricky, but its very important so take note:

0 = Player is holding the key down. uselss for capturing the key that triggered the script, but you can use it for an additional key. If you are using playerkeys method outside of the key scripts, this is the only type setting that works. See example below.

1 = This is the setting you will use most often. This never works anywhere else. It detects the key being pressed.

2 = This works like 1, but for when the player releases the key.

Key - The key in question.

Now, all you need to do is use a series of these stored into variables and you can find out exactly what key activated the script and how it did so. See the script below for an example. For simplicity sake I removed all the character functions except a couple of Hanzou's.

Code: [Select]

void main(){
   
    //Damon Vaughn Caskey
    //
    //06/10/2007
    //
    //Captures keystrokes and performs actions accordingly.
     
    void vSelf = getplayerproperty(0, "entity"); //Get calling entity.
    void vName = getentityproperty(vSelf,"name"); //Get name of calling entity.
int  iPlIndex = 0; //Player index.
    void vAniID = getentityproperty(vSelf,"animationID"); //Get current animation ID.
    void vAniPos = getentityproperty(vSelf, "animpos"); //Get current animation frame.

void iJump = playerkeys(iPlIndex, 1, "jump"); //New key status of "jump".
void iSpecial = playerkeys(iPlIndex, 1, "Special"); //New key status of "Special".
    void iAttack = playerkeys(iPlIndex, 1, "attack"); //New key status of "Attack".
void iAttack2 = playerkeys(iPlIndex, 1, "attack2"); //New key status of "Attack 2".
    void iAttack3 = playerkeys(iPlIndex, 1, "attack3"); //New key status of "Attack 3".
    void iAttack4 = playerkeys(iPlIndex, 1, "attack4"); //New key status of "Attack 4".

void iJumpR = playerkeys(iPlIndex, 2, "jump"); //Release status of "jump".
    void iSpecialR = playerkeys(iPlIndex, 2, "Special"); //New key status of "Special".
    void iAttackR = playerkeys(iPlIndex, 2, "attack"); //Release status of "Attack".
void iAttack2R = playerkeys(iPlIndex, 2, "attack2"); //Release status of "Attack 2".
    void iAttack3R = playerkeys(iPlIndex, 2, "attack3"); //Release status of "Attack 3".
    void iAttack4R = playerkeys(iPlIndex, 2, "attack4"); //Release status of "Attack 4".

    if (vName == "Hanzou"){ //Playing as Hanzou?

       if (vAniID == 2 || vAniID == 105){ //Jumping?

          //Double jump. At any point in jump, player may press jump with direction keys to perform a second jump in midair.
          if (iJump){ //New jump key press?

             if (playerkeys(iPlIndex, 0, "moveright")){ //Holding key moveright?

                if (getentityproperty(vSelf,"direction")){//Facing right?

                    changeentityproperty(vSelf, "animation", openborconstant("ANI_FOLLOW10")); //Switch to forward double jump.
                    changeentityproperty(vSelf, "animpos", 0); //Switch to frame 0
 
                 }else{ //Facing left.
                       
                    changeentityproperty(vSelf, "animation", openborconstant("ANI_FOLLOW9")); //Switch to backward double jump.
                    changeentityproperty(vSelf, "animpos", 0); //Switch to frame 0
                   
                 } //Facing.
                                 
              }else if (playerkeys(iPlIndex, 0, "moveleft")){ //Command left?
             
                 if (getentityproperty(vSelf,"direction")){ //Facing right?

                    changeentityproperty(vSelf, "animation", openborconstant("ANI_FOLLOW9")); //Switch to backward double jump.
                    changeentityproperty(vSelf, "animpos", 0); //Switch to frame 0
                 
                 }else{ //Facing left.
                       
                    changeentityproperty(vSelf, "animation", openborconstant("ANI_FOLLOW10")); //Switch to vertical double jump.                    changeentityproperty(vSelf, "animpos", 0); //Switch to frame 0
                   
                 } //Facing.
             
              }else{ //No direction.
                   
                 changeentityproperty(vSelf, "animation", openborconstant("ANI_FOLLOW8")); //Switch to desired animation.
                 changeentityproperty(vSelf, "animpos", 0); //Switch to desired frame.
           
              }
       
           }
       
        //Double Rekko Zan. At start frame of Rekko Zan, player can tap attack to perform the Double Rekko Zan instead.
        }else if (vAniID == 25){ //Freespecial 2?
                   
           if (vAniPos == 0){ //First frame?
             
              if (iAttack){ //New attack key press?
                       
                 changeentityproperty(vSelf, "animation", openborconstant("ANI_FOLLOW13")); //Switch to desired animation.
                 changeentityproperty(vSelf, "animpos", 0); //Switch to desired frame.           
   
              }else (iSpecial){ //New special key press?
             
                 changeentityproperty(vSelf, "animation", openborconstant("ANI_FOLLOW15")); //Switch to desired animation.
                 changeentityproperty(vSelf, "animpos", 0); //Switch to desired frame.
                 
              }
   
           }
           
        //Crouch. Player can press Attack 2 when idling to fight from a crouch position, and again to return to normal.   
        }else if (vAniID == 0){ //Idle?
             
           if (iAttack2){ //New attack 2 key press?
   
              changeentityproperty(vSelf, "animation", openborconstant("ANI_ATTACKBOTH")); //Switch to desired animation.
              changeentityproperty(vSelf, "animpos", 0); //Switch to desired frame.
         
           }   
         
        }
   
    }
         
}

Not too bad right?

What you see above enables a couple of things that could never be done as seamlessly otherwise:

• Double Jumps: Hanzou can double double jump in any direction. This is done by checking the following when the script activates:
  
  A) Is the character Hanzou? If not, no point in checking anything else.
  
  B) Is Hanzou in any of his jump animations? If not, the rest doesn't matter.
  
  C) Was is it the jump key that activated the script? If it was, then we know we are going to do a double jump of some type.
  
  D) Is the player holding moveleft or moveright?If so we are double jumping right or left, but we need to know which direction character is facing so to use the correct animation (if you don't mind using the same animation for forward or back jump, you can skip the next step).
  
  E) What direction is the character facing? This will determine the animation used.
  
  So the end result is that when playing as Hanzou, while jumping you can hold back and press jump to do a backflip double jump, forward and jump to do a forward flip double jump, or just press jump to hop straight up in the air. Since in all three cases we are switching to a new animation (the animations themselves have the needed jump command), the above checks will all fail during the double jumps, which means the player can't double jump again until they land and jump normally.
  
  Of course, nothing stops you from just using toss entity instead of switching animations, and thus literally giving the character the ability to fly. If you want to get really tricky, try combining this with gravity settings and an appropriate overlay to make under water levels where the jump button becomes the "swim" key like old school Mario Brothers (and yes, you will see that from me very soon).
  
  
• Alternate techniques: Hanzou has three versions of his projectile move ("Rekko Zan"); single, double, and a "super" where he throws 8 in a rapid series. Now instead of making a separate command for each, the three are combined into a single move with alternates.
  
  First, the player inputs the command for normal Rekko Zan (D, F, A). If the player does nothing else, Hanzou throws one projectile. But if the player presses attack again during the first frame, the move switches to Double Rekko-Zan where Hanzou fires off two projectiles much quicker then he could have done two normal Rekko Zans. Since the start up frames are identical, there is no visual difference other then a longer pause before move comes out, which is exactly what we want in this case anyway. If the player presses Special during the first frame instead, Hanzou will perform the super version and fire off 8 projectiles.
  
  So how do we do this? Just as with double jump, a series of simple checks:
  
  A) Is the character Hanzou? If not, no point in checking anything else.
  
  B) Is Hanzou in his Rekko Zan animation? If not, the rest doesn't matter.
  
  C) Is Hanzou in the first frame of Rekko Zan? Once he moves past first frame, the alternate versions are not available.
  
  D) Was it the attack button that activated the script? If so, do the Double Rekko Zan. Hanzou needs a split second longer to start the move and uses more MP, but that second projectile comes fast and hard.
  
  E) If it wasn't the attack button, was it the special button? if so, do the Okugi Hachi Kadodan Hikari Kiri!! It might be costly MP wise, but let's see how the other guy likes eating 8 giant ki shurikens in a row!
  
  Now for extra credit, try using this idea to create all new moves or regain lost ones. How about regaining use of attackforward even with a running/blocking character?
  
  
• Using "Unavailable" Keys: For a change of pace, let's duck down and fight from a crouching position. Same principal as above, just combined with an animation that includes a weapon model switch which allows Hanzou to use an array of moves while ducking. By repeating this move again we switch back to normal position. What makes this trick "special" is that it uses Attack 2, a key that at time of this writing has no mapped command. In my module, Attack 2 is more or less a "stance" button; by holding different directions and pressing Attack 2, players can access different stances and move sets depending on the character. Most characters just have duck (attack 2 by itself) but a few (Hayabusa in particular) have more.
  
  You obviously don't have to use the alternate buttons like I do; just apply the principal and you can map pretty much anything you want to to the alternate buttons. For an easy idea, try using Attack 1 for punches and Attack 2 for kicks like old school Double Dragon or Attack 1 for quick attacks and Attack 2 for strong attacks such as in Sengoku 3 or XBox Ninja Gaiden. Also, who says Attacks buttons have to be attacks? Just like I use Attack 2 for stances instead of attacks, you could go outside the box as well and try calling up menus, activating items, even non direct fighting moves like dodging and footwork (make an effective boxer!), and so on. Use your imagination!
  
  
  
  

One last advantage of key captures? No more annoying "Why is the engine remembering and doing the last command I entered with an animation script" issues.

And that's all for now. Whew...

DC

[Fightn Words]

Thank you for posting, this is excellent Damon. Scripting seems pretty d@%^ usefull.

I have some questions regarding scriptings limitations/capabilities (I hope you can answer):

you could go outside the box as well and try calling up menus, activating items

I assume you mean like the Capcom Dungeons & Dragons games or the Knights of Valour games- press a button, and a 'mini-menu' pops up to select whatever. Is this possible?

Does scripting have the ability to alter Open BOR's current limitations, specifically:

Can 'true' secret characters be made- unlocked by different means then just by beating the game once?

Can levels be made bigger- or more 'interactive' with scripting? Specifically, could you make the playing-field less pedestrian- like going right,then down a ladder then left again, etc.?

Could you have more interactive 'events'- wherein what is accomplished in-game affects the path the player takes. Like say, Superman kills Brainiac with his heat vision instead of just 'defeating' him, so he goes on to level path 2c, etc.?

Could you have more then one ending to you're game?

And stats! Can you effect players 'abilities', without using weapon or the offense/defense feature? Like affecting range of characters attacks, unlocking moves, altering existing values like attack power, and speed, etc.?

Could the main menu get a facelift, more or different options?

Etc., etc., etc...

Basically, how far does scripting really go?

[Orochi_X]

Thanks DC. I can get cooking with this tomorrow.....

[Damon Caskey]

Thank you for posting, this is excellent Damon. Scripting seems pretty d@%^ usefull.

I have some questions regarding scriptings limitations/capabilities (I hope you can answer):

you could go outside the box as well and try calling up menus, activating items

I assume you mean like the Capcom Dungeons & Dragons games or the Knights of Valour games- press a button, and a 'mini-menu' pops up to select whatever. Is this possible?

Yes, it is, albeit a bit tedious. I've done experiments making in game menus for my next module (Quests of Quein) combining script with text objects. It's a bit of a pain to get going, but works great and is really sweet to see in action.

Can 'true' secret characters be made- unlocked by different means then just by beating the game once?

Yes they can, though the only method I have tried is a bit of a hack; scripts can be used to spawn an invisible entity which will itself load a character and make him selectable. As far as persistence goes, script variables can supposedly be saved, but I haven't tried yet and don't know how/if it works.

Can levels be made bigger- or more 'interactive' with scripting? Specifically, could you make the playing-field less pedestrian- like going right,then down a ladder then left again, etc.?

More interactive? You bet! Bigger? No. You actually don't even have to use scripts to do tricks like ladder climbing and such, but even with script there is no way I know of to scroll the playing field on any plane other then the one it is set for.

Could you have more interactive 'events'- wherein what is accomplished in-game affects the path the player takes. Like say, Superman kills Brainiac with his heat vision instead of just 'defeating' him, so he goes on to level path 2c, etc.?

Yes you can. You would simply use script to gain more control over the invisible end level item spawn trick.

Could you have more then one ending to you're game?

Yes, but you'd have to make the extra endings using multiple in level scenes. I know of no way to change the built in "ending".

And stats! Can you effect players 'abilities', without using weapon or the offense/defense feature? Like affecting range of characters attacks, unlocking moves, altering existing values like attack power, and speed, etc.?

Aside from obvious things like health, MP, and such not really. There are some status features out there, but they are undocumented and as far as I know unfinished. UT was a lot better at adding goodies then he was at documenting them, so I'll have to get back to you if I uncover anything else. In the meantime if you want to do all those things, you will have to use alternate models. Fortunately, script is very good at that and even has a method for switching models without using weapons; though its still experimental.

Could the main menu get a facelift, more or different options?

The menu itself is not accessible to script. You can do some tricks here and there during the character select screen, but that's about it.

Etc., etc., etc...

Basically, how far does scripting really go?

The simple answer to that is "I don't know", and that's the way I like it, because that's the whole point of script. A year ago we all knew the limits of the engine; now nobody knows and that means each new module can have more surprises.

To try and technically answer your question, scripts can pretty much take control of anything entity related. They can do almost anything anything you can do with text files, and they have a touch of access to internal engine functions during gameplay mode (spawns, variables, key events, etc.).

What they can't do is provide access to anything outside of gameplay (start menus, end, scoreboard, etc.), and even during gameplay they only give you greater access to the engine; they can't actually make the engine do something it wasn't already capable of doing (like scrolling a horizontal level vertically).

DC

[Fightn Words]

I see- this is very useful information, thank you. Very exciting possibilities for modders! 

I suppose the only thing terribly disappointing to hear is that the levels layout cant be messed with more. But really other then that a modders vision is only limited by what hes willing to work for (naturally).

I've done experiments making in game menus for my next module (Quests of Quein) combining script with text objects. It's a bit of a pain to get going, but works great and is really sweet to see in action.

I'm sure more then a few modders are going to want to 'borrow' that script...

[Bloodbane]

 Anybody can answer my previous questions?

 Anyway, I understand the idea what DC meant in the latest code he posted. However there are some stuff I don't understand.

 1. Why this code could detect a button is released while the previous code can't? I can see voidi..R but I don't understand how they work.

 2. What should I do to fix the previous code with this? I can see that it's missing funtion to detect button being unpressed but I don't know how to add that function there.

 3. In keyd001, playerkeys uses iIndex but in this code it uses iP1index. What's the difference between iIndex and iP1index?

 4. You mentioned key#.c scripts. Where to get that scripts? or we should make them ourselves?

 The code to alter animation to other animation if attack is pressed is great. Reminds me too some brawlers where we can do that also.

 Speaking of that, I hope lagarto is reading this. He once asked for something like that.

[Orochi_X]

I'm not as knowledgable as DC but I think I can help....DC will let us know if I'm wrong 

1. This has better functionalities...UT made it to detect more key events.

2. You should do what I (and possibly DC) is doing and use this instead of the other code to perform certain scripted moves.

3. It's actually iPLindex. iIndex is the same as "self" and iPlIndex checks for the player who performed it.... Player 1,2,3 or 4

4. key#.c goes in the main scripts folder inside the data folder. DC actually already stated this in his first post.

[Damon Caskey]

Anybody can answer my previous questions?

I know its doubling up because OX answered these, but I'll give it a try too.

1. Why this code could detect a button is released while the previous code can't? I can see voidi..R but I don't understand how they work.

It's not a matter of code so much as it is when the code is run. Scripts in BOR (and most anywhere else) are event driven; at certain "events" a given script is run. The previously released script when set up as instructed runs each time your character changes frames. The engine is updating at a different rate and thus your pressing a key is simply never going to be in synch with the animation update. That's why the key functions in the first script can only detect "held" keys.

The script just above runs directly in response to the engine's key event, which occurs both on press and release of a key. Therefore it can be used to detect a key being pressed, or released.

2. What should I do to fix the previous code with this? I can see that it's missing funtion to detect button being unpressed but I don't know how to add that function there.

You don't. That key001 function is just a "wrapper" I wrote to convert the player keys method into a more usable output for other functions in order to cut down on repetitive code. You don't even have to use it; it's the playerkeys() method that is really grabbing keystrokes.

Because of the nature of the key#.c scripts, there is really no reason to do that and so I just used the playerkeys() method as is.

3. In keyd001, playerkeys uses iIndex but in this code it uses iP1index. What's the difference between iIndex and iP1index?

They are just variables with different names. I use a variable naming convention called "Hungarian Notation" which makes for some odd names but helps with debuging.

4. You mentioned key#.c scripts. Where to get that scripts? or we should make them ourselves?

You make them yourselves, and the above is an example; they are nothing more then text files with ".c" instead of ".txt". You just change the index to match the player for each.

The code to alter animation to other animation if attack is pressed is great. Reminds me too some brawlers where we can do that also.

 Speaking of that, I hope lagarto is reading this. He once asked for something like that.

Thanks, that's exactly what I was going for!

DC

[Orochi_X]

No worries ; Deeper explainations are always welcome 

[Damon Caskey]

Here are some throwaway clips that give an idea of what some scripted moves look like. Remember, all three of these moves only use up a single special slot; they are each activated by a successive command via script based key capturing during the normal Rekko Zan.

Rekko Zan.

Double Rekko Zan. Also note the scripted throw and transparent afterimage as Hanzou dashes forward or backward.

Super Rekko Zan. This clip demonstrates use of targeting and global variables; as both a repeat counter for the super (It's made of four animations, one start, one end, and two middle that are looped via script until a counter limit is reached), and as a target "lock" for auto combo moves. Notice the ease with which Omote is juggled by a second move after initially being smacked into the air with an uppercut?

Targeting variables are useful for moves like that kick series. When each kick hits, Omote is realigned perfectly by the script for the next kick until he is sent to the ground; just like similar moves in many 2D one on one fighters. Used sparingly, it makes for some really slick looking juggles and has a ton of potential elsewhere too. And yes, time did "stop" when the super started. It's an easy trick and has nothing to do with script. Just spawn a noskip text object with your favorite animation and you're done.

I'll be going in depth about how to use these variables soon.

DC

PS: That Omote has 1000HP for testing, so don't fret that I made the PCs weak just because he doesn't seem to be taking much damage from Hanzou's attacks. And OX, since you are a fan, you probably are aware Hanzou's old sprite set never had that final pose for throwing a Rekko Zan series (makes sense since he never had any more then the Double until NGBC). Just FYI I took it from Fumma's fireball slug trick animation with new colors and a frankensprited head.