Author Topic: Learning to script  (Read 3104 times)

0 Members and 1 Guest are viewing this topic.

kenjamin

  • Poptart
  • *
  • Posts: 5
    • View Profile
Learning to script
« on: June 14, 2012, 04:43:32 am »
I'm brand new to scripting and such and have never had anything past a basic level class for C++.

Where can I start learning about scripting for Arma 2? Specifically DayZ?

I've downloaded the pack of MrMedic scripts and played around with those, but I'm curious. Is there a specific programming language syntax the scripts for arma 2 use or is it a proprietary language?

Where is a good resource to learn what scripting commands do and what the classes and variables are? Is there a help file that BIS has that lists all this?

Where did you guys learn from?

In addition, the MrMedic scripts stopped working recently and I've been getting kicked for script restrictions. I went through all the files and did a dead simple search and replace for MrMedic and changed the name of the directory of the scripts also and it seems to work for some scripts, but the list of scripts doesn't work so I've been resorting to changing the start2.sqf to simply execVM the script i want to use and then activating that with the OpenModMenu option in game which seems to work for spawning crates of guns and ammo and that, but carpet bombing and things that open the map and exec dialogs dont.

Is there a specific way battleye checks to see if a script is restricted? What are some ways you can bypass script restrictions on battleye?

If you could point me towards the resources to learn this I would be thrilled.

Does anyone plan on writing a tutorial for newbies to scripting for arma 2 that introduces the very basics of how scripting works and what can and cant be done with it?

Thanks in advance.

Temo

  • Relentless Teamkiller
  • **
  • Posts: 93
    • View Profile
Re: Learning to script
« Reply #1 on: June 14, 2012, 04:50:49 am »

kenjamin

  • Poptart
  • *
  • Posts: 5
    • View Profile
Re: Learning to script
« Reply #2 on: June 14, 2012, 04:58:47 am »
Nice. These are awesome. Thanks.

Fishgun123

  • Online Villain
  • ***
  • Posts: 223
    • View Profile
Re: Learning to script
« Reply #3 on: June 14, 2012, 12:13:57 pm »
Scripting seems very differcult but it is very possible to learn. :icon_rolleyes2

[TKC]Symantic

  • The Indifferent Character
  • The Central Committee
  • Heckler
  • *
  • Posts: 1647
  • I can has personal text?
    • View Profile
Re: Learning to script
« Reply #4 on: June 14, 2012, 01:18:44 pm »
Scripting seems very differcult but it is very possible to learn. :icon_rolleyes2

scripting is difficult for some because its a totally different concept from anything that most people use/learn in their everyday life.

computers are pure logic. if this, then this. shit doesn't magically happen, and you don't need a genius mind to create on a computer.

one of the first things you NEEEEEED to learn to do is create the hack in a language you are fluent in (english is fine).

here is an example from another game a long time ago.

The anti-cheat had a value that was 1 (on) when it was scanning, and 0 the rest of the time.

So, my program would have something like this in it.
Code: [Select]
kill_anti_cheat()[
if anti_cheat = scanning_now
then turn_my_cheats_off

else
if anti_cheat= not scanning
then turn_my_cheats on
]

thats kinda how i organize my stuff in my mind. read each line, one at a time.

this is whats called a function, every-time your program calls "kill_anti_cheat()" then those instructions follow.

Im a 101% arma noob, but why don't people use conventional methods of hacking this game?

NOTE*** this code i posted wont work in any other languange than my language, but it does almost look like C++ eh?
Enjoy your creative game-play, whatever that may include.

SquidManHero

  • Relentless Teamkiller
  • **
  • Posts: 59
  • I can cut diamonds with these babies!
    • View Profile
    • Floss all day - Web comic!
In their language, he is known as SQUIDMANHERO
In our language, that is...well...SquidManHero

Temo

  • Relentless Teamkiller
  • **
  • Posts: 93
    • View Profile
Re: Learning to script
« Reply #6 on: June 14, 2012, 06:04:22 pm »
http://pastebin.com/98XEc4jM

credits to the guy who made this (i only have the file on my pc. Do not know where from)!

Fishgun123

  • Online Villain
  • ***
  • Posts: 223
    • View Profile
Re: Learning to script
« Reply #7 on: June 14, 2012, 08:56:10 pm »
Scripting seems very differcult but it is very possible to learn. :icon_rolleyes2

scripting is difficult for some because its a totally different concept from anything that most people use/learn in their everyday life.

computers are pure logic. if this, then this. shit doesn't magically happen, and you don't need a genius mind to create on a computer.

one of the first things you NEEEEEED to learn to do is create the mod-app in a language you are fluent in (english is fine).

here is an example from another game a long time ago.

The anti-cheat had a value that was 1 (on) when it was scanning, and 0 the rest of the time.

So, my program would have something like this in it.
Code: [Select]
kill_anti_cheat()[
if anti_cheat = scanning_now
then turn_my_cheats_off

else
if anti_cheat= not scanning
then turn_my_cheats on
]

thats kinda how i organize my stuff in my mind. read each line, one at a time.

this is whats called a function, every-time your program calls "kill_anti_cheat()" then those instructions follow.

Im a 101% arma noob, but why don't people use conventional methods of mod-apping this game?

NOTE*** this code i posted wont work in any other languange than my language, but it does almost look like C++ eh?
Okay well I think I might try but I am more interested in video editing.. although that shouldn't stop me. SO I want to get more better at that if you see but aswell want to code ( Still at mid school too ) but yeah.

ZOldDude

  • The Unknown Rank!
  • Administrator
  • MasstKer
  • *
  • Posts: 20874
  • Old School TKC
    • View Profile
    • Admin
Re: Learning to script
« Reply #8 on: June 14, 2012, 08:56:21 pm »
http://pastebin.com/98XEc4jM

credits to the guy who made this (i only have the file on my pc. Do not know where from)!

Quote

    This
    ====
    
    
    I've made this short tutorial to give you a crash course on what exactly "this" or "_this" is.
    
    There are basically three places where you see them:
    
    In "init" fields of units
    In scripts
    In the condition fields of triggers & waypoints
    
    Each of these three areas covers a different skill level of mission editing, so this tutorial is for editors of a wide range of skill.
    
    If you are just starting out editing, you only need to understand the first part of the tutorial ("This" in Init Fields).
    If you are starting to get into advanced editing or scripting, you should read and understand the entire tutorial.
    There really isn't that much to it, because I'm only covering two little words...
    
      Now, let's get into it....
    
    
    
    "This" in Init Fields
    =====================
    
    First off, what is an "init" field?
    Basically, it is a place that you put little lines of code that will be run at the beginning of the mission.
    I'm sure you've seen many bits of code that you can put in init fields, to do different things with that unit, like:
    
            this setdammage 1  ->  kills the unit
            this addweapon "m16"  ->  adds an m16 to the unit
            this moveindriver helo1  ->  moves unit into driver seat of helo1
    
    Now, the question is, how come you have to put these lines in a unit's init field?
    Is there something special about the init field?
    Could I put something in one unit's init field, and have it affect another unit?
    Without getting into scripting, I'll just tell you that what you are looking at is almost exactly the same as the kinds of things you put in scripts.
    The difference is, yes, there is something special about the init field of a unit.
    And that thing is "this".
    
    "This" (or "this", or "tHiS"; capitalization doesn't matter) is a special word ("command"). When you put it in the "init" field of a unit, "this" is just another way of saying "the unit who's init field I'm editing right now".
    
    Lets look at one of the above lines again:
    
            this setdammage 1
    
    The line has three parts.
    The middle part is the command ("setdammage").
    What is put in the rest of the line, and what it all does, depends on the command you are using.
    In this case, the command will hurt a certain unit to a certain damage level.
    The right part of the line is what damage level we hurt the unit to (0 being no damage, 1 being full damage).
    The first part of the line is what unit we are going to hurt.
    
    In this case, we put "this" in as the "unit" we want to hurt.
    Since we are putting this in a unit's init field, that unit will be hurt.
    Again: "this" is another way of saying "the unit who's init field I am editing right now".
    
    Instead of using "this", we could simply name a unit (by entering something in his "name" box), and then use that name in one of the code bits we looked at above.
    So we could make a unit, and name him "bob".
    Then we could place a new unit, and in his init field, put:
    
            bob setdammage 1
    
    In this case, the first unit we placed ("bob") would be killed, NOT the unit who's init field we put that line in!
    So really, "this" is just a way to save us time, because it lets us refer to a unit without using his name.
    
    To give you an example of this, let's say we want to make all the units we place stand up, all the time.
    To do so, we could place a unit, name him "a", and then put this in his init field:
    
            a setunitpos "up"
    
    Then we could make a unit, name him "b", and put in his init field:
    
            b setunitpos "up"
    
    Then make a unit named "c", and one named "d", and so on.
    This would be a real pain, wouldn't it?
    
    Well, instead of doing all that, we could just make one unit, and put in his init field:
    
            this setunitpos "up"
    
    Then we could just copy and paste that unit to our heart's content, without ever changing his init field.
    Doesn't that seem easier?
    
    
    A last word on init fields:
    
    There is nothing else special about them, except that they run code at the start of the mission, and "this", which I just talked about.
    Lines of code that don't use "this" can be put anywhere, the only difference is when that code is run.
    Init fields always run at the start of the mission, while "on activation" fields of triggers will run when that trigger goes off.
    That is really all there is to know about "this" and init fields.
    You likely won't understand the rest of the tut unless you know a little about scripting. For those of you who do, I'll go on.
    
    
    
    "This" in Condition Fields
    ==========================
    
    Place a new trigger.
    Open it up, and all you will see in it's condition field is "this".
    So what the heck does that mean?
    
    It isn't the same as in init fields, that wouldn't make any sense.
    Well, you know all those conditions that you set in the "activation" part of the trigger? Those are "this".
    Okay, I know that doesn't make sense, so a little explanation is in order:
    
    
    The Quick and Dirty on Boolean Expressions
    ------------------------------------------
    
    The "condition" field uses something called a boolean expression.
    "Boolean" (named after the English mathematician George Boole) means that it is either TRUE or FALSE.
    
    You likely have seen something similar in algebra classes:
    
            x > 7
    
    In this case, the above expression is TRUE when x is greater than 7, and is FALSE when x is less than or equal to 7.
    Many OFP commands return "boolean" values (true or false).
    
    For example, "alive player" will return true when the player is alive, and false when he is dead.
    
    Boolean expressions can be more complicated than one little operation.
    
    That is where the commands "and" (same as "&&") and "or" (same as "||") come in.
    They mean the same thing as they do in english.
    
    "AND" means "this condition AND that condition must be true", while "or" means "this condition OR that condition must be true".
    
    For example:
    
            (x > 7) AND (alive player)
    
    The entire expression will return true when x is greater than 7, AND the player is alive.
    If either the left or the right statement is false, the expression as a whole will be false.
    "OR" works in a similar way:
    
            (x > 7) OR (alive player)
    
    This will be true when EITHER x is greater than 7, OR the player is alive.
    If either side (or both) of the expression is true, then the whole expression will be true.
    
    There is one last boolean operator, as they are called, in OFP: NOT (same as !).
    "NOT" will return the opposite of whatever is next to it.
    
    So for example:
    
            NOT (x > 7)
    
    The part in parenthesis (x > 7) will be true when x is above 7.
    However, since the NOT is there, the expression as a whole will be FALSE when x is above 7.
    
    Generally you should avoid using NOT if you can, since it can be confusing.
    In the above example, we could have just said (x <= 7).
    
    But sometimes we have to use NOT, like if we want to return true when the player is dead:
    
            !(alive player)
    
    There is no limit to how much you can use boolean operators.
    And remember, there are 2 different ways to "spell" each one (AND + &&, OR + ||, NOT + !).
    
    For example:
    
            ((x > 7) || (alive player)) && (!(alive bob))
    
    My last word of advise when using boolean expressions is to USE LOTS AND LOTS OF PARENTHESIS!
    Just like in normal math, there is an order of operations for boolean expressions.
    If you don't use parenthesis, the expression may be evaluated differently than you expect!
    
    
    Back to "This"
    --------------
    
    The condition field of triggers use boolean expressions, like we learned about above.
    The trigger will only "fire" once the boolean expression in it's condition field is true.
    
    So what about "this"?
    
    "This" refers to everything you set in the "activation" part of the trigger.
    If you make a trigger that is set for "west present", then "this" will become true once a west unit is in the trigger area.
    Normally there is only "this" in the condition field, so normally the trigger will only fire when the condition ("west present") is met.
    
    However, using the stuff we learned above, we can now make more complex triggers.
    For example, we could set a trigger to activate when you radio "alpha".
    
    In it's condition field, we could write:
    
            this && (alive bob)
    
    Now, the trigger will only "fire" when you radio, AND bob is alive.
    
    As you can see, you can now make much more complex conditions for your triggers!
    
    One last note is that if you erase "this" entirely from the condition field, it then doesn't matter what properties you set in the 'activation' section of the trigger, it will only depend on what is in the condition field.
    
    
    Waypoints are very similar.
    With waypoints, "this" is true when the unit goes to the waypoint.
    
    So if we made a waypoint with the condition:
    
            this && (alive bob)
    
    The waypoint would only be "completed" (meaning the unit will go to his next waypoint, and the 'on activation' field of the waypoint will be executed) when the group goes to the waypoint, AND bob is alive.
    If bob died before the group made it to the waypoint, then the waypoint would never be completed, and the group would never move on.
    
     Simple, right?
    Well, now you know all there is to know about condition fields and using "this" in them.
    You'll be happy to know that boolean expressions are also HIGHLY useful in scripting (in the ? command), so if you didn't know about them or understand them before, you are now ready to learn more about scripting from your favorite scripting tutorial.
    
    Now, onto the next section, which deals exclusively with scripts.
    
    
    
    "_This" in Scripts
    ==================
    
    Alright, if you're still with me, it means you have started to make your own scripts.
    That's good; now I'll clear up something that seems to be confusing for most beginning scripters, and is even slightly misunderstood by many experienced scripters.
    
    In every script, we have access to a special variable called "_this".
    
    What is held in that variable changes depending on how you call the script, and by using and understanding that variable, we can move beyond just making a list of commands, and into really making a script.
    
    First, lets take an example:
    
            player exec "myscript.sqs"
    
    That will execute myscript.sqs.
    Now in that one instance (a script can be run multiple times at the same time, each one that is running is called an "instance") of myscript.sqs, the variable "_this" will refer to the player.
    Why?
    Because the player ("player") is what we put next to "exec"; so that is what is passed into "_this".
    
    Notice that "_this" has an underscore next to it, which means that it is a local variable.
    
    If you don't understand what that means, you need to go back and read your scripting tut again, because it is CRUCIAL that you understand the difference between a local variable and a global variable.
    
    I'll say it again, whatever you put next to "exec" when executing a script, will be passed to the script in the variable "_this".
    
    One important thing worth noting, is that if you put a variable next to "exec", the value currently in that variable will be sent to the script (not the actual variable).
    
    For example:
    
            VAR exec "myscript.sqs"
    
    Will pass whatever the current value of VAR is to the script.
    
    If you then make changes to that value (_this) in the script, VAR will not change.
    Likewise, if VAR changes after you run the script, the value in the script (_this) will not change either.
    
    You can put any type of variable next to exec.
    An object, a number, an array, etc.
    Most of the time, arrays are used, because you can then pass more than one piece of data to the script.
    
    For example, if we say:
    
            [player, 5] exec "myscript.sqs"
    
    Then "_this" in that instance of the script will be an array, that holds the player and the number 5.
    If we want to access certain elements in the array, we need to use the "select" command.
    
    For example, to get the first element of the array (the player, in this case), we need to type:
            _this select 0
    
    Usually (but not always) you will want to save all the elements in the "_this" array to new variables, to make things easier for yourself, which is why most scripts look something like this:
    
            _unit = _this select 0
            _count = _this select 1
    
    But keep in mind that you don't have to 'extract' all the elements of the array to their own variables.
    If you only use a certain part of the array once or twice, it is better to not make a new variable, because variables just take up CPU power, which believe it or not makes a difference when you are using lots of scripts.
    
    So, in the above example, if we only needed to use "_count" one time, we could do it like this:
    
            _max = 2*(_this select 1)
    
    One final thing, is that functions use _this just like scripts do, as you will see if you begin writing functions.
    
    
    Special Scripts and _This
    =========================
    
    There are two special scripts where you can't specify the value of _this, because it is defined for you.
    
    First, there are scripts run by actions, added via the addaction command.
    For these scripts, _this is always an array with three elements:
    
            The object the action was attached to
            The unit that used the action
            The index of the action
    
    Next, there are eventhandlers.
    
    Each different eventhandler has different values for _this.
    
    
    
    The Last Word
    =============
    
    I hope you found this tutorial useful.
    It is the first OFP tutorial I have written, but I hope it is understandable.
    
    Please post some comments and suggestions, such as what was unclear, what needs to be explained better, what to add, etc, so that I can revise the tut in the future.
    
    Have fun editing!

*While we crash and burn, small, low tech, agrarian societies such as the Hmong in the mountains of Laos will continue on without so much as blinking an eye.*

Temo

  • Relentless Teamkiller
  • **
  • Posts: 93
    • View Profile
Re: Learning to script
« Reply #9 on: June 14, 2012, 08:59:12 pm »
posting wall of text is allowed?

MrMedic

  • MasstKer
  • ********
  • Posts: 8900
  • programmer/dev/software engineer
    • View Profile
Re: Learning to script
« Reply #10 on: June 15, 2012, 01:13:10 am »
Quote

    This is this..
    ====

    Have fun editing!

^ thats what i would of wrote.



EnCoded Message: i3iy9yl8kr2xf3g2Txs3pr6ye3ya7jg5ty2z

https://www.youtube.com/watch?v=62_7-AYfdkQ
you need a paypal account for the private versions.

Website:
http://bit.ly/medic101

Teamspeak 3: 85.236.101.5:10157

Buster

  • Klass Klown
  • ***
  • Posts: 295
  • Kool Kat
    • View Profile
Re: Learning to script
« Reply #11 on: June 15, 2012, 02:27:46 am »
Quote

    This is this..
    ====

    Have fun editing!

^ thats what i would of wrote.





Lol, they know  :icon_laugh

ZOldDude

  • The Unknown Rank!
  • Administrator
  • MasstKer
  • *
  • Posts: 20874
  • Old School TKC
    • View Profile
    • Admin
Re: Learning to script
« Reply #12 on: June 15, 2012, 02:55:47 am »
Quote

    This is this..
    ====

    Have fun editing!

^ thats what i would of wrote.





Well the other day you told people (hint: _This) and it went right over top of most peoples head.

*While we crash and burn, small, low tech, agrarian societies such as the Hmong in the mountains of Laos will continue on without so much as blinking an eye.*

daleeb

  • Intentional Cheater
  • **
  • Posts: 45
    • View Profile
Re: Learning to script
« Reply #13 on: June 15, 2012, 01:04:40 pm »
Quote

    This is this..
    ====

    Have fun editing!

^ thats what i would of wrote.





Well the other day you told people (hint: _This) and it went right over top of most peoples head.

I think its more the fact that nobody really cares about medics hints and screenshots any more  :icon_laugh
I have actually learned from Joopigs, Neils, and bouncers posts.
Medics triple and quadruple posts in a row in 90% of the threads in the arma section of this board just make you think "wtf is with that guy"

MrMedic

  • MasstKer
  • ********
  • Posts: 8900
  • programmer/dev/software engineer
    • View Profile
Re: Learning to script
« Reply #14 on: June 15, 2012, 01:12:55 pm »
Quote

    This is this..
    ====

    Have fun editing!

^ thats what i would of wrote.





Well the other day you told people (hint: _This) and it went right over top of most peoples head.

I think its more the fact that nobody really cares about medics hints and screenshots any more  :icon_laugh
I have actually learned from Joopigs, Neils, and bouncers posts.
Medics triple and quadruple posts in a row in 90% of the threads in the arma section of this board just make you think "wtf is with that guy"

another fan ?  :icon_biggrin2.



EnCoded Message: i3iy9yl8kr2xf3g2Txs3pr6ye3ya7jg5ty2z

https://www.youtube.com/watch?v=62_7-AYfdkQ
you need a paypal account for the private versions.

Website:
http://bit.ly/medic101

Teamspeak 3: 85.236.101.5:10157