pedeathtrian

KK, can you please also clarify remoteExec in part on manual removal of JIP statement: wiki page says I use remoteExec ["", car]; or remoteExec ["", netId car]; whereas I see these commands miss targets parameter. What value should it have? Same as at establishing JIP statement? Or maybe it is a correct syntax when functionName is set to empty string? Thanks.

[unit, "faceName"] remoteExec ["setFace", 0, unit] or [unit, "faceName"] remoteExec ["setFace", 0, netId unit] This way command will be executed for every client and every foregoing JIP while unit exists.

Tested on Escape from Altis vanilla 1.8.0 (bleeding-edge/26-07-2016/); A3 stable branch from steam (windows version). 1. Actions for hack UAV terminal and UAV backpack are duplicated though I only have one UAV terminal and obviously only one UAV backpack, see screenshot All actions work though. 2. UAV terminals and GPS (could be found in weapon boxes near wrecks) allow to use map and see where enemy positions located (if markers enabled). At the same time "Find map" task is still not completed (see screenshots) Probably "Find map" task should be rendered completed upon finding UAV terminals and/or GPS also. Anyway, "Find map" seems to be purely optional task since I managed to complete the mission without this particular task completed. When enemy markers are disabled or set to "Show upon discovery", this task makes no sense at all. Call it "Find map (optional)" maybe?

Sorry for dumb question, but... Are you by any chance trying to change parameters of already running mission? Does the same happen when you run #missions, reselect mission, then, while it is not started trying to change parameters?

Unless you can have quick and flawless victory and make everyone think you did the right thing. This way you can have any type of war started.

Get surface normal at some point, project it on XY plane (i.e. drop its z coordinate, and (optionally) normalize vector), convert projection into compass direction: you end up with direction of maximum slope gradient at that point. Beware of normal vectors very close to Z axis, they're the source of roundoff and other calculation errors. No direction loop required.

Larrow, thank you very very much, sir!

Check BIS_fnc_terrainGradAngle and surfaceNormal.

If you host the game (isServer) you can apply changes to objects directly. Otherwise, you use remoteExec with targets==2 to have this code executed on server. Of course, you can have remoteExec branch only, this will work on host too, costing you some time to execute extra call. This code does not do nothing to nils. Notice exclamation mark that inverts isNil. This code only operates on all non-nil elements.

Then check the amount of damage too (is exactly 0 in godmode): unit addEventHandler ["HandleDamage", { params ["_unit", "", "_damage", "", "", "_hitPartIndex"]; private _uid = getPlayerUID _unit; //systemChat format ["%1 Damage taken: %2, his UID: %3", _hitPartIndex, _damage, _uid]; if (_damage == 0 && _hitPartIndex == -1) then { // report cheater (don't use systemChat only: it reports on cheater's machine; e.g. use with remoteExec) } }]; Also, check that -1 case for _damage value, should not be 0 when not in godmode. UPD. And don't forget this event handler hits locally, e.g. on _unit's machine. Consider not having it from the beginning of mission but spontaneously setting it remotely by server to perform check only, then remove (just in case cheater can use removeAllEventHandlers). UPD2. Another plus of having EH spontaneously added is in the case when cheater has his own "HandleDamage" event handler which reduces the amount of damage inflicted. Your handler becomes last, and if I understand EH system correctly, you will see the value changed by cheater's handler (if he is smart he will not set it to 0, but reduce it significantly, so it still loks like he gets damage; but you can detect those cases too in your last EH).

To make it JIP-compatible run the randomization once (and serversidedly, e.g. in initServer.sqf) and stash the result in a variable.

"HandleDamage" event handler is hit with value 0 for damage if allowDamage is set to false. UPD. And hitPartIndex is set to -1.

Don't get me wrong. I'm for disarming, arms proliferation control and making serious treaties. We had a treaty on anti-missile systems, then US decide they need no rules anymore and leave. There was a resolution in UN General Assembly to support that treaty. US, Israel, Micronesia and Paraguay voted against and 80 countries supported it. US leaves. Somehow it did not affect their reputation (somehow it never happens at all). Then they start to arm Russia's neighbours. Can't we have defensive/whatever we want systems on, our own after all, territory? This is the only option when other side does not want to negotiate and wants to arm instead. That's how it looks from here.

Ah, that's probably because of some nils sneak into array. You had this isNil check from the beginning. Try if (isServer) then { { if (!isNil "_x") then { _x hideObjectGlobal false; _x enableSimulationGlobal true; } } forEach (RaidArea079124 + RaidSite079124ObjectList) } else { [ [], { { if (!isNil "_x") then { _x hideObjectGlobal false; _x enableSimulationGlobal true; } } forEach (RaidArea079124 + RaidSite079124ObjectList) } ] remoteExec ["call", 2, true]; } Right. Also try to minimize passing values through network. It looks like all you should really pass is identifier of raid area (or unit HVT1, which I guess is tied to that area). Then server uses all that heavy nearestObjects commands and enables and unhides what it finds there. After all I don't completely understand what is trigger for. nearestObjects could find all objects anyway.

When you're a server, when you hit that action and this line executes [{_x hideObjectGlobal false, _x enableSimulationGlobal true;} forEach (RaidArea079124 + RaidSite079124ObjectList)] remoteExec ["call", 0, true]; here's what happens: 1. The contents of remoteExec's left argument array are not of type 'Code'; therefore evaluated locally, that is forEach command runs, unhides objects and enables simulation for them since you're a server; forEach returns nil (result of last executed command). 2. command [nil] remoteExec ["call", 0, true] is executed, which is nonsense because it stands for call [nil] an all clients. But anyway, all job is done in 1, so everything looks fine (kinda works when you're a host, though some crazy luck it is). When you're not server, you fail to change objects' states since you're not the server, and hideObjectGlobal and enableSimulationGlobal are to be run by server only. You also fail the step 2 because of incorrect syntax. Correct syntax for call is arguments call body Therefore correct syntax for remoteExec would be [arguments, body] remoteExec ["call", targets, JIP], body is of type 'Code', so extra curly braces added: [[], {{_x hideObjectGlobal false, _x enableSimulationGlobal true;} forEach (RaidArea079124 + RaidSite079124ObjectList)}] remoteExec ["call", 2, true]; Since required commands are to be run by server only, targets parameter for remoteExec is set to 2, not 0. BTW, is it really necessary to have JIP=true? In general, having "call" to be allowed for remote execution with arbitrary code as argument is bad design, consider reworking this part. For example, have a script for this and pass only list of objects to process.

Tinkering. Tinkering everywhere :) Unfortunately there's absolutely no explanation of what Type field is and what values it can take. Something like side has. Intead all these magic constants we have. If there were a list of possible values I would have used it in the first place since I visited this page before posting in this thread, and the best I found (apparently didn't search too good) was displayName coupled with filtering by isKindOf. But thanks anyway.

I was talking about propaganda. And I was not suggesting limiting any freedoms. "do something with this" was addressed more to their block rather than to introduce yours. Exactly. "Deal with extremistic propaganda" is not necessary limiting something 'bad'. Instead it is producing more 'good' to oppose. Sorry for being unclear. What is their level? They have no material body (no, their 50k-250k troops do not count). You can't win with planes and rifles either. There's absolutely nothing ISIS fighter would envy you for. He is simply not aware of.

asd That makes it harder to defend these areas and in no way makes it easier to attak other countries. Russia does not have those 'systems' at US borders. You missing the time factor again. Even if converted (S350 could not be), it has thousands of kilometers more in distance to reach US. Both sides should be quiet and negotiate and not leave treaties for strained reasons.

No, sorry. How many deaths do you have caused by 'regular' criminal activity? Car (and all other technogen) accidents? Why u no frightened? They frighten people because you allow them to. Damn, you even help them to. Why no request for silence in social media like in Bruxelles? Of course it can't work every time, but hey, you are the guys with brains here, not them, right? Evolve. Now is the point where you create something to win.

We live in information world and our societies are fully open and vulnerable to threats coming from info space. And those inferiors know that well. Your armies are for wars passed long ago. No matter how much troops they have if you don't fight them where they fight you, in information space. Unfortunately information freedom unties their hands and ties your. Do something with this and not with their troops.

Whoa, that's much better. Where can I find values for this 'type' property?

The good and the best defence systems have fallen in the past. Does that say something to you? Reaching, exactly. What's the problem with this? It is very tightly tied with time. Look at Europe's map: rockets based in latest NATO countries (like Estonia) could reach russian military facilities in 6 minutes. Six minutes, Carl! Long before all those trains and submarines are ready to fire. This is reaching. When you've gone full retard and want this world burn to ashes, place multi-purpose anti-missile systems here. For today, probably... Brainwashing is making people think that the ability to place rockets (incl. silo-based) in Europe would not be used when such necessity appears. Nuclear powers balance is not what you discuss in terms of military tactics. Every small step can pay off in the future, and not making this step can cost you everything. Not being able to eliminate enough of enemy's facilities today does not mean you will not be able tomorrow. And you prepare today. This is called strategy btw.

Instead of getting parents for every you can use isKindOf (it's more effective than BIS_fnc_returnParents): if (_className isKindOf ["Pistol", configFile >> "CfgWeapons"]) then { // ... } or getting all pistol configs at once: _pistolConfigs = "((configName (_x)) isKindof ['Pistol', configFile >> 'cfgWeapons']) && (getText (_x >> 'displayName') != '')" configClasses (configFile >> "cfgWeapons"); Another approach is to check "cursor" property of weapon class, which could be "hgun", "arifle", "srifle", "mg", "missile", "rocket", "", "EmptyCursor" (and probably others). This way you can tell rifles from machineguns for example or sniper rifle from assault one.

The point is all that anti-missile systems are easily converted into offensive systems reaching most russian military facilities (including nuclear). Not saying these rockets can carry nuclear warheads.

All new mods (CfgPatches classes of used addons) must be listed in addOns[] array (in class Mission) in mission.sqm (and removed mods should not).