xxanimusxx

There are three methods I can think of to achieve this: 1) Create a trigger everytime a vehicle is !alive and handle the despawn whenever someone enters the area around it 2) Create a while-loop which checks the distance to every player to each vehicle after !alive 3) Create a while-loop which does the same like 2), but from the perspective from the player. 2) is effective when there are many vehicles, but a small number of players. 3) is the opposite to 2). The question here is: Is the amount of vehicles you want to have monitored dynamically or a known set? Like if every vehicle on your map should get monitored, regardless if new ones are spawned or not. If thats the case, I'd tend to 2), because you could easily add the vehicles to a globally known array and wrap a loop around it. Now coming back to the title of your topic: You need help, what did you do to solve your problem? Where can we help you? What informations do you need? Is this going to be a MP mission? :)

This could be off topic but please try to bear with me: Having static objects like fortifications or "un-intelligent" ones without any attached actions won't count towards network traffic, because they have none, right? There was something meantioned in the BIKI article for enableSimulation as far as I can remember. According to this fact, isn't all this local spawning of objects to prevent network traffic irrelevant if there is none to be afraid of?

The latter one obviously :D You have to check if all players in the access list for a specific fortress are gone on every disconnect-event, if they are, re-enable the teleport script, else do nothing. Basically it is: onPlayerConnected: is the player in the access list and the teleport script is enabled? Disable it! onPlayerDisconnected: Are all players in the access list offline and the teleport script is disabled? Enable it! The real hurdle will be creating the access list for each fortress and keep track of every change made in the database as well as ingame.

Everything relating to persistance will make your overall code managment much more complex, there is no way out of it I'm afraid. Because there is persistance, you have to fetch all the data and prevent any inconsistencies which can occur if ingame events aren't handled the right way and written back into the database. As always my disclaimer follows: I don't have THE answer, just a suggestion how you could - or rather how I would - do it. Let's wait for some other answers and suggestions and if nothing useful turns up, just PM me and I'll fix you the code (expect for the persistance part...)

Well that's for you to decide :D As always there are several ways how to implement this, but you need at least these details: assign the fortresses an unique identifier, something like a name which begins with "fortress_" and a number as a suffix (this could be advantageous for your database, just create a table named "fortresses" or something and the primary key could be used to suffix the unique identifier ingame. You could easily link the UserID in the database with the fortress to create an affiliation). In the init.sqf, check if it's the server and fetch all fortresses plus the users affiliated with it from the database and save it in a multidimensional array or any other data structure you see fit. As may best put this into a function so you can call it everytime you need to update the affiliations. create a global array which holds the unique identifiers of the fortresses and will be used as a condition for your triggers (we'll name it "empty_fortresses" for this example). Place a trigger for each fortress into their center and set the condition like this: "fortress_ID" in empty_fortresses Replace fortress_ID with the specific unique identifier of that fortress. Now you could use onPlayerConnected and onPlayerDisconnected to check if all players affiliated with a specific fortress are disconnected and if they are, add the unique identifier of that fortress into "empty_fortresses". This would trigger the scripts you put into the activation field of the trigger you created after fetching the fortress list and execute whatever you had in mind. Just a suggestion though: Teleporting players for this purpose seems to be a bit improper, because teleporting is something you'd never have in a "real" enviroment. Something like placing barricades around the fortress or even a gate which can be locked is more appropriate :D

You could use onPlayerConnected and onPlayerDisconnected to execute scripts which will teleport away all people if the owner of the fortress is not online, easy as that :D

I think it will help alot if you could at least give us some informations about your mission, like the rough scenario and what interactions you want to have in there. Delivering some specific information will help others to query their knowledge and come to you for help if they have the knowledge required for your scenario.

Why shouldn't you be able to nil a variable? _myVariable = nil; if (isNil "_myVariable") then { // Works fine };

Well there are several ways to do it, the best looking would be creating a GUI with images and stuff but that's to hardcore for your demands. These commands can be used to deliver some nice looking effects: cutText titleText BIS_fnc_infoText Put the command into your init.sqf and make sure to sleep one or two seconds to make sure the commands won't fire too soon :D

Since when is the init.sqf executed for non human players? Did I miss something? I mean I'm a rather new ArmA2 guy and all but I had the firm conviction that the init.sqf is executed upon human players when connection into your map. All you do in your init.sqf using the "player" keyword will only affect human players, so you don't (and moreover can't) have to discern between human players and AI. Since I'm really confused here, can someone clarify this with more details? :D

One popular way to do this is to get the players withing the trigger and query if the current player the onAct-field is executed on is in that list. Your onAct-field would look like this: if (player in thisList) then {playSound "skin";};

There is also a nifty guide to code optimisation for Arma2 in the BIKI. And although I know that the following question is really dumb, but does your scripts also lag without the code you posted above? You don't seem to use any seriously exhaustive commands which could slow down your script for several seconds, so my guess (and the ones of everyone before me) would be that another script is slowing down your overall script execution.

The forEach-Loop causes that everyone except of your soldiers will count towards the kill counter, hence the query if _x is not in friendlyAIUnits. What you actually do is limiting the counter to soldier1, so if soldier1 dies, the one killing him will get his counter upped. If soldier1 is someone in your team, this would have the opposite effect of the one you wanted to have. I guess you want to adjust who actually can increase his kill counter, am I right? If that's the case, you have to change the if-clause in the eventhandler to make sure that the _killer is (for example) soldier1.

Put this anywhere BEFORE you add the displayEventHandler: player_do_active = false; Now you change your handler to this: if (_dikCode == 0x0D) then { player_do_active = !player_do_active; if (player_do_active) then { execVm "player_do.sqf"; }; }; and finally change your sqf's content to this: if (isNil "player_do_active") then { player_do_active = false; }; while {player_do_active} do { player playMove ""; sleep .1; }; Et voilà :D

Everything you place using the Editor will be written into your mission.sqm-file, which gets read and executed way before your init.sqf can kick in - if you want to randomly create one of the camps, you have to do it in your init.sqf (e.g. the server/dedi). One possible way could be this: gather all the objects' references for every camp in arrays. Name your objects according to your camps, like "tent3_camp1", or "fireplace1_camp2" or whatever you feel comfortable with. Now define a two dimensional array and insert the object's names: _campObjects = [ ["tent1_camp1", "tent2_camp1", "fireplace1_camp1"], // Camp1 objects ["tent1_camp2", "tent2_camp2"], // Camp2 objects ["tent3_camp3" ...... ] // Camp3 objects ]; Randomly select one of the camps_selectedCamp = floor(random 3); Cycle through all the other camps objects and delete them (in your init.sqf): if (isServer) then { _selectedCamp = floor(random 3); _campObjects = [ ["tent1_camp1", "tent2_camp1", "fireplace1_camp1"], // Camp1 objects ["tent1_camp2", "tent2_camp2"], // Camp2 objects ["tent3_camp3" ...... ] // Camp3 objects ]; for "_i" from 0 to 2 do { if (_i != _selectedCamp) then { _objectsInCamp = _campObjects select _i; { deleteVehicle _x; } forEach _objectsInCamp; }; }; }; Dont forget to actually fill in the array with the names of your objects, otherwise it won't work. There is another, an automated way to do this, but it is exhaustive for the server so this should work well if you can put up with naming all of your objects :D

When your dialog is created, the onLoad-field is being executed, which in return will call the function named "FRAME_01_Load". _this is an array in that context of the dialog which contains the reference to the dialog in the first element. So what the function does is: Get the control you want to modify (displayCtrl gets you the child-control of a control, in this case your dialog), and using ctrlSetText you can modify the text your control holds at any time. Everytime you create your dialog the text will be filled accordingly.

Well what I did was saving the references of the child controls of my "display" into an global array so I could use them without having to switch between namespaces - I was forced to use disableSerialization nevertheless. But I'd be interested how others do this :D

I really don't like to stuff complex code into the activation field of a trigger, but meh, here you have one possible solution: {if (_x isKindOf "Air") then {while {count (crew _x) > 0} do { ((crew _x) select 0) action ["eject", _x];};};} forEach thisList; The rest of the trigger's configuration is up to you :)

The best way is to find a superclass of the objects classes you want to delete (because it will help you avoiding loops) and switch them with "building" in the code I wrote above. Then you'd change "_x hideObject true" with "deleteVehicle _x" and voila, buildings be gone :D If you just want to delete specific buildings, you can of course use the direct classname (e.g. "Misc_TyreHeap").

I put exactly this code into the top of my init.sqf AND in a script which gets called when I pick an action I attached to my player. _myWhile = { _counter = 0; while {true} do { _counter = _counter + 1; hintsilent str _counter; }; }; call _myWhile; hint "Done!"; As prove that this is a legitimate call the last hint "Done" never gets shown or heared. In both scripts the counter is way over 1 million. So how did you execute your while that it just loops 10k times? It would be very interesting to know if there really IS an limitation to consider.

Hmm now I'm confused, I just called the code I posted above (wrapped in a "call { .... }") and it still counted way above 100k. So can I assume that there is no limitations i direct (call) and asynchronus (spawn/execVM) calls or did I just do something wrong? :S

Just a question here: If you want to completely hide the IED into the dead bodies, can't you just hide the IED itself? Like using hideObject and showing it when some conditions are met? Or do you want that the IED should show a little so the player can discern if the body is safe or not?

There is no limitation to how much loops a while can do, this was due to some bug it seems but it has been fixed ages ago :D I just put this lines of code into the init.sqf and it worked like a charm even for more than 10k: _counter = 0; while {true} do { _counter = _counter + 1; hintsilent str _counter; }; The other option would have been putting your while into a function and counting the loop interations and upon reaching 9999 you'd stop the while-loop and call the function again. But you don't have to worry bout that, no limitations are set.

You either place two trigger for Opfor and Blufor or use just one with "Anybody" and check which side the players are. Because the first attempt should be slightly easier to use, place two triggers on the same spot and set the activation BLUFOR and OPFOR, both repeatedly. In the activation field you've to add: {removeAllWeapons _x;} forEach thisList; There could be another solutions so if someone else has better ideas, just pop them :D

setTaskComplete is not a valid command :D You really should look into script error output while developing missions, preferably using the startup parameter -showScriptErrors I'd use a taskHint instead of hint, well, because it's... flashier? :D