Scripting Discussion (dev branch)

[gossamersolid 155]

I think only unit which you try to move in should be local to where you execute command, vehicle could be remote. So if you pubvar vehicle reference after creation you can move every client in locally to client.

I'll try this suggestion out if Das' doesn't resolve my issue. Thanks for the suggestion.

There are many many instances of the client calling 'createVehicle' in BIS code which you and I have no ability to disable.

It's a worthy ideal to have all create functions called only on server, but it just isn't reality.

I've already moved a lot of server-side only stuff over to be server and client due to how slow it seems anything PV related is regardless of what I try to do. It's unfortunate, but that's the way it goes I guess.

Something on the side - It'd be great if there was a command to change the irTarget attribute of a vehicle. When I used to use addons for my mission, I could prevent certain vehicles from being locked ever, but now I'm back at the mercy of the vanilla configs. Something like veh setIrTarget 0 would be amazing. Not sure how hard that'd be to implement or if anybody else actually cares about it haha.

[fn_Quiksilver 1635]

Dropping inventory items on the ground and shooting bullets are somewhat equivalent to createVehicle calls (as both are filtered by BE's createvehicle.txt), but otherwise a blank mission never uses createVehicle to spawn driveable vehicles client-side.

Thats a good point.

I am a bit torn about the client creation ability.

On one hand, its a vulnerability ... On the other hand, it allows the easy harness of lots more CPU power in the session, without the ping-pong network traffic spam and locality headaches.

Another example of client creating vehicle is when he crashes a plane or helicopter upside down at speed. the client creates many "CraterLong" vehicles. Sure they are not driveable, but the function is still called.

Most shocking vehicle I have seen client create is the weapon holder created by simply opening your inventory. Every time you press ' I ' a weaponholder(simulated?) is created, and deleted when you move away or close the inventory.

Inadvertently found it when working on garbage cleanup scripts. Experimented with turning clients into vacuum cleaners to offload code from the server, but turns out their inventory closed every time the 'vacuum cleaner' cleaned up nearby weaponholders. stopped there instead of continuing with the fussing. The hope was to give players points for keeping the server clean :) racing around cleaning up garbage and stray mission objects.

If only we could remove "createVehicle" command on clients somehow...

Perhaps a separate createVehicle function for drive-able/usable assets, which contains a missionConfigFile variable condition in it?

createObject [] for type 'buildings' and structures ('house','building'), and reserve 'createVehicle' for stuff with inventories and seats. (air,landvehicle,ship,reammobox)

Edited May 25, 2015 by MDCCLXXVI

[bad benson 1733]

Most shocking vehicle I have seen client create is the weapon holder created by simply opening your inventory. Every time you press ' I ' a weaponholder(simulated?) is created, and deleted when you move away or close the inventory.

if i remember correctly, it's a non simulated one. i remember trying to change that to give dropped weapons physics so you could pick them up and manipulate them a la source engine. the situation the simulated ones are used is when people and AI get killed so the weapon drops nicely alongside the ragdoll effect. pretty sure that's the sole purpose and reason the simulated one was added to the engine.

[torndeco 128]

Anyone able to get

class CfgRemoteExecCommands {};

To work via mission description.ext

It appears to be broken for BIS_fnc_MP & remoteExec etc

Unless i am making a stupid mistake

[das attorney 858]

Yup I'm very curious too, can we get some docu?

https://community.bistudio.com/wiki/remoteExecCall

https://community.bistudio.com/wiki/remoteExec

[gossamersolid 155]

https://community.bistudio.com/wiki/remoteExecCall

https://community.bistudio.com/wiki/remoteExec

Hmmm. Rather disappointed that there doesn't seem to be an ability to natively support callback functions (for the remoteExec) and no ability to just plain old return the value (for remoteExecCall). I was looking forward to using these instead of my own solution (as I currently do), but I require the ability to fire a callback a lot of the time. How are we supposed to know if the function even finished running to use these in our own networking scripts? I don't see any handles being returned or any feedback that it's finished.

Unless I'm missing something here, what's the point of ever using remoteExec if it returns no value?

[das attorney 858]

Hmmm. Rather disappointed that there doesn't seem to be an ability to natively support callback functions (for the remoteExec) and no ability to just plain old return the value (for remoteExecCall). I was looking forward to using these instead of my own solution (as I currently do), but I require the ability to fire a callback a lot of the time. How are we supposed to know if the function even finished running to use these in our own networking scripts? I don't see any handles being returned or any feedback that it's finished.

Unless I'm missing something here, what's the point of ever using remoteExec if it returns no value?

As far as I can see, it is a replacement for bis_fnc_MP. Whereas you might have done this in the past:

[_this,"horde_fnc_doSomethingOnServer",false,false,true] call BIS_fnc_MP;

You can do:

"horde_fnc_doSomethingOnServer" remoteExecCall [_this,2];

Lack of return is ok I think as using bis_fnc_mp only returns the packet as the handle which is pretty useless imo. I think chiefly benefit is using native scripting command to handle your network stuff as opposed to using bis/your functions will be presumably faster.

I already set up my functions to fire a callback using existing pV/bis_fnc_mp architecture so I could just replace the callback commands with this.

I can't really see a downside, but maybe you have spotted something I didn't. One thing I didn't get was use of '2' as server. I would have expected '0' or something else. Using -ve though with number to say "any computer except this one" is a nice touch though.

Also, custom handle for persistent is better than old system imo (where you used to have to check the mission logic for queued persistent functions).

Just my initial impressions though.

[fn_Quiksilver 1635]

As far as I can see, it is a replacement for bis_fnc_MP. Whereas you might have done this in the past:

[_this,"horde_fnc_doSomethingOnServer",false,false,true] call BIS_fnc_MP;

You can do:

"horde_fnc_doSomethingOnServer" remoteExecCall [_this,2];

Lack of return is ok I think as using bis_fnc_mp only returns the packet as the handle which is pretty useless imo. I think chiefly benefit is using native scripting command to handle your network stuff as opposed to using bis/your functions will be presumably faster.

I already set up my functions to fire a callback using existing pV/bis_fnc_mp architecture so I could just replace the callback commands with this.

I can't really see a downside, but maybe you have spotted something I didn't. One thing I didn't get was use of '2' as server. I would have expected '0' or something else. Using -ve though with number to say "any computer except this one" is a nice touch though.

Also, custom handle for persistent is better than old system imo (where you used to have to check the mission logic for queued persistent functions).

Just my initial impressions though.

2 is the owner return for the servers own client (__SERVER__)

//initServer.sqf
dasAttorney = (createGroup EAST) createUnit ['O_soldier_F',[0,0,0],[],0,'NONE'];
diag_log str (owner dasAttorney);   // 2

first non-server client who connects is 3.

[das attorney 858]

2 is the owner return for the servers own client (__SERVER__)

Yeah I know how the owner method works but from Morickys own comments, the server is not always guaranteed to be a set number (here he mentions 0).

_serverID = owner (missionnamespace getvariable ["bis_functions_mainscope",objnull]); //--- Server ID is not always 0

Anyway, I'm not too bothered about why, just that I need to remember 2 as server, rather than FALSE like in bis_fnc_MP.

[killzone_kid 1327]

The server dpnid is always 2. Object owner is different.

[fn_Quiksilver 1635]

Yeah I know how the owner method works but from Morickys own comments, the server is not always guaranteed to be a set number (here he mentions 0).

_serverID = owner (missionnamespace getvariable ["bis_functions_mainscope",objnull]); //--- Server ID is not always 0

Anyway, I'm not too bothered about why, just that I need to remember 2 as server, rather than FALSE like in bis_fnc_MP.

moricky often incorrect esp concerning zeus and arsenal and MP stuff :D

[das attorney 858]

The server dpnid is always 2. Object owner is different.

Ah okay, 2 makes sense then. I read a link here for some info (in case anyone else is interested). https://msdn.microsoft.com/en-gb/library/cc227827.aspx

Thx

[Larrow 2812]

Anyway, I'm not too bothered about why, just that I need to remember 2 as server, rather than FALSE like in bis_fnc_MP.

Same, wish it also supported Boolean value like BIS_fnc_MP. (meh wont take long to get used two after the first couple of mistakes :) )

Otherwise its great to have an engine side solution to fnc_MP and i especially like the ID option so we dont have to query the logic to remove persistent calls.

[gossamersolid 155]

While every new engine side addition is welcomed, I'm still hoping they'll add the ability for a callback.

[das attorney 858]

They changed the documentation today but looks like the commands weren't updated in DB yet.

Doc now says:

params remoteExecCall [functionName, targets, jipID];

But command syntax in game is

functionName remoteExecCall [params,targets,jipID];

Just thought I'd mention it in case anyone is playing with them.

[killzone_kid 1327]

Feel free to add more commands here: https://community.bistudio.com/wiki/Category:Broken_Scripting_Commands

Help mission makers to not waste time because of commands that are released half cooked.

[h - 169]

How is diag_activeMissionFSMs broken?

EDIT:

Seems that the for example the wiki exampel works just fine..

Of course I have no way to verify the timeout is right..

Edited May 29, 2015 by h -

[killzone_kid 1327]

How is diag_activeMissionFSMs broken?

EDIT:

Seems that the for example the wiki exampel works just fine..

Of course I have no way to verify the timeout is right..

It doesn't show *all* FSMs running just some

[h - 169]

Oh, OK..

Assumed it did since a mission seems to have huge amount of FSMs running..

Edit:

Although, to pick a nit, the description doesn't exactly claim it returns all of them, it just says it returns an array of them :D :p

And as such it's not "completely broken", but I digress, it should return all to be of any use..

Btw, would be interesting to know is it supposed to return only external FSM but also the in-engine FSMs..

Edited May 29, 2015 by h -

[killzone_kid 1327]

Oh, OK..

Assumed it did since a mission seems to have huge amount of FSMs running (maybe shifting some of that stuff in-engine would be wise)..

Edit:

Although, to pick a nit, the description doesn't exactly claim it returns all of them, it just says it returns an array of them :D :p

And as such it's not "completely broken", but I digress, it should return all to be of any use..

Command name says it should return active FSMs. When I have no FSMs in my mission running command returns no FSMs, but in fact there is BIS FSM that is running, when I have my FSM started, command return BIS FSM but completely ignores mine. Doesnt matter which way you look at it, it is called broken. I have reported this soonafter those diag commands were released, and it seems that no one is interested correcting this. Like with those turret commands, released many versions ago, no one gonna fix them, because they work somehow, doesn't matter that they do not work as intended, right? At least BIKI users get warned.

[GieNkoV 30]

addBackpackCargoGlobal should be added to this list too...

[killzone_kid 1327]

addBackpackCargoGlobal should be added to this list too...

What happens there?

[GieNkoV 30]

Backpack is added to chest, is visible by everyone, can't be picked up anyway.

[killzone_kid 1327]

Backpack is added to chest, is visible by everyone, can't be picked up anyway.

Chest?

[h - 169]

Command name says it should return active FSMs. When I have no FSMs in my mission running command returns no FSMs, but in fact there is BIS FSM that is running, when I have my FSM started, command return BIS FSM but completely ignores mine. Doesnt matter which way you look at it, it is called broken. I have reported this soonafter those diag commands were released, and it seems that no one is interested correcting this. Like with those turret commands, released many versions ago, no one gonna fix them, because they work somehow, doesn't matter that they do not work as intended, right? At least BIKI users get warned.

Was just jesting really.. Fully support you on this (didn't even realize it was broken until now..).

It seems that if the scripting commands work for some obscure BIS own circumstance it doesn't matter if it doesn't elsewhere.. Much like some of their functions of which many are completely useless unless things are done exactly like done in theirs campaign or whatever (begs the question why make them public at all.. Also a ton of the stuff done via their sqf functions should be available as in-engine scripting commands instead anyway)..

It indeed is odd, seems like if you have no custom FSMs running it returns none but if you do it returns all kinds of BIS FSMs as well..

EDIT:

I took upon using a term "BIS'd" years ago which seems to fit these situations pretty well.. ;)

Edited May 31, 2015 by h -