b101_uk

well if you scale down triangle so they are very small so are almost always sub pixel on even on a high resolution screen there becomes a point where storing the data for a triangle disproportionally bigger than that of just describing it as a single point Take a triangle: 3 vertices which each require there position in x, y, z so that 9 high precision numbers. 1 normal which is another high precision number for x, y, z space and another number for direction. 4 numbers between 0 and 255 to describe RGBA Vs. An atom/voxel/whatever: 3 high precision numbers for x, y, z position. 1 number for normal direction 4 numbers between 0 and 255 to describe RGBA An a small value to describe the blob that will be shown there. The net saving of the latter is a at least 7 high precision numbers being stored when triangles get extremely small.

If you go by land mass Limnos is ~477 km2 but you need to put it in a space of ~30km by ~35km to account for its shape Its how you infer things relative to the quotes of being ~2.4 times the size of Takistan which is 100% land mass thus sits in the smallest possible bounding box of measurement, also let’s not forget BIS don’t count the bounds of the sea or low detail land outside of the detailed area or they would be claiming ~55km x 55km of usable space or being able to get up to ~63.7km of distance between 2 objects just in the A2 editor yet still being able to drive much further! ;) SEA in A2 etc is hardly a hit on the frame rate so why would it be in A3 ;) edit: BTW: I was using the largest quotient of land mass area’s I could find for Limnos, which makes my argument harder than using the other smaller land mass area’s which are almost exactly 2.4 times the size of Takistan’s land mass area even though you need a ~30km by ~35km space to drop it into.

err the A3 Lemnos is going to have be > ~40km x ~40km before you even add the sea either side of the widest parts so it’s going to have to be in the region of > 50km x 50km, also Lemnos is not a place you associate with trees as its very sparse in that respect anyway so would be much more like A2’s Utes than the tree covered Chernarus which both work well with the TKoH CP. Just compare the amount of triangles and transparent texture there is to sort out there occlusion in a A2 trees vs. a house you cannot enter then bare in mind the house doesn’t sway in the wind like some A2 trees and that a house may occupy the space of >4 or more trees ;)

Yes the last iteration of the TKoH CP is much better is lots of respects, On the plus side: We now have clutch between the engine & rotor which for the most part seems to work, The torque gauge is now functional in range without seemingly having the strange problems, The climb rate has been tweaked a little (lower), If you keep maximum torque load for more than ~55sec the main transmission fails, if you keep it on ~98psi to 102psi it’s about 10mins before the same happens, as for the >87psi <93psi range I gave up after 10min at x4 game speed, also before it fails things start to shake . On the negative side: The TOT is now reading to low IMO (only just under 600C) and seemingly hardly moves even if you run it at ~98psi torque load and have added enough “weight†so it cannot get out of ground effect or off the ground! (FYI: if you want to add more weight use “NAME setcustomweightrtd VALUE;†(e.g. “heli1 setcustomweightrtd 300;â€) ware NAME is that what you gave the helicopter in the editor (heli1) and VALUE is expressed in kg (300) and pertains I think to cargo weight which is additive to the base weights in mission – you set the value back to 0 by issuing the command again either by a trigger/waypoint with “0†replacing the prior value, it makes it easy to make missions using triggers etc and the “attachTo†& “setcustomweightrtd†commands as you can load/unload something into the helicopter then add an appropriate weight e.g. “crate2 attachTo [heli1,[0, 1.05, -0.28]]; heli1 setcustomweightrtd 300;†– don’t attach the default ammo crate as it makes the helicopter explode shortly after take-off/>80kts – or if you attach the 45gal barrels in the rear it will refuel in flight!) There is still no NR needle which is more importet now we have a “clutch†given you can no longer infer NR rpms from N2 rpms if the engine shuts down, We can seemingly get to a potentially higher hover altitude than the normal MD500D figures would suggest for a given weight on an ISA day OGE (which was spot on before) so perhaps suggesting a “hot & high†hybrid variant??? Something else I noticed is the effects of forward or rearward speed vs. cyclic position is seemingly opposite (left><right) to what it should be, the retreating rotor blades are on the left, the advancing rotor blades are on the right when flying forwards, when transitioning from trimmed stick centre hover forwards you need to move the stick with bias for left of centre for level flight in-game, when flying backwards you need bias right of centre for level flight in-game which both go directly opposite left/right of what they should, i.e. if you are trimmed centre stick in a hover and you fly forwards slowly building speed with the advancing blades on the right then you would expect that side to start generating more lift than the retreating left side thus by implication require less blade pitch while the retreating side requires more blade pitch to account for the blades relative air-flow speed differences, if you are having to go into left stick bias as forward speed rises that means you are increasing the pitch on the advancing right side and decreasing it on the retreating left side. :confused: As for autorotation’s, they are still falling apart on the ground slide (or lack of it) mostly resulting in nosing over as the skid “digs in†which I don’t think is helped by the seemingly almost total rigidity of the skids vs. real life and the skid collision modal, also nosing over now is less likely to end in death 99% of the time, also in view of the fact there is no reference for NR with the engine off I still think the rotor speed is deficient for a given weight, you certainly don’t get the feeling of ever having to apply collective or slow in order to stop the rotor from ever going “to fast†or even trying to maintain optimal rotor RPM range, that said it is an improvement and going in the right direction, so I am just hoping they are withholding the NR needle until they have looked more into this. :)

press the Esc key as if you were exiting/saving/restarting, then press the F1 key.

I would call the “HUD†the formerly green then white heading scale, radio altimeter (high above AGL) and the speed (normally grouped around the top centre edge of the screen) also perhaps the visual indicator for the collective application (top left edge of the screen), none of the above work or they have defaulted to “off†between this and the last iteration of the TKoH CP with seemingly no key combination to turn them on/off (regardless of difficulty setting.) If you use “other vehicles†in TKoH CP you do get their respective HUD (speed & condition/fuel/etc). The analogue gauges do turn on/off with the “RCtrl + H†(I would call this a panel not a HUD as it’s err mimicking the/a gauge panel) “J†toggles the “task info†part of the in game UI The compass, watch, GPS all toggle etc with their respective buttons. Wile you’re here and looking and as its related to gauges, are there plans to add the second short fat “NR†needle (inner scale of rotor RPM) above the current longer thinner “N2†needle (high pressure stage outer scale % RPM) on the 3d cockpit combined “NR & N2†gauge – one of the most important gauges? ;) (FYI: N1 is the low pressure stage)

With my a2oa profile, this iteration of the CP none of the HUD is working regardless of the difficulty setting (don’t know about the analogue gauges as i cannot remember how i turned them off in the first place!) but i fly using the 3d gauges anyway. if i delete my a2oa profile so the game makes a new one next time it starts then only part there in game is then the analogue gauges and the crosshair the rest of the HUD is missing.

It also seems that 2 of any 3 passengers who start off a mission as “in cargo†do not load and are just left standing by the helicopter and also won’t follow orders to get in (won’t follow any orders), while the 3rd passenger who dose start in the helicopter will follow orders. However if you assign a “get in†WP etc method (passengers start outside the helicopter – not part of the player group) or have them all start outside then given them an order to get in (in players group) they will correctly get in.

Works for me with -nosplash But "-skipIntro" caused an error during the loading screen.

It would be interesting to know given the heritage of BIS and how ofp/A/A2/A2OA /TKoH work if in game when outside the “helicopter†you can take on roles like SWAT/EMS/FD/etc or to be able to drive etc a very limited amount of group specific vehicles #1 #1 = vehicles owned by a specific group like “SWAT/police†“EMS†“FD†etc, thus most vehicles in the game world would be undriveable as they belong to a “civilian†group. I wander also if we will have to ferry around a Mr Bill Gate who owns Microsaft or executives from that famous aviation company Bowing who stoop to new levels in aviation, or even people from that major on-line pornography search-engine Googirl who specialise in finding pictures of girls covered in jam and other sticky foodstuffs. ;) (saft = a contraction of “Silly†and “daftâ€)

WASD for movement :rolleyes: is for abnormal people who haven’t learnt its best to use the curser keys for movement then have the mouse on the left of the keyboard while having your joystick on the right all ergonomically placed so you can easily use the joystick (flying) & mouse at the same time or to be able to switch seamlessly between any two without moving anything or siting unnaturally. (I am right handed BTW)

I have lost count of the amount of times the helicopter has nosed over when landing from autorotation’s :eek: it definitely feels related to how the skid/ground interaction is working, it’s almost as if the collision model of the skid at the front instead of being described as a nicely radiused bend upwards in the skid tube made out of many facets (we are talking triangles and polygons) that its literally being described by a single facet at >45deg <90deg to the horizontal, thus as soon as the nose of skid is presented to the ground slightly nose down aspect you get the sharp effective edge between the horizontal facet and the >45<90deg facet digging in/giving higher resistance thus causing the nose over, and that’s without mentioning the effect of making the skid effectively shorter vs. the CoG. You can see the above problem if you switch to the 3rd person view with the helicopter on the ground, position the view so you can clearly see the nose of the skids, start it up, push the cyclic fully forward, then apply a slight collective to initiate slowly nosing over, if you look at how the collision modal interacts with the ground it clearly is NOT curved up as per the visual modal as the nose of the skid disappears under the ground almost as if there is NO upturn to the nose of the skid. part of thes skid problem: iSvLWOz_ZK8

Oy81YP-q8R4 IgrN0fyDRsQ

I feel you could be right, though it’s appearing as excess initial climb both in a hover and at 60kts, with respect to gross weight #1 vs. power vs. altitude it’s actually hitting the right values with respect to 9600ft maximum altitude for hovering out of ground effect performance on a ISA day if its mimicking being fitted with an ALLISON 250−C20B, if it’s supposed to be a ALLISON 250−C20R/2 power plant it is somewhat short of the expected 13200ft on an ISA day (#1 @ ~2650lb gross weight). If we take the expected torque gauge reading for a power setting and the relating TOT gauge temperatures and rotor (NR) and N2 gauge RPM’s/% for real life & in game we should expect the following. MD500D with ALLISON 250−C20B power plant (420SHP, 375SHP take-off, >350/320SHP continuous): Maximum take-off (5 minutes): 87.2 psi torque with a TOT of <810°C (~375SHP) Maximum continuous with TOT at or below <738°C: 81.3 psi (~350SHP) Maximum continuous with TOT above >738°C: 74.3 psi (~320SHP) Transient torque: 87.3 to 93.0psi torque for 15 seconds at 103 present N2, if TOT >810°C to <843°C then 6 seconds. 93.1 to 97.6psi torque for 3 seconds at 103 present N2, if TOT <810°C. MD500D with ALLISON 250−C20R/2 power plant (450SHP, 375SHP take-off, 350SHP continuous): Maximum take-off (5 minutes): 87.2 psi torque with a TOT of <810°C (~375SHP) Maximum continuous with TOT at or below <752°C: 81.3 psi (~350SHP) Transient torque: 87.3 to 93.0 psi torque for 15 seconds at 103 present N2, if TOT >810°C to <843°C then 6 seconds. 93.1 to 97.6 psi torque for 3 seconds at 103 present N2, if TOT <810°C. In game light helicopter AKA:MD500D: Maximum torque reading ~70psi with ~103% N2 & NR and TOT of ~750°C (low alt) Maximum torque reading ~50psi with ~103% N2 & NR (maximum alt) Maximum TOT = just under <810°C but that’s with N1, N2 and thus NR at >90% rather than ~103%. Possibility 1: If we perhaps assume the torque gauge is under reading ~27.6psi so ~70psi indicated is really 97.6psi it would follow that if you reduced the ~70psi torque reading by dividing it by 1.1192 (97.6psi / 87.2psi = 1.1192) to ~62psi that would equate to Maximum take-off power (87.2psi), if you then reduced the 70psi reading still further by dividing it by 1.2005 (97.6psi / 81.3psi = 1.2005) to ~58psi that would equate to Maximum continuous power (81.3psi) etc, which gives a more “weighty†less powerful feel but is still does not feel quite right even though if you divide one power rating agenised another it would seem to agree the dividing factors above, e.g. 420shp / 420shp = 1 vs. 97.6psi / 97.6psi = 1 (~70psi) 420shp / 375shp = 1.12 vs. 97.6psi / 87.2psi = ~1.1192 (~62.54psi - Maximum take-off power) 420shp / 350shp = 1.2 vs. 97.6psi / 81.3psi = ~1.2005 (~58.31psi - Maximum continuous power) 420shp / 320shp = 1.3125 vs. 97.6psi / 74.3 = ~1.3135 (~53.29psi - Maximum continuous power >738C) The only problem with the above range of values in-game is the drop between 70psi & 50psi between low and maximum altitude just does not fit any dividing value and is too large to be accounted for with power change or a constant ~375shp. Possibility 2: However if we infer any validity of the altitude tests I did for “altitude for hovering out of ground effect @ ~2660lb†for a ALLISON 250−C20B and remember that in real life this is taken at Maximum take-off power @ 87.2psi with N2 @ >102% <103%, N1 @ >102% <103% and NR @ >102% (487rpm) <103% (492rpm), then if we look at the only in-game torque gauge condition that the above other conditions will take place wile the torque gauges remains at a constant possible reading then that is with the in-game torque gauge reading 50psi from 0ft threw to 9600ft MSL, which also gives a fair assimilation of climb rate in hover being less than the climb rate @ 60kts IAS and that the @ 60kts IAS initial climb equals about ~1900ft/min from just above sea level (at ~2200lb). Also with an in game torque gauge reading of 50psi in the above there is NO more power thus torque available ~9600ft (@ ~2660lb) so trying to increase the collective only reduces N1, N2 & NR beneath <103% to ~90% - the SHP reserve above >375SHP to <420SHP is to ensure that e,g. you still have just about ~375SHP available at a given max altitude at a given weight. So if we take ~50psi in-game as being the 87.2psi Maximum take-off power thus being 375SHP then the following would be expected: ~55.96psi would = 97.6psi (87.2psi / 97.6psi = ~0.8934 thus 50psi / ~0.8934 = 55.96psi) ~50psi would = 87.2psi ~46.61psi would = 81.3psi (87.2psi / 81.3psi = ~1.0725 thus 50psi / ~1.0725 = ~46.61psi) ~42.6psi would = 74.3psi (87.2psi / 74.3psi = ~1.1736 thus 50psi / ~1.1736 = ~42.6psi) How do the above values around 50psi stack up relating to “powerâ€: 375shp / 420shp = 0.8928571428571429 so that would make 56psi 375shp / 375shp = 1 thus 50psi 375shp / 350shp = 1.071428571428571 so that would make 46.66psi 375shp / 320shp = 1.171875 so that would make 42.66psi The only problem with this range of values in-game is the massive possible rise between 50psi & 70psi Now, if you have read this far well done and if you have understood the above even if it’s just enough to see that out of possibility’s 1 & 2 there is some maths that stacks up for both, however BOTH fall down on one fundamental problem which is why in the game dose peek torque at low altitude peek at 70psi and at maximum altitude 50psi giving a devisor of 1.4 or ~0.7142 dependent on how you wish to divide 70psi vs. 50psi & given the real life 420shp & 375shp relationship? if we start by acknowledging There is an under reading of torque by ~27.6psi if we take the gauge at face value when showing 70psi. If we don’t take the gauge at face value but assume ~62.54psi or ~50psi are 87.2psi Maximum take-off power then the gauge is under reading by between 24.66psi (/1.3943) and 37.2psi (/1.744) respectively. Simply dividing the in game torque gauge readings between its respective low altitude 70psi maximum value and it maximum altitude 50psi yields a 20psi error (/1.4) With the engine on and collective fully down when on the ground there ~12psi of torque registering on the gauge, if the gauge is under reading by ~27.6psi when showing 70psi how much is it under reading when its showing ~12psi of torque just sitting on the ground with the collective down? If the in-game torque gauge is reading a residual ~12psi when on the ground with the collective fully down then it’s quite possible we would expect Maximum take-off power to be ~12psi lower than it should be on the current <70psi gauge display range i.e. to happen at ~50psi rather than an expected ~62psi. If we take the latter two statements pertaining to the residual ~12psi of torque and apply it to possibility 1 & 2 we get some logical consequence which solves the problem with each, which would be, if ~50psi currently in game best represents real life Maximum take-off power then it would follow that ~62psi would be the proper value in the current game if it was not for the residual ~12psi when on the ground with the collective fully down (50psi + 12psi = 62psi), if the residual ~12psi of torque was removed then then during hovering out of ground effect 9600ft @ ~2660lb instead of the torque gauge dropping to 50psi it would only drop to 62psi to represent Maximum take-off power, therefor confirming possibility 1 & 2 and how they apply to each other currently in game. :) So in short: ;) If you want to fly the light helicopter in a realistic manner with respect to climb performance and power given the current misreading of the in-game torque gauge and excess power then you should stick to the following torque gauge readings (until such time as BIS fix the torque gauge readings to reflect what’s happening on a proper number scale and perhaps fix some fudged values relating to torque). ~55.96psi would be Maximum Transient torque @ 97.6psi (~420shp) ~50psi would be Maximum take-off (5 minutes) @ 87.2psi (~375shp) ~46.61psi would be Maximum continuous <738°C TOT @ 81.3psi (~350shp) ~42.6psi would be Maximum continuous >738°C TOT @ 74.3psi (~320shp) If you are from BIS and are reading this then you need to look into/take note of: The torque gauge and correct its range of movement. The relationship of the TOT to other values. The amount of residual torque with the collective in the fully down position and controls centred (~12psi). How any residual torque and application of collective could conspire together to give too much effective lift by e.g. being additive (+12psi) or subtractive (-12psi) etc. (could also explain why the light helicopter is so light on the ground with zero collective) The intrinsic relationship between 375shp & 420shp being the same distance apart as 87.2psi & 97.6psi are to each other, which are both smaller relative gaps than the current 70psi & 50psi gauge relationship. To perhaps add the NR needle above the N2 needle (which is currently acting as NR) so the combined N2/NR gauge works correctly instead of inferring N2 from NR when the engine is running. To perhaps implement a “overrun clutch†in the physics flight modal so that when the throttle is closed/cut-off in flight (or you lose the engine – fault/failure/etc.) that the “engine†correctly disconnects from the main rotor so NR remains in the normal range during autorotation while the N1 & N2 fall to their correct value being ~65% rpm at idle or 0rpm for cut-off, as its currently implemented there is no “clutch†modelled so N1 and thus N2 are slaved to the rotor RPM (over-run clutch are fitted to MD500 to disconnect the rotor from the engine etc during shutdown and autorotation – the turbine slows at a faster rate than the rotor) And relating to the above overrun clutch point, hypothetically if you have gone as far as programing a “drag factor†for how quickly the turbine (engine) wants to spin down, then without a “theoretical†overrun clutch during e.g. autorotation the factor of drag from the turbine would be trying to slow the rotor causing the deficiency in rotor RPM we see in-game during autorotation? (relative to weight/ speed/etc) :)

err no, a MD520N is the no tail rotor type which also has the pointy nose like the MD500E etc. it is most likely an MD500D (type 369D)

The actual ground altitude for “Takistan†being incorrect for the place it is mimicking is of NO relevance what so ever to the tests I did as I am using pressure altitude and then verifying it with radio altimeter, so as it is its just mimicking a place <>1000ft MSL though I have mostly been using the A2 islands. (good old symbolic folder link) Takistan like all the other A2/A2OA islands/maps when set to the same date, time and good weather condition will all yield the same results ~70% of the time with minor deviation in the remaining 30%, it would be rather pointless to test using bad weather and unsettled conditions as there would be far to many random factors at work perturbing things, Typically May 1st 2011 at 8am was used, as well as Aug 1st 2011 at 10am, the assent time for 9600ft was 15min to 16min with the last 1000ft being very slow in the order of 5mins, with the A2 island they both have sea so both the radio altimeter and pressure altimeter should read the exact same value when over the sea, with A2OA maps there is no sea but the borders around the main map are quite uniform or if you can stay above your take-off location you know the pressure altitude at take-off so e.g. 9600ft could be verified by adding your e.g. 1000ft MSL take-off height to the radio altimeter AGL value which then should total 9600ft as per the pressure altitude reading. If you play around with the weather settings etc. without going to the extents of rain/storms etc you can seemingly perturb density altitude outside of a “standard atmosphere†causing +-500ft or more changes to e.g. 10100ft or 9100ft before lift/power runs out depending on the trend of the weather change.

there are some surprises if you compare in-game to what you would expect from a MD500D with a ALLISON 250−C20B using the rotorcraft flight manual data which show that things are going in the right direction with what BIS are doing. e.g. in game, if you load the helicopter with full fuel and have 4 people (euroman 1 & 2 + TKON pilot etc) in it then climb to the maximum altitude it will hover out of ground effect at 9600ft MSL using pressure altitude, if you repeat the test with just the pilot and full fuel you yield 16900ft MSL with the rotor at the normal RPM. (Remember ~9600ft & ~16900ft MSL) If I then take the official real world minimum flying weight of 1538lb, add the real world ~402lb of fuel for a full tank we get 1940lb excluding pilot/passengers, if we approximate a pilot or passenger as being ~180lb each we get a gross weight of ~2120lb with just a pilot and with a full complement of passenger we get ~2660lb gross weight. (Remember ~2120lb & ~2660lb gross weight) Now if I get out my chart that plots a “standard atmosphere†in temperature vs. pressure altitude (also density altitude but on a standard atmospherics day pressure & density altitude are the same) and look up the temperature for ~9600ft & ~16900ft MSL I get -4°C & -19°C, now if I look up “HOVER CEILING − OUT OF GROUND EFFECT (OGE)†for the ALLISON 250−C20B powered MD500D, and look specifically for the maximum gross weight for hovering at a pressure altitude vs. temperature given on a standard atmospherics day and compare ~9600ft with -4°C I get a maximum gross weight given of ~2700lb which is extremely close to the ~2660lb achieved, if we take ~16900ft & -19°C we get ~2150lb gross weight, so it shows that even though I don’t know the exact weight BIS assign to pilot/passenger weight or the exact figure they use for fuel or the helicopters zero fuel weight one can only surmise they are close to the real world ones and using a standard atmospheric day. :)

Here is some more info, The height velocity diagram (height above ground vs. IAS speed) & the maximum gross weight limit diagram (for calculating the maximum gross weight vs. “effective†altitude above sea level that applies to the height velocity diagram). the area that has no cross-hatching are altitude (AGL) and speed combinations (Kts IAS) that an “average pilot†should be able to carry out an autorotation at a density altitude corrected maximum permissible take-off weight. FYI: the cross-hatched portion on the left side of the height velocity diagram is what is known as the “Dead man’s curve†also the deeper your to the left of the curve the harder any autorotation is going to be. Also it’s a bit hard to see, but the recommended take-off profile line continues up the 60kts IAS vector to ~295ft AGL. http://myweb.tiscali.co.uk/toddysspace/page_5-20.gif > 100kb http://myweb.tiscali.co.uk/toddysspace/page_5-21.gif > 100kb http://myweb.tiscali.co.uk/toddysspace/page_5-22.gif > 100kb

FU III was also based around Seattle etc, spent many hours of fun flying and gliding in that.

dev-heaven.net issue 23276 - Light helicopter AKA: MD500D - autorotation rotor RPM. ;)

I quite agree in “real life†they do slow to a slower speed in the flare before levelling out for touchdown, but that would be indicative of them being able to maintain more rotor rpm on the decent and in essence being able to apply some collective to effectively slow the rotor from going over-speed and thus reducing the rate of descent or to reduce collective to regain RPM, they also get more energy from the flare so can naturally slow more and can have slightly longer to level out/land at a lower speed because of the extra RPM and that’s besides the extra cyclic control authority they would have to level out from the flare. With the exception of the S-92 clip all the other clips I posted show lightly loaded helicopters, the S-92 was at maximum take-off weight, if you look at the abundance of clips on youtube both from inside and outside it becomes clear from looking at the rotor RPM gauges (inside) it’s no bother to maintain ~100% RPM up to just before transition to flare and that during flare they will get maximum RPM >100% while applying some collective as they trade the rate of descent energy for the forward speed energy in the ground effect zone, or from the outside you hear the rotor RPM climb on entry into the flare. ---------- Post added at 10:58 AM ---------- Previous post was at 09:29 AM ---------- Anyway, some official factual rotor RPM during autorotation from the “ROTORCRAFT FLIGHT MANUAL MD 500D - Model 369D†(30 Sep 2010 revision, MD Helicopters Inc.) Taken from section IV Normal Procedures - Autorotation RPM: 485rpm @ 2250lb gross weight @ 60kts IAS (sea level to 1000ft) with the collective fully down. With gross weights above 2250lb increase collective control as required to maintain approximately 485 RPM. Rotor speed will decrease approximately 10 RPM for each 100 pound reduction in gross weight and increase approximately 6.5 RPM for each 1000 foot increase in density altitude. Implications derived from other statements in the “ROTORCRAFT FLIGHT MANUAL MD 500D - Model 369D†The Empty Weight/minimum flying weight is 1538lb so is +fuel +passengers +cargo weight etc, which logically gives a minimum ~414RPM @ 60kts IAS (sea level to 1000ft) excluding fuel, pilot/passenger & cargo weight which only server to increase RPM. The MTOW is 3000lb so the rotor RPM could increase by ~75RPM to 560RPM unless it was checked by collective being applied to hold >485RPM <523RPM @ 60kts IAS (sea level to 1000ft). Maximum fuel weight is 402lb (234L) with optional self-sealing tanks to 416lb (242L) with standard tanks. Thus if you are in a MD500D flying and you have to autorotate after you have run out of fuel and you weigh 170lb and you are intend to land at just above sea level from 1000ft you would reasonably expect to see at the very least ~17RPM to account for your weight and a further ~414RPM for the helicopters weigh giving a total of ~> 431RPM @ 60kts IAS which would also mean if you wanted to achieve maximum glide or minimum rate of descent you could apply collective to maintain 410RPM at either 60kts or 80kts or regain some RPM afterwards.

A bit of general flying around, landings, etc. :bounce3: JZqeJYe2K3M :rolleyes:

The speed was 60kts to 80kts IAS which is correct, what maybe makes it look fast is the >3000ft/min descent rate without rotor RPM gain, if you go slower than <60kts IAS then you will have a steeper descent which requires more stored rotor RPM to pull out which is made harder because the game is not allowing sufficient rotor RPM to be gained. e.g. of real life autorotation: MD500E 180deg full down autorotation eNJSFXuwGQU full down autorotation in a Robinson R22 h5WoDFwikfQ 360deg full down autorotation wOJSo6_F6mE full down autorotation iRPTHaxEF9E S-92 full down autorotation 4JqmoWAhv5g MD500E full down autorotation NIvfBQcBb8E EC-120 full down autorotation phaWRjAVnes Huey 180deg full down autorotation PcVxRzBfY2s

Some autorotation attempts. :eek: Kb77ZMaPXWQ 4 people + full fuel.

It has potential, but they need to listen to some E.g. Ash Ra Temple (AKA: Ashra/Ash Ra, Manuel Göttsching) for inspiration for instrumentals. e.g. Echo Waves Eight Tracks Blackouts Boomerang Shuttle Cocks Lotus Pt1 / 2 77 Slightly Delayed Midnight on Mars