Quantum

what about the limitSpeed <speed> command?

Think of it this way. The description.ext entries for dialogs (and the dialogs controls, backgrounds and objects) are just templates, they don't exist until a dialog is instantiated. For those who aren't sure what I mean, I'll make it a little more plain: A dialog definition in description.ext says what pieces are part of the dialog, what types of controls and the various attributes each control will have. That's it. The dialog doesn't exist or become valid until it's created using createDialog "<dialogname>". The same way a tank is described in the config file but doesn't exist until it's dropped in the editor or created on the fly with createVehicle. You can't have guys get into a tank definition, but you can once a particular type of tank has been created. Same thing. Also: if you look at the 3rd letter of IDD and IDC it tells you what "type" of ID it is, ID"D" is a dialog ID and ID"C" is a control ID. If I understood your last question about what the IDx is; yes, the IDC is the reference number for the control. Hope that helps someone.

a "patch" eh? thank god for diff

nope, that's the monster I'm dissecting at the moment.

are you using their "latest and greatest" 2006 ffur?

mis-post, please delete

mis-post, please delete

Does the flashpoint.rpt say anything specific? As for "turning off" the animations, ouch. they are defined in the config file. No easy way to do that. As to "work-around", only way is to not use the mod, sorry. They incorporated quite a few new animations and pulling them out of the config entirely so you just used the standard OFP ones is possible, but since it's not simply copy/paste the animation section only I'm not sure how far you're willing to go. If any soldier/vehicle references the animation definition(s) then you'd be looking at a very unpleasant time indeed. Is there any particular point that it always happens? Is it repeatable to the extent that a certain mission does it? "always crashes" is kind of ambiguous.

Ok, nice compilation of mods and well done on getting it all organized. Kudos for the hard work. but... At what point did you decide the RPG or even the M136AT4 (LAW replacement) did more damage than say, TANK ROUNDS?! Â 550 dmg for an RPG; FFUR_Sabot120......dmg=380 FFUR_Staff120........dmg=125 FFUR_Apam....(this round is messed up, you have dmg=10 but only 1 round is fired, no Burst= setting. If you're doing this via script I'd like to know where you're catching it, because the vehicle M1Abrams doesn't have a Fired event handler installed that does anything but the tracer effect and the light show) FFUR_Mpat.... [no entry, which is jacked because the vehicle M1Abrams entry has it listed as a magazine.] I added this round into the 'class CfgAmmo' section. Unless it was your intention that the M1A-series not fire any HEAT rounds, which would be odd. Back to the issue at hand. Why did you make man-portable AT rounds' damage values so high? In this same vein, I noticed under headings like "FFUR real-world values" you have all kinds of numbers, and a whole lot missing. I'll elucidate: Almost every rifle you had inherit from Riffle, except for the odd russian weapon here and there. No initspeed= values for almost all of them. After spending about 6 hours surfing I found all but a couple of the muzzle velocity values, and those I couldn't find were for some of the more esoteric rounds you have in the config file. You have every russian round I compared doing 10+% more damage than their U.S. counterpart round. With a russian value of 10 on some and the U.S./NATO round doing 7, that's a 30% bonus to the russian round. You have the 5.45 doing significantly more damage than the 5.56, which general research regarding gelatin testing and pig-shooting proved to be false. The 5.45 has a very low probability of fragmenting at any range whereas the 5.56 has a very good chance of generating 3 fragments on impact. [ballistics and wound assessment testing]. The russian 5.45 was found to tumble, as does the 5.56, but the 5.45 wound stretching was found to be negligible in comparison to the 5.56. Range was a factor for the 5.56 round, but results still proved the 5.45 to be significantly less lethal unless it struck the heart or liver (the liver being less resilient and therefore more prone to ripping when stretched), and it did shatter on impact with bone. This is only one such example of misrepresented values. You have U.S. weapons firing russian ammunition. You have both russian and U.S. weapons firing the wrong calibre rounds. (which goes to the previous point). You have russian silenced ammunition doing significantly more damage than U.S./NATO non-SD ammo. I'm not sure what you mean in the config when you comment block out a section and say it's supposed to be real-world values when I can find no normalization to any of the values. If you picked a round, say the 7.62 x 51 mm NATO, and made it do dmg=10 then based the other values around that, that would have at least made some sense. You tout the FFUR as a realism mod and yet there are huge discrepancies and no baseline values. As I said at first, good work on bringing all these mods together and making it functional. But please, until you've actually spent some serious time making adjustments and researching available real-world data, don't put "realism" anywhere in your FFUR adds/posts, it's not right. Many others have spent inordinate amounts of time researching and attempting to implement values that give the OFP engine reactions in-game that mimic as best they can the real-world. You're complete disregard by making the same claim is disrespectful. Your first line; "New realistic Game play Aspect enhancements. (Ammunitions, AI, loadouts..etc)" Normalize the values, double-check weapon/ammo usage, don't presume or enforce the idea that russian material sets the standard; de-facto or otherwise. I've spent the last two days going through your config and after finding these issues I was just aggrevated. Don't piss on the works of those mods you pulled into this compilation. You seemed to have just thrown them in, in some places. So overall; 9/10 for getting it all together, still some pieces missing but I can do that myself. 1/10 for research and implementation of data 0/10 for claiming realistic values when they're not. [btw: a couple of the m/s values you have, exceed the threshold where the metal used in the actual round would vaporize when fired] (ok, maybe not that bad, but very damn close) And no, not trying to be a complete ass about it, but I know the authors of some of those works you used spent a hell of a lot more time making the single mod you pulled then you spent on the compilation as a whole. Bad form FFUR, bad form. The convoluted nature of your events for TANK is surely adding unneeded overhead: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class EventHandlers { Â Â Â Â Â Â Â Â Â Â Â Â init="_this exec ""\ffur_effects\tank.sqs"""; Â Â Â Â Â Â Â Â Â Â Â Â fired="_this call loadFile {\ffur_effects\tracer\firedEH.sqf};"; killed="_this exec ""\ffur_effects\tank\boom.sqs"""; }; I'm going to optimize this for myself but you might want to look at just how loopy these events are being handled. You have a lot of "drop" calls taking place but you have them spread out over a lot of different scripts, consolidate these down to a single call and streamline what you're trying to do. I know you pulled these in from earlier works but come on guys, copy/paste just means unnecessary calls and can lead to the dreaded flashpoint.rpt entry.

Thank you. Â That clears 2 questions off the books.

All BIS missions have the following: any mission.sqm;   briefingName="@STRCNO_xx"; (typ. xx corresponds to numeric prefix of mission, i.e. 01Invasion.noe.  This is used in the campaign level mission.sqm/stringtable.csv files.  Along with this, the briefing.html has a title tag but the text that appears on your mission book in game is determined by mission.sqm:briefingName.  Does <title>?</title> have any impact? q: I haven't found a tutorial or reference that states what the @ does as opposed to the $ when referencing strings in stringtable.csv.  Are there any other prefixes that have special use? assumption: The @ is only used in mission.sqm as a replacement for $ ($ being used in everything else) because of the way mission.sqm files are parsed. a: ? entries in stringtable.csv;   $STRn_?.....   (n being D,M... (?... prefixed D,M... (?... also contains  v,r... q:Many tutorials that seem to cover the various sound entries don't address what the 'n' part means, nor do they go into the rest of the $STRn_?..... reference.  Some say you can name it anything as long as the entry matches a stringtable.csv line.  BIS seems to jump from n=D to n=M in it's cfgSounds, as well as changing the ([v,r] in [?.....]) section. Is the format BIS uses required? Does it ultimately have any effect on the parser/game depending on format used? assumption: BIS' parser doesn't care as long as the entries match up with stringtable.csv.  The lines they use; $STRD_D02v01 $STRD_M02v01 $STRCNO_01 ...  are all a matter of convention and their format is not required.  02 in the first example came from mission 02....., anv v01 is the first cfgSounds entry (v=voice? , r=radio?). $STRD_ (<-D = ?) $STRD_D (<-D = ?) $STRD_M (<-M = mission?) $STRC (<-C = campaign?) a: ? None of the tutorials have addressed this continuity in BIS' design, or that there may be some benefit (beyond it's uniformity) in adhering to it.  As an aspiring mission builder I'm reading everything I can find that doesn't have 'holes' in it, i.e. "Your cfgSounds entry must/must not have a name="" entry, but we don't know what the third parameter is..." and so on. I stay away from those.  There are a few that filled in the gaps but again, the naming convention is ambiguous at best. Campaigns: BIS seems to name their cutscenes xnn?............ In the game, when selecting a campaign, some are <cutscene>, does the prefix x do this? Continuing this thought, does the actual mission name have to be prefixed with x "x01FacetoFace.Noe".  The description.ext for the campaign has a 'class name' reference and the 'template' reference. Do both have to be x-prefixed to get the campaign entry <cutscene>? <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class xMeeting: MissionDefault {   noAward=true;   end1 = Crossroad;   end2 = Crossroad;   end3 = Crossroad;   end4 = Crossroad;   end5 = Crossroad;   end6 = Crossroad;   lost = Crossroad;   template = x02Meeting.Noe; }; -- (campaign level) -- cfgSounds Can a mission call sounds defined in this description.ext? Apparently so, BIS does it.  Are there any special setup instructions for this procedure? description.ext:cfgIdentities BIS defines them in campaign level, then in a mission level mission.sqm you see; init= xx = this loadIdentity ""02IC3"""; I've found no tutorial that touchs this question, at what point did cfgIndentity "Viktor" become "02IC3" ?  A search for loadIdentity, saveIdentity, load/save for campaign variables wasn't helpful.  This usage seems to be integral to BIS' campaign missions but no info for the masses.  I'm just getting into the gamut of campaign creation and this functionality, a single global cfgIndentity collection, should be used extensively in every campaign, it's the "how the hell?.." part that's the question. I hoped to find some of the more astute campaign/mission builders in the forums.  Please don't answer "I'm not sure", that defeats the purpose of the forum. (yes, I've gotten that response).  I'd just like to keep the topic, well, on topic. The gist of this being, if BIS did it this way, are there undocumented benefits?  What are BIS' conventions?  Is the approach taken by other campaign developers compliant or did they find a more effective and efficient way? (<- this I doubt, OFP:R far exceeds any other FPS in quality, quantity, extensibility, replayability and damnit! It's the cat's ass!) Sorry, I digressed or regressed, whatever your perspective. I appreciate any construction explanations and solutions about these posers.  If there is any other information about campaign creation that you have found by trial/error that is undocumented please feel free to enlighten me and the forum at large. And yes, I'm superflous by nature.  Also nocturnal, diurnal by force. Thank you for any and all help in advance. I will tell you the theme of my campaign if you ask, otherwise we'll just take it as my first attempt. That should do it for now.  I tried to be sure these questions weren't explained elsewhere.  You'd be amazed how many non-related results you get with a search for "cfgSounds" Thank you and have a pleasant tomorrow. [bottom spacer] If a hamster weighs 2 pounds and a cat could throw a discus, how many ducks could afford to buy a Lamborghini?

Found this thread in a search. Did everyone bail on getting together better documentation on making and using Dialogs? I'm just now getting to this part of OFP modding and though Vecktobosons' tut is great, there seems to be a great deal more functionality that people were looking into. OFPECs' only Dialog resource is Vecktorbosons. Anyone know where to find more extensive docs? Thanks all

Here's the math part of it </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ; WatchHere ; Quantum ; pass in obj and 2 angles, the elevation and azimuth. ; tells the object to dowatch[x,y,z]. ; I use a hardcoded magnitude just for the sake of simplicity ; [object, azimuth, elevation] exec "scripts\info\watchhere.sqs" _obj = _this select 0 _az = _this select 1 _el = _this select 2 ?(_el > 90):_el = 90 _x = 1000 * (sin _az) * (cos _el) _y = 1000 * (cos _az) * (cos _el) _z = 1000 * (sin _el) _ox = getpos _obj select 0 _oy = getpos _obj select 1 _oz = getpos _obj select 2 _x = _ox + _x _y = _oy + _y _z = _oz + _z _obj dowatch [_x,_y,_z] exit <span id='postcolor'> You can embed the code into your script or just make this a script and call it with the params. If you have two guys facing two directions, say Ad and Bd (for Adirection and Bdirection), just figure out how fast you want them to turn to face the direction you want.  1) Ad = 320 Bd = 190, so guy A is looking ~NW and guy B is looking ~S.  You want them to face each other?  You need to know WHERE they are in relation to each other.  You can do this to find out the bearing angles: Do this _frompos  = getpos A _topos = getpos B then do this code </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ; break down the position arrays _srcx = _frompos select 0 _srcy = _frompos select 1 _tgtx = _topos select 0 _tgty = _topos select 1 ; some good ol fashion math _diffx = _tgtx - _srcx _diffy = _tgty - _srcy _xsqrd = _diffx ^ 2 _ysqrd = _diffy ^ 2 _RangeToTarget = sqrt(_xsqrd+_ysqrd) ; determine the angle to target as THETA ; THETA = arctan(x/y) for direction _Theta = 360 + (_diffx atan2 _diffy) <span id='postcolor'> _Theta = the angle from source position to target position, in your case, take guy A first as source and guy B as target to get the bearing angle from A to B.  Use B as source and A as target to get the bearing angle from B to A. Say guy B is at an angle of 120 degrees from A's position.  You want A to turn and face B.  Since in your example you said Ad = 320, you know you need to turn either left 200 degrees or right 160 degrees (320 + 160 = 480 degrees, subtract out 360 since you passed 0 degrees, leaving 120 degrees to the right of 0 degrees).  You can feed in 480 degrees, but I generally clip the range to 0-359 for display purposes. Ok, say you now want A to turn left those 200 degrees to face B.  Set up your loop to decrement 320 till it hits 120.  The amount you choose and the delay you use will determine how fast A turns to face B. Feed the new value (originalAngle - decrement) to the code at the top and A will turn to face that direction.  You only have to calculate the bearing angle once, then increment/decrement the value to reach the desired final angle. If you think this is confusing let me know. Quantum

Just curious, but how does one 'compile' the weapon.cpp? It's interpreted, isn't it? Quantum

After scouring this forum and others, I have not found any definitive works on all the functionality of these items. Â There are those who have touched on some of the collection, like "Guard" waypoints and Activation types/styles/methods for triggers. Â I'm talking about the nitty and the gritty, the kind of breakdown that allowed BIS to build their missions. Â The exact specs on these editor components. I've tried to follow the logic chain of their triggers/waypoints/logic groups/synchronizations, to very little avail. Â Some of you have posted some very good implementations of some of these items. Â Unfortunately I have also read that a great deal of what people are conveying are suppositions based on cursory testing. Â Though helpful, without a solid description of what each setting for each of these items are, it's not readily obvious what can and cannot be done in a mission design. And so I finally decided, after reading a books worth of forum posts and digging through web sites (at 56K no less) to come to the crew to seek the answers. I need the BIS - OFP/R - Â Â Â Â Â HOLY GRAIL OF MISSION DESIGN Â Â A comprehensive description of everything in the mission editor. Â If a Trigger item has 14 settings, plus others that show up depending on how it might be placed (i.e. grouped, synchronized, etc), what do those settings do? Â How are they interrelated to the rest of the items? Â Can a trigger link a logic group to a waypoint that shows up only when the second member of an enemy tank platoon crosses a bridge and causes an A-10 squad to intercept the incoming BMP's? (<-exaggerated I realize, but now that I think about it...) Some of this fictional scenario is somewhat explained through various forum threads. But again, 70+% of those posts include the phrase(s) "AFAIK", "I think it...", "It might be...", "I'm not sure, but try...". These good-natured, well-intentioned people are trying to break apart a very complex set of components by trial and error. The permutations alone would give Einstein a headache. What we need is the manual. Not speculation, supposition, euphemisms or information gleaned from a telephone psychic. Has BIS ever released this information? Â Do they plan on enlightening us with all the esoteric functionality that could completely change the mission building landscape? Â Would their design team give the public the same information they themselves had access to so we can continue designing for OFP/R/GOTY in it's assumed final incarnation? Since they seem to be headed towards OFP2 with the last of the resources that produced the "LAST EVER" patch, would BIS be so kind as to give us the final, unabridged, unadulterated, unleashed, underdog documentation? Though it may seem a bit superfluous, my intention is for the benefit of the community, not an attack on anyone or BIS for that matter. Â It's disconcerting to spend 4 hours looking for the answer to a question that noone knows directly, it's all a guessing game. Â I just hope BIS will grant us the power to carry on the legacy of OFP/R while they pop smoke and head for OFP2 land. Hell, I'll send you my sister! Best regards, Quantum Better Living at the Sub-Atomic Level (My friends call me the Rambler sometimes, I don't know why)

I'd like to better understand the reason why some 1.85+ versions say put in standard addons (.\addons) and others say put in res\addons. If you put everthing in .\addons what harm/good does it do as opposed to res\addons? What is the difference and benefits? thanks Quantum

Moochose Grassyass Quantum I live in the state of confusion

Didn't know if the whole arty thing was said and done, but I went ahead and addressed an earlier comment in one of these messages about handling the TTL of 'shell' objects by recreating it downrange.  So here it is (hope it's not too big and forgive me for all the comments, I wrote this for my use but also to teach a friend): </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ; MidFlightRound  (commented out the wazoo) ; Quantum ; The purpose is to create a projectile somewhere ; along it's trajectory mitigating the TTL of 'shell' objects. ; *********************************************************************************** ; TRAJECTORY MATH AND SCRIPT APPROACH DEFINITIONS ; *********************************************************************************** ; Ideally, this script should be called right after the artillery unit performs the 'FIRE' ; action. That way you get the sound effect of the gun firing and then this script handles ; the round. ; The reason for this script is to address the TTL (time-to-live) issues with ammo types ; inherited from the 'shell' object.  Since an object of type 'shell' has a TTL = 20 secs, ; we need to recreate the shell anytime we know the time will exceed the TTL. ; Using addon artillery pieces is the definitive reason behind this script. ; ALL addons intended to be used as artillery suffer from this TTL restriction. ; Firing a 'shell' object at actual military velocities (such as initspeed=900 m/s) means ; the round would be off the map at an elevation as little as 5 degrees (henceforth just d). ; Such shallow trajectories are very rarely, if ever, used in actually battlefield deployments. ; The idea is to arc the round high enough to make the range required but also to come in ; at such an angle as to miss any obstructions between the artillery piece and the intended ; impact location.  In order to best represent this in OFP's engine we need to precalculate the ; actual trajectory values and determine if the round, at the defined initial velocities ; (the horizontal and vertical components), would exceed the TTL before the round is to impact. ; It's all about the math.  Since we don't need to be concerned with the actual artillery piece, ; we hand in the 'shell' type defined in the addons cpp file and do the math. ; For the enlightenment of the uninitiated I will put down the base math required and my approach. ; These are the standard trajectory formulas from any decent physics book. ; Vo = initspeed = desired muzzle velocity of the round you want to create (velocities in m/s) ; T = time in seconds ; g = gravity  (I presume to be 9.8m/s^2, though I've never read it in the forums) ; V(horizontal h) = Vo * sin(elevation)   V(vertical v) = Vo * cos(elevation) ; Hmax (maximum height reached) = (2 * Vv^2) / 2g ; Tof (Time of flight) = (2 * Vv) / g ; Vt (vertical velocity at time T) = Vv - (g * T) ; [now for the FUN formula, range.  this is gonna take a little space to make it look good] ;               2 * Vo^2 * sin (2 * elevation) ;    Range (R) =  --------------------------------- ;                        g ; H (height) = Vv * T - (0.5 * g * T^2) ; D (distance) = Vh * T  (no minus anything because gravity doesnt change horizontal velocity) ; So the order of business is to; ; ; A) Calculate Vy and use it to calculate the Tof ; If Tof>19s then just calculate the position on the trajectory at (Tof - 19s) and place ; the round there, give it the right velocity vectors and let it go. ; THIS is the best and still correct method. ;  If Tof<19 then don't do anything.  The reasoning is, this script is ; intended to be used in conjunction with the actual artillery piece.  If the artillery round ; fired by the actual artillery object has a Tof < 19 then let the artillery round do it's ; thing and don't worry about it. Otherwise, create the damn thing somewhere downrange. ; B) Use Tif (Time in flight) = (Tof - 19s), plug it into the first 2 formulas we need to ; solve for; ; D and H (so we know how far away and how high the round should be) ; C) Solve Vh anv Vv (so we know how fast the round should be travelling when it's created) ; Theta and Phi are commonly used as references to angles, I will adhere to this defacto standard. ; Theta will represent the direction angle (x,y) in the horizontal plane. ; Phi will represent the elevation ( adjacent segment [x,y], z) in the vertical plane. ; Theta will determine the [x,y] horizontal location on the map at range D from it's origin. ; position x = (sin(Theta) * D) + (starting point x = from position select 0) ; position y = (cos(Theta) * D) + (starting point y = from position select 1) ; position z = H + (starting point z = vertical offset) ; Phi is used in calculating the initial Vh and Vv, which are then used for the setvelocity vector. ; D) Delay creating the round downrange until Tif has expired. This makes the round arrive at the ; time it would have if the games Ttl were not an issue.  So artillery rounds still take time ; to reach their target and you still have a really good chance of hearing them buzz over your ; head (at least, I hope so. I wrote this intro before coding it as a guideline to myself). ; E) CamCreate[x,y,z] the round at the correct coordinates ; F) SetVelocity[x,y,z] with the right velocity vectors ; G) FINALLY!  let the game engine have it's way with our creation ; H) Shout profanity as you watch your round pummel the target. ; *********************************************************************************** ;  CODE STARTS HERE ; *********************************************************************************** ; frompos the x,y,z position where the round is created ; topos the x,y,z position where we want the round to land ; initvel the muzzle velocity of the round,  This should equal the addons intended initspeed ; so the downrange velocity vectors are correct.  When the round is created I give it ; the setvelocity vector based off of initvel, as it should be. ; elevation the muzzle elevation at source. (this is really fudge-factored, because the round is ; created near the artillery piece, not necessarily at the end of the muzzle) ; vertoffset the vertical offset where the round is created. ; round the type of object to create (something derived from 'shell' would be nice) ; timeoff the amount of time prior to impact you want to create the new round.  If 0, then the ; round is created at the impact point. Remember not to set this higher than 20, because ; at 20+ seconds prior to impact the round will exceed the Ttl live and not impact! ; The other thing is, you probably want to be closer to 18 seconds to impact, that will ; give you a 2 second buffer in case the engine happens to count fast :) _frompos = _this select 0 _topos = _this select 1 _initvel = _this select 2 _Phi = _this select 3 _VertOffset = _this select 4 _round = _this select 5 _TimeOff = _this select 6 ; Get the initial velocity vectors and see if Tof > 19s. ; Theta determines direction, PHI determines elevation ; The magnitude of the first vector is the requested Velocity ; The base of this triangle represents the hypotenus of the direction vector ; so we calculate the Z (verticle axis) first ; ; velOY is the vertical velocity ; velOX is the horizontal velocity  (we use these for Vv and Vh as defined above) _velOY = _initvel * sin(_Phi) _velOX = _initvel * cos(_Phi) ; check the Tof  (again, I am assuming g=9.8) _Tof = (2 * _velOY) / 9.8 papabear sidechat format["Time of flight: %1",_Tof] ; If Tof < _TimeOff seconds then exit, we don't need to do anything. ; If you want to test lower Tof's, just comment it out. ;?(_Tof < _TimeOff):exit ; delay just a short bit to give the real artillery round time to clear the area ~0.1 ; at this point Tof > _TimeOff seconds, so let's get Tif (= Tof - _TimeOff) _Tif = _Tof - _TimeOff ; If you set _Tif = 0 here, the round will start at Time=0 in the trajectory, which will ; start the round at the beginning of it's trajectory.  The round will then travel along it's ; normal trajectory and impact as long as the dreaded Ttl is not exceeded. ; You can set this to any time.  It is the time in flight of the round, so Tif=2 means start ; the round where it would be 2 seconds into it's trajectory.  The tricky thing here, is if ; you are using an extremely shallow elevation and/or very low initial velocity, you could be ; starting the round AFTER it would have impacted.  Be sure you don't! ; Uncomment the line below to do this, mainly for testing. ;_Tif = 4 ; let's figure out the distance the round will have traveled at time Tif and it's altitude (height) ; H (height) = Vv * T - (0.5 * g * T^2) ; D (distance) = Vh * T  (I copied this from above to keep it fresh in your mind) ; For our caculations, _Tif represents time T _Distance = _velOX * _Tif _Height = (_velOY * _Tif) - (0.5 * 9.8 * _Tif^2) ; We now know how far it's traveled and how high it should be.  So we need to know how fast it's ; going in the vertical plane.  Is it climbing or falling at Tif?  Well, let's see, that's ; Vt (velocity at time T) = Vv - (g * T) _velVert = _velOY - (9.8 * _Tif) ; and Vh doesn't change. Well, I don't know what air resistance coefficient OFP uses, so I just ; start the round with the "no air resistance" horizontal velocity, which is the initial ; horizontal velocity _velHor = _velOx ; With all these vector components we can now construct the pre-creation parameters. Namely ; the actual game [x,y,z] arrays. ; First we need to know the direction the round was fired.  We get that by doing simple trig ; using our source position as the origin and the target position as the [x,y] ; break down the position arrays _srcx = _frompos select 0 _srcy = _frompos select 1 _tgtx = _topos select 0 _tgty = _topos select 1 ; some good ol fashion math _diffx = _tgtx - _srcx _diffy = _tgty - _srcy _xsqrd = _diffx ^ 2 _ysqrd = _diffy ^ 2 _RangeToTarget = sqrt(_xsqrd+_ysqrd) ; determine the angle to target as THETA ; THETA = arctan(x/y) for direction _preangle = atan(_diffx/_diffy) ; now which quandrant are we in? ?(_diffy < 0):_Theta=180+_preangle ?(_diffy >= 0):_Theta=360+_preangle ; correct for negative directions and directions over 360 ?(_Theta > 360):_Theta=_Theta-360 ?(_Theta < 0):_Theta=360+_Theta ; _Theta is our direction.  So let's figure out where in the game ([x,y,z]) world it would be. ; I realize I keep changing the reference to height with a simple reassignment, but it's for the ; sake of explaining what, why and how. ; The actual X,Y position is simply the direction * magnitude(_Distance) _preposX = sin(_theta) * _Distance _preposY = cos(_theta) * _Distance ; To get the starting coordinates, we need to add in the starting location of the arty piece ; the round was "started" from. _posX = _srcx + _preposX _posY = _srcy + _preposY _posZ = _Height + _VertOffset ; the full position vector is [_posX,_posY,_posZ] ; We now know where to place the round.  Let's figure out the velocity vectors.  These vectors will ; tell the round how fast to go and in what direction. ; Since we know the magnitudes of both the horizontal and vertical components, we use a little ; more trig to calculate the x,y,z. ; X and Y are in the horizontal plane, so the vector _velHor tells us the magnitude, which is the ; same as the hypotenus. So to get X and Y...... ; Trig hats on = true _velX = sin(_Theta) * _velHor _velY = cos(_Theta) * _velHor ; and the Z component is just _velVert.  This is true because the Z axis is not based off the direction ; our projectile is traveling, it merely tells us if it's climbing or falling. _velZ = _velVert ; the full velocity vector is [_velX,_velY,_velZ] ; Lets wait for Tif before creating the round ~_Tif ; Create the round _op = _round camcreate[_posX,_posY,_posZ] ; Point it in the direction of travel. (Remeber, there is no PITCH command, we can only tell the round ; it's horizontal orientation) _op setdir _Theta ; Start it flying _op setvelocity[_velX,_velY,_velZ] ; Now let the game engine take over, we're done! exit <span id='postcolor'> Works like you expect.  I still have the pressing question of what gravitational constant they use.  Since they do alter the trajectory effectively by a different G value and/or -Vh over time (simulating air resistance).  Guess the BIS guys never gave the final answer to that, at least not in this thread. Hope it's not beating that dead horse too bad.  Was not my intention.

I've been trying to do this the old fashioned way apparently.  Though I do have a small result set I'd like you guys to look at and tell me what you think. The code used is </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ;Calculate the necessary x,y,z velocity vectors for firing a projectile ;Quantum ; ; src is the firing unit pos array, tgt is the destination pos array ; rounds is the number to fire, ; elevation angle ; dir is direction of course ; initvel is the horizontal velocity ; initvo refers to the vertical offset where the round is camcreate'd (off the ground) ; --------------------------------- _src = _this select 0 _tgt = _this select 1 _elevation = _this select 2 _rounds = _this select 3 _roundtype = _this select 4 _velinit = _this select 5 _initvo = _this select 6 ; --------------------------------- ; break down the pos arrays _srcx = _src select 0 _srcy = _src select 1 _tgtx = _tgt select 0 _tgty = _tgt select 1 ; some good ol fashion math _diffx = _tgtx - _srcx _diffy = _tgty - _srcy ;[west,"HQ"] sidechat format["diffs:%1,%2",_diffx,_diffy] _xsqrd = _diffx ^ 2 _ysqrd = _diffy ^ 2 _range = sqrt(_xsqrd+_ysqrd) ; determine the angle to target as THETA ; THETA = arctan(x/y) for direction _preangle = atan(_diffx/_diffy) ; now which quandrant are we in? ?(_diffy < 0):_theta=180+_preangle ?(_diffy >= 0):_theta=360+_preangle ?(_theta > 360):_theta=_theta-360 ?(_theta < 0):_theta=_theta+360 [west,"HQ"] sidechat format["dir:%1 range:%2",_theta,_range] ; ; setup the vectors ; Theta determines direction, PHI determines elevation ; The magnitude of the first vector is the requested Velocity ; The base of this triangle represents the hypotenus of the direction vector ; so we calculate the Z (verticle axis) first ; _velOY = _velinit * sin(_elevation) _velOX = _velinit * cos(_elevation) ; velOX is now the hypotenus (magnitude) of the direction vector ; so get the x,y components from it _velx = sin(_theta) * _velOX _vely = cos(_theta) * _velOX ; _fullstr = format["Vector info OY:%1 OX:%2 X:%3 Y:%4",_velOY,_velOX,_velx,_vely] [west,"HQ"] sidechat _fullstr ; so the full vector is [_velx,_vely,_velOY] _op = _roundtype camcreate[_srcx,_srcy,_initvo] _op setdir _theta _op setvelocity[_velx,_vely,_velOY] [west,"HQ"] sidechat "Artillery round fired" ; _counter = 0 #loop _oppos = getpos _op _px = _oppos select 0 _py = _oppos select 1 _diffx = (_px - _srcx) _diffy = (_py - _srcy) _travel = sqrt(_diffx^2 + _diffy^2) ;hint format["travel: %1\ndamage: %2",_travel,damage _op] ~0.1 _counter = _counter + 0.1 _opd = damage _op ?(_op == _op):goto "loop" [west,"HQ"] sidechat format["final x:%1 y:%2",_px,_py] ~2 _fullstr = format["velinit: %1\ntravel:%2\ntime:%3\ndmg:%4\nelevation:%5",_velinit,_travel,_counter,_opd,_elevation] hint _fullstr _op = nil exit <span id='postcolor'> Using this I built a table. Theta = 45 (tested values are avg's, about 5-6 test shots)     tested  tested | calculated values are Vo    range  time   |  Voy   Time   Rng    Rng Error% ----------------------------------------------------------- 30    89    4.1     21.21  4.32   91.83     3 45    185   6.5     31.82  6.49   206.63    10 60    315   8.5     42.42  8.6    367      14 75    473   10.5    53.01  10.82  573      17 90    620   12     63.63  12.98  826      24 105   779    13.5    74.24  15.15  1125     30 120   963    14     84.84  17.3   1469     34 at theta=45 Voy = Vox so Vox is not in the table You can see in my code I get the proper vectors first for elevation, then using the base I build the x,y vectors. Looking at the hint/chat output, all the vectors are correct.  It's the error rate that get's flaky.  There is some inherent error in the tested values because I couldn't get good timings with a delay of <0.1.  But these results, even with a 1% error still show a definite reduction in range and time. When the Tof (time of flight) approaches 18 secs the code still works, but of course the shell has exceeded it's Ttl (time to live) so there is never an impact. I was hoping to build an elevation chart for some of the add arty pieces out there, like the M101 and the M109.  Looking at their initspeed's it appears it would be useless to do so for such high speeds.  The best range at 200m/s is around 1800m.  Not a great distance.  The M109v2(Heat) fires at 900m/s, even with a calculated elevation of 10degrees the round would fly off the map.  At 45d elevation the round takes well over a minute just to reach it's apex. With an ~20sec Ttl and this ever elusive (-vt), will using real pieces for artillery work?  Sure you can use the 900m/s initspeed's, but your trajectory is so shallow that it kind of defeats the idea of dropping shells from above, especially to clear buildings.. my 2 cents, Quantum