Author: Pierre MGI
Author Website:

Short description: Need to test a code in the editor?
Date: 2016-08-03 22:52
Submitted by: Pierre MGI


Comments: (1)
Rating:



 

Hi,
This is a basic consideration about testing a script.

First of all, please consider the sqf language for coding. sqs is outdated.
I recommend you to use a sqf highlighter to make easier your writing. Many errors can be avoided with such tools like Poseidon from Tom_48_97.

Usually, mission makers are writing an sqf file with lines of code and uses a command such as execVM to fire it at the right place in the scenario.

There are some variants depending on what you want to obtain, and what is the nature of the code (scheduled, unscheduled). This notion will be explained later, but roughly:
- "call" means immediately run this code; following codes (lines) are not run until the end of the called one.
- "spawn" means run this code in parallel with main code. execVM is similar.

Now, let's say you have something to test in your mission. Instead of creating an sqf file, you have two easy ways to test a code (even a long one!):

- use the debug console;
- place a trigger on your map in mission editor, no condition (delete this in condition field), none, none.

Both methods imply you wrap your code in:
 0 = [] spawn { <your code here>}
and the code must be blank of any comment (no // or comment or /* */) or the code will stop and fail.

I'd rather like the trigger, because it "belongs" to your mission and you can test it as you want:
- type this in condition field (remember other conditions are none none, no area), and the trigger will never fire (no test for code)
- delete this in condition field (let it blank) and your code is ready to fire. Condition is always true and trigger will fired at start.

An example?
I liked to help for making a tank firing at infantry with HE shells instead of standard APFSDS ammo.
I added a Slammer tank (tk) and a trigger, deleted this in cond field, add this code in on act field:
    0 = [] spawn {
      tk removeMagazinesTurret ["2000Rnd_65x39_Belt", [0]];
      while {true} do {
        waituntil {!((tk nearTargets 1500 select {side (_x select 4) getFriend side tk < 0.6}) isEqualTo [])};
        _tgt = (tk nearTargets 1500 select {side (_x select 4) getFriend side tk < 0.6}) select 0 select 4;
        if (_tgt isKindOf "man" && (tk currentWeaponTurret [0] == "cannon_120mm")) then {
          tk loadMagazine [[0],tk currentWeaponTurret [0],"16Rnd_120mm_HE_shells_Tracer_Red"]
        } else {
          tk loadMagazine [[0],tk currentWeaponTurret [0],"32Rnd_120mm_APFSDS_shells_Tracer_Red"]};
        sleep 0.2;
    }}

You don't need to test it anymore or you need to test something else? No need to erase the trigger, add < this > on condition field. Trigger is always false and the code is skipped.

One more thing, I barely write a working code at the first trial. I'm always referring to the rpt file (report) in the hidden folder c:\users\...you\AppData\Local\Arma3 .
Open the last one with a notepad.
Check for error(s) generally located at the end of the file (for a test).

Some tracks to follow:
- variable not found or missing element: your (private) variable is undefined within the scope (section of code calling this variable);
- missing elements in an array (like 0 provided, 3 expected) Usually, a missing position or a missing object passing its position
- suspension not allowed in this context: typically you're trying to run a scheduled loop in a called (immediate) context. Should not occur if you're using the wrap 0 = [] spawn {code}. But this can be fired within an eventHandler scope.
- missing ; How many times I wrote = instead of == , I can't count. Generally, you can't close the trigger with such error!

One rule: always respect the syntax as specified in BI library. If a parameter is object, that means a unit or a vehicle or a building but something present in editor or spawned. It's a very common error to replace this object (a rifleman unit) by a string like "B_Soldier_F", or the contrary.
Plenty of BI commands returns the "typeof" object instead of the object itself. Best example are for weapons or magazines. All commands are returning strings or arrays of strings but not the object itself. Some others are object oriented like entities, nearObjects, findNearestEnemy, lineIntersects,... and they often returns an array with objects.



Tags: No tags