engima

New version. Version 0.70 Added search and replace functionality. (Big thanks to Josef!)

Engima's Parked Vehicles v1.0 Overview Engima's Parked Vehicles is a script that adds empty vehicles in garages and next to buildings across the map in an Arma 3 mission. Description To "complete" my Engima's Traffic script I have also created a general script to place empty vehicles near or in Buildings across a map. Vehicles are created when a player gets within spawn distance, and they are removed again (and remembered), when all players get beyond spawn radius. You can customize types of buildings and types of vehicles, spawn radius, and use callbacks for when vehicles spawn and despawn. For a vehicle to spawn in or outside a building there has to be a garage definition entry for that building in the file Engima\ParkedVehicles\GarageDefinitions.sqf. Garages and other buildings for islands Stratis, Altis, Malden and Tanoa are supported out of the box. Anyone can add more garage definitions when needed. Download Using the TypeSqf Editor (recommended for Windows users) From Github Installation TypeSqf: Open the CPack Console and type "install Engima.ParkedVehicles". Manual: Copy the folder Engima and the file initserver.sqf to the root of your mission. (If you already have the initserver.sqf file in your mission, copy the content from my file into yours). Usage Configure/Customize the script by altering the parameter list for the main function call. File "Engima\ParkedVehicles\ConfigAndStart": // Set custom parameters here private _parameters = [ ["BUILDING_TYPES", ["Land_FuelStation_02_workshop_F","Land_GarageShelter_01_F", "Land_FuelStation_01_shop_F", ...]], ["VEHICLE_CLASSES", ["C_Offroad_01_F", "C_Offroad_01_repair_F", "C_Quadbike_01_F]], ["SPAWN_RADIUS", 750], ["PROBABILITY_OF_PRESENCE", 1], ["ON_VEHICLE_CREATED", {}], ["ON_VEHICLE_REMOVING", {}], ["DEBUG", false] ]; // Run script _parameters call PARKEDVEHICLES_PlaceVehiclesOnMap; Script can also be extended to contain support for more garages/buildings. This may be important if you want to use the script on maps for which the default package was not intended. In that case you want to add building definitions to the file "Engima\ParkedVehicles\GarageDefinitions". Vehicles for building classes that do not exist as a building definition will not be spawned. Licence MIT. Version History Version 1.0 -First version. Other releases Engima's Traffic (script) Engima's Civilians (script) Escape Tanoa (mission)

The GarageDefinitions.sqf file contains a list of garage definition items (arrays with values). You should not add the function, you should use the function to create new garage definitions, and then add them to the list. 1. Create a temp mission. Decide a building that you want to use and put a vehicle near it. 2. Start the script in init (or in a trigger), send in the building and the vehicle as parameters, and park the vehicle as you want it. 3. Quit temp mission and open the RTF log file. Last garage definition entry is the last position of your vehicle. Add that definition to GarageDefinitions.sqf.

Thanks for notifying me about the script error! Here, use the script below - (I'll also include it in future versions of the package). Example of usage: Put in a vehicle near a building and name it myVehicle. Create a radio trigger and put the following line in it: [nearestBuilding myVehivle, myVehicle] spawn PARKEDVEHICLES_MonitorGarageDefinition; Script will output the garage definition (as a hint and in RTF), and you can drive around with the vehicle until your satisfied with the positioning. The last parked vehicle entry in the RTF will be the garage definition you need. Script:

Is it a building that has building positions? Otherwise the building pos attribute must be sent in as -1. Or there is something wrong with your definition item in GarageDefinitions.sqf. Check the file and make sure you follow the pattern. Post the line here if you still do not find the problem. A garage definition defines how the vehicle will be placed in relation to a building. It is an array with building type, building pos reference and position and direction of vehicle in relation to the building. (Only the building type will not be enough, you must investigate each one.)

First, this is not really how you should think of or use event handlers. You use an event handler to react on an event, and not enabling or disabling them as you find suitable at the moment. If you have more than one event handler of a type and they interfere with each other - that is affecting the same resources - you do better merging them into one. Then you have full control over all conditions. Second, is HandleDamage your example? It’s not just any example, since it is one that returns a value that sets the unit’s health, and therefore it is more to regard as a special case i believe. Third, why would you want to turn on and off Ace during a mission?

No. The idea behind this script is to define a parking spot in relation to a building. But if anyone can tell me how to recognize car parks and their bays then I might support them in a new version.

Forgot it. Now added under Installation. Thanks!

New version. Version 0.69 -Added support for all script commands up until Arma 3 version 1.96 (into ScriptCommands.xml). -Updated dependency to .NET to 4.6.2.

New version. Version 2.1 -Mission parameters are now saved in profile, and reused by default. -Removed error message about missing image Escape.jpg. -Lowered the number of armed and heavy armored vehicles in general traffic. -Added more possible locations for comcenters. -Fixed: Removed some vehicles that required the Laws of war DLC. -Fixed: Too few enemy ambient infantry in the woods. -Fixed: Script error when hijacking comcenter.

I didn’t know that. So in general, if you have a group with waypoints and deletes them all the way down to index 0, what will happen? I expect nothing, but apperently something can get wrong. Will the Arma engine get confused? Obviously in this case...?

Since Escape Chernarus for Arma 2 there is "some" support for porting it to different islands. However I'm working on exactly that, and I already have a playable but not ready for release version of Escape Altis that I have played for test with friends. I'm planning on releasing that later, and at the sime time make the mission as easy as possible to port. If you want to port this very mission I then recommend to wait for Escape Altis.

Ok, sorry. Try removing him in ON_UNIT_REMOVING then, which is executed right before the vehicle is removed.

No. It should be no problem. The new driver will be handled like the old one.

Yes, possible vehicles is an array that goes into the start parameter set as VEHICLES. And the default driver can be replaced using the ON_UNIT_CREATED callback (called after unit has been created). And if you want some more control over spawned vehicle classes other than pure random, or number of vehicles during certain times of the day etc, use callback ON_UNIT_SPAWNING (called right before a unit is created).

If you expect repeat then there's a problem. It's not unsolvable, but maybe not the solution I'd chosen. If your condition is (!alive radar or !alive tower or !alive radio_operator), and radar, tower and radio_operator are variables for objects in the editor, then the condition will evaluate to true if one of them dies, thus the activation code (that sends reinforcement) is executed. However, the contition will need to be false again for the trigger to fire repeatedly, and that will not happen until all objects are intact again. No. The code in the deactivation box is simply executed when the condition goes from being evaluated to true to be evaluated to false (like the opposite of activation). I don't know. I seldom use triggers. They are good since they are executing in unsceduled environment, which is much faster. On the other hand the code is not being kept together and command sleep won't work. From Arma 1.97 you can use command setTriggerInterval to slow down the condition check when you do not need to check all the time. And 100 scripts that mostly sleep is not a problem either. But of course, you should keep performance in the back of the head all the time. For exampel command waitUntil can be set to not check too often if you write waitUntil { sleep 10; my_condition };.

Of course there is an OR command. But you seem to have misunderstood triggers. A trigger is checking the condition over and over (every half second by default). When the condition evaluates to true the activation will execute. If trigger is set to repeat, than the condition will need to evaluate to false sometimes after first activation to be able to activate again, which will not happen in the approach you are suggesting. (When trigger condition goes from true to false is when the deactivation code is executed.)

@JD Wang I needed what you asked for myself. Check out my new Engima's Parked Vehicles script: http://typesqf.no-ip.org/cpack/details/Engima.ParkedVehicles

_grp01 = grpNull;

I looked into it a little, and the script actually do remember state of despawned area. Wrote it a long time ago, so I forgot. That said, the triggers should be removed when a town is empty, but that is not the case now. Plan now will be to update script at some time after setTriggerInterval comes to Arma.

Thanks. Glad you like it. 1. setTriggerInterval sounds nice. That should be an easy fix. But I give no promises for when you got it. 2. Script does not ”remember” if units are killed or not, and therefore I do not delete the trigger. If you leave and come back there will be new units patrolling. I understand that people may want both, and actually I’m in need of that feature myself, so I might add that parameter too. 3. Yes, that is possible. You do it by configuring and starting two instances of the script, each with its own parameter set. Look for ”instance” in the documentation. 4. Again, see 2 above. Probability of presence is checked each time you enter inside the marker.

Sure: https://github.com/XEngima/Arma3-Scripts-PatrolledAreas Full documentation is included in Engima\PatrolledAreas\Documentation.txt. For Windows users interested in keeping up to date with future updates of these scripts the TypeSqf editor is recomended.

Maybe this script can be helpful: Engima’s Patrolled Areas

Ok. Sounds probable. Let’s hope it is an easy fix.

I did a little more testing. First with a simple init.sqf file like this: init.sqf: waitUntil { !isNull player }; hint "First"; sleep 10; hint "Second"; sleep 3; hint "Third"; sleep 3; hint "Fourth"; The first sleep (sleep 10) was simply ignored (for the JIP). The rest of the sleep commands worked as expected. I did the same thing, but put the hints and sleeps in another file, and started it with execVM. But the result was the same. First sleep was ignored. I did the first thing, but put the code in initPlayerLocal.sqf instead (which would be a bit of a better practice). The same result. Then I put an action on a coffee table in game and started the hint-sleep sequence on an action (putting an addAction in the init.sqf). This worked as expected for both hosted server's player and JIP. Then I tried to replace the sleep with a waitUntil like this: init.sqf: waitUntil { !isNull player }; private _jipEnteredTime = serverTime; hint "First"; waitUntil { serverTime > _jipEnteredTime + 10 }; hint "Second"; sleep 3; hint "Third"; sleep 3; hint "Fourth"; This worked as expected, so for some reason only the first sleep command was a problem. Conclusion: First sleep command for a JIP seems to be ignored if hit during the initialization phase. My guess would be that there is something scheculish thing that has not yet been initialized properly, so to be able to trust the sleep command one should not use it until a few seconds into the mission. Use of sleep in init files should really work, but actually I have never regarded it as best practice. A suggestion to a solution or workaround (if not Boehmia fixes this) would be to only use init files for initializations, and not running code. Init could contain a waitUntil a few seconds so that everything stabilizes and initializes, and the the running code can be started (like execVM "start.sqf").