loyalguard

How about using createSoundSource to play a sound? You would have to delete it to stop the sound but it is something you can spawn on the server and all nearby client units should be able to hear it. You can find a list of the sounds (maybe use Alarm) here: Six Config Browser Sound Vehicle Classes

There was another thread recently asking a similar question here: http://forums.bistudio.com/showthread.php?t=124901 I am not sure if any of the solutions proposed resolved it though.

There is no specific ammo count event handler. You could use a fired event handler to trigger a script or function that could check ammo levels via the ammo or someAmmo command or if you did not want it to be based on firing, you could run a loop that would check ammo levels at set intervals.

You would need to add an external script or insert it into a unit line line. Here are some related threads that explore how to do it more deeply: http://forums.bistudio.com/showthread.php?t=118272 http://forums.bistudio.com/showthread.php?t=110863 It specifies locations, colors, etc.

Pere the Biki article: Light can be created with command createVehicle with special vehicle class "#lightpoint" for example: _light = "#lightpoint" createVehicleLocal pos; _light setLightBrightness 1.0; _light setLightAmbient[0.0, 1.0, 0.0]; _light setLightColor[0.0, 1.0, 0.0]; _light lightAttachObject [_object, [0,0,0]]

First an answer to some of your side questions and then to the heart of the matter: -"triggers created by script, only exist on the server" if the script is run on the server. If it is run on a client it will exist there too. -Use thisList when referring to the trigger within its own condition, activation, and deactivation code. -Use list when referring to a trigger outside of itself. So, if you wanted to refer to units inside a trigger's detection area from an external script or a different trigger then you use list. Now, on to pitfalls and the crux of the matter. IMO, outside of a few circumstances, if you have a complex condition to evaluate, then it should NOT be done within a trigger's condition field. Now, I realize this is easier said than done...because it is easier said than done. To make what you are trying to do MP compatible is not a simple task outside of a trigger. A trigger is a powerful and neat little package but the more complex the condition code...the harder it is to control the power. I will have some example alternatives for you later...but I just wanted to put that out there.

Terrain level may just be speculation but I have had weird things like that happen before. If you are using the trigger condition code I think you are using, if the selection is lower than your desired height because of a difference in relative or absolute ground/terrain leves, it could explain why the trigger never fires. It may be a stretch but it popped in my head so I though I would mention it.

Regarding the triggers not activating...there could be some weirdness there with terrain level. What would be helpful is a controlled test, that is, one clutter/IED/Trigger combo run in SP and then on DS to see what works and what doesn't.

I agree with Twirly. Password is easy. You just use ctrlText to get the text from an input field in the dialog and compare it with a variable. When you are ready there is some example code I am happy to share from my AEG project.

Ok. So. Without !isServer it should exec everywhere and create the trigs everywhere. When you say some dont work, what do you mean? The detection? The satchel disruption? Explosions?

So if you use !isServer to exit then the trigger will never be created on clients. If you have no condition, then the triggers will be created where the script execs. How is the script exec'd? Init line, init.sqf?

You are probably on to locality as the issue. Triggers placed in the editor are local everywhere. Triggers created via createTrigger are local only to where they are created. If you want the trigger to be able to detect all units it has to be created on the server and all clients.

Check out this thread for some disccussion and possible solutions: Collecting inventory items?

Glad you tracked them down..btw, the reason why you may not have had lines numbers for some of the errors is that if you use call compile (I think you said you did) I don't think you get line numbers if there are errors in it.

Nice Job...see this thread on the BIS Module Improvement Project

I cant say for sure but I bet the problem is strings with strings. SetTriggerStatements takes three strings as arguments. So, if you use strings inside strings you need to use double double quotes or single quotes like ""neck"" or 'neck'. You have strings inside strings for condition and on activation.

Ok, Below are some links to get you familiar with some scripting basics. They for ArmA but the same principles should apply for TOH. http://community.bistudio.com/wiki/Category:Scripting_Topics http://community.bistudio.com/wiki/ArmA:_Scripting_-_Getting_Started http://community.bistudio.com/wiki/ArmA:_Introduction_to_Scripting Before writing any code, map out your mission concept OR more specifically: 1. When/how do you want your traffic accidents to happen: On mission start, after a certain period of time, more than one possible at same time, only if player asks for one to "respond to". 2. What will prompt the player to respond. Chat messages, hints, Radio message, etc? 3. What do you want to happen when the player responds? You will probably need a single script file just to create your accidents. You will probably need another script to resolve each of your accidents as well (board chopper or whatever you want to happen). A script file is just a text document with .sqf at the end You have a great community here to help you work on your mission

Here are a couple of threads from the A2 editing forum that may help you find road surfaces to place your objects: http://forums.bistudio.com/showthread.php?t=113719 http://forums.bistudio.com/showthread.php?t=98075 If you wanted a simpler approach, you could always choose several dozen of your own locations, put down markers, and then use the markers parameter of createUnit Array to choose one of the marker locations at random and place a game logic there. Then use the position of the logic to place the rest of your objects. It's a great mission concept...you should pursue it. Don't leave it to the experts...become one!!!

There may be a conflict in the trigger parameters that I cannot see. Try placing a new trigger, said it to repeating, enter the condition code that I gave you , and put in your on activation code. If that still does not work, it may be easier to do this in the script like twirlys

No need for a detection type or radius. Try taking out.

If you mean how often the trigger checks the condition, it will do so most likely every frame.

Untested but try this as your condition line: ({(side _x) == east} count allUnits) <= 50 Make sure the side of your OPFOR is east or adjust accordingly.

You can use createUnit or CreateUnitArray to spawn an AI unit. Ensure that the player has a group and that you put group player in the parameters or you can place a unit in the editor then use join to add the AI to the player's group.

Solution in this thread (posts 1 & 2). Just substitute color of your choice: http://forums.bistudio.com/showthread.php?t=113691

Here is another good thread on the topic: http://forums.bistudio.com/showthread.php?t=98937