Script handles

[ColonelSandersLite 0]

This will doubtlessly sound like a kinda odd question, but is there any way for a script to get it's own handle?

For those of you who do not know what a handle is, here's an example:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_scriptHandle = [] execVM "myscript.sqf";

sleep 5;

terminate _scriptHandle;

The reason I'm asking this is for the benefit of calls script that do not return a handle, such as through addAction.

Edit after the fact:

The way I solved this is detailed below, along with a link to the finished project.

[UNN 0]

If you mean directly, then no, I don't think you can. Indirectly, you have a few more options. Using either a single global variable\array or the setVariable command.

Something like:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">MAN01 AddAction ["An Action","AScript.sqf"];

AScript.sqf:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">(_This Select 0) setVariable ["SCRIPTPOINTER",_This ExecVM "TheRealScript.sqf"]

UserActions are a bit clunky, can't Spawn or Call code with them either. Unless you do something similar to the above.

[Synide 0]

i don't think so... but you could try making the variable that will hold the 'handle' in the top-most script a 'global' and not a 'private' variable. and in the sub-script (which would be spawn'd or execVM'd) you could wait till it is not nil. - give it a try...

when i say 'global' variable i mean 'global' to the particular computer, not a global multiplayer (publicVariable) scope...

also, you could try...

for your example ... a script that is called by 'addAction' - you could just make it your personal design with regard to your scripting whereby all 'initial' or 'first' level type scripts would be 'manager' type scripts that in turn call your sub-scripts.

and, these 'manager' scripts would handle your 'scripting handles'...

get what i mean?

[ColonelSandersLite 0]

Figures. I didn't think so but there was a little bit of wishful thinking there . Time to do some restructuring of this stupid port over...

[ColonelSandersLite 0]

I ended up using an array pointer to solve the problem, in sort of an indirect fashion kinda like unn describes above, but not quite.

It looks something like this (note that all details non-relevent to this discussion have been removed. There may be an error or 2 I missed due to sloppyness on that.):

ScriptA.sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

sleep 0.01;

if (count _this < 4) then // called by mission editor in init.sqf or initline

{

_unit = _this select 0;

_handler = [];

_handler set [0, [_unit, _handler, true] execVM "scriptB.sqf"];

}

else // called by action from scriptD.sqf

{

_unit = _this select 0;

_oldActionID = _this select 2;

_handler = _this select 3 select 1;

_unit removeAction _oldActionID;

terminate (_handler select 0);

_handler = [];

_handler set [0, [_unit, _handler, false] execVM "scriptB.sqf"];

};

ScriptB.sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_unit = _this select 0;

_handler = _this select 1;

_firstRun = _this select 2;

if (!_firstRun) then

{

//do some stuff that should only be done on subsequent runs related to toggeling off.

};

// do stuff that should always be done on every run related to toggeling off.

while {alive _unit} do

{

waitUntil {(_unit == player or !alive _unit)};

if (!alive _unit) exitWith {};

_actionID = _unit addAction

[

"Toggle On",

"scriptC.sqf",

[_unit, _handler],

1,

false,

false,

""

];

waitUntil {(_unit != player or !alive _unit)};

_unit removeAction _actionID;

};

ScriptC.sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_unit = _this select 0;

_oldActionID = _this select 2;

_handler = _this select 3 select 1;

_unit removeAction _oldActionID;

terminate (_handler select 0);

_handler = [];

_handler set [0, [_unit, _handler] execVM "scriptD.sqf"];

ScriptD.sqf

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_unit = _this select 0;

_handler = _this select 1;

// do stuff that should always be done on every run related to toggeling on.

while {alive _unit} do

{

waitUntil {(_unit == player or !alive _unit)};

if (!alive _unit) exitWith {};

_actionID = _unit addAction

[

"Toggle Off",

"scriptA.sqf",

[_unit, _handler],

1,

false,

false,

""

];

waitUntil {(_unit != player or !alive _unit)};

_unit removeAction _actionID;

};

All of that was just to put together a framework to support an action menu toggle that only shows for a player unit and only for the person playing said unit, is mp capable, supports jip, and supports teamswitch.

Edit after the fact:

The finished product can be seen here:

http://www.flashpoint1985.com/cgi-bin....t=67970

[mr.peanut 1]

Ouch!

[Synide 0]

All of that was just to put together a framework to support an action menu toggle that only shows for a player unit and only for the person playing said unit, is mp capable, supports jip, and supports teamswitch.

cool... so how do you get it to have an action menu item only showing for the player?

in my experience action menu items are globally 'seen' and locally acted upon - that is once you add an action menu item to your playable character... as soon as my playable character walks within range I can 'see' and 'fire' your action menu command... that's why in the called script you have to weed out who fired it... so anyway moving on from that...

was the objective of your thread to have a 'toggling' action menu command?

or maybe you could just post some psudeo code on what it is your trying to achieve...

in ofp i did a little action menu toggling thing whereby it was a pace counter...

essentially the character could pickup a pace counter at which point they got an action menu 'Start Pacer'

when 'Start Pacer' was run it removed itself as a action menu item and added 2 new menu items called 'Pause Pacer' and 'Reset Pacer'... and so the story goes on... it worked nicely 'cause also the 'killedEH' was chiming in when necessary...

the point is... action menu items get access to their own 'handle'...

it just looks like to me, with your above scripts that your using VM's to manage the adding and removal of action menu items when you don't need too... they can do it themselves in concert with the killedEH... or maybe that's a wrong take on what you're trying to accomplish...

[t_d 47]

Quote[/b] ]in my experience action menu items are globally 'seen' and locally acted upon - that is once you add an action menu item to your playable character... as soon as my playable character walks within range I can 'see' and 'fire' your action menu command... that's why in the called script you have to weed out who fired it... so anyway moving on from that...

If you add the action only locally, it only can be seen on that certain computer. For example: if(local S1)then{player addaction [whatever]};

In this case only the player where S1 is local can see the action.

[Synide 0]

i'd have to disagree... i'll go back and test if needed... but, i'm 90% certain i'm right... a few months back i was playing around with a 'capture' civs with an action menu... the civ's had action menu commands added to them on the server and were captured by players at which point they moved to the players computer/group... other players could still see and activate the civ action menu item... but, as i say it was a while ago and i'd have to go and retest...

also, noticed in OFP when i used to add a action menu items to players i could 'see' and activate their action menu command...

that's why in the action menu script that gets called you get...

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

//_Sender=Unit who sent the action command (usually the same as the 'attached to' unit)

//_Unit=Unit the action is 'attached to'

//_Index=Index number of this action in the 'attached to' units action menu

then in your script you have to...

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

if ((_Unit == player) & (_Sender == player)) then {} else {};

isn't that right?

but... we're getting away from the topic...

[ColonelSandersLite 0]

but... we're getting away from the topic...

It's fine. The original topic has been solved, so I have no problem discussing this as it pertains to the scripts above .

i'd have to disagree... i'll go back and test if needed... but, i'm 90% certain i'm right... a few months back i was playing around with a 'capture' civs with an action menu...

T_D is absolutely correct in that action menu items are only added locally. I'm 100% sure on this issue, as I have it working as described.

If you want to see this concept in action, I recently wrote a script for a mission where I took advantage of this. You see it in Operation Shining Anvil Co 1-2 by playing the sniper, and the spotter respectively and playing with the weapon switching option available to the sniper only .

The question, and the scripts derived from the question where on account of me making a publicly releasable generified version of the weapon switching script present there. Shining anvil does not support team switching or JIP, but if 2 in 10 people that use my script will need it, it will be important for me to have it in place.

The public release version of that script is actually done (with documentation and supporting web page). The only reason I haven't released yet is that I need one final test to be sure an issue with lost equipment with JIP is solved. Special Ed (who has helped me test it so far) is busy till the weekend, so it'll be released somewhere between saturday and monday most likely.

the point is... action menu items get access to their own 'handle'...

I believe they get access to their actionID, not to their script handle. If you can tell me otherwise, I'd be interested in finding out how that works. See, here, I needed the ability to terminate the scripts themselves, not just remove their action menu items. The script's looping indefinatly is necessary to make add/remove the action from the unit whenever a player jumps into or jumps out of the unit. The terminate command is the only practical way that I can think of off the top of my head to stop script A after script C is started without adding a global.

[Synide 0]

yip, agreed... i'm going senile in my old age... just re-tested and an action added on another comp. is local to that comp. - unless the unit moves computers... cool i was wrong.

actions don't have 'script handles' - i used the wrong terminology there but yes you can get the actionID from within the called script of course...

I checked trying to get of the 'script handle' from within a spawned VM thing and the result was a 'scalar' value...

sorry, i really am having a 'bad hair day'... usually a bit more 'on the ball' with this sort of stuff... looks similar to a 'lockable' vehicle mechanism i made a while back... anyhoo.