Evil_Echo

Also, some systems have enough reserve pressure to operate for short periods of time without the engine running. Apaches use that technique to restart their engines under normal conditions, but there is a access panel on the side to repressurize the hydraulics by hand if needed.

Shweet..... And thank you, CarlCustaffa - good find.

Scanty... Is there any way I can get a list of function names? Working on it now. It's a big module and I have to stare and compare to see what changed vs. the BI module.

Frederf: There is no white paper about the design on ACE ruck system, but since I did the coding of that system most would say I know it pretty darn well. And in order to make it work with A2, I had to learn how that worked also. Tcp has taken over that code since I left the team, he's the only other person qualified to discuss the how and why matters. CarlGustaffa: I know all too well about the magazine refresh issue. But the current design was meant to deal with the huge problems in network code and compatibility that the old ACE1 system of virtual magazines introduced. So when it came down to a chance of some people exploiting the code vs lag, disappearing mags, not being able to pack other addon mags in ACE rucks I made the judgement call and still stand by that. Tcp and I talked at length about other ways to store items and perhaps someday he'll improve the system to make magazine counts stick. If he does I'll applaud his efforts, not that easy a nut to crack without more support functionality from BIS. Both: I understand your desire for extra realism and dismay when players don't behave the way you want them too. I don't agree with the viewpoint about player behavior control. A good mod should be a toolkit that provides the mission maker with the ability to control those aspects, but not impose the rules itself, especially in a way that cannot be overridden by the mission maker. I used to play BF2 a lot and our clan did try Project Reality. While we loved the way they extended the map system and it had beautiful models, the rule sets they imposed on the game made it unplayable for our team. We weren't opposed to realism, our team operated as a special operations unit conducting asymmetrical warfare - infiltration and sabotage. In theory PR would have been a perfect match, but arbitrary rules changing how objectives were captured, respawn methods, combined with other teams not following the guidelines made play impossible. So we dumped PR and switched to ArmA, which had the enhanced realism AND the flexibility to allow for differing styles of play. My own mission designs for our clan include some training missions far more hardcore than most players are used to. You get limited ammo at your starting location and that's it. No respawns and the AI is enhanced by me to be ruthlessly efficient in it's use of support resources. The challenge is to figure out how to beat the mission by improvising, using your head to fight unconventionally. Dipping your mag in a ruck won't do jack to help in those missions. My folks rarely run out of ammo anyway - they either beat the scenario or die. When we play on public servers we do see a lot of retarded behavior. But that is the nature of public servers and we have better things to do than fret about what the admin should be doing. We just get to work making the enemy's day miserable. So what if some fool scarfed up all the stingers from the ammo box and now we have a Hind base-raping our MHQ? While everyone else is moaning, I've got an AT-4 out - it does not care about counter-measures and is quite deadly once you learn to lead a flying helo properly. Is that realistic? You bet it is if your life is at risk - experienced soldiers learn that the field manual is not the only way to get a job done. Any mod or server that gets uppity about me keeping my team alive via legitimate, but unconventional, tactics will get dumped in a New York minute. You folks are entitled to your opinions, allow me to have mine. We both can enjoy ArmA as long as we stay flexible and not impose on others.

I can't say whether the simulation is terrible or not without being able to read the source code for it or at least the internal notes on it. All we know is that our knowledge is incomplete and it appears the stock configuration are not always in agreement with publications of the RL specs. In the best of worlds we'd either have better info or the ability to define our own simulations. Sadly we cannot right now and do the best we can with what we have. I'm glad the formula helped. If we keep plugging away, perhaps you, I, Mando, Q1184 all can figure out more details that can be of use.

Glad to help. Show those folks what real fire-power is all about.

Ok - more good news. I figure you have a couple of known values and just want the other value to fit the performance. Let's assume you know.... Max speed - a common number in the literature and really what you're trying to fit the config to match. Burn time - again a common number to locate or easy value to assume. More on that later... What you need then are the sideAirFriction and/or thrust values. The friction value is relatively constant across missile types since it represents the geometry. You can vary this a bit to tune the steering, but let's aim for the thrust numbers. So I take my fancy ( and confusing :D ) formula from before and try to solve for the thrust. And the answer is quite ugly, I'll spare your sanity by not showing you that. But I don't need the general solution. We're looking at the thrust needed to get us to the top speed for this missile. Which means I can borrow a trick from calculus and get what is called the limit. Which is NOT ugly at all and does not even mention the burn time ( after all - I'm asking for the max speed at time infinity - well after the motor has stopped firing ). That answer is... V = sqrt(0.022*thrust*sideAirFriction) / (0.022 * sideAirFriction ) Very cool. We can solve that for the values we need. If you know the value of thrust and want the friction... sideAirFriction = thrust / ( 0.022 * V^2 ) and if you want the thrust, having already picked a friction value to use... thrust = 0.0022 * V^2 * sideAirFriction I'd use the 2nd formula and just fiddle with the sideFriction to get appropriate maneuvering characteristics. Anyway - hope this helps.

CG - the reason the M240 and M249 mags use different slot capacities in ACE is because Rocko set it that way and I had no desire to argue with him about it. You do that sometimes when trying to get along with a team. I wish people would stop thinking the ACE system of rucks as the One True Way and any other system as fatally flawed. BI chose to use slots, ACE uses volume. Neither manages to model reality perfectly. But in a $50-something simulator, both systems are good enough. Let's not get all holy about one or the other. BTW - I don't think much of people demanding BI or add-on makers change their product to enforce some personal notion of exploit management. You do that in your mission and more so in proper server administration. Overt bugs do need fixing, but if you don't like some clever person hauling/possessing gear that you don't like - deal with it on your own site and don't jam your opinions down everyone else's throat.

Problem with using auto-hover is that at high speed it brakes so hard you pop up - making your bird an easy target for AA fire. Best way I found to bleed airspeed is to do a hard 180 turn. Then if you wish, you can use auto-hover, but often you won't need it anymore. Should be able to keep altitude below 40m quite easily with just a bit of practice.

No problem friend. Have faith, we'll get something good for you. I'm just sorry for being slow.

Arty module deals with high fire angles by default. I'd concider making it work in other modes just a small challenge. :-) Anyway - link to some stuff I wrote on Armaholic... http://www.armaholic.com/forums.php?m=posts&q=10845

Sorry - this kind of math does cause insanity at times. The good news is that the solution to that equation leads to a "simple" form. velocity(t) = (tanh(t*sqrt(sidefriction*thrust)) * sqrt(sidefriction*thrust) ) / sidefriction which when plotted gives a nice velocity curve that rises in nearly a straight line for a while and then levels off to a near flat line. Using your numbers - at about 10 seconds. So this is looking good ( aside from your confusion, but bear with us ). Now just give us a bit of time to solve the formula in another way so that it we can get your thrust values or sidefriction for you.

I have a couple of irons in the fire. Most I can predict the time needed. But all I can say for this project is "soon", since it's partly research into better cluster detection methods and that will take an unknown amount of time. But I do expect some version out soon enough with the expectation that I'll have to continue to improve the code.

Good to see we have a handle on the friction issue now. Those numbers start to make sense to me. The reason behind your issue with doubling of some values is related to the physics. Most people learn about acceleration in high school, but you only get taught the case that ignores friction. For good reason too, you need good skills in calculus to deal with the more complicated cases. Which is what this is and why doubling some numbers does not lead to doubling the final speed - friction eats up more power at higher speeds. --- Additional. What was the mass of the missile you are using during testing?

Oh my.... I'll see what I can do - have access to reference tomes on ballistics, but still need to reverse-engineer what BIS uses for their model. One thing comes to mind - sideAirFriction vs AirFriction in the config. Also, I know many missiles use two-motors, one for initial boost and another to sustain. So the thrust phase might be much shorter than you believe.

Trivial to accomplish.

Mando might know. I have some background in physics and math, might be able to help if all else fails.

Perhaps you could lock this thread and start a new one with updated info....

Think that is bad - AI dropping a nuke is really tragic. IRL you'd never fly slow or dive-bomb with one of those. Toss-bombing or lay-down at speed are the way. Youtube had a vid of someone doing some fancy bomb runs using the new record/playback functions. Maybe that is the way to go for these kind of problems.

7894rmnxyj: No problem. Breeze: 1. If it looks good enough, sure. Meanwhile, search around and you should find my posting with an earlier version of the fire-mission script. Should work fine for triggers, etc. 2. BIS arty modules requires the mortars/howitzers/etc to be synched with a given module. ACE version does not use synch, but does require you to register the units to a module via assign statements. So one way or another the batteries have to be tied to a given group. I use the BIS method for now since the AI batteries should stay on just the server and don't need much tweeking to work even in MP play in that situation.

Have fiddled with that for some time with good success. Calling fire missions is quite straightforward, just need to sync arty modules to your batteries, name those modules and then use a small script ( posted examples of that some time ago ). The tricky part ( and more interesting ) is designating targets in the first place. You could just use triggers for that, but I like something a tad more sophisticated. So have been playing around with Finite State Machine ( FSM ) files. With those you can do quite a bit. Mine is using a list of designated spotter units and another list of artillery batteries. It periodically gathers intel from the spotters and tries to find clusters of worthy targets then assigns fire missions to the various batteries. Still a work in progress, but I like how it works so far.

Thanks Killswitch - that's exactly the info I needed. Any chance for option to control content on that screen? Guessing no...

Nou, I wish you stop whipping out the troll word whenever you get a question you don't like. I happen to like CBA a lot, just not the constant spamming of names. It may be there is some good reason for the screen. My own rig is water-cooled, fast enough the screen seems to be useless. Hence asking for more detail and being willing to accept a good answer. I'd hoped something along the lines of The init takes X msec to run on a 2.6 dual core - it you click on Y during that time we CTD. Just some simple facts so I can understand why and even help you out.