-
Content Count
144 -
Joined
-
Last visited
-
Medals
Posts posted by Radioman
-
-
I'm not sure if this is a SP or MP issue.Basically I want each player in MP to be only to run this action once.
in the init of the unit I have
player addaction ["Spawn Quad Bike","scripts\spawn_quad.sqf"];
spawn_quad.sqf
private ["_unit", "_quad"]; _unit = this select 0; _quad ="B_Quadbike_F" createVehicle (position _unit); _unit removeAction 0;
The above doesn't work. I does if I substitute "_unit" with "player". But I need it to run separately for each player in MP. Do I need the variables to be private? If so, how do I ensure the script only runs for the player that called it?
_this
-
Firstly your compiled code wont work and throw an error. Secondly there is no harm in transferring strings. The reason why code is harmful is because hackerfunction = {}; publicVariable "hackerfunction" now every client has the function on their machine. all you need now is to use BIS_fnc_MP to pass the name of the function and parameter. Now please enlighten me with the similar procedure for the string exploit.He's going on about how people are daft and put 'call compile _pvVar' in their PVEHs.... So, his argument is a tad invalid, as a workaround already exists to fix that issue.... Simply, don't trust stupid people to program missions. call compile public variables.
-
I vote that all 'global effect' functions become local effect, with the exception of perhaps 'passive' methods, like createmarker etc.
Good mission coding practice would be to make the server handle if/how/when an event should cause global effect, via PVEH, and NOT have any call compile _pvVar anywhere, as that's simply stupid. Use a flag based PV, as you'd only need the passed variable content be a few characters long.
Edit:
I also vote that missions that have 'disableGlobalEffect = true;" set in their .ext, override a server's disableGlobalEffect, if it is not explicitly set. (ie, not in the config)
That way, admins can choose whether or not to allow global effect or not. I believe, however, that BIS would need to implement an execution wrapper for addons etc, so that addons can have, in their config.cpp, a flag that allows global exec of calls it does, vs having them universally blocked
You may say "BE Filters do this!", but, you can't cover all eventualities without breaking missions, if you have a cycle. You cannot expect server admins to de-pbo all missions, check through them, make sure the BE filters don't clash, and make adjustments.... Most server admins cannot even tie their shoe laces.... BE filters were only marginally effective on Arma 2, and they were set up on static missions (DayZ) where the code rarely changes, and yet still hackers ran rampant....
So.... BIS needs to publish a plan for all this, for all of us to critique, and white-hat the crap out of, until it's covered all bases of security, and functionality.
I don't give a wooden nickle about breaking people's code. We don't want the same old crap ported up from A2, which was ported up from A1.... It's all really REALLY bad code, full of holes, from a long passed era of 'Pre-mainstream Arma'. Batten down the hatches, and make it so only SMART people can only do the RIGHT thing.... Your audience has changed, and so must your outlook on security, BIS.
-
You see I would have agreed with you there months ago when I was deciphering dayz code and looking up BIS_fnc functions. Oh the horror of ArmA 2 BIS library. ArmA 3 BIS library is actually very well written, so something must have drastically changed between then and now. Also the fact that we now have all commands read only and compileFinal says a lot about the direction BIS taking.Yes, a newly adopted direction.
Also, the A2 functions are still in A3, so that's still something to worry about.
-
The only time I've seen dynamic call compile used is when people try to dynamically access existing public variable name. This http://killzonekid.com/arma-scripting-tutorials-variables-part-2/ explains about namespaces and why you dont need to do call compile like that. Dynamic on the fly function creation? I wonder under what circumstances you would need it.Well exactly, there's no REAL reason to do it that way, but, with BIS, there's no surprises there.
I mean, considering that this virus thing could even happen, I'm not surprised anymore by this mandatory library and how insecure it is....
I'd never do something like what I described, but I've yet to go through ALL these functions and check them.
-
Please elaborate. Output of compileFinal is fixed code, how do you compileFinal a variable?BIS could have somewhere in their library, that pulls a variable from the UINamespace, and 'call compile's it. You could compileFinal something into that variable, and then the function will recompile it again. But this isn't very probable, because of the fact that call compile doesn't take 'code' as a parameter, so thus would probably just error out instead.
When I say variable, I mean it loosely. As, in SQF a function is just a variable that contains code, so, they're quite related.
There could be some parts of the library that dynamically create functions and then run them later, so thus, aren't compileFinal. Again, I'll have to do some digging to be sure....
-
Yes, I know. I think this is a good step. Should be enough to stop people from hacking without needing to actually hack anything.Though, there's a flaw in this, in that there's some dynamic variables that are called by BIS functions, that players can compileFinal, and inject code in that way. >.> I'm yet to test this however, but I'll give it a try and find out if BIS made a fancy way for just their function library to be able to overwrite 'final' variables/functions.
-
createMarker might be global, but setMarkerPos isn't so if you want to move your markers dynamically, you need to update them on clients with setMarkerPosLocal, at least that's how I understand it.Usually I do things like this:
1) Update setMarkerPos server side
2) PV a variable like markerPosUpdated or whatever
3) Have a client side PVHE on that variable run setMarkerPosLocal.
My question was related to WHICH HE is doing what and from what Radioman just posted, if you define the HE client side, it's ONLY the clients doing it, which is fine for me. That means when I PV, only the variable is sent (which is ridicule), all the rest is done 100% client side. If this is indeed true, I don't really see the problem with doing SHITTONS of stuff on clients, just using flags variable that you PV here and there on the server (apart from core server stuff of course).
I'm still wondering if it's more efficient to pack all that you can into an array and send that over once, or to have tons of little independant variable that you PV as you go. I'm guessing arrays is the way to go but that would mean sending bigger chunks to everyone at the same time...
As you said though, you NEED to send that stuff to the client, one way or the other. All you can do is find the "best" way, I agree. But in the end, it needs to send something :)
You can break up PVs without much issue. As long as you're not sending hundreds at a time. Optimisation is key, and there's not been any specific findings on whether PV packing is faster or not.
PVClient and PVServer can help slim things up.
-
Alright, but what about addPublicVariableEventHandler? Is that 100% client based once the map is loaded or does the server send the ENTIRE thing every single time? (I updated the post you replied to while you were replying). I mean the wiki says it's the EH doing it, but which one? client, server, my grandma's?Doing what exactly?
The publicvariableEH runs on whatever client/server instance it's defined on. It's a local object, so having one doesn't pass it's existence over the network.
BIS_fnc_MP does NOT pass entire code blocks across the network. It only passes the function name, which is called on all clients/target client. So thus, you MUST have the function defined on the target first, or it wont work.
For updating marker locations, if it's for showing where players are on the map etc, you can do that locally, without any need for any public variables. Just put all the player slot object names into an array, and every second or so, update each object's marker.
-
Something I don't understand.You need publicVariable to make sure some things update on clients, and at the same time it everyone seem to agree that it screws everyone over. How the heck would you update markers on a map for a MPMission without telling all clients to update it for example? I mean, no matter what, at SOME POINT, you need to send stuff to clients and force them to update..
Yes, PublicVariable is fine. Just it's ability to send code isn't. That's all. You can update your markers fine, because you've no reason to have to PublicVariable the code to do so....
-
Not to mention, shouldn't private ["cb"] cause a compile error?
private scope is just limiting that variable's content to that script (or braces block, depending on where it's defined), so you can have many _cb in different scripts, and they could all have differing values.
all variables starting with an _underscore are treated as private by the engine. All variables without an underscore, are treated as 'global' variables, which can be accessed anywhere within the game session where it's defined (so, on the client, in this case). Changing that value anywhere, will change the value for all other uses of it also (essentially).
Global variables are not public variables (in regard to how Arma works, a public variable is one that is synchronised across the network to all clients + the server, unless done specifically for individual sessions), so using a global variable wont interfere with other clients.
-
They can always stop publicVariable from transmitting code.They could, and that'd be a nice step in the right direction, but then it breaks addons running things over the network for non-addon running clients. So, they need to do a radical redesign/implementation of this entire spectrum of the scripting engine. Essentially, allowing only the server to BIS_fnc_MP, but also some kind of addon thing too, I don't really know.
Essentially, we can't say "Oh, thingA needs that function, so don't remove/change it", as that doesn't fix the REAL problem. What needs to be discussed is the way to solve all problems, not just create more.
---------- Post added at 21:21 ---------- Previous post was at 21:20 ----------
Will do, I've edited it and will try and test with a friend again some time today, cheers.By the way, the examples on this page
https://community.bistudio.com/wiki/BIS_fnc_MP
use spawn BIS_fnc_MP but these were examples from the Take On Helicopters page for this function, it says it should actually use Call for execution in Arma 3, will that make any difference?
I'd just use call. I'd say that page is a little wrong currently, and all BIS_fnc_MP calls within the function library use call also.
-
Thanks I will try this. I thought it might be something to do with the object being local. Would just changing it to a global name so it is called "cargobox1" instead also get around the problem?No, that wont fix the problem. I've told you how to fix the problem.... Exactly how. Do that, and it's fixed.
---------- Post added at 21:01 ---------- Previous post was at 21:01 ----------
I was speaking about scripting command on hacker local machine, which has global effect. This is a problem since OFP. It's less vulnerable than executing full script on everyone computer, but still, ruining a game with one script command with global effect is far too easy...Well, for now, lets stick to stopping the crazier stuff like free-roaming viruses and stuff and executing code, vs global effect functions from one client.
-
Well, this BIS_fnc_MP really doesn't work for me, this is how I'm using it and it will only show the action for the server and not clients even though it's being told to execute on all clients. Here's a cut down version of the script:// Create addAction function CF_addactionMP = { private["_actName","_object","_screenMsg","_scriptToCall"]; _actName = _this select 0; _object = _this select 1; _screenMsg = _this select 2; _scriptToCall = _this select 3; if(isNull _object) exitWith {}; _actName = _object addaction [_screenMsg,_scriptToCall]; }; if (isServer) then { // Create cargo box and attach it to the vehicle (Settings are for c_offroad class only) _cargobox1 = createVehicle ["B_supplyCrate_F", getPos _veh1, [], 0, "NONE"]; sleep 2; _cargobox1 attachTo [_veh1, [0,-2.0,-0.65]]; _cargobox1 setDir 90; // Add action to vehicle [[action1,_cargobox1,"Unload Cargo","scripts\carintel1.sqf"],"CF_addactionMP",_cargobox1,true] spawn BIS_fnc_MP; };
Is there anything wrong with this or does this function just not work properly?
_cargobox1 is an object that is local to the server. So thus, it'll only run the function on the server.
To quote the wiki: "Object - function will be executed only where unit is local [default: everyone]"
So, call this:
[[action1,_cargobox1,"Unload Cargo","scripts\carintel1.sqf"],"CF_addactionMP",nil,true] spawn BIS_fnc_MP;
Should work, but I don't think you can just send an object over the network, and have it mean anything on the client's side.
So, you'll need to send the _cargobox1's netID. So, this:
[[action1,netid _cargobox1,"Unload Cargo","scripts\carintel1.sqf"],"CF_addactionMP",nil,true] spawn BIS_fnc_MP;
and modify your CF_addactionMP function to this:
CF_addactionMP = { private["_actName","_object","_screenMsg","_scriptToCall"]; _actName = _this select 0; _object = objectFromNetID (_this select 1); _screenMsg = _this select 2; _scriptToCall = _this select 3; if(isNull _object) exitWith {}; _actName = _object addaction [_screenMsg,_scriptToCall]; };
-
I'do agree with Radioman. You can still run bad code on everyone machine with this :[{player setpos [0,0,1000]},"BIS_fnc_spawn"] spawn BIS_fnc_MP;
And even if BIS removed the Bis_fnc_spawn from the library, hacker can still modify memory to run any script on their machine.
Correct on point 1, but wrong on point 2. You can edit your own memory, etc, and implant any code you like, but to execute it over the network, I suppose is a fault of BIS_fnc_MP, which, is essentially STILL a problem, if it can be used for non-BIS functions.
BIS needs to only allow BIS_fnc_MP run BIS functions, and get rid of/fix any functions that call compile / spawn etc from passed params.
But, it appears that BIS is pretty hard-set on keeping fnc_MP as is, and I can't communicate the above to BIS because of the aforementioned flaws in their feedback tracker, and the forums.
-
Because it would run on all machines when you create a vehicle whether you wanted it or not, so a hacker could execute code on each client by just creating a vehicle. Also old MP framework with RE was flawed for the same reason. Now you cannot send code and execute it over network, you have to have a function name you want to execute instead and this is where you can control as mission maker what is going on and what should and should not happen.Your answer has little-to-no relation to my post... unless you meant to quote Defunkt?
If a hacker can run 'setvehicleinit' then a hacker can run 'PV a variable, and BIS_fnc_MP it'.... Which is exactly how that virus came into being.
-
Great if it works but then I have to wonder what has actually been achieved by removing SetVehicleInit?You're pretty correct. So we all need to figure it out so that things can be made secure, vs reverting to old news. There's no real VIABLE way to communicate these solutions to BIS, as the feature tracker is a popularity contest, and the forums are a mess of old news and dribble. So, yeah, we need to figure that one out first.
-
I know how public variables work, I'm just not keen on having to edit every mission I might wish to host.Why the shit would you have to edit the mission? I honestly have no clue why you're saying these things.
Do you think you need a PVEH? No, you don't.....
As before, you simply PV the function, then call it using BIS_fnc_MP, and it'll run that function on all clients.
Otherwise, tell me. What do you need to add into your missions that's so damned impossible with the above explanation? If you can call 'setvehicleinit', then surely you can call other things too?
-
Sure, but like I first said, it would be even better to cut these kiddies off at the knees by preventing clients from injecting their own scripts rather than just trying to limit the damage they can do.Sure, but isn't that exactly what you're doing with your addons? Sending code via setvehicleinit is just the same ?
Unless you're going to expect server admins to depbo their allowed addons, read through it and add each of it's setvehicleinit calls etc to the filters?
Just installing mods is hard enough for most server admins. Expecting them to work out the filtering system from A2OA with BE? It only really worked for places that ran just one singular mission. DayZ, or Wasteland, or whatever.
It's pretty useless if you have a mission cycle.
-
Losing SetVehicleInit just kills a lot of possible functionality that could really help the multiplayer landscape so used, to refer back to my previous example, like an *optional* addon that allowed those players that have it the ability to jump small obstacles, but again, without breaking the game for those that don't have the same addon installed.You can do all the things you did with setvehicleinit, with BIS_fnc_MP...... You really need to give an example to push this to us. If you're saying "People can't join this server, because one of our mods needs to do netcode stuff, and some people wont have it, because I cannot push it to non-modded players", then you're incorrect.
function = compile {code};
publicvariable 'function';
^ Bam, code sent to all clients. Very much the same way as setvehicleinit did. All you have to do now, is call that passed function via BIS_fnc_MP, which can also call that code on JIP for new players, etc.
Am I missing something?
-
At this point i'm not making my scripts depending on BIS_fnc_MP, wouldn't be surprised if it changed or even got removed!This is very correct. So! In regards to addons, I suppose you'll just have to sit still and wait for beta or release, or something. Unless they say 100% that they're not changing it.
Edit: And something you could do to push this to either being 100% fixed, or whatever, is to pound the crap out of BIS's function library backbone and find bugs. Because ALPHA.
-
Can I just ask, when I make a function to be used by BIS_fnc_MP where am I supposed to put it? Currently it's inside the isServer if statement of my script and the function is to add an action for all players. It is set up to execute the code on all clients but it is still only showing the action for the server. Is this because I need to move the function it is calling outside of the isServer?The function needs to be defined on both client and server, if it's to be ran by the two. So, you need to assign it to a variable that will be set on both client and server. Yes.
-
What addon? BIS_fnc_MP is ArmA 3 library means if you have ArmA 3 you have BIS_fnc_MP. init.sqf is downloaded automatically when you connect to a server. What addons are you talking about?I give up. This has totally train wrecked for no reason whatsoever.
Defunkt is on about an addon he's written (Or whatever) which uses setvehicleInit. Now, re-read everything he's said thus far, and it'll make a lot more sense. Though, it's still not impossible to fix, and my solution is still valid.
-
Ah, I get it guys. It took a while, but he's on about addons, vs missions. Didn't notice it because he was very non-specific for some reason.
With regards to addons, we've already covered that solution.... You publicvariable the function, then call it via BIS_fnc_MP..... JUST how it works with setvehicleinit, essentially.
addaction in multiplayer
in ARMA 3 - MISSION EDITING & SCRIPTING
Posted
He doesn't need fnc_mp, he's not running it as an event, it's just a thing everyone has, so the init.sqf is fine.