blakeace

Updated to version 1.0.2 Download available from the first post. Fixed error where nothing was returned in the vector up z value calculation. Implemented a yaw component to increase heading change. Improved the terrain avoidance algorithm to be much more effective.

One way with how your script is already written would be (neokika's suggestion is totally valid too), At the ,moment the variables which contain the reference to the objects you are creating are only defined within the scope of the if statements they are in. If you placed this out side of the if statements at the start of your script which will mean the variables exist at the level where you want to later delete them; [url="http://community.bistudio.com/wiki/private"]private[/url] ["_bg1","_cb1","_cb2","_cb3","_cb4","_rb1","_rb2","_rb3","_rb4_s1","_s2","_s3","_s4","_s5","_s6","_b1","_b2","_rw1","_rw2","_sg1","_sg2"]; You could place this after your waituntil statement. { deletevehicle _x; }foreach[_bg1,_cb1,_cb2,_cb3,_cb4,_rb1,_rb2,_rb3,_rb4_s1,_s2,_s3,_s4,_s5,_s6,_b1,_b2,_rw1,_rw2,_sg1,_sg2]; Nice road block by the way :) Hope this helps Blake

@Sickboy,Foxhound and Old Bear - Thanks for that! I have already written the code for inputting the waypoints, I have already prototyped some code to check where you are in reference to a line. I just need the time to gather a few more ingredients and mix them together. One limitation of this code is the turn rates aren't that spectacular I often use a rudder input to help increase the turn rate. At this stage the AP only rolls the aircraft, letting the flight model drift around from that position. When I get chance I want to have a play with the postion vectors to see if I can increase the turn rate a little. That was the idea behind this mode, but as per above the turn rate, which in turn affects the turn radius is quite large even with the use of rudders to help turn. If you place the aircraft in this mode, you can select a "reasonable" bank in the roll. If you add rudder, in an A10 at medium speed your orbit will be approx a 6km diameter circle. The A10 doesn't like turn turn much without rudder, so that would not be practical. I have a gaming keyboard, so I can at least get my rudder to hold down and use this mode specifically for the reasons you give. One of the many things on my todo list is looking to see if there is a effective way of increasing the turn rate from within the code. Well I hope it helps, I find the best aspect has nothing to do with all the different modes etc, but how it automatically goes into attitude mode where checking the map, I have lost count of how many times I have flown an aircraft into the ground whilst trying to grab a quick look into the map and not wanting to fly to high that I get busted by enemy AA. "Quick quick, come on close CLOSE yes, ARE CRAP!" :butbut: Edit: Ok I had a bit of a break through this morning, managed to overcome the problems I was having with the turn rate and changed how I calculated the terrain avoidance. This should really improve the ability to use this for orbiting areas, as well as implementing a waypoint following system. :) So the next version should be a fair bit better and responsive.

Updated v1.0.1 Just a small fix from when converting, forgot to rename 1 line as joystick references are different for forwards and back compared to TOH. Preventing ATT mode from allowing adjustments in the pitch angle. First post updated. Sorry Sickboy and Foxhound, missed that one in my testing. @Sickboy and Foxhound - Thanks as always @Kremator, Cheers enjoy!

Sorry about that, grabbed the wrong one. Updated with the correct one, which is the _ee version with V2 tools. https://rapidshare.com/files/2304492762/Blakes_TOH_autopilot_v_1_0.rar First page is also updated with the correct bisign. Cheers Sickboy for picking that up :) Blake

Updated to Version 1.0 Download available from the first page. Version 1.0 Added autopilot panel dialog Removed action menu items Removed hover hold Increased autopilot power to hold desired attitude Added AP master button OjoU-URNDZc

Ok from my first read I assumed it was just to do with the on click aspect. There were a few things addwaypoint references a group, not the unit. the if statement will only check for a result once not multiple times waiting until the condition is true. You need some sort of loop for that eg waituntil. I'm not sure of how close in has to be when referencing a location, but I think you would need something to check for a bigger range. Also the location isn't a position, but a location object. You used mv_22, then you use osprey where osprey doesn't look to be defined. Added a couple of extra checks, when trying to get it working. Plus smoke as I was curoius as to how it would look. Try this: alphaleader sidechat "Open your map and mark the drop zone for the supplies by clicking one time where you'd like for the ammos to be dropped"; _mk = createMarker ["drop_zone_mk",position player]; _mk setMarkerColor "colorBlue"; _mk setMarkerShape "icon"; _mk setMarkerSize [1,1]; _mk setMarkerDir random -10 +random 20; _mk setmarkerText "Supply Drop Zone"; _mk setMarkerType "empty"; mapclick = false; onMapSingleClick """drop_zone_mk"" setMarkerPos _pos; clickpos = _pos; mapclick = true; onMapSingleClick """";true;"; waituntil {mapclick}; alphaleader sidechat "Drop zone marked!"; mv_22 enableSimulation true; mv_22 hideObject false; sleep 0.5; _start_pos = getpos mv_22; deleteWaypoint [group mv_22,1]; _wp=(group mv_22) addWaypoint [getMarkerPos "drop_zone_mk",0]; _wp setWaypointType "MOVE"; _wp setWaypointBehaviour "CARELESS"; mv_22 flyinheight 200; _mk setMarkerType "Flag1"; waituntil {! alive mv_22 or (mv_22 distance clickpos) < 700} ; if (alive mv_22) then { sleep (3 + (random 3)); hint "drop drop drop"; _ammos = "USSpecialWeaponsBox" createVehicle (mv_22 modeltoworld [0,-10,0]); _smoke = "SmokeShellyellow" createVehicle (mv_22 modeltoworld [0,-10,0]); _chute = "parachute_US_EP1" createVehicle (mv_22 modeltoworld [0,-10,0]); _ammos attachTo [_chute, [0,0,0], "paraEnd"]; _smoke attachTo [_chute, [0,0,0], "paraEnd"]; _chute setpos (mv_22 modeltoworld [0,-10,0]); deleteWaypoint [group mv_22,1]; sleep 3; _wp=(group mv_22) addWaypoint [_start_pos,0]; _wp setWaypointType "MOVE"; _wp setWaypointSpeed "NORMAL"; _wp setWaypointBehaviour "CARELESS"; waituntil {! alive mv_22 or (mv_22 distance _start_pos) < 500} ; mv_22 enableSimulation false; mv_22 hideObject true; };

Have you tried moving the remove onclick functionality to below the waituntil, it should work there. alphaleader sidechat "Open your map and mark the drop zone for the supplies by clicking one time where you'd like for the ammos to be dropped"; _mk = createMarker ["drop_zone_mk",position player]; _mk setMarkerColor "colorBlue"; _mk setMarkerShape "icon"; _mk setMarkerSize [1,1]; _mk setMarkerDir random -10 +random 20; _mk setmarkerText "Supply Drop Zone"; _mk setMarkerType "empty"; mapclick = false; onMapSingleClick """drop_zone_mk"" setMarkerPos _pos; clickpos = _pos; mapclick = true; true;"; waituntil {mapclick}; onMapSingleClick ""; alphaleader sidechat "Drop zone marked!"; mv_22 enableSimulation true; mv_22 hideObject false; _wp=osprey addWaypoint [getMarkerPos "drop_zone_mk",0]; _wp setWaypointType "MOVE"; _wp setWaypointSpeed "LIMITED"; _wp setWaypointBehaviour "CARELESS"; if (mapclick) then { _mk setMarkerType "Flag1"; }; Not tested, but is how I have it setup when users update their steerpoint in my PINS mod. Also is this line required at all after the waituntil? _pos = clickpos; Hope this helps Blake

MyrK6aJ5WqA Warning: Firstly these scripts push the limitations of the current engine and may result in weird bouncing shaking etc. It may even hang the game. Which is why I have be postponing it's release. I can't remember which patch caused the first issues, so future patches may help or even make things worse. That said I still love the sense of approaching a ship readying myself to try and hit that moving target. The stability has dropped off a little since I started this, probably due to small changes to flight models etc. I played around to try and minimise the issues as best I could. In the end I felt it better to release so others may enjoy the satifaction I have been getting even with the limitations. Installation: For convience I have just zipped up my testing mission to make how to setup your objects and scripts easier to understand. Place the mission folder once uncompressed into your TOH editor missions folder. This is generally located in Documents -> Take On Helicopters -> missions folder. Access the mission by starting the TOH editor and loading the mission NAVAL_AVIATOR. Introduction: I have only designed this with single player missions in mind. I think the issues and limitations of what this is trying to do would only be exacerbated in a MP environment. There are a few things I would like to work on and improve, but I haven't a lot of time at the moment so thought it better to release it in an "as is" state for those like me who have always wanted something like this in a simulation. After the first preview, on my machine every time I try and start after causes the helicopter to de-rotor and induce a weird slow down to 1 frame per second as it seems the physics engine or similiar has a stroke :P May or may not occur to others? I released this as an editor mssion as it is more a base for others to build on; As such I have kept the content to a minimum rather than create a polished finished mission. Basically the mission starts on one ship, then requires you to fly and land on another ship before rescuing three engineers from a striken and sinking cargo ship (rope rescue). You then need to drop the men off on the heli pad on the mainland before returning to the first ship. If you have issues at mission start like I now am, remove sh = [this] execVM "Heli_Start_pos.sqf"; from the player helicopters init field. The scripts: Heli_Start_pos.sqf sh = [Helicopter_object,Helipad_object_attached_to_ship] execVM "Heli_Start_pos.sqf"; This positions the helicopter on the landing pad of a valid ship. Valid ships require a helipad attached to the ship marking the landing pad. NOTE: Remove this script if you have problems on mission start to have the helicopter start elsewhere. I basically can't use this part anymore and generally start off ship. Removing the ship motion may also help. Landing.sqf sh = [Helicopter_object] execVM "Landing.sqf"; This script is what enables the helicopter to land on valid ships. It tries to give a sense of grip to the surface of the pad, and when the relative velocities are similiar attachs the helicopter to the ship. Reduce the throttle to below 40% quickly, because throttle positions above 40% is the trigger to release the helicopter from the ship allowing it to takeoff. Special care is need here to ensure you are holding the controls in a "balanced postion" to stop the helicopter spinning or rolling at the time of release. ShipMotion2.sqf sh = Ship_object execVM "ShipMotion2.sqf"; Makes the ship roll and pitch. Removing this will reduce physics issues, but reduce immersion slighty too in my opinion. waypoint_update.sqf sh = [] waypoint_update.sqf; This script analyses the players waypoints and if they are placed within 40m of a ship object will update the waypoints posiotn every few seconds to the new position of the ship Load_talk.sqf sh = [Helicopter_object] execVM "Load_talk.sqf"; A quick attempt at having the loadmaster help talk you down onto a ship. Updates are ideally to slow for my liking. Ship_sinking.sqf and swim.sqf These are just two scripts used to create the rescue situation. Deck_light.sqf Used to try and give some light on the ships helipad. I would find the ship would not be illuminated at all times. That said using my mobile parts addons spotlight and this at night is hard and awesome at the same time! Variables: Helicopter variables: this setvariable ["Landed",false,true]; This is required to initialise the variable used to check if the helicopter is attached or not. Helipad_invisible_H variables: Used to mark the ships landing area. Hint for new ships use a visible helipad object to find the relative position on a ship then change it to the invisible sort. this attachto [ship41,[0,115,-10.4]]; Test mission download, with scripts included: https://rapidshare.com/files/584853022/NAVAL_AVIATOR.rar

Hi HeliEye, Welcome to the forums, I have the pro version and have used it through the arma series and TOH with no issues. The first thing I would check is you haven't accidentally assigned the rudder axis to the forward assignment as well. My ussual trick is the game picking up one of the dials or the slider if I haven't centred them correctly. Arma's and TOH's controls setup is very flexible in it allows multiple assignments. Are you using the Saitek profile editor? If so you would also need to check it hasn't got in the rudder assignment something like the W key? Hope this helps Blake.

This is the function I created for my AI FO addon. If the result is 1 it is an artillery piece. I haven't found an instance "yet" where it didn't yield the correct result. _Fnc_Is_Vehicle_Arty = { _Veh = _this select 0; _result = 0; if (isNumber (configFile >> "CfgVehicles" >> _Veh >> "artilleryScanner")) then { _result = getNumber (configFile >> "CfgVehicles" >> _Veh >> "artilleryScanner"); }; _result }; Hope this helps Blake

Blake's Mirrors HCoBY853yUE Requirements: (All EE versions) Requires extended event handlers found in Community Base Addons. http://forums.bistudio.com/showthread.php?t=103871 History: v1.0 (Only in EE version) Changed the way key presses are detected. Now using CBA Key Management for a more robost detection. Changed the drivers key press from hold breath to toggleweapons. v0.2.1a (Only in EE version) & v0.1.1a (module) A quick fix where I hadn't limited the getin handler to the player allowing the addon to possibly run multiple times v0.2a (Only in EE version) Extended eventhandler version. Added black and white camera effect. Added global array to store mirror positions. Global array allows other vehicle type to gain mirror functionality without additional code. v0.1a Initial release only module version. Introduction: A mod that allows drivers of cars and trucks to use mirrors giving a more realistic experience in those roles, rather than having to rely on the outer body experience to view behind when reversing :P Hopefully A3 will make this redundant. The placement is determined by a generic placement by type of the vehicles. As such one size doesn't always fit. See below to override the default placements if required. Features: The ability to look backwards emulating the side mirrors of a vehicle. Being able to still control the vehicle while viewing backwards. NVG compatible, though you will get the over exposure effect each time you change view. Installation: Install as you would any other addon. (Check the BIS forums if unsure!). In the editor place a Blake's Mirrors module onto the map. All editor placed cars and trucks are now enabled. If the player starts in the vehicle, functionality is created through the getin event handler requiring the player to dismount and get in the vehicle again. Keys: Drivers Mirror - Toggle Weapons (Default F button). Passengers mirror - Gear (Default G button). Usage: Download: Version 1.0: Blake's Mirrors - Extended Eventhandlers v1.0 Blakes Mirrors - EE version (v 1.0) : http://www.armedassault.info/index.php?game=1&cat=addons&id=1823 https://rapidshare.com/files/1282061961/Blakes_Mirrors_EE_v1.0.rar

Sorry Bier AIG Tartar, I thought I had responded to this. I did have an experiment around with this concept, but I found using switchCamera to change the view which still allows retaining control of the vehicle, I haven't been able to find a way of altering the FOV. At the current setting looking down doesn't give the pilot enough information to be that useful esp concerning obstructions. I played around with altering the angle, instead of looking straight down I tried setting it out slightly on a 60 degree angle. I found this a little disorientating, without much improvement on obstruction observation. You could use the camera commands, but the issue there is not being able to control the aircraft at the same time. The only real use I could see was for lining up underslung loads when using the likes of RAV lifter. This is still at 20m high! GRID 038 017 on Utes. No use for clearances.

Sorry I'm not sure what you are hoping to do? Setup so the vehicle seems to have two cameras each on the sides of the vehicle? If that is the case, you just need to set the x part to be non zero. So that you have something like: spwnrtn1 = this spawn { _this setvariable ["mirrorpos",[[color="#FFA500"]2[/color],-3.1,-0.2],true]; _this setvariable ["Camera",true,true]; waituntil{Blakes_Mirrors_Loaded}; sleep 0.01; [[_this]] CALL Fcn_Blakes_Mirrors; }; Instead of: spwnrtn1 = this spawn { _this setvariable ["mirrorpos",[[color="#FFA500"]0[/color],-3.1,-0.2],true]; _this setvariable ["Camera",true,true]; waituntil{Blakes_Mirrors_Loaded}; sleep 0.01; [[_this]] CALL Fcn_Blakes_Mirrors; }; The values would just need to be adjusted for your vehicles particular size. Hope that helps Blake

I'm glad you like it. Thanks for the feedback, I didn't realise that was occuring, the actions have a logic to check if there is or isn't a gunner. Though in testing I found I have a check that looks if the player has no weapons it terminates the weapons management aspect of the mod. I will have to have a look at a way of working that differently. Cheers Blake.

No worries. The only reason to wait for Blakes_Mirrors_Loaded to be true is if you are spawning vehicles or setting up non default vehicles like armour and want to use the Fcn_Blakes_Mirrors to give that vehicle the mirror functionality. Blakes_Mirrors_Loaded just ensures the spawned vehicles that require it don't run the function before it is initialised. Have you set the x component of the mirror position array to 0? The way the code works is it just mirrors the array by multiplying the x component by negative one. In the first post in the example for the Lav25 to create a reverse camera effect I used 0 so it was centered to the rear of the vehicle, rather than having the efeect of having two cameras if I had used a non 0 value. No probs. Me two :)

There are only two ways to import in a list of custom positions with the current version. From the first post: The other way is undocumented. I was starting to learn about how to read and create config's (Not that much further along these days either :p ). The idea was to eventual read a value that was from an object's own config, but at that stage could only create a new config, and I am still learning how to alter existing configs. You can create a custom addon which contains a class that can be read to see if that object type has a listing. Not a very good solution, but more an experiment. If you know how to create your own pbo's then you can add this, each time Blakes mirrors sets up a vehicle it checks the BlakesMirrorPositions config to see if there is a matching entry that has the same class name as the vehicle. If it does find an entry it uses that position. In the config.cpp class CfgPatches { class cleggys_Mirror_list { units[] = {}; weapons[] = {}; requiredVersion = 1.0; requiredAddons[] = {"Blakes_Mirrors_EE"}; }; }; class BlakesMirrorPositions { class HMMWV { mirrorposition[] = {1.2,0.7,-0.9}; }; class MTVR { mirrorposition[] = {1.4,2.3,0.5}; }; class HMMWV_TOW { mirrorposition[] = {1.2,0.7,-0.9}; }; class HMMWV_MK19 { mirrorposition[] = {1.2,0.7,-0.9}; }; };

@Old Bear and Foxhound Thanks as always :) Cheers mate, p.s. I haven't been able to duplicate the residual bomb aiming remaining on? Sent you a pm with some ideas for you to look at to try and identify what's going on. Lets hope it works. I haven't done any genuine testing with multiple players, just with an ai aircraft that was transmitting the same data on the dedi, so fingers crossed. Any feedback would be very much appreciated. Note: I have tried to minimise the networking of the data as much as possible. The aircraft only updates transmits it's data once per sec, so the position of the camera effectively lags behind what the pilot sets it to by one second.

Updated Version 1.02 available from the first post. Added map auto closes after selecting the steerpoint. Added a menu item FEED that broadcasts your cameras video feed to an external unit such as a JTAC. (Alpha)(Hold zoomout key to access. Requires a camera). Added a modded Rover terminal, an adaption of the default laptop that functions as a Rover terminal. (Alpha) tTMI9qtSMtc Note: This has only been tested by myself simulating the other half using the AI and dummy variables emulating other players on my dedicated server. Results may differ when proper use occurs sorry. Still quite rough, and any feedback would be appreciated. Ugly58 thanks for the idea.

The command doesn't allow for passing or returning parameters. You'll need to use a global variable or similar, I either try and use a well named global variable, that won't get used elsewhere hopefully, or an object variable using the setvariable getvariable commands. Another option is from within the scope of the onmapsingleclick command set a marker to the _pos position. In your code outside of the click command read the value or position of the marker. Hope this helps Blake.

Updated Version 1.4 available in the first post. Updated the prediction algorithm when units are on a road. Tweeked the general prediction algorithm's lead caculations. The BIS artillery module now gives the artillery units all the available ammo types by default. Because of this the below changes were made. Set the default SADARM ammunition type count to zero. By default these specialised rounds shouldn't be available I believe. Updated the sample missions. No need to manually set specialised ammo types to the artillery units, they now get them by default. ~Note: Use the ammo type number of fire missions counters to set which types are available and how many missions they can deliver. Thanks Rydygier for getting me thinking about the road algorithm again :)

_name = format ["marker%1", _count]; _marker = createMarker [_name, position _next_pos ]; _marker setMarkerShape "ICON"; _name setMarkerType "DOT"; _count = _count + 1; _count was initialised earlier. Each time a new segment was found it runs over this section of the code(in the loop) to generate a new marker so I could visualise what the code was doing. I didn't explain the video to well, as it was fairly late when I finally finished playing with the algorithm. At the top of the screen is a marker which represents the calculated impact point that the mod usually derives from analysing the targets movement. So when the algorithm I was using got to the intersection to the farm, it checked both segments and determined that the distance from the main road segment was shorter than the farm lane segment. In most circumstances, this simple selection technique shouldn't be an issue in the functionality of the mod as the lead on the target isn't that great that choosing the wrong path will probably only affect one mission before the target if not killed passes that point.

At the moment it sort of does this, though the radius of the nearRoads command is kept quite small. The bigger the radius the larger the impact the command has when running. Being server side I am always trying to minimise the impact a mod like this has. After posting above I had an idea of how to control the intersection prediction. Keeping it simple, always follow the path that reduces the distance to the direct line prediction point. Then use that distance to calculate what the required cumulative distance added up between sections. Not perfect by any means but I think an improvement generally over the current version in most circumstances. A small video of my testing not showing intersections but how distance and curves are worked out. Edit: Actually there is one intersection at the farm, thanks Orcinus for spotting that. QivjC1YHbdc

For the sake of simplicity and trying to minimise the computational overheads as much as possible the road check only works on relatively straight roads. I have wondered about this command roadsConnectedTo, if that could be used to trace possible paths away from the current position, using the position of each segment to calculate distances over the "curved" paths. It just seemed like it would be quite intensive to calculate especially when there are also multiple path choices due to intersections. I may play around with it at a later stage if I ever get enough time :p I haven't tested the command, so it assumes I am interpreting what it does correctly.

Cheers, I'm not sure if this is helpful with how you are designing things; But the addaction command also has a condition parameter that allows you to specify certain tests when determining whether the action is available or not. If these actions are required multiple times, then using the condition parameter maybe easier than removing and re creating the action? Maybe you could use something like checking the speed of the IFV. eg speed IFV != 0 in the stop action condition. You could have another action called start that only appears when the speed is 0. You could also have another check that looks at the distance between the vehicles position and the final position. Eg IFV distance Move pos > 20. If it is less than 20m then the stop action isn't available. Then when another move is ordered, the stop action will again display. Depending on what you are trying to do these options may or may not help? Blake.