PLP

Don't forget different physical effects dominate at different length scales, and I would guess that is why R/C sims might be more close to reality in the end. I guess (would have to look it up though) stuff like air compressibility, sonic effects,... can all be neglected at the R/C scale? Insect aerodynamics are worlds away from A380 aerodynamics, even though they spawn from the same equations.

Make sure the task of the refueler reads "refuel", make sure you have a refuelling il78 and not a transport, radio F6 should have a list of refuellers, you need an AWACS for a radio vector, otherwise the F10 map can do. I can make a very quick example mission if you are still struggling. Cheers

Bump. Just came across this when reading a magazine, from a P51 crew chief: Interesting, is this modelled? I doesn't seem to be exactly our case, but I'm not really sure.

Yeah I just did two more test flights in singleplayer, and here are my results: Takeoff left tank, main downto 25gals on the climb (full throttle), then cruise (~FL280) at no more than 40" manifold pressure -> fine. Inflight start with L/R tanks full, center empty, cruise at no more than 40" manifold pressure -> fine. Climb @ about 50" MP, & 50'MP maintained during cruise (fl~200) (and therefore tank switches) -> right ext tank no more fuel pressure Level @ about 50-55" MP , maintained during cruise (low alt) -> no more pressure in from right ext. tank I'm suspecting some kind of vapour lock is simulated if you ask too much pressure while you switch tanks. My next test will be 50-55" MP, but reduced throttle for the fuel switch. EDIT: So this really seems to be it: keep Manifold pressure low enough when switching ext. tanks. I did a flight were I cruised at high altidude, MP between 50-60", exept for the fuel switches, where I momentarily took MP down to the green range, and I was fine (was able to empty both tanks, as indicated by the fuel slider in alt ' ). I did another flight where I just flew balls to the wall and switched ext. tanks, and sure enough after a couple of switches, no more fuel pressure from the right ext. tank

from what I read they would bring the rear tank down to 25 gallons as soon as possible, then switch to ext.. The mustang was such a slouch with that rear tank full that no pilot wanted to risk an encounter in that situation.

Out of curiosity, what kind of manifold pressure did you fly on the fuel tanks? I had the same problems, but just did a two-hour cruise (on 10x speed) on ext. tanks (with L-R internal tanks full, but main empty) while keeping manifold pressure in the green range.

Although I initially also believed it was wrong, this makes sense, and I am mad at myself for not having thought it through. but in my game only the port aileron fletner is moving, is that correct? and this is why trim does not move your stick when you are stationary, but then moves it when you are at speed *sudden clarity*.

Hope I'm not double-posting or missing something obvious (google-searched the forum, I did), but the set internal cargo function does not seem to work anymore. I tried both Mi8 and UH-1H. Attached is a trivial track&mission to illustrate the problem. It's a great shame, Internal cargo makes flying the Huey so much more challenging. Edit: attached the attachements UH1H_customcargo.miz Cargoprob.trk

Might improve with EDGE then? Was wondering if it concerned more the rendering only, or how deep into the DCS physics the EDGE overhaul will go.

So, I followed your sound counsel:smilewink:, and here are my doubts on the flight model: In light slopes it seems very accurate to me, but on ledges it seems to jump from one slope to the next, and above steep slopes there is an air cushion when the front of the skid is at 1-0.5m from the slope that just does not seem realistic to me. In a steep slope, the air should not be stopped (like when it's flat) but merely deflected, so I reckon the ground effect should be much less repulsive. Let me stress again I'm not saying this as a know-it-all expert, these are just my educated guesses and I would love to know how the ground effect is modeled in the sim, and how much thought & love they gave slope ground effect. Because I am a showoff, here are snapshots of my slope landing in a light slope, with the stable cyclic & collective inputs:

I also wanted to post about this. I was also wondering about ground effect in steep slopes, it does feel unrealistic, but then of course I have no idea how it should be in real life. Maybe somebody knows how it is modelled in the sim? It's a shame, because it makes things like: (56:44) really hard at the moment. But then again maybe it's already totally reallistic and I just need to work on my skills.:pilotfly: cheers

https://medium.com/war-is-boring/4ef05200dd79 "As with previous attempts to retire A-10s and U-2s, the current proposals are subject to Congressional approval. And getting lawmakers to sign off on the cuts could be easier said than done." So it's not over just yet I suppose.

This is again one of those things where you would need so much effort to do a good job: a real temperature-dependent IR image with bright exhaust trails is probably just a utopy right now. I do hope though that edge will enable monochromatic IR textures for objects (scenery and other), that would be a huge leap forward from what we have now. Also I think right now the background texture for IR imaging does not change with the seasons... or maybe I'm wrong?

Looks nice. I was also thinking the concept would work better with DCS:WW2 (which will probably also be a lot about the air war.)

One way to go would be to write a shell program, which would use DCS for battle simulations, creating miz files and then analysing player performance (the way Tacview can do.) A simple start would be an air war between carrier groups: The program would give you a war room or AWACS view of the situation, then whenever a confrontation occurs (e.g. two aircraft less then 50nm apart), it would create a miz file representing the exact situation, launch DCS, let you play the battle and then look at the outcome (with possibly a time limit after which your actions in DCS are effectless.) This really would just be applying the "total war" system to DCS. Well even this relatively simple example would probably imply months of programming... I guess I'll rather let ED surprise us with whatever they have in mind. EDIT: by shell program I mean a front-end, not a program run in a terminal. Rather poor choice of words

Wake turbulence should also make A2A refueling more interesting. :pilotfly:

Yeah, still debugging, but along the lines of: Unit2UnitClock = function(unit1Name, unit2Name) --local unit1pos = Unit.getByName(unit1Name):getPosition.p --local unit2pos = Unit.getByName(unit2Name):getPosition.p local hdg1 = mist.getHeading(Unit.getByName(unit1Name)) local hdg2 = mist.getDir(Unit.getByName(unit2Name):getPosition.p, Unit.getByName(unit1Name):getPosition.p) local clock = (hdg2-hdg1)*6*math.pi clock = math.floor(clock + 0.5) if clock == 0 then clock = 12 end return clock end

Thanks a lot, yeah did not realise it would be that simple :doh:.

Quick question: is there any script for returning clock positions strings, like the one your wingman always uses (sam launch, 1 o'clock etc.)? I can't find any, either in the ED doc or the mist doc. BRstring works fine, but it feels unnatural for your copilot in the Huey to instantly give you exact range and heading... Don't waste any time on my account, just if you could point me in the right direction I'd appreciate it very much. Thanks a lot in advance Edit: Here it is if it can spare anyone time: unit2UnitClock = function(unit1Name, unit2Name) local hdg1 = mist.getHeading(Unit.getByName(unit1Name)) local hdg2 = mist.utils.getDir(( mist.vec.sub(Unit.getByName(unit2Name):getPosition().p ,Unit.getByName(unit1Name):getPosition().p)), Unit.getByName(unit1Name):getPosition().p) local clock = (hdg2-hdg1)*6/math.pi clock = math.floor(clock + 0.5) if clock <= 0 then clock = clock + 12 end return clock end unit2UnitClockString = function(unit1Name, unit2Name, text) local hdg1 = mist.getHeading(Unit.getByName(unit1Name)) local hdg2 = mist.utils.getDir(( mist.vec.sub(Unit.getByName(unit2Name):getPosition().p ,Unit.getByName(unit1Name):getPosition().p)), Unit.getByName(unit1Name):getPosition().p) local clock = (hdg2-hdg1)*6/math.pi clock = math.floor(clock + 0.5) if clock <= 0 then clock = clock + 12 end return (text .. clock .. " o'clock.") end unit2UnitClock.lua

Another related question, how do you deal with more than one enemy (whithout awacs?) I often have the problem (against AI usually) that when I fly against a flight of 2-3-4 planes I win my first duel with the lead, but by then find myself with no idea of where the other planes are (and often get shot down like a duck). This is less a problem with the eagle (TWS & easier RWR.) Any tips?

goupName... :doh::wallbash:. Thank you so much sir! It now works, and my knowledge of lua programming is much better. I think a lot of my confusion came from the fact DCS does not automatically reload the script somehow. I once commented a part of it, saved, relaunched the mission, and the commented part still executed! Seemingly you need to reload the script from the Mission editor Do script file. The reason I used a fakeZone and not a vec3d is that the initial point of the script was to have troops run to your Huey wherever you landed in the LZ, using mist.groupToPoint which needs a zone. The group inside moving zone condition then triggers the pickup. I can now go extract hiding troops under heavy enemy fire :). :pilotfly::joystick::gun_smilie: Then I ran into the strange behaviour (due to DCS not always reloading the script file I guess.) The function (groupGoUnit) now works, and I am not sure 100% why earlier attemps at the exact same thing did not work, but who cares:)? groupGoUnit = function(groupName,unitName,form,heading,speed,onroads) local fakeZone = {} local pos = Unit.getByName(unitName):getPosition().p fakeZone.point = { x = pos.x, y = pos.y, z = pos.z} mist.groupToPoint(groupName,fakeZone,form,heading,speed,onroads) end groupGoUnitDef = function(groupName,unitName) local fakeZone = {} local pos = Unit.getByName(unitName):getPosition().p fakeZone.point = { x = pos.x, y = pos.y, z = pos.z} mist.groupToPoint(groupName,fakeZone,"Custom",nil,9999,0) end

Thank you so much for your prompt answers. You raise many good points and expose a lot of my bad coding habits:music_whistling:. Well since the second script does nothing more than define a function I though it would still work, but yeah you're right I'll do it this way from now on :) . Oups :shocking:, ok I wrote this example a little bit too fast... Oh, I naively though everything that was not public was local, but I guess that's just a C habit... I stand corrected! Thanks I corrected my code (attached), unfortunately I am still experiencing different results when I copy the content of the function as defined in the lua file in a "do script" (with function args defined just above), which really confuses me to be honest. Maybe variables that are accessible from the main are not accessible from a subfunction? how could that be? It gives a strange error at second 15 (execute from function), but the explosion at a point does not work at second 30. Mist_check-corrected.miz TestFct.lua

Hi all, Is there any reason that Do Script and Do Script file with the exact same script in the file that is in Do script are different? Is it normal for it not to be possible to to define a function in "do script"? Furthermore, If I copy the code from my function and put it in a Do Script, it gives a different outcome. (I changed all the variable names and defined all the arguments with the good value.) My question is really: Am I missing something, or is this not really normal? I'm kinda confused:confused: Thanks in advance for any answers I attached an example of a mission giving me issues. Mist is used. Execution at time 3 and 30 should be exactly the same. More precisely the infantryman should be moving at second 3 and the tank should re-explode at second 30. Mistv3_2.lua Mist_check.miz explodetest.lua

I'm from Physics - I was more thinking along the lines of a sphere near an infinite cable (that's what we do, simplify the problem until it becomes easy, and then think we know it all, and try to predict life, the universe and everything ;) ). Jokes aside, it should give you the right order of magnitude. The exact shape (sphere or complex chopper) should not dramatically change the capacity AFAIK, exept maybe for the rotorblades. You're probably right, I underestimated the capacity that the chopper presented respective to the nearest "ground": the return cable in this case I guess. I'll do a back-of-the-envelope estimate if I find the time (with spheres and infinite lines of course). Although it should not be important if the helo is out of metal or not, as long as it is more or less a conductor. The problem should be shape-dependent before all afaik. I think as you pointed the main problem is that you can build up to very big voltage (200kV was measured by the army in the cited reference) since the air is such a good insulator, and the main charge leak would be due to humidity. But then again as Bignewy mentioned, I'm not sure you can kill someone since the current*time is so small. You apparently need 1350 milijoules for static to be lethal (http://www.straightdope.com/columns/read/3044/can-static-electricity-kill-you). It would be interesting to estimate what current you need to keep the chopper at the cable's potential and how that compares to the miliamp which is the current dose which you start to feel, according to: http://www.physics.ohio-state.edu/~p616/safety/fatal_current.html

Well, if I remember my electrodynamics course correctly, static electricity can reach very high voltages because the capacity between the chopper and the power line is very small (you can define capacity between any two conductors). This means that a small charge (created by friction) will translate to a huge voltage difference. That is why static creates a impressive shock without being really dangerous (small charge hence little energy). When the helo is connected to the power line, this static electricity is instantly unloaded, and the whole helo is at the potential of the cable, be it grounded or oscillating at 110kV/50Hz. The point of this connection is to make sure the static electricity is not unloaded through the worker. Power in the cables should not be an issue as long as you stay clear of other cables or the ground, just like when birds land on power cables. I'd attach a bunch of formulas and compute the whole stuff, but I'm far too lazy for that:).