Bon

It's not working with AI dude. It's intended to be used in missions with AI disabled. Sorry.

I have to say that moving "#include" statements before script calls or spawn blocks is never a good idea. Before it comes to the GL4 things, nothing can go wrong in your init.sqf file. The "if(isNil "task1done") then{..." is just a variable declaration, as well as bon_settings... and ace_sys_tracking_markers_enabled. Then comes a "spawn" block that also gives back a script handler immediately. So NOTHING can go wrong before the GL4 section and it will always come to it. Now, on the other side, if you put the GL4 initialization to the top, and something goes wrong within that, you can forget about all the other stuff, too, since the GL4 initializations are done with including code instead of calling an external script. So most definitely, keep it like this.

Maybe this thread could be of interest for you: http://forums.bistudio.com/showthread.php?t=96202

No. It is just a thing of locality. An action assigned from within a script that runs locally on certain machines can't be shown on other machines, as it doesn't exist for 'em.

You want the action assigned locally on the player, not globally. Then the editor, or more specifically, a trigger, is a very bad idea to do so. Name the player, let's say, P1. Then write into a script, e.g. the Init.sqf file: if(player == P1) then{ _increasetargets = player addAction ["Increase targets.","targetsettings.sqf", "",1, false, false, "", ""]; }; EDIT: That's it for your intial concern / what your initial post was about. For restricting the action to be in a certain area, the very last post of shk should finally give you all information you need: Name the trigger that describes the area, and edit the addAction statement to the following: if(player == P1) then{ _increasetargets = player addAction ["Increase targets.","targetsettings.sqf", "",1, false, false, "", "player in list <triggername>"]; };

Ye, I initialized the variables in my Init.sqf but of course checked first if they are nil or already transmitted. And I tested it sooo many times, and every time it looked to me the variable didn't get transmitted when I jip. So I put an extra "publicVariable" for each needed variable into the onplayerconnected statement, and bam, screwed all my code because the related publicvariableEventhandlers got executed on each machine when someone connected. So I had to make the pbEventhandler check whether it was a regular broadcast or related to jip, and that's what I was talking about. Then I went another direction by storing variables in a variable space, and let the joining players get all the information to get up-to-date by themselves, checking the variable in the variable space. So far, my experiences using this way are much better than with publicvariables and publicvariableEventhandlers.

From my own experience, I recommend to avoid using publicvariable whenever possible. First of all, I had it sooooo many times, that a publicvariable won't get synced to JIP machines. Secondly, a variable being broadcasted will be broadcasted to every machine, not only on the joining one. Then using an addpublicvariableeventhandler can screw your whole work. Third, its just unnecessary network traffic. Keep it clean and local unless this is not possible. Trust me. It is always better to: set a variable of a persistent object (e.g. a game logic) and then let the client get the variable itself instead of triggering code by a addpublicvariableeventhandler.

I don't think that this setVariable will work. AFAIK "group" is not an object you can set variables to. For checking whether a unit is of a certain group, you could proceed as Egosa described it, i.e. putting Alpha = group this; into the leaders init line, so that the groupname will be stored into the Variable Alpha, the check then would be simply group <unit> == Alpha; (that's what Egosa tried to point to I think)

Ask yourself if the condition in the trigger will be true for someone who joins in progress. Lets assume, there is an object which activates the trigger once it is destroyed (typical example, condition somewhat like "!alive tank"). Of course it will be destroyed for a jip as well, so on a jip machine this trigger gets activated right away. Machines on which this one trigger got activated before, and considering the trigger NOT set to "repeatedly", this trigger will not fire again on your machine when another machine joins. The very best way of learning this / getting familiar with it, is just to try it out. It is no problem to setup a dedicated server on your own local machine, start ArmA as usual and connect to the dedicated server. Cutting your internet connection allows you to start ArmA twice or more times, and connect multiply on the server. This way you can test for MP behavior, JIP aso.

The weapon on back is stored in the variable "ACE_weapononback". So you can put a weapon on back with the command player setVariable ["ACE_weapononback",<weapon>,false], and obtain it by _weapononback = player getVariable "ACE_weapononback".

hmm, stay with "respawn_whatever", create two other markers like "Squad1" and "Squad2". Furthermore create a trigger around the "respawn_whatever", activation on the resistance thing, present, and condition: call {if(count thislist > 0) then {{if(group _x == squad1) then{_x setPos getMarkerPos "Squad1"} else{_x setPos getMarkerPos "Squad2"}} forEach thislist};false} Note the two variables squad1 and squad2, which must be bound to both the groups of the squads. Just give it a try.

Hehe, that looks like an interesting issue, since there can't be a line 0 in a textfile. Also 'c' after Arik (whatever that means) doesn't seem to be related to anything of the arti script. May you provide me with your code, I'll then check it myself.

Deadfast, don't wonder, that's the way the ACE wiki tells him how to do ;)

Yep, set up a dedicated server on your own machine, detailed information here. Make sure that this kickDuplicated thing (don't know the exact name) is set to false. Also set persistent to 1, so that a mission doesn't stop when there's no player on it (also requires to have AI disabled and respawn enabled I think). Cut yout internet connection so that your ArmA2 can't connect to GameSpy. Then you are able to connect with more than one instance on your server, and enables you to test everything, including JIP.

Hi fellas, @CombatComm: Really , forgot about your post. Fact is, I have nothing to do with Domination, doesn't play it (that often), neither will I ever modify it. You have to ask the Domi Heroes in the Domination thread for this script to be integrated. Same story with Evolution. @tyrspawn: imo this script is far far away of perfection, but , was really happy when I read your post. Just to make that clear first: The whole radio message stuff happens only on your own machine, no other player should be able to read it (would indeed be really annoying, and it would mean unnecessary network traffic). To have an option to turn all the chatter on and off might be a good point. But then somehow feedback of what you did would be missing. So best would be to cut only particular messages out, but that leads into too much variety for me to extract it to adjustable options. My suggestion just for you: The whole chatter stuff takes place in the bon_arti_request.sqf, just go through the script looking for each line that contains the word "sideChat", and comment it out if you want (by adding two slashes at the beginning of the line). A "round complete" message is missing, because it is a bit complicated to implement in the current script: All the shell-creating / shooting stuff is relocated to the server machine. You setup your fire mission, press Execute, then the radio messages take place in a script running on your own machine, the firing stuff takes place in a script running on the server machine. This architecture has its reasons. ;) Now for such "round complete" message I'd need to detect when the server finishes firing, then make only the arty system user show a message that it is finished. Too much effort and too much unnecessary network traffic for this purpose. There are lot of such small aspects that might be nice to have, but aren't worth the possible performance decrease it could cause. Hope you all agree with that. :cool: Hf.

Yeah, its very simple: Someone walks into the trigger area and activates it, in other words, set its status to "active". While active there is no chance to activate it again, it must be deactivated before, i.e., no unit of given side is within the trigger area. Now what I don't know actually, is, how long a dead unit remains in the triggerlist.

Hi mate, regarding to the first issue, indeed it won't work letting a remote machine, say, the server, manipulate a player local on another machine. Dunno if it is just because the to manipulate unit is remote, or if it is a feature of the engine that a remote machine can't affect the local entity. That's why it is working in the editor preview and with your unit when hosting locally, but not with your friend who's entity is remote to the server. However, you can make it that a local player gets moved into a vehicle from within a server script by using setVehicleInit. Code: _group = group (_this select 0); _vehicle = _this select 1; { _x setVehicleInit format["this moveInCargo %1",_vehicle]; } forEach units _group; processInitCommands;

condition: time % 60 == 0

Dunno if the ACE2 thread would be the more appropriate place for this question, however, you cannot disable Stamina and keep rucksacks enabled (as it is also mentioned in the ACE2 wiki). And that's good !!!

my "regeneration" of this code considers any kind of man. goliath, just replace "SoldierWB" with "Man". Thats all.

Hi mate, just to eliminate all evil pitfalls... You know that onPlayer(Dis)Connected is only executed on the servermachine, do you? Even if you initialize this command on a client, it only runs on the server. So you want the increased/decreased countvariable to be valid on all machines, you have to broadcast it.

There might be more elegant ways instead of using triggers, but dunno any ^^ I think the condition is correct, since "player" always addresses only the local instance, in other words, if a particular player leaves the trigger it should not be necessarily true on every other machine. What exactly did u written in the activation field? Try this: Trigger "Anybody present", condition "player in thislist" And on Deactivation, i.e., once the player leaves the trigger area and is not in the list anymore, write player setDamage 1 That should do the trick.

Your task is to search and destroy Ammo Caches the enemy stock in the village of Ursana, and to return to base afterwards. Maybe that's it, maybe there's more, find it out on your own. ;) Included features: modified AIS Loadout Presets enemy moving by UPSMON Artillery Request System and some more stuff.... Required Addons: Isla Duala Note: With a mission parameter you can choose between Vanilla equipment or ACE2 equipment. The latter one of course requires you to run ArmA2 with ACE2. Download from chernarus-force.net Download from Armaholic.com (Thanks, Big)

That is THE drawback of addons and custom/usermade modules: A connecting player has to have them downloaded before and ArmA2 started with them in order to play this mission. Any additional .pbo's are not transmitted over network when connecting, only the mission file and eventually face- and sound files from the other players currently playing. So in case you publish a mission which uses additional addons, you are to give a "required addons" list as well. IMAO you should always think in a way that, creating a mission supposed to be played by any public player, keep it tight, reduce addon dependencies to a minimum (ignoring island addons), otherwise expect only few players to download and play that mission.

Hi JW_Custom and all, usually I am never doing anything like self-advertising in a sense of pointing to scripts that I wrote myself, and neither is my intend to do now. But two of my scripts are more or less addressing perfectly some points that are mentioned here so far. Revive I scripted a somewhat simpler BIS AIS clone some time ago, that, apart from its incompatibility to AI (which affects only SP missions anyway) behaves exactly the same way as the BIS module does. It also comes with the possibility to set the "tolerance" against hits. This "tolerance value" you can extract to a mission parameter, so that you can set the difficulty of the mission in the following sense: The parameter would be the threshold of either fall in agony or die instantly when receiving damage. A Lower Tolerance means that you fall in agony as usual, but also can die easier, a very high tolerance would make it harder to die instantly - you can even increase this to a value you cannot die anyway, this would be almost equal to Revive (like Norrin, except that you can still bleed out). Loadout presets The advantage of this script is that the mission maker can predefine weapon setups instead of using ammo boxes. That would give you as mission maker full control of who carries what, to avoid SMAW-Sniper dudes, and makes it easier for you to balance sides out. I myself used the combination of these two features in a couple of coop missions that I made or edited, both with exactly the two suppositions as I mentioned above, and in all cases they did what they were supposed to. As I said, not that I want to self-advertise myself, hoping that this could help you a bit? Hf. EDIT: My overall thinking is just: if there are different minds about some functionality: Do it as a parameter.