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)