onMapSingleClick – Talk

From Bohemia Interactive Community
Jump to navigation Jump to search
No edit summary
m (Return value)
Line 24: Line 24:
I am used to functions returning values. Not commands returning values. --[[User:ViperMaul|ViperMaul]] 05:34, 10 July 2007 (CEST)
I am used to functions returning values. Not commands returning values. --[[User:ViperMaul|ViperMaul]] 05:34, 10 July 2007 (CEST)
:This is how you do it in a .sqf file: ''onmapsingleclick "[_pos, _units, _shift, _alt] execvm ""mapclick.sqf""; true";'' execvm returns a handle, not bool.. so throw a fake bool on the end. --[[User:Doolittle|Doolittle]] 05:46, 12 July 2007 (CEST)
:This is how you do it in a .sqf file: ''onmapsingleclick "[_pos, _units, _shift, _alt] execvm ""mapclick.sqf""; true";'' execvm returns a handle, not bool.. so throw a fake bool on the end. --[[User:Doolittle|Doolittle]] 05:46, 12 July 2007 (CEST)
== Return value ==
Let's clear this up.
this '''command''' does <u>not</u> return [[Anything]]
it is a command that, at 'some future time' will execute '''[[Code]]'''
whether the individual and wanted command(s) within [[Code]] return a boolean true would be highly problematic and unlikely.
So, in order to satisfy the engine, a [[Boolean]] [[true]] is required <u>from</u> the [[Code]]
It is an engine requirement that the 'click has been processed'.
Presumably if it gets any other value, the engine will sulk, or worse, repeat the [[Code]] in the belief that it needs to.
an excellent example of how to achieve this miracle is given above and repeated here
onmapsingleclick "[_pos, _units, _shift, _alt] execvm ""mapclick.sqf""; true";
the command (yes, it is a command) 'true' is passed back to the engine. The fact (mentioned above) that execVM returns a handle is irrelevant, it is overridden by a subsequent command, true

Revision as of 01:46, 5 September 2007

Note: This expects a bool return value, unlike onPlayerConnected. --Doolittle 07:33, 9 July 2007 (CEST)

Much appreciated. Please give an example. Thanks --ViperMaul 11:40, 9 July 2007 (CEST)

Command description text already states this.

If click is processed, command should return true.

Planck 11:53, 9 July 2007 (CEST)

Correct me if I am wrong here. But technically speaking the term "command" in "If click is processed, command should return true" when applied to the following example given onMapSingleClick """SoldierWB"" createUnit [_pos, group player]";

in this statement the command == """SoldierWB"" createUnit [_pos, group player]" right? And if command returns true then this example evaluates to onMapSingleClick true; This is judging by the read.

Is it not a better example to say _result = onMapSingleClick """SoldierWB"" createUnit [_pos, group player]"; where _result can equal true or false? Again if I am off the mark then I am confused and I am asking for a concrete example to clear this up for me and probably others.

I am used to functions returning values. Not commands returning values. --ViperMaul 05:34, 10 July 2007 (CEST)

This is how you do it in a .sqf file: onmapsingleclick "[_pos, _units, _shift, _alt] execvm ""mapclick.sqf""; true"; execvm returns a handle, not bool.. so throw a fake bool on the end. --Doolittle 05:46, 12 July 2007 (CEST)

Return value

Let's clear this up.

this command does not return Anything

it is a command that, at 'some future time' will execute Code

whether the individual and wanted command(s) within Code return a boolean true would be highly problematic and unlikely.

So, in order to satisfy the engine, a Boolean true is required from the Code

It is an engine requirement that the 'click has been processed'.

Presumably if it gets any other value, the engine will sulk, or worse, repeat the Code in the belief that it needs to.

an excellent example of how to achieve this miracle is given above and repeated here

onmapsingleclick "[_pos, _units, _shift, _alt] execvm ""mapclick.sqf""; true";

the command (yes, it is a command) 'true' is passed back to the engine. The fact (mentioned above) that execVM returns a handle is irrelevant, it is overridden by a subsequent command, true