Need fresh eyes on my script...

[jimsolo 12]

Could you guys look at this and tell me if you see the problem/s...

Its part of a support script that is fired by a action command in another .sqf.

First off, my map click stopped working and I cant figure out why. It was working at one point.

Second. I can seem to get the Chopper to move to its second location or wp.

(Chopper called via Action Key then lands picks up player and carries to second location. Action key tell chopper when to lift off. Player is NOT grouped with crew.)

I have tried Domove methods, wp methods and I cant get either to work. :confused:

_man = player;
_helo = MedHelo;
_Trash = Trash;
LZclick = false;
Med_Status = 0;
publicVariable "Med_Status";

_Loc = createMarkerLocal ["Loc", getpos player];
_Loc setMarkerShapeLocal "ICON";
_Loc setMarkerColorLocal "ColorGreen";
"Loc" setMarkerTypeLocal "Dot";
HintSilent "Please Mark LZ";
_LZ1 = createMarkerLocal ["LZ1", [0,0,0]];
_LZ1 setMarkerShapeLocal "ICON";
_LZ1 setMarkerColorLocal "ColorGreen";
"LZ1" setMarkerTypeLocal "hd_pickup";
onMapSingleClick "'LZ1' setMarkerPosLocal _pos,LZclick = true";
waitUntil {LZclick};
onMapSingleClick "";
LZclick = false;

_LZ1 = getMarkerPos "LZ1";
_Pad1 = "HeliHEmpty" createVehicle _LZ1;
deleteMarkerLocal "Loc";
landed = false;

_wp1 = _helo addWaypoint [_LZ1, 1];
HintSilent "Medevac is in route.";
_helo flyinheight 70;
_helo setBehaviour "CARELESS";
[_helo, 1] setWaypointStatements ["true", "landed = true"];
waituntil {landed};
_helo land "get in";
_helo addAction ["Take Off","Medevac\takeOff.sqf",[],6];
HintSilent "Standing by.";
waitUntil {takeoff};
landed = false;

_helo doMove getPos MedSpawn;
_helo flyinheight 70;
_helo setBehaviour "CARELESS";
waitUntil {_helo distance MedSpawn > 20};
_helo land "get out";
waituntil {(!alive _helo) or (0 >= count ((crew _helo)-[MedCrew]))};
Sleep 30;

if(alive _helo)then{deleteVehicle _helo;};
Live_Helo = false;
if(alive MedPilot1)then{deleteVehicle MedPilot1};
if(alive MedPilot2)then{deleteVehicle MedPilot2};
if(alive MedMedic1)then{deleteVehicle MedMedic1};
if(alive MedGunner1)then{deleteVehicle MedGunner1};
if(alive MedGunner2)then{deleteVehicle MedGunner2};
deleteMarkerLocal "LZ1";
deleteVehicle _pad1;

landed = false;

...///

Help and Constructive Criticism only pls. No "Hey you know we have like 6 Support Scripts that work great already out there" comments pls.

Thx in advance, :p

Jim

[twirly 11]

Just reading through I don't see any problrms other than might be caused with stuff that is referenced outside of the script itself....like "Medcrew"..."MedSpawn" etc.

So maybe look there!

[Muzzleflash 111]

Try changing

onMapSingleClick "'LZ1' setMarkerPosLocal _pos,LZclick = true";

to

onMapSingleClick "'LZ1' setMarkerPosLocal _pos;LZclick = true; true";

Semicolons separate statements. You should always return a value from an onMapSingleClick. If everything is working out right then that should be true.

[PELHAM 10]

I ran it through the Squint script helper / checker:

It suggested:

add this line top

private ["_man","_helo","_Trash","_Loc","_LZ1","_Pad1","_wp1"];

change your line to this

onMapSingleClick {'LZ1' setMarkerPosLocal _pos;LZclick = true};

change your line to this

onMapSingleClick {};

Don't know if any of that will work but it gets me out of trouble often.

It could not check the variables such as MedPilot1, Trash, takeoff etc: as they are defined/exist elsewhere.

[st_dux 26]

I'm not sure exactly what you're trying to do with the chopper/addAction stuff, but your onMapSingleClick stopped working because you tried to separate a statement with a comma ( , ) rather than a semicolon ( ; ). Despite Squint's propensity to suggest it, "private" is rarely necessary, and it certainly is not in this case (nor will it fix anything).

[sbsmac 0]

Despite Squint's propensity to suggest it, "private" is rarely necessary

Indeed, 'private' is way of restricting the scope of a named local variable Unless you happen to be using a variable of the same name elsewhere you won't have a problem. However, since people often _do_ use similarly named variables in different parts of the script and since the resulting errors are often subtle and hard to track down, using 'private' is a good habit to get into.

[st_dux 26]

The use of private in the main scope of a script (as was suggested here) can only have an effect on things if the script in question is actually a function that is being called by another script (essentially creating a new scope in the latter script). Otherwise, it's purely redundant: Local variables in outer scopes cannot be made private from inner scopes, and scripts running in different threads (i.e., any script executed via execVM or spawn) using local variables of the same name will never conflict with one another.

[sbsmac 0]

Actually, the original post said it was _part_ of a script ;-) Regardless, I don't disagree that there are situations where 'private' is redundant, but it still does no harm to err on the side of caution.