SSG Plazmoid

so working on a blastwave effect for my SCRIPTS. I thought it might be nice to have objects randomly destroyed in an ever increasing radius out from ground zero. Using nearestobject I was able to find the next nearest tree or bush or road or whatever and setdammage 1 on it. I then used my fire script to place a small fire there. The odd thing I ran into was at some points OFP crashes to desktop with no error, it just closes. I narrowed the problem down to setting dammage 1 on the object. I'm not sure which object(s) don't want to be destroyed but there are some. Two questions, can anyone think of a better way to randomly choose objects to destroy not knowing ahead of time where ground zero will be. And second, does anyone know the object types of bushes, trees, road pieces, etc. so I can explicitly search for that nearestobject.

I generally use the mod method only because I 1st figured out how to make mod help me when reporting speed or distances from calculations. I found it irritating to see my speed reported as 192.123543635 or my position reported similarly. By using _result = _result - (_result mod 1) you will get the value rounded down to the next whole number.

sorry got the wrong forum but I had assumed there would be discussion of how the scipts had been modified and how the drop mushroom cloud is formed. Both of these are fairly advanced scripting and mission editing topics.

I added a few things to MF's creation for use on our server. Increased the maximum number of player slots to 30. Haven't been able to test with that number yet but I imagine the server will break at some point. If so will reduce the max squad size per player (except for the commander) Added motorcycles and buses (bus requires light fact upgrade) In an effort to stop the 3 hour games (as much as we enjoy them) since we're not supposed to tie up the server for more than an hour I thought it might be nice to add an expensive nuke for each side that once launched wins the game for the side that launched it. To keep it simple both sides just use the scud launcher. While it's possible to simulate a nuclear A10 LGB I didn't want the west team to see their $75,000 crash on take off or have someone nuke something that shouldn't be nuked (like his own base). Added Scud launcher which requires heavy fact upgrade and nuke upgrade. Once launched, the game goes to a cutscene of a beautiful mushroom cloud which has the enemy commander as ground zero. No addon is used for the explosion or mushroom and it really does look nice. Just using bunches of drop loops to generate the mushroom column and top. I'm still tweaking the initial blast so any suggestions would be appreciated. Also, added a test that watches for when one team holds all the towns at which point the game is won. (Haven't tested this one yet though). Also, added a loop that sets flagowner to objNull for each flag in case someone inadvertantly "takes" the flag from the pole. If the server isn't very populated we prefer to play the original. But if there is a demand for the map to end in a reasonable amount of time we'll use the modified version to help one side win more quickly. See links below to download to try em out. I host files on my wife's business site so don't wander off outside the ofp folder unless you want to see some homes for sale lol. regards, SSG Plazmoid Version for testing with nukes set to free cost: http://www.soldbuysam.com/ofp/CTI_30_1_10b_SHoP_source.zip http://www.soldbuysam.com/ofp/CTI_30_1_10b_SHoP_map.zip Version for play/test with nukes set to normal cost: http://www.soldbuysam.com/ofp/CTI_30_1_11b_SHoP_source.zip http://www.soldbuysam.com/ofp/CTI_30_1_11b_SHoP_map.zip

bn880 - are you saying if I want to spawn vehicles on the fly (or respawn) in multiplayer and have known vehicle names I should initialize the empty names I want to use at mission start? Does this get around the problem of not knowing what the vehicle name will be after creation? thanks, Plaz

is there a place to see all of the various actions available to order units or groups?

Generally I share a tank only with people I know and people that are in the same group as me and on the same teamspeak channel with me. If the commander isn't in the same group as the gunner, the gunner will hear the commander calling targets but I don't think he will get a target box. Playing primarily on the SHoP server on tank maps Thief and I generally tear up most competitors with him driving and me gunning. If you ever see Thief on your server you should consider him to be your tank driver and me as your gunner

woohoo, thank you very much for your reply. Here's the latest version that I'm testing. Have tested with one enemy to the group so far. Will try a group vs them and see what happens. The script does the following: mounts an AI group in a truck. the zeroeth element of the group is selected to drive. at no point do I refer to the leader of the group, instead I always refer to (units _group select 0) to get the first element of the group no matter how many have died. the AI group has some move waypoints and a cycle waypoint that describes their patrol route. there's 2 triggers repeatedly looking for enemy detected by resistance (one for west units and other for east units). the script compares the detectedenemy list with which enemies the group knows about. If any element of the group knowsabout a target with a value of 1 or greater the group goes into assault mode. if the target is over 200m away the group drives toward the target to get within 100m. if the group isn't mounted in their truck they first mount up (if the truck is drivable). if the target is under 200m all elements of the group get the order to move to the last known position of the target and to fire on the target. The group behaviour is set to "COMBAT" when in assault mode the group checks how much it knowsabout the target every 15 seconds. If the knowsabout value falls below 1 or if the target is dead the group breaks off attack and scans for more targets. if no more targets are found in the detectedenemy list that the group knowsabout (with value greater than 1) the group returns to their vehicle (if driveable) and continues on their patrol. the script exits if no elements of the group are alive. -------------------------------------------------------- ;called by AI group leader in init ;[groupname, vehiclename] exec "ResPatrol.sqs" _group = _this select 0 _truck = _this select 1 #start ?(!canmove _truck || !alive _truck):goto "top" _myunits = units _group {_x assignascargo _truck} foreach _myunits (units _group select 0) assignasdriver _truck _mounted = true #top _detectedlist = resdetect_east + resdetect_west ?(count _detectedlist > 0)&&(({(units _group select 0) knowsabout _x >= 1} count (_detectedlist) > 0)):goto "scan" ~5 ?(count units _group == 0):exit goto "top" #scan _group setbehaviour "SAFE" _mytotal = count _detectedlist ?(_mytotal == 0)&&(_mounted):goto "top" ?(_mytotal == 0)&&(!_mounted):goto "start" _mycount = 0 #loop1 _mytarget = _detectedlist select _mycount ?({(_x knowsabout _mytarget) >= 1} count (units _group) > 0):[_group,_mytarget] exec "main/new_KnowsAbout.sqs" ?(((units _group select 0) knowsabout _mytarget) >= 1)&&((units _group select 0) distance _mytarget > 200)&&(canmove _truck)&&(alive _truck):goto "mounted_assault" #loop2 ?(((units _group select 0) knowsabout _mytarget) >= 1)&&_mounted:goto "dismount" ?(((units _group select 0) knowsabout _mytarget) >= 1)&&!(_mounted):goto "attack" _mycount = _mycount + 1 ?(_mycount < _mytotal):goto "loop1" ~3 ?(!_mounted):goto "start" goto "top" #mounted_assault (units _group select 0) domove getpos _mytarget @((units _group select 0) distance _mytarget < 100) goto "loop2" #dismount _myunits = units _group dostop (driver truck0) @speed truck0 == 0 (driver _truck) action ["EJECT",_truck] {_x action ["EJECT",truck0]} foreach _myunits {unassignvehicle _x} foreach (units _group) _mounted = false #attack _group setbehaviour "COMBAT" {_x domove getpos _mytarget} foreach (units _group) ~5 {_x dofire _mytarget} foreach _myunits #update ~15 ?(count units _group == 0):exit ?(!alive _mytarget):deletevehicle _mytarget; goto "scan" ?((units _group select 0) knowsabout _mytarget < 1):goto "scan" (units _group select 0) domove getpos _mytarget goto "update"

I'm interested in making smarter AI. I wanted a simple way to have AI patrol between towns driving a truck but to stop and engage enemy they see along the way. One method was to have all the waypoints I need to make this happen (get in, get out, seek and destroy, move, cycle) and to synchronize to which ever waypoint I needed and move the waypoint using setWPPos to bring the waypoint to the leader. It worked sort of they seemed to give up too easily on finding the contact that caused them to stop in the first place. So the other method was to have two waypoints, move and cycle at either end of the patrol route. At mission start the leader's init field calls a script that assigns the group to the truck, moves them into the truck, and then waits for knowsabout to be greater than zero. At which point the truck stops, the group gets out, are ordered to attack the contact, and after some period of time they get back in the truck and continue on their way. Two problems with this strategy. First, knowsabout (as I understand it) requires that I check each potential target if they knowabout it. Second, even after killing the contact knowsabout does not immediately drop to zero. Is there a way to access every target an AI knows and then check the knowsabout value for each of those? And is there a way to help them forget more quickly after the contact is dead. thanks, Plaz --------------------------------------------------- _group = _this select 0 #start _myunits = units _group (units _group select 0) moveindriver truck0 {_x moveincargo truck0} foreach _myunits @"_x knowsabout bob > 0" count (units _group) > 0 _myunits = units _group dostop (driver truck0) @speed truck0 == 0 {_x action ["EJECT",truck0]} foreach _myunits _group setbehaviour "COMBAT" {_x dofire bob} foreach _myunits ~20 ?(count units _group == 0):exit goto "start"

to eject the entire group at once without listing each member you could do this: {_x action ["EJECT",choppername]} foreach (units blackopgroup) this way later in the mission if blackopdude3 is dead it doesn't matter because you're not listing the group elements specifically.

to turn the lights off on a vehicle (other than manned M2) setbehaviour to stealth

Thought it would be cool to see smoke and fire tralling from damaged aircraft. Like most of what goes on in multiplayer it's not as simple as you first think. As each client needs to draw the smoke each client needs to know what the vehicle object name is, that objects position, etc. Also, vehicle respawn is handled server side only to avoid multiple respawns so how would clients run a script called only by server? So, using Tact's suggestion to my other question of how to do things with respawned vehicles I've gotten smoke working. Need to test it on a dedicated server but I think I've done the scripts in a way that they'll work on dedicated server correctly. First, we need to know all of the vehicles that we'll want smoke added to. For each one you'll need a global variable that is associated with that vehicle in some way Let's say you add 3 choppers to your map - your variable names need to be different than the object names to keep things from getting confusing. on your map you have these named units: chopper1 - in init: [this,"chopper1"] exec "vrs.sqs" chopper2 chopper3 in init.sqs you could have: mychop1 = chopper1 mychop2 = chopper2 mychop3 = chopper3 in vehicle respawn vrs.sqs in addition to reading in the object you need to also read in the other paremter we passed which was a text name of the object name. after the vehicle has been created a call is made to "smoke_master.sqs": </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">[_vcl,_vehicle] exec "smoke_master.sqs"<span id='postcolor'> where _vcl is the vehicle object that was just respawned using _vcl = _type createvehicle [_respawn_xpos,_respawn_ypos,0] and _vehicle is the text name of the original object name. in smoke_master.sqs we need to reassociate the object name back with the text name: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">_vcl = _this select 0 _vehicle = _this select 1 ?(_vehicle == "chopper1"): mychop1 = _vcl ?(_vehicle == "chopper2"): mychop2 = _vcl ?(_vehicle == "chopper3"): mychop3 = _vcl<span id='postcolor'> and now we can track that respawned vehicle by using one of our known object names (mychop1, mychop2, mychop3, etc) regardless of being respawned because each time it is respawned the new _vcl object is reassociated with our known object names. Anyhow next trick is for all the clients to watch for some different things like damage. Each client needs a script so we call "smoke_client.sqs" from init (with no parameters). In smoke_client.sqs we have a loop that looks for values to be true or false for each vehicle and if conditions are met to do something. For smoking damaged vehicles each vehicle needs to meet the following conditions: vehicle is damaged more than some amount you specify (I used .5) vehicle is in the air (for aircraft) vehicle is not going backwards (for choppers) to keep smoke out of pilots view smoke isn't already turned on for this vehicle otherwise we would keep launching smoke scripts. </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">#start ~1 ?(getdammage mychop1 >= .5)&&(getpos mychop1 select 2 > 10)&&!(mychop1_smoke):[mychop1] exec "smoke_damage.sqs"<span id='postcolor'> once "smoke_damage.sqs" is called we have to set the smoke variable to true for the appropriate vehicle (to keep smoke_client from launching more smoke scripts). Now we get to the actual drop stuff. For each vehicle type you'll want the smoke to be in a different position depending on the effect you are going for. I wanted it to look like it's coming from the engines so on the biplane the engine is forward of center, on a chopper it's rear and above center, etc. Also on the A10 and SU25 there are two engines so I did dual trails of smoke. next in same file we define the starting and ending color of the smoke or fire. then we loop very quickly drawing the smoke and fire over and over. In the loop we watch for some conditions to be true like if the vehicle has been destroyed or the altitude is below 1 (it landed) or in the case of choppers the speed is equal or less than zero. In any of those cases the script exits after returning the vehicle smoke variable to false so it can work again when conditions are met in smoke_client. Finally it's just a matter of playing with the drop command, your colors, and the offsets to get the look you want. For the fire I wanted little puffs of fire every now and then but not continuously. So in the loop I have a random variable and if it's above a certain value the fire gets drawn in addition to the smoke. For the dual engine aircraft I used a 2nd random variable to randomly select which engine the fire puff came from. It's hard to explain clearly how this all works but hopefully have given a good idea for you. I'll add another message soon with all the source code(s). Plaz

After a little more detailed testing I've discovered that my method of passing vehicle ID to the clients still isn't enough to wake the clients up. Using createvehicle I created 5 A10s. Using createunit I created 5 soldiers and assigned each soldier to an A10. Then I put the planes up in the air and gave them forward velocity. When I tested it locally it worked perfectly. When I tested on a dedicated server connecting as a remote client none of the AI moved into the planes and smoke wasn't visible from any of the planes. This is because I had used ?!(local server):exit in my vehicle creation script so that I didn't get a copy of an A10 per client executing the script. When I took out the local server check I got an extra set of planes. The extra set controlled and spawned by my client had smoke while the server created planes did not. So..... method #1 seems to be a failure. I will try to do vehicle respawn via the setdammage 0 method and avoid the whole business of passing newly created vehicles to the clients. Or, I might try vehiclerespawn via triggers that use createvehicle but this would require a trigger per vehicle. If anyone can get a client side script to operate using a server side created vehicle please let me know how you got it to work.

had been using sin (2 * _elevate) but an engineer friend of mine brought over a physics book and for balistic motion the formula given used (cos _elevate) * (sin _elevate) at 45 degrees the two formulas are the same. however as we move farther away from 45 degrees the sin and cos of the angle diverge so in angles approaching 0 and 90 degrees the result from the two formulas will differ. I haven't tested with any other angles but 45. As for shell timeout I think my next experiment will be to recreate the shell at the top of the parabola halfway along it's journey to double the range (as someone suggested earlier in this thread). Also was considering moving a game object along with the shell and attaching a local sound to it. Can you do this with game objects or the sounds are actually on triggers? Haven't played with it much but I think this is a way to get a nice sound going over as the shell passes.

the killed event will work for dead stuff where I want the custom fire and smoke to burn for a fixed time. the idea for smoking aircraft though is to begin showing the smoke only after the aircraft is damaged to a certain extent. However it happens I just need to get the new object ID of a respawned vehicle out to the clients before or after damage reaches some threshhold.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Koolkid101 @ Jan. 10 2003,23:19)</td></tr><tr><td id="QUOTE">If i download this so it shows smoke will it mess up my multiplayer?<span id='postcolor'> Are you asking if you download this smoke will it add something that messes up multiplayer? The answer is no. This isn't an addon just a little more complex use of the drop command that BIS built into the OFP engine. So everything that is needed to see the smoke and fire is already in your game - no addon needed. I just have used the built in commands to help clients see the smoke in multiplayer games. Map editors would need to add these scripts to their maps though. You won't see fire/smoke in other maps unless the author has put in these type of scripts. Doolittle - the hit and killed events will register on the local machine only but all other events will be executed on all of the clients? I think I read it that way. So looking at my handy list of eventhandlers dammaged looks to be the only one that might help in this context. The dammaged eventhandler passes "how much". I wonder if this is the amount of dammage that just happened or the amount of dammage that the object currently has? Aha, I see though. Regardless of the amount of damage (total or just the last little bit) this event would trigger a script to run on all clients? And in that script I could then getdammage _vcl to wake up the smoke/fire/fuel scripts. I notice though that dammaged gets 2 parameters, string: selectionName and scalar: howmuch. What is selectionName? Also did a search and saw Keg's post where he got dammaged to trigger when he shot soldiers legs out. So perhaps dammaged is related to !canmove? Will test. thanks, Plaz

I played around with different values for muzzle velocity at increasing distances with the gun angled up at 45 degrees. In the formula: _muzzle = sqrt (4.9 * _deviate * _distance / ((sin _elevated) * (cos _elevated))) where _elevated = 45 degrees gun angle up the columns (shown below the formulas) are the _deviate value on the left and it's associated range on the right. For example, for a target at 250m the _muzzle velocity formula would be: _muzzle = sqrt (4.9 * .75 * 250 / ((sin 45) * (cos 45))) which = 47.87m/s and should hit your target dead center. for a target at 2000m the _muzzle velocity = _muzzle = sqrt (4.9 * 2 * 2000 / ((sin 45) * (cos 45))) which = 197.99 0.75 Â Â 250 0.76 Â Â 375 0.8 Â Â 500 0.855 Â Â 625 0.925 Â Â 750 0.99 Â Â 875 1.05 Â Â 1000 1.11 Â Â 1125 1.18 Â Â 1250 1.25 Â Â 1375 1.33 Â Â 1500 1.415 Â Â 1625 1.51 Â Â 1750 1.61 Â Â 1875 1.6675 Â Â 1937.5 2 Â Â 2000 I've plotted the values and there is a curve but it flattens in the center (750m-1500m) and then angles sharply up as you near 2000m. The shells either timed out at ranges beyond 2000m or they disappeared for some other reason. I'll work on the altitude above sea level example dinger offered.

Here's the scripts and a demo mission. In the demo just hit radio charlie (0 0 3) which will put some damaged planes in the air flown by AI so you can see the smoke trails and fire. http://www.soldbuysam.com/ofp/drop/smoke_stuff.zip I've added a few things since my first post. Damaged aircraft lose fuel continuously until they run out. You can set the amount of time it takes for fuel to go to zero, I think I used 60 seconds. dual engine aircraft like the A10 and SU25 make dual smoke trails. There are two sets of smoke scripts. One set for destroyed vehicles that makes a fire and smoke where the vehicle was destroyed. Another set that attaches smoke to flying aircraft. The destroyed scripts all start with "destroyed_" and the smoking aircraft scripts start with "smoke_". The main difference between them is the smoking aircraft script gets a vehicle object passed to it and the destroyed vehicle script gets a 2 dimensional position passed to it. The other difference is the destroyed smoke/fire lasts for an amount of time you specify while the aircraft smoke lasts as long as the aircraft is flying or alive. *note: I use x and y for horizontal and z for vetical. For the destroyed smoke/fire I make use of the elapsed time to gradually phase out the smoke and fire rather than seeing a visible line flow up when the smoke stops. As time progresses the fire gets smaller and smaller with the particles lasting a shorter amount of time and the transparency going toward zero. Added a cpubenchmark check in the "smoke_client.sqs" and "destroyed_client.sqs" files. This will force the client script to exit if the cpubenchmark is below some number (I think I used 1500). IF YOU DON'T SEE SMOKE CHECK YOUR CPUBENCHMARK and change the value in those two scripts to something lower than your benchmark. Please let me know what benchmarks can handle the smoke scripts - would be handy to know. Mine is 3800. You may be wondering why is there a server script and client script and actual smoke script? The trouble is how to pass the ID of a respawned vehicle to all the clients since you don't know beforehand what the object ID will be. The trick I made use of is to have the server start a server side script whenever a vehicle is respawned. The server script then waits for @(getdammage _vcl > .5) in the case of the smoking aircraft. The server script for destroyed vehicles waits for @(!alive). If the destroyed condition is true the server script does the following: mydestroyed = mydestroyed + [_vcl]; publicvariable mydestroyed. If the damaged condition is true the server similary does the following: mydamaged = mydamaged + [getpos _vcl select 0, getpos _vcl select 1] and makes the variable public. Meanwhile there's the destroyed and damaged client scripts that are waiting for the count on mydamaged or mydestroyed to be > 0. Once the count is 1 or more the appropriate script springs into action and creates smoke/fire. If anyone has a suggestion how I can improve anything or speed anything up please let me know! Also included in the zip I think is an arty.sqs script which has some experimental formulas for artillery given start and end coordinates. regards, Plaz

couple of ideas. you could setpos him every few cycles so he stays put where you want him. Or is there a way to have a have a unit use his binos. Sorry I don't know the script command to do that but I imagine there is one.

In order for crew to respawn into the vehicle after it's been respawned you just need to do your moveindriver, moveingunner,etc commands right after the vehicle is created and turned to it's correct direction. I would copy the vrespawn.sqs script and make a special one for crewed vehicle respawn. When you specify vrespawn.sqs in the init field of the vehicle when it's first placed in the editor (or the 1st time via script) you would pass the unit IDs of the units that will be moved into the vehicle. So, instead of [this] exec "vrespawn.sqs" for an m1a1 tank for example you might have [this,driver,gunner,commander] exec "vrespawn2.sqs" where driver, gunner, and commander are the unit names of the units you want crewing the tank. Then in vrespawn2.sqs: _vcl = _this select 0 _driver = _this select 1 _gunner = _this select 2 _commander = _this select 3 right after the vehicle is respawned just move the 3 units into their respective positions: _driver moveindriver _vcl _gunner moveingunner _vcl _commander moveincommander _vcl Something like that should do the trick

something that is kind of related to camcreated explosions client/server is the use of drop. Is drop client side only? If it is. it would be very helpful to have a drop2 that creates particles which exist on all clients or another object type instead of "cl_basic" have "cl_mpbasic" like there were different kinds of objects camcreated some which were client only and some transmitted to all clients (like the explosions). Currently to do smoke on clients I have to track damage to vehicles for example on the server and then make the value public after some threshhold. Meanwhile I have to have a script on each client waiting for that value and then they can execute their drop scripts.

I'm trying the trick of using triggers or markers to get height above sealevel. However I'm either doing it wrong or it's not giving me what I expected. suggestion 1) place a marker on the map where you want to see elevation above see level. Move marker out to sealevel "marker_name" setmarkerpos [0,0] height above sealevel is getmarkerpos "marker_name" select 2? Gives some random negative number close to -1.5 (maybe it changes every time I do it cause the sealevel is raising/lowering?). suggestion 2) place a named trigger on the map. Using trigger_name setpos [getpos object select 0, getpos object select 1, 100] should put the trigger 100m ASL so you could see the difference at that point between ASL and AGL. However it just puts it AGL :/ I looked in elevation.sqf for coc_mines: _elevation = (acos (_range/_distance))*((({COCMinesWidget distance _subject > _distance} count [0])*2)-1); I don't understand some of the syntax of the forumula (the 2nd part). Anyhow, suggestions or personal results from trying either of the methods would be helpful. thanks, Plaz

the only solution I've found is to do something with the variable right after the vehicle is created. When we create a vehicle using: _vcl = _type createvehicle getpos _pos we know the object ID of the newly created vehicle because it's equal to _vcl. However, only the server knows this. And if we are doing vehicle respawn correctly we're allowing only the server to execute the vehicle respawn script. So, how to get the ID of the newly created vehicle to all the clients? One method that works (but sucks) is to have a publicvariable for every single vehicle and load your new value of _vcl into that variable right after the createvehicle command and then make that variable public so all the clients get the new value. The drawback of this method is you need a variable for every vehicle which seems messy. So here's a question. Let's say we do something like this: _vcl = _this select 0 _type = _this select 1 _position = getpos _vcl _direction = getdir _vcl #start @(! canmove _vcl) ?!(local server):goto "skip" deletevehicle _vcl _vcl = _type createvehicle _pos _vcl setdir _direction #skip now here is the question of whether this works or not. If I skip to this point in the clients will they know what _vcl equals? I don't think they will... So, how do we get that value to the clients if not by way of a publicvariable for each vehicle?

hehe ah well, it was fun working through the math anyhow. As for drag we just need to figure out what the coefficient of drag they are using is and then compensate with our muzzle velocity? It should be possible to compare the difference between expected and actual impact. The difference will be larger as distance increases so we can multiply by some compensation in the muzzle formula so we would have 9.8 * _dist * something that increases with distance?

- UPDATE - Well, I decided to go out and enjoy some time away from the computer but I kept this problem in the back of my mind. Had an idea on the way home and gave it a try just now. To scale the values of x and y so that a ratio that atan can handle is calculated I just needed to make use of pi/2 and -pi/2. So, here are the formulas for horizontal direction/offset with the result in degrees. This will give the direction your gun needs to face to hit a target anywhere on the map. _x0 = getpos _gun select 0 _y0 = getpos _gun select 1 _x1 = getpos _target select 0 _y1 = getpos _target select 1 _xx = (_x1 - _x0) _yy = (_y1 - _y0) _xx1 = pi/(2 * _xx) _yy1 = pi/(2 * _yy) ?(_xx1 > 0 && _yy1 > 0):_offset1 = atan(_yy1/_xx1) ?(_xx1 > 0 && _yy1 < 0):_offset1 = (atan(_yy1/_xx1)) + 180 ?(_xx1 < 0 && _yy1 > 0):_offset1 = (atan(_yy1/_xx1)) + 360 ?(_xx1 < 0 && _yy1 < 0):_offset1 = (atan(_yy1/_xx1)) + 180 I created a loop in a script and drove around in a tank in a circle from my "gun" and verified the values atan was giving. When I crossed a 90 degree boundary (90,180, 270,360) I watched the values that atan was creating and adjusted them accordingly so that I finally got a smooth transition around the circle from 0 - 360. The only other thing that's needed is to account for when _xx1 = 0. If _yy1 > 0 and _xx1 = 0 we know it 0 degrees and if _yy1 < 0 and _xx1 = 0 we know it's 180 degrees. In my travels looking for answers to this question I came across some cool sites that might be of interest to some of you. http://hyperphysics.phy-astr.gsu.edu/hbase/ttrig.html http://www.technion.ac.il/~orenh/proweb/ The 2nd one mentions some forces acting on an artillery shell that I didn't remember and some I didn't know. Drag people have been talking about here but I hadn't considered lift and wonder if it's modeled. Also gravity is generally expressed as 9.8 m/s^2 but it's actually closer to 9.78. Unsure with the distances possible on the island if either of these will affect the flight of the shells. - END UPDATE - I'm trying to work through the formulas and the method of getting the horizontal offset angle (direction) is giving me fits. the formulas is arctan (y/x) where y = y1 - y0 Â and x = x1 - x0 (the start/end vector components). however this formula expects values of -pi/2 <= y/x >= pi/2 (or -1,1 are close enough) and in our usage this will only be true on the 4 diagonals (45 degrees, 135, etc). As the direction deviates from those diagonals the result of the formula is more and more wrong with the result blowing up to 360 as you approach multiples of 90 degrees. the solution is to somehow scale the ratio down to be <=1 or >= -1. but I'm not sure how. the angle will stay the same if the x and y legs are scaled down right? I understand that you need to add 180 or 360 to the resulting angle depending on which quadrant the angle is in (0:90 = quadrant I, 270:360 = quadrant II, 180:270 = quadrant III, 90:180 = quadrant 4). If angle theta is in quadrants II or III you add 180 to the result. If theta is in quadrant 4 you add 360 to the result. Anyhow, I'm not sure how to feed values I want to the arctangent function that will give real results. I know my ratio needs to be between -1 and 1. So if y = y1 - y0 = 10000 and x = x1 - x0 = 5 how do I scale them to fit atan? thanks, Plaz