Home   Help Search Login Register  

Author Topic: Easy Company & BugTracking  (Read 797 times)

0 Members and 5 Guests are viewing this topic.

Arrouan

  • Guest
Easy Company & BugTracking
« on: 01 Dec 2002, 06:17:29 »
I already asked you people for help, but apparently nobody knows the answer to the "action" mystery (no problem :))

I'll tell you why I desperately need the command: for the moment I'm scripting some kind of "Easy Company" mission (Band of Brothers). But - in OFP version 1.30- there seem to be a lot of bugs and undocumented features. It would be a great help if some of you guys helped me out here.

#########################################

For this reason I propose we start some kind of "undocumented" (or less known) list. Here's my contribution:
(maybe you can find it one day at ofp.kroffel.com)

1) Public variables have not to be declared publically if you declare them in an "init.sqs" script - at least that's what I think. I saw some scripts by snypir and found out he didn't use a single public variable.

What's the use of PublicVariables, you'll probably ask ... You use them to define global - not (script) local - variables. This means "variables that keep on living outside scripts". Example: I'm building the E-company mission. If you want to lay a Firing Base, or give covering fire, you can first check wether there is already a firing base etc, by defining a public variable (or just a variable in the init.sqs script) and switching it to true:
eg.

PublicVariable "FiringBaseBusy"
FiringBaseBusy = FALSE

After you have declared the variable globally, you can alter it through a local script (eg. the Firing Base script)
Moreover you can declare a public variable in any script you want (when you need the variable) - although, of course, I think it's better style to declare all Public Variables beforehand.

Conclusion: you can use PublicVariables not only for multiplayer misions, but also for Single Player missions. If you're a bot creative you can even pass them as "kinda arguments" to scripts !!!

2) Arrays can be initialised by declaring an empty array. Honestly spoken: I first tried:

Array =
  • , which gave me an array containing (of course) "0"

Array = [ObjNull], which gave me an object with initially 1 element, "ObjNull"

I thought it was impossible to declare an empty array (since I am very suspicious to "empty memory space" - it usually gets filled up with all kinds of garbage - try it in JAVA !!!), but finally I saw you could initialise it with

Array = []

simple, but undocumented...)

3) It is impossible to make groups act the way you want (eg. try the <Group setUnitPos "DOWN"> command for a group, it won't work, you'll need a for-like structure)

4) Only the < [Array] exec "script.sqs"> command accepts strings, which have been formatted by the <format ["String %1", _variable]> command. So don't try to use it to name units for example in a for-structure <_u% = Units Player select _i>, it'll return the error: "error type: expected object, instead of string" (or something like that).

5) OFP scripting does not accept strings within strings:

I tried \", ', but neither of them worked. You can declare some strings as varables, eg <_wp0 = "M16"> after which <Unit AddWeapon _wp0>, but you can't replace a "BLUE" or "UP", ... string by a variable :(
Note that you cannot use it in <"_x blabla" Foreach Array> structures, neither in <[Array] exec "script.sqs"> structures.

(I think we should claim the right to use nested strings !!!)

6) I have a bug with <AddAction> commands being displayed twice in a demo ... sometimes ...

Arrouan

  • Guest
Re:Easy Company & BugTracking
« Reply #1 on: 01 Dec 2002, 06:22:18 »
I forgot to mention that any help (with E-company missions) is welcome.

I already have a "Lay firingBase", a "Covering Fire", and a "Send in Assault team". I'm still working on a "Move to Target ZIGZAGGING" and a "Blow up Target (with pipebomb)" script.

The first three will be published next week.

Robbo

  • Guest
Re:Easy Company & BugTracking
« Reply #2 on: 01 Dec 2002, 10:21:40 »
Quote
But - in OFP version 1.30- there seem to be a lot of bugs and undocumented features. It would be a great help if some of you guys helped me out here.
Why don't you download 1.46 from www.flashpoint1985.com
Its free and fixes a lot of bugs ??? ;)
Robbo

Gameer_77

  • Guest
Re:Easy Company & BugTracking
« Reply #3 on: 01 Dec 2002, 14:31:59 »
5) OFP scripting does not accept strings within strings:

I tried \", ', but neither of them worked. You can declare some strings as varables, eg <_wp0 = "M16"> after which <Unit AddWeapon _wp0>, but you can't replace a "BLUE" or "UP", ... string by a variable :(
Note that you cannot use it in <"_x blabla" Foreach Array> structures, neither in <[Array] exec "script.sqs"> structures.

Don't quite get what your on about here, but try double quotes:

Ex.  "_x setunitpos ""uP""" foreach units this


Offline Dinger

  • Contributing Member
  • **
  • where's the ultra-theoretical mega-scripting forum
Re:Easy Company & BugTracking
« Reply #4 on: 02 Dec 2002, 06:12:20 »
First, upgrade to 1.46 at the very least.
Second, if you really like OFP scripting, get resistance.
1.85 introduced some sweet features.

Be sure you distinguish between bugs and features:

Quote
1) Public variables have not to be declared publically if you declare them in an "init.sqs" script - at least that's what I think. I saw some scripts by snypir and found out he didn't use a single public variable.
Not true.  The reason for using init.sqs scripts in MP is that they're run on all clients, unlike init fields for units or init eventhandlers.

Quote
What's the use of PublicVariables, you'll probably ask ... You use them to define global - not (script) local - variables. This means "variables that keep on living outside scripts". Example: I'm building the E-company mission. If you want to lay a Firing Base, or give covering fire, you can first check wether there is already a firing base etc, by defining a public variable (or just a variable in the init.sqs script) and switching it to true:
eg.

PublicVariable "FiringBaseBusy"
FiringBaseBusy = FALSE

After you have declared the variable globally, you can alter it through a local script (eg. the Firing Base script)
Moreover you can declare a public variable in any script you want (when you need the variable) - although, of course, I think it's better style to declare all Public Variables beforehand.

Conclusion: you can use PublicVariables not only for multiplayer misions, but also for Single Player missions. If you're a bot creative you can even pass them as "kinda arguments" to scripts !!!
Actually, this isn't the case. Variables come in two flavors: Global and Local.  Global ones hold throughout the mission, local ones are in the script.  For old-fashioned OFP scripts, the difference is the underline before local variables.
With 1.85 and functions, we can define the scope of variables using the Private command.

Both global and local variables are specific to the machine running it.  That is, there is no built-in synchronization of these variables between MP clients.

PublicVariable is not a means for defining a variable, but a means for broadcasting it to other clients.  Of course, it only works for global variables.
So for example, if you run a server-side script with the following lines:

PublicVariable = "MyNumber"
MyNumber = 1200

If you hadn't defined MyNumber beforehand, all your clients will register MyNumber as having a null value, i.e., as a non-variable..

Quote
2) Arrays can be initialised by declaring an empty array. Honestly spoken: I first tried:

Array =
, which gave me an array containing (of course) "0"
Array = [ObjNull], which gave me an object with initially 1 element, "ObjNull"

I thought it was impossible to declare an empty array (since I am very suspicious to "empty memory space" - it usually gets filled up with all kinds of garbage - try it in JAVA !!!), but finally I saw you could initialise it with

Array = []

simple, but undocumented...)
Yeah, it took me a month to realize you could do this.
Quote
3) It is impossible to make groups act the way you want (eg. try the <Group setUnitPos "DOWN"> command for a group, it won't work, you'll need a for-like structure)
Not impossible, but very, very hard, and for the most part, not practicable.
Quote
4) Only the < [Array] exec "script.sqs"> command accepts strings, which have been formatted by the <format ["String %1", _variable]> command. So don't try to use it to name units for example in a for-structure <_u% = Units Player select _i>, it'll return the error: "error type: expected object, instead of string" (or something like that).
I don't understand your argument, but you certainly can pass:
["Barney"] exec "Script.sqs"

Quote
5) OFP scripting does not accept strings within strings:

I tried \", ', but neither of them worked. You can declare some strings as varables, eg <_wp0 = "M16"> after which <Unit AddWeapon _wp0>, but you can't replace a "BLUE" or "UP", ... string by a variable
Note that you cannot use it in <"_x blabla" Foreach Array> structures, neither in <[Array] exec "script.sqs"> structures.

(I think we should claim the right to use nested strings !!!)
A. AFAIK you can replace a "BLUE" or "UP" by a variable.  YOu probably have trouble with the specific variable.

B. Before 1.85, you could nest strings, you just had to be tricky about it:
    1. You get one level of nesting by using "" ""
    2. You can nest any further numbers using variables.
    3. ForEach executes the string to its left; Count runs a boolean on the string to its left.  Both require an array to tell it how many times to run.  Neither needs to use _x in the string.

C. After 1.85, we get:
    1. {} are used for strings, allowing an indefiinite number of levels of nesting.
    2. Call allows us to execute strings

Quote
6) I have a bug with <AddAction> commands being displayed twice in a demo ... sometimes ...
Did you add the action to more than one unit?
Dinger/Cfit