zodd

Cent - Apologies, I looked at it quickly without considering it (or testing it) - My bad, it actually works perfectly! So good... thanks so much! Checking finished moving with repeatable radio trigger hint. Kord - Thanks for your input - Not needed at the moment for this case but I think it would definitely be beneficial for other aspects that I am planning. Thanks again all - much appreciated!

No joy with the group this because the script is being called from a different unit (Commander unit assigning waypoints to subordinate units)

The issue with a global variable is I don't know which unit it will be for; it is a commander script that assigns waypoints dynamically. I need a way of tracking when a unit is moving and when it has completed the waypoint. I tried the call compile but couldn't get it to work.... no joy with the example above or any of my tinkering. Will try a bit more when I get a chance but open to other ideas too! Thanks again!

You are completely missing the point... What i find amusing/bewildering is that zooloo75 has said repeatedly in many of his threads, that it only takes him a few minutes to make a mod... Almost flaunting his skills.... then one day he says that he has no time to update or work on his mods... As I said at the start of my reply; there is a big difference in making a functional prototype and polishing/developing something to do exactly what you want. See here: http://forum.unity3d.com/forums/34-Works-In-Progress Have a look how many posts on there are prototypes v. finished products. What I am getting at is it comes cross like you are having a go at him because he made this quickly but he isnt able to continue it (or promise to). Ongoing support/maintenance of anything software related is a MASSIVE task; dont underestimate it. Hopefully one day he will remind himself that it only takes a few minutes for him to whip out a new mod/script... and with that mindset im sure hell see that he actually has plenty of time!!! 1. As above, it doesnt only 'take a few minutes'. I made a silent takedown script in a few minutes... it would take a LOT longer to make it polished and to continue supporting it. 2. He is studying... Real life comes first. If you are supportive then be supportive, but I would avoid coming across like a self entitled spoiled brat (eg. your most recent post) Maybe use this as motivation to learn yourself.... Back on topic - good luck with studies Zooloo; might have a look inside to see how you made it work!

A lot of the time a basic prototype is a lot easier/quicker to make than a polished product... So while he may be good enough to turn out something like this relatively easily, the polishing and finishing is likely to be a lot harder and more time consuming... Especially when real life commitments come in! He does some amazing stuff but if this one doesn't get developed further... you can use as is, use another mod or pick this one apart and try and develop it further yourself!

Edit - wrong ship post... Awesome work on this one - looking forward to playing around with it!

For the issue with MAN class walking and the limited size LOD; I understand you cant have multiple ones per object but would it be possible (as a hacky solution with an init script) to have several separate smaller (walkable) objects and add them to the ship using attatchTo?

Looking beautiful mate; keeping an eye on this one!

Gday all, I am in the process of working through an AI command mod and wondering if anyone has any cunning ideas on how you could go about generating a MCOO style analysis of a map for the AI to use? (ie. get the data so what I am working on can analyse it) Something like: In addition, I am trying to work out the best way to do a line of sight analysis Something like: http://casoilresource.lawr.ucdavis.edu/drupal/files/images/condor_facility-4m_los.preview.png (655 kB) I think you could check a route by having a general position you want to avoid and run LOS checks every 10/20/50m along the planned route... Possibly using something from http://forums.bistudio.com/showthread.php?135252-Line-Of-Sight-(Example-Thread) or http://forums.bistudio.com/showthread.php?90864-Script-function-request-Line-of-sight-check&p=1504843&viewfull=1#post1504843 Any other ideas would be great. The combination of those two will allow the AI to work out the best avenue of advance (based on passability of terrain and identifying dead ground) Any thoughts would be much appreciated

Ok - some success in a basic proof of concept... I am using terrainIntersect and loops to find areas of dead ground. Currently it only checks a single direction (due north for ease initially) however intent from here will be to check areas in an angle either side of the intended assault to work out a route into the FUP too. The script loops from the initial position and adds a minimum distance to start checking from. This prevents dead ground within close range being considered. It can be set to 0 to check from the observer's origin. There is an offset that can be modified; currently I use it to add a bit of height as a safety buffer. The loop checks from the observer position to a location a set angle and distance from them; a set interval is added to this each time until it reaches the number of cycles. This allows you to specify the accuracy (eg. Check every 5m, 20m, 50m etc) and distance (eg. if interval is 5m and you want to check to 1km, you would use 200 interval loops) It also identifies the closest FUP available. You specify how many intervals of dead ground you need (ie. set how 'deep' the FUP needs to be to be considered valid) and how far into the dead ground the FUP will start (eg. You could have the FUP right on the cusp of visibility or you can start it further into the dead ground) As always, pictures are a good demo: Basic eg: https://dl.dropboxusercontent.com/u/74159983/deadGroundDemo1.jpg (214 kB) Checking with more detail (FUP needs to be a bigger size here; note the dead ground ignored because it isnt sufficient size) https://dl.dropboxusercontent.com/u/74159983/deadGroundDemo2.jpg (212 kB) Another demo showing where small amounts of dead ground are https://dl.dropboxusercontent.com/u/74159983/deadGroundDemo3.jpg (208 kB) If you need a big FUP you would use something like the above; if you wanted a LUP for a sniper for example, you could use a smaller interval and FUP size. Obviously still very basic WIP but at least the concept is feasible! Script allows you to specify the interval between

Pretty sure it isnt possible... but does anyone know a way of reading an external (.txt) file from a packed/compiled mission?

Read an external file after it is pbo packed... The current mission is a chopper training mission... the idea is it starts on a radio trigger and records (unitCapture) you doing the tasks.... if you do well, you can copy your movement data and send it to other people... A second radio trigger is basically "Watch sampled flight" which would show a flight done by other people using unitPlay... Movement data taken from a file you pasted to. The key point is the movement data would be taken from a text file separate to the pbo'd mission so you could paste new flights into the text file and fire up the mission to see the results of other people's attempts.... Easy (and current) workaround is just leave it un pbo'd and get people running it from editor.... But did get me thinking if it was possible to read data from an external file for a compiled mission?

One addition: For the unitPlay, enclose everything in if (isServer) then { //Stuff goes in here }

http://community.bistudio.com/wiki/getDir Then http://community.bistudio.com/wiki/setDir

Just because I like the idea... The link given has all the info you need but to summarise: BACKGROUND BIS_fnc_UnitCapture Description: Records movement data of input unit over a specified period of time. Pressing the ESC key, the duration ending, or the unit dying ends the recording. Parameters: Unit - Unit to capture movement data from Duration - Duration to capture for OPT:FPS - OPTIONAL: Frames recorded Per Second (default 20). Limit is 1 - 100 OPT:Firing - OPTIONAL: If true, will record the input unit's weapon fire data as well OPT:StartTime - OPTIONAL: Starting time offset for the frame time CONTEXT I will use your scenario as context - we will have a boat called boat1 and we want to insert them onto a beach What unit capture/play actually does is copy the POSITION and when you play it, it sets the vehicle position to the position it was every frame when you recorded - this simulates the movement! It also means a lower FPS recording (covered below) will seem jerky because ... well it is! USAGE (RECORDING) So to run unit capture at a minimum you use something like: rec1 = [boat1, 300] spawn BIS_fnc_UnitCapture; ***NOTE: Use SPAWN not CALL This will record the unit 'boat1' movement for 300 seconds or until you press escape (or die) If you are going to do it in MP or when you review it, it seems choppy, you can make it smoother by increasing the recording FPS value (defaults to 20) So eg2 (What I used in the test mission I will link to) rec1 = [boat1, 300, 40] spawn BIS_fnc_UnitCapture; (boat1 recorded for 300 seconds at 40 FPS) To actually record something you need to call that function. Easiest way is to set up a radio trigger with the above line in the On Activation. Another way to do it is just put that line in the unit init box (which will start recording as soon as the mission starts) So to record what you want - start the recording, do whatever crazy driving you want to do and then press escape (which will bring up the standard escape/pause menu). Press it again or click resume game and when you are back in game you will have a hint summarising the recording. Now all you need to do is press F1! RECORDED! F1 pressed... WHAT NOW? Alt-tab out and open note pad (or other script editor). Paste the data (control-V or edit-paste) and you will see a WALL of numbers come up. That is the movement data you just recorded in the form of arrays of positions. Step 1 -Assingn the movement data to a variable. (eg. testMovementData1) At the VERY start of the data (eg. something like this: [[0,[2771.43,6518.35,-0.383466]........) put testMovementData1 = So now you have something like: testMovementData1 = [[0,[2771.43,6518.35,-0.383466]........ Step 2 - SEMI COLON! At the end of your data, put a ; ie... .....,[0.854578,-0.687499,0.00402232]]] becomes .....,[0.854578,-0.687499,0.00402232]]]; Save the file as testMovementData1.sqf in the folder that your mission is saved to. SCRIPTING TIME! Create a new sqf file (we will call it moveBoat.sqf) In moveBoat.sqf put: move_now = [boat1, testMovementData1] spawn BIS_fnc_UnitPlay; THAT WAS EASY... PLAY! Open your mission again and remove the recording part (ie. if you put it in your boat1 init, delete it) All we need to do is execute our testMovementData1.sqf script (to set the value of our moveData) then our moveBoat.sqf file! For now, create a radio trigger that will execute the script (eg. On act -- null = [] execVM "testMovementData1.sqf"; null = [] execVM "moveBoat.sqf";) Note - You can just have one script with all the information in it ie. instead of setting your move data in testMovementData1.sqf, you can declare the variable at the start of the moveBoat.sqf and paste the wall of text in there... The issue with this is if you have multiple sets of movement data (eg. an insert and an extract), it can make your script messy! Press preview! Nothing happens.... the boat sits there... Call your radio trigger - And we are away! POINTS TO NOTE! Floating boat! As the unitCapture works on POSITION, you may find your boat floats a bit - that is due to differences in the waves when you recorded it. For a boat insertion I would suggest setting the waves to 0 to avoid that issue. Quiet insert! If you play it straight away, you will probably find you are moving but there is no engine sound... There are two ways around this: 1. Write in your mission that you are inserting super quietly 2. Give the boat a waypoint straight in front of it and put your unitPlay call in the onActivation of the waypoint - the AI driver will turn the engine on and you will have the engine sounds! Note that the engine sound wont change in line with the speed though (recall that this issue is caused because all we are doing with unitCapture/unitPlay is setting the position of the boat to give the illusion of movement) I DONT WANT THE BOAT TO WAIT ON THE BEACH! You can get rid of the boat by giving it a waypoint once you are out of the boat. You can also use unitCapture/Play to record some funky driving to get rid of it. See next post for some more advanced options including detail on getting the blokes out of the boat. ---------- Post added at 11:17 AM ---------- Previous post was at 10:45 AM ---------- SOLUTION TO YOUR QUESTION I have set up a QUICK demo mission of how it could look for you here: https://dl.dropboxusercontent.com/u/74159983/testCapturePlat.Stratis.zip (Note it was meant to be testCapturePlay but I typed it too quickly... oops) The way I did it was recorded myself driving to the insertion location, escape, F1 and set that as moveData1 I then made a script that would: 1. execute that data (unitPlay) 2. On completion of the playback would immediately start recording again. (See below for how-to) 3. Unload the dismounts in the boat I then ran the mission a second time with the above script in the init of the boat. This led to: 1. Me as driver sitting the the boat not controlling it 2. Arriving at the beach and a recording starting 3. Transported dismounts got out one at a time 4. Then I pulled back from the shore and took off. 5. At a suitable distance away, escape, F1 and save the data to moveData2 I then exited the mission again, and modified the script to do the below: 1. Execute moveData1 (insertion) 2. On completion of that playback, execute moveData2 (extraction) 3. Unload dismounts in the boat This new script was saved and now when you run it, the boat goes to shore, dismounts unload and the boat extracts. RATIONALE FOR MY SOLUTION The main benefit of unitCapture/Play is you have fine control over the movements. The issue you will run into a lot of the time with a vehicle inserting then extracting is the gap between you arriving at your destination and when you have to leave - the AI will try and take over and do unpredictable stuff... Then when your departure unitPlay script is called the vehicle will teleport to the location you started the recording from - Looks terrible! The benefit of the above technique is whilst you are playing two seperate recordings, the second one starts immediately after the first. It also allows you to set up your disembark script to fire between the two recordings. That means the second recording will commence with you waiting for dismounts to get out, then when you are happy they are all out, you execute your amazing departure! The best way to work this stuff out though is just make a test mission and play around. (eg. Want a hover tank? unitCapture a chopper, fly low and slow, then unitPlay that data on a tank!) WHEN HAS RECORDING PLAYBACK FINISHED? If you want to wait until the playback is finished before doing something (eg. Wait until insertion playback is finished, then order dismounts to get out/play extraction unitPlay) you can add a variable that will be assigned TRUE when it is finished. eg. [sCRIPT] boat1 setVariable ["InsertionDone", false]; [boat1, moveData1, [boat1, "InsertionDone"]] spawn BIS_fnc_UnitPlay; waitUntil { boat1 getVariable "InsertionDone"}; // stuff you want to execute once insertion is complete! [boat1, moveData2] spawn BIS_fnc_UnitPlay; [/sCRIPT] GET DISMOUNTS OUT For this scenario I named the group of dismounts delta1 by putting in the group leaders init delta1 = group this; Then in the insertion script (As it was being run right at the start of the mission) I put [sCRIPT] {_X moveInCargo boat1} forEach units delta1; [/sCRIPT] then in the same script, once the playback of the insertion had finished I put [sCRIPT] { doGetOut _X; unassignVehicle _X; } forEach units delta1; [/sCRIPT] Simple search will help for that kind of stuff eg: http://forums.bistudio.com/showthread.php?76848-Eject-MoveInCargo-Howto WHAT ELSE CAN IT DO? You can also set it to record firing data... Quite useful for if you want to set up a perfect CAS run, you can record movement and firing data then when a trigger fires have the plane come in perfectly and engage the (static) target (assuming you can pilot it well enough!) If you are interested in that, PM me or I can add it to this post for reference later if needed. FINAL POINTS As I mentioned earlier, the engine will not be on if you start playback on init. You can try out something like: [sCRIPT] this engineOn true; [/sCRIPT] Or set waypoints. Note this is true of choppers too - if you go straight into unitPlay with a chopper on the ground, you will be flying with no engine on! The benefit of waypoints is (eg. using the boat insertion example) you can set a waypoint out to sea where you want the boat to wait and call the insertion movement on init. Once the AI has control of the boat again he will go back to heading to the current waypoint. Note you would still want to record part of the movement away from the beach to ensure that the driver: 1. Waits for dismounts to get out 2. Doesnt do something stupid like drive into a rock But it does mean you could have a much shorter unitCapture/Play; once he is safely pointed to the waypoint, when the unitPlay ends he will keep going to it! Hopefully that helped you out somewhat, have fun playing around with it! BIG CAVEAT - All of the information above is stuff I have worked out through trial and error - I am by no means a jedi at this stuff and would listen to those more informed over me if it is contradicting. That said - All of the above is stuff I have effectively used in SP and MP (hosted and dedi) without issues. Also - Some of the stuff included in unit init would be better in the init.sqf however it was kept in-editor for simplicity at this stage. Variable declaration especially would be better declared in the init.sqf!

Waypoint issue - As above. Change "hold" to "move" and synch with trigger and it will work fine. Chopper lights - http://www.armaholic.com/forums.php?m=posts&id=88077

You could try using EJECT to get them out. As far as the insertion goes, have you tried unit capture/unit play? That way you can drive exactly how you want for the insertion and ensure you drop them right where you want them

I am doing up a basic supply carrying/loading script for a mission I am making; works perfectly so far (Players can grab barrels and move them to vehicles, load them in the back and unload them) I am using the attachTo and detach for this however when I detach a barrel and they are above the ground level, they just float there (ie. no gravity/physics) Does anyone know how to re-enable gravity on these objects? Current workaround is just setPos to ground level but surely there is a better way? (Or at least ANOTHER way?)

I am using it now but because it has different results when in a vehicle (the player is higher) I was hoping for physics to take over. (And seems like it logically should be able to if something is above the ground) Although interestingly... with the metal bins gravity doesnt seem to want to work but I changed to the plastic bins and they work fine!

enableSimulation didnt work (tried it first up) Neither did setVelocity.... strange?

Did you have the trigger over all the units you want to have the action? ie. for everyone then have the trigger fire on anyone present. There should be no reason it conflicts with that init file... have you tried it without your custom stuff to make sure you can get it working?

I think that is a relic from when it was not MP tested? Just the automatic Armaholic release template anyway... But there could still be minor issues I spose!

Not exactly what you are after but I made an A2 script (Which I might redo a bit better for A3) that required actual adjustment; you still use a map click for the target grid but the rounds have more realistic first shot accuracy and you have to adjust (left/right and add/drop) to get the point of impact on target before fire for effect. Note this doesnt use real arty pieces - you set up simulated ones in the editor (You can specify round type, ammo, first round accuracy, fire for effect dispersion etc too) http://www.armaholic.com/page.php?id=16625

Sorry all - been away a while. Sound - could look into it if you are still keen Stealth requirement - it is a bit difficult to do effectively - mainly due to in built AI. I have used it a bit in more chaotic fighting (When one AI is engaging another person) Friendly fire - an easy option - I believe it was in the readme part but if not it is quite simple to change (let me know if you still need it)

I am trying to set up an ambush scenario; there are some mines on the road and on the edges; if one of them is detonated I want the AI to commence the attack but if they are bypassed the AI should remain in hiding. Seems simple enough; trigger with waypoints but how would I synch the trigger to the mine(s) detonating? I am using the minefield site with 0.1 radius and one mine to put them down in exact locations. The only other thing I can think of (which is a bit more of a hack) is to just use a trigger to initiate the explosion which could become the trigger for the attack but I am not keen on doing it this way because I want to give the players the option of disarming mines if found. Any thoughts?