CareyBear

Actually Dinger, that was the conclusion I'd come to as to the only way to effectively do it. I didn't know that CoC has a .fps decoder.. I'll have to try that technique. I'm currently working on a 'goal seeking' algorithm that I can set up and leave running. Uses fuzzy logic to adjust the initial velocity until it gets within a 0.1% error for range, then tries again for +10m range.. If I get the damn thing working, here's hoping I can leave it running and go to bed, then wake up and write down all the values it's spat out, then use a lookup table for 10m range increments. At least.. that's the theory.. Similar to your approach denoir. The thing is... you can do it with a fixed elevation angle, or a fixed muzzle velocity, but both limit you.. then you can do it with both variable, and get a major headache. uiox: That's a good idea.. I haven't played with drop, but if you can create a particle with a volume and density, then you have a fixed mass, and I can actually figure out whether OFP uses physics or approximated physics... hmm... wow, a way to get a value for k! *wanders off to play with drop[]* One useful item can be found here, for anyone who's interested in the physics behind this problem but hasn't done honours physics.. Virginia University Physics - Air Resistance Excel Spreadsheet

Even if a radio command cannot be triggered (ie, condition will still evaluate to FALSE), it will still appear. You can get around this. I suggest you don't hit yourself with the comref and instead read the fine print... </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">index setRadioMsg text <snip> Description: Set radio message (0, 0, map radio) to given text. Use "NULL" to disable radio slot. <span id='postcolor'> so... for RADIO ALPHA CONDITION: this && allowstrike in init.sqs "0" setRadioMsg "null" allowstrike = false When you want it to be usable, allowstrike = true "0" setRadioMsg "Call Air Support" player groupchat "We need support.. better call for a strike" The groupchat is just so that the player knows they suddenly have a radio option. I'm not able to test this solution right now (it's from memory) but it should work. You can also do something like "0" setRadioMsg "Not Available" or "0" setRadioMsg "-------------" & if you use a boolean variable condition (like the allowstrike example) nothing will happen if the player tries it. Cheers, CareyBear

Since you're using an empty helicopter, that means that 'transport unload' is not the WP you need. Sorry milkman, but GET OUT is correct in this situation, cos you want the driver and gunner to get out as well. What the WP types do (to the best of my knowledge): GET IN: Get into the vehicle. Fill crew positions and cargo positions (crew first). LOAD: Board the vehicle. Fill cargo positions only. GET OUT: Get out of the vehicle. Affects all group members regardless of vehicle position. UNLOAD: Get out of the vehicle. Affects only group members in cargo positions. TRANSPORT UNLOAD: This group unloads a transported group. Might also unload group members in cargo positions, not sure. I just made the same setup you described and got it to work (with the usual helicopter meanderings before it finds the landing point) by doing this: Player is not the group leader. Hind (Mi17) is EMPTY Invisible H at the landing point WP1: MOVE (place this WP near the chopper) WP2: GET IN (place this WP DIRECTLY on the chopper when you create it. If you've done it right, you shouldn't be able to move it without moving the chopper too) WP3: MOVE (over the other side of the island) WP4: GET OUT (place this WP DIRECTLY on an invisible H or visible H. Again, if you've placed it right, you should not be able to move it without moving the H as well) WP5: MOVE (somewhere near the H - if you don't do this, sometimes they don't get out.) This worked fine for me (OFP v1.91) There are a number of non-wp methods of landing a chopper, including some that use no WPs at all, or use markers, or use triggers and markers - even methods that are totally script/function based. If you want to use markers, check the comref. The commands are all there. Triggers are just that. When a condition is true, the trigger goes off and executes the code in the On Activation field of the trigger. You will need to know how to script to take advantage of this, unless you just want to play with the Effects section of a trigger (sounds, camera effects, music and on-screen text). A trigger (type: SWITCH) can also be used to 'skip' waypoints by synchronising the trigger with the WP. If you want anything more complex, I suggest you try OFPEC again. Cheers, CareyBear

Yes, OFP uses -9.8m/s/s as gravity (as far as I've been able to ascertain). OFP *does* use some kind of drag modelling - I'm fairly certain of this. The reasons I believe it does are: 1) Objects have a terminal velocity.   Car terminal velocity (tested with: Jeep, UAZ, Trabant): 47 m/s   Shell terminal velocity (tested with: Heat105, Shell120, and the 30mm shell - can't remember the name): 140 m/s Terminal velocity in physics is calculated by: tv = sqrt (mg/k) where tv = terminal velocity, m = mass, g = gravity & k = drag coefficent. That's how I got a value for drag.. but that meant I had to use assumed values for mass of the object. In physics, drag affects an object in flight according to the following equation: f = kv^2 where f is the force applied in the opposite vector to the velocity (v). Note that it is dependent on velocity. This ain't no simple math problem folks. The only way I know of to calculate this accurately in advance is multivariable calculus, and I ain't goin there..  A way to simulate it is to use a piece of code like: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">_k = -2 * (10 ^ (-2)) _t = 0 _v = 100 _z = 0 _g = -9.8 #uphalf ~0.1 _t = _t + 0.1 _kv = -((_k * _v)^2) / 10 _v = _v + _kv _v = _v + (_g / 10) _z = _z + (_v / 10) hint format ["Time: %1\nAlt: %2\nV: %3\ndv: %4", _t, _z, _v, _kv] ?(_v > 0): goto "uphalf" _maxalt = _z #downhalf ~0.1 _t = _t + 0.1 _kv = -((_k * _v)^2) / 10 _v = _v + _kv _v = _v + (_g / 10) _z = _z + (_v / 10) hint format ["Time: %1\nAlt: %2\nv: %3\ndv: %4", _t, _z, _v, _kv] ?(_z > 0): goto "downhalf" hint format ["Time: %1\nMax Alt: %2", _t, _maxalt]<span id='postcolor'> This little script is a simulation of an object given an initial z velocity of 100m/s then falling down again. This script gives very similar results to a shell being fired upwards at 100m/s. If you do not include a drag coefficient (set k to 0 at the start of the code) it is no longer a similar result to actually doing it in the game. Oh, the delays are just so I could 'see' the imaginary shell going up and down again via the hints. I also had a version that simulated it in increments of 0.01 seconds, but the increase in precision did not make much difference.

Prospero: I'm not using a loop with the actual experiments except to track current velocity and position of the test object, and when I do I refer to _time rather than using inaccurate delay values. Since the object is created at the start of the script, _time is accurate enough. The idea is not to constantly update the velocity, but to be able to calculate an accurate *initial* velocity, so that air resistance effects on the trajectory of the object are included in the initial 'firing' of the projectile - this is because a) if you're gonna simulate something, may as well be as realistic as possible about it , and b) The system I have in mind should be fully MP compatible - though that may need a custom addon. Harnu: Damn. I didn't realise that. That's a problem with anything over about 1km range, but one I can already see a few ways around. Thanks for those numbers, though.

I've never posted in this forum before I did a search through here and a few other places on the net, and haven't found an answer to my questions. A brief background: I'm working on a generic artillery system for OpFlash using setVelocity and basic trig - the problem I'm running into is that the drag effect on projectiles reduces accuracy substantially at ranges over about 400m, though maximum range achievable by this system should be several kilometers. I've tried various experiements to attempt to isolate the drag factor, but the results I'm getting are a bit inconsistent. I *think* that Flashpoint uses a turbulent flow drag model based on kv^2 where k is roughly -2 x 10^(-2) for a shell object (such as "Shell120") - at least, using that value I've managed to get my simulated projectiles achieving the same range for the same velocity as by direct experiment in the game. I'm also pretty sure that the k / mass values are standardised for shell objects / car objects / tank objects so that all shells have the same terminal velocity, all cars have the same terminal velocity etc. That value for k is only an estimate though - there would be no more accurate way to calculate it without knowing the object's *mass*. In fact, assuming a mass of 1 for a shell, the terminal velocity of a shell suggests a k value of -5 x 10^(-4) - but this doesn't give me accurate projections. I can't believe I'm simulating a simulation to try and work this out, but there you go. My questions are: Does Flashpoint model air resistance with a standard physics model of turbulent drag (I assume it ignores laminar flow drag effects since they're all macro bodies)? If so, what is the mass and/or k (drag coefficient) value for a bullet / tank shell? Does the model include Archimedes' effect? If not... What algorithm or lookup system has been used to approximate air resistance? If anyone can help me out, I'd appreciate it. Cheers, CareyBear ofpec staff