blakeace

null = [thislist select 0' date=Guns1,4] execVM "aifiremission.sqf" If you place the above in a trigger, thislist select 0, specifies target the first unit that is part of all the units that activated the trigger. Which is the first doesn't matter, for our needs it just means he drew the short straw. Guns1 would be the name of the artillery module you synced with your artillery units. 4 is how many rounds to fire. Below is the list of the optional arguments. Note friendly is by default opfor. So if you want to fire at opfor you need to change this. null = [thislist select 0,Guns1,4,"HE",100,20,5,"SoldierWB"] execVM "aifiremission.sqf" The above would be required if the trigger was for firing on opfor troops. The reason there are so many arguments is we wanted to changed the last option, and have to include any arguments that proceed it. Battery - which is the name of the artillery module you are calling (Default Art1) Number of rounds - How many rounds to fire assuming the artillery has the ammunition (Default 1) Round Type - Select the type of round HE by default. The other types must be added to the artillery objects for them to fire them (Default "HE") Dispersion - Basically how much spread between rounds (Default 100) Prediction Calibrator - A way to influence how far ahead in the current direction of the target to rounds land (Default 20) Skill - A basic way to see how accurate the placement is values from 1 to 10 (Default 5) Friendly - Checks to ensure their is not a friendly of this type within 50m of the impact location (Default "SoldierEB") Ok so that goes in the activation field. The oldtime component is just a way of getting the trigger to fire more than once.

Just a little proof of concept I have been playing with. I like the idea of the ai artillery being as real as possible within the restrictions of the game. So I like the idea of a FO that can be killed, stopping the eyes of the artillery. I like having real guns, whose rounds take time to get from firing to impact, and can be destroyed which will stop the artillery as well. Meaning they generally have a finite amount of munitions as well. With real guns it allows multiple FO's to call them and they can only fire at their maximum rate. Problem is when rounds take approx one minute to travel to impact a lot of things can change. Mainly the target you are aiming at will not be in the say place. So I started with a small script that has a basic prediction calculation to set the impact hopefully where the target will be. Then I realised there are many ways that a mission design might want to implement an ai artillery component. For me at the end of the day I like the implementation to be resonably simple. So I wanted to use the existing artillery module. That way most of the artillery style objects can almost be interchanged with little or no messing about. So I thought how about a modular system, with a core component that can have extra stuff built around it. It also allows for improving the system and making it upgradable too. http://www.armaholic.com/page.php?id=8421 It has the core script, plus three applications of implementing the core script. These can either be used as is, or as a base to customise your own system. This can be as simple as adding to a trigger, or an elaborate custom script. Most of the time all you need is some arty objects sync an artillery module to them. Create an FO style unit and place one of the scripts, or your own, with the appropriate parameters. Just make sure they are in range, and they can be called to fire the custom munitions if you have added the appropriate magazines. Now the features are fairly simple, the prediction just takes a snap shot of the speed and direction of the unit. so ai being ai can make some rounds land in odd spots. It has a limiter to stop fast units causing rounds to land miles away. Though the system could have this added to it with it being modular. It has a simple friendly check to make sure there are no friendlies with 50m of the impact area at the time of firing. Though the dispersion parameter can make this still to close. Anyway, it should be ok on a dedicated, I did a small amount of testing on ours.

Not sure about this one mate, have to admit I am far from a dedicated server expert. I can only confirm it is doing the same thing on our server. Sometimes it would set the correct angle in relation to the truck, but would always fail to angle correctly to set the connection point correctly. Wish I could be of more help, but this will have to wait for someone who is more familiar with dedicated servers.

I use this to quickly find the class name of any object I can place in the editor. This might help in the future. hint format["%1", typeof this] Place it in the init line of the object whose name you require. Also what I do is keep a little notepad file on the desktop with all the little tid bits that I nedd only every now and then. But usually couldn't find the link again when I did need them. Works for me anyway :)

@Lucky44 I have found the BIS Wiki to be very helpful when it comes to confirming the syntax of your scripts. http://community.bistudio.com/wiki/sqs http://community.bistudio.com/wiki/sqf http://community.bistudio.com/wiki/Control_Structures

Yep I got tcp's one going, nice and simple tcp thanks! Did you remember to name the trigger:- trgArty I forgot this first try then looked at the script and realised this is what was missing with my trial.

Not without a lot of work. Regarding the turning circle it is not as noticable, the example you give is the worst case scenerio using the vehicle with the smallest turning circle attached to the longest model towed. Though trying to turn the C130 without it is even more fun! I will take the limitations for the benefits.

Ok I must admit I love Norrins little attachto scripts. I have altered and played around with the bike on the pickup one to acomplish all sorts of things like carrying ammo crates, mortars, adding searchlights to the back of trucks the list goes on! Here is one thing that I am sure some people will love. I have always wanted to be able to tow the M119 around before a truck. Now this doesn't do anything fancy it just attaches the gun to the back of the truck, so the wheels don't rotate and the base plate is still present, though partially hidden most of the time. At least it gives me the ability to add this to the missions if I need to relocate etc. // mount_vcl.sqf // © JUNE 2009 - norrin (norrin@iinet.net.au) _vcl = _this select 0; _caller = _this select 1; _typeOfVcl = _this select 3; _dir = getdir _vcl; _mountVcl = objNull; _blogs = 0; _c = 0; _dir1 = 0; if (count nearestObjects [player, [_typeOfVcl], 20] > 0) then { _mountVcl = nearestObjects [player, [_typeOfVcl], 20] select 0; }; if (vehicle _caller != _caller) then {_caller action ["GetOut", vehicle _caller]; sleep 1}; if (!((_vcl getVariable "NORRN_mountOn_vcl_pos1") select 0)) then { _dir1 = getdir _vcl; _vcl setdir 0; _mountVcl attachTo [_vcl,[0,-6.4,-1.2]]; _mountVcl setDir 180; _mountVcl setVectorup [0,-0.15,1]; _vcl setdir _dir1; sleep 0.1; _vcl setVariable ["NORRN_mountOn_vcl_pos1", [true, _mountVcl], true]; }; if (true) exitWith {}; So all I have done is added bits to the mount_vcl.sqf script. Then in the init line of the truck assigned the type of object to be attached to M119 nul = [this,"M119"] execVM "mountOnVcl\mount_vcl_init.sqf"; The rest of the scripts are as per Norrins Put bike in Pickup scripts. As always love your work Norrin! This has not been tested in MP, just been playing around, and their is probably a better way of doing it, but it may just give a little enjoyment to others like it has to me.

Sorry I cannot give you an answer for this, but I can point you to a thread on our forums, because one of our members suffers from similiar issues. His problem is less severe once he switched off his IP suppliers firewall. Though not completely gone. Anyway here is the thread, so that it might help narrow down your issue. If you do find an answer please post as this is driving Mofo nuts! http://www.zspecialunit.org/forums/arma-2-armed-assault-2/1116-operation-save-mofo-mon-14-9-09-2030-aest-9.html Another topic on a similar issue has started here, but doesn't contain a lot at the moment. Though worth watching, as it is how I found this thread! http://www.gamingsa.com/forums/showthread.php?p=86630#post86630

I was playing around with this to randomly destroy buildings and cars in an area. I haven't tried it in MP though. the Value 500 is the destruction radius. By changing the random result will alter the percentage of destruction. 3/10 If you make the 3 a 10 then everything will be destroyed. if you make it a 0 then only 1 in 11 will be destroyed. Be careful to ensure this only runs on the server in MP as the Random command will produce different results in each client. buildings = nearestObjects [targ1,["Static"], 500];{_x setDamage (random 10)+3/10; sleep 0.2;} foreach buildings; cars = nearestObjects [targ1,["Truck"], 500];{_x setDamage (random 10)+3/10; sleep 0.2;} foreach cars;

Not sure if this would work, or if it fits in with what you are trying to achieve, but have you tried using the attachto command to attach extra empty harriers to a ai flying one, that would possibly give a very tight formation. Though I have not tested this.

We have tried it on our servers, in conjuntion with MAP_ReducedVoice addon , and haven't had any instances of it hanging the server. The issue we have is the inconsistant comms between users. One will be really clear, while the next person is very choppy. We had a theory that it might have be due to the individuals client being unable to cope, but experimented with them tuning their system down if it was related to a priority mechanism, that sacrificed comms to help maintain other aspects of the game. Didn't seem to alter their comms clarity. So at this stage we have disabled them for simplicity, but would love to enable them as it improves the flexibility immensely. Has anyone else had similar issues? Or more importantly a solution! Cheers.

As usual Jones love your work, killing click on map arty one mod at a time! I have updated the calculator to use mils and comes default with Jones Mortar addon's ballistic values. For those that don't know it, it is an Excel spreadsheet used to calculate fire solutions for arty addons "usually Jone's awesome stuff" in a more realistic way, by communication between FO and the battery. You can get it here http://www.gamingsa.com/forums/showthread.php?t=3055 or http://www.armaholic.com/page.php?id=2892 A quick tute can be found for it here. http://www.zspecialunit.org/forums/arma-2-armed-assault-2/1036-fire-control-calculator.html

Don't worry, I am keeping an eye on Jone's awesome work! At the moment it isn't really worth adapting my fire control calculator until until Jone's manages to crack the multiple ammunition charges. As long as the ballistics retain one air friction cooefiient value, then the calculator can simulate any rounds ballistics. Then it is just a matter of adding angles measured in mils for compatibility. Though the MRLS is a different story as the calculations require adaption to incorporate rocket thrust. Always good stuff Jones!

There is possibly a more elegant solution, but what I did was add in the activation line of the trigger a public variable eg alarm = true; Then create additional triggers that check just for that variable's condition to be true with the same sound effect. Place these extra triggers over buildings or guard towers to give a better sense of where the loud speakers are.

Well you really haven't given much information to go buy, here, is it a dedicated server, what type of missions, everyone, etc. I know running a mission with most of the modules, such as the ambient civilians module will reduce the fps on our dedicated server from 50 to around 15! It could also be your settings you are using, our server admin likens it to solving a rubics cube. You almost solve it, try to fix the next bit and it all messes up again!

Ok firstly I am presuming that map markers are off lol. If you are being dreopped off via a vehicle such as a helicopter. If you have a look at the map before you reach your drop off point you will see as vertical and horizontal line which moves with the heli, because all vehicles contain a gps by default (except bikes I think). So as long as you check that just as you get out, probably quikly place a marker you will know where you are. Depending on the mission and the mission designer check to see if they have included any gps units in some of the ammo crates. In the map view it will display your current location using a six figure grid reference. In normal game view use right ctrl m (default) to bring up a mini map which is your gps. Else learn a little basic map reading skills such as triangulation to help find your position. There are plenty of web pages that provide tons of info on this stuff.

Acutally the Arma2 grid reference for the default maps is 100m squares when using the six figure grid reference. Arma1 had a 200m four figure grid reference. It is easy to verify, go into the editor, place a player unit on one grid line, place a second unit one grid line over. Assuming you are zoomed in on the editor map. When you preview it if you have friendly tags on if you hover your cursor over the unit it will state it is 100m away. This makes the grid reference system more conventional. Well in reference to twenty year ago anyway when I was in an arty regiment. We would use six figure grid references for fire missions. If someone wanted to emulate inaccuracy ignoring things like atmospheric condtions etc. then you would need to include how accurate is the location of the guns known, say some where within one 100m grid square. The same for the target, depending on how accurate the map is, how correctly the refences are being used to locate the target point etc. You resonably say an initial error of upto 100m meters is possible. It could easily be more or less depending on the skills of the person reading the map, and how accurate the map actually is! The advent of GPS systems has probably improved the above assumptions though I am unable to validate something like that.

Place this in the init line of the object you are trying to place on the deck. This will allow for the different tides during different times of day etc. this setPosASL [getposASL this select 0, getposASL this select 1, 15.9]

The middle value will the same height as the artillery object. With the example you gave the mortar would be sited at a height of 340m above sea level. So if the target was at the same height as you, you would place this line on the desired target. The two extreme values indicate impact points if the target was 1000m above or below you. So if your target was situated on a hill whose height was 1360m above sea level, using you example you would place the 1360 line on the desired target. 6 figure grid reference. If you open the map and are viewing the same area as the fall of shot cursor is located, if you have your map zoomed in you get a much more detailed image of the cursor. You will then also notice another value after the height. This value is the time of flight for the round. Now the problem is you cannot use your mouse to alter the mortar while in map mode. Answer map something like keys, or in my case my joystick to the Aim up,down,left,right controls so that while in map view I can fine tune the aim. I imagine that below 30 degree's the method of calculating the fall of shot would be very inacurate and subject to intervening objects as well, which is probably why the cursor disapears.

Incognito84 we've had a couple of Americans on our Australian server with no problems yet!

numpad 0 gives me and internal viewport view. Numpad enter toggles internal external view.

That is actually the correct way. During a fire mission the CP will state "Shot over" When the FO heres this he responds "Shot out" acknowledging he has heard the report of shot. Approx 10 seconds before calculated impact the CP will radio "Splash over" indicating the rounds will impact now. Why? the FO is an arty officer attached to an infantry unit. So instead of watching the impact zone waiting he is free to do other tasks. After he hears "Splash Over" he responds "Splash Out" to acknowledge he has heard the report of splash and can bring his bino's up to watch where the rounds fall so he can then call in adjustments etc. In artillery fire missions very strict radio procedures are followed, including reading back every aspect of a fire mission to ensure everything is correct. Why because you DON'T want to get it wrong!