klem

Yes, it's already reported, I was adding info in case it helped.

If it helps at all, my 'left' monitor is monitor number 4 as seen in windows/Nvidia setup: monitors numbered 4 2 3. Monitor number one is a lower monitor not in the Surround setup.

A good assessment of the pilot probably responsible by someone I know to be diligent in the extreme. Unfortunately we are not getting the MkIXe with the 2x20mm and 2x50 cals but the MkIXc which at least has the 2x20mm (and 4x 0.303). It will be enough to knock down those pesky 109s and 190s. :thumbup:

I'm adding here in case it's related - or not. On mission load the loading screen switches from centre to left screen. Map is also on left screen while click points remain on centre screen and have to be 'found'.

If that's a promise I'll clear space in the hangar :D

As you can see from my youthful slender frame I too am a Spitfire pilot. Virtually. All Spitfires are beautiful but after a flight in a Rapide with MH434 formating alongside I had the pleasure of leaning against her, arm resting casually on the cannon fairing, as you do, and I began my story.. "There I was at 30,000 feet..... " More screenshots please, I am going cold turkey.

........ or to put it another way as I learned many years ago getting my gliding licence, set it up then hold just off the ground and try not to land..... until it just does.

WHY485, I've been playing with the fx file that you created for the opposite reason that you created the mod, I wanted to find a playable solution to WWII/Korean eyeball dog-fighting and I don't like the way the stock imposters are rendered. We will always be up against the MkI eyeball versus monitor problem so a compromise is always going to be necessary. I understand your reasons for going 'realistic' but the DCS visibility system is flawed and IMHO the problem is not with imposters but with model rendering/contrasts at the far rendering distance where there is a 'vanishing point'. So, I also wanted to overcome the vanishing point at switch-over from imposter to model. I'm still playing with it and have actually come back around to the the stock imposter sizes (maxsize = 16) and discovered that it is more about contrast and managing it against distance than anything else. So first off, full credit to you for the fx file mod which does this. Maxsize 16 seems to be about the right size for matching the imposter size to the model at switch-over although that might still change, perhaps to 14 or 15. I also introduced a general contrast factor (less or more) to be applied to the overall results of your distance/contrast calculations to tweak the overall levels. At the moment there is a stage before model rendering where the imposter(?) is a solid crude aircraft shape for the MiG-15 so I still have more work to do on contrast levels although the switch-over seems to have improved as if the imposter is being brought in earlier than before. The distant imposters seem to be different for the MiG-15 and Mustang so I have to research what imposter 3d creations are being used for these although I doubt we can change them, e.g. at longer distances the MiG imposter looks a twin engined a/c but that could be a poor and distorted representation of the wing fences. I'll keep tweaking over the next week or so and see what I can come up with. At the moment my imposters are still too dark at distance. Also, although the switch-over seems to be dictated by model size, it seems the size of imposter that actually first renders can be adjusted using IMP_MIN_DISTANCE so that it can begin to be scaled down at distances closer than the most distant model rendering and so allows imposter first-render size tweaking, i.e. the closest imposter doesn't have to render at MaxSize. I know our objectives are completely different but thanks for the fx file.

Thanks Stonehouse. That put me on the trail. I am just being opportunistic btw.:) EDIT: forget all that, I just found out my GCICAP file is not the same as the latest!

I am trying to call GCICAP function from the ME Action DoScript as follows: gcicap.spawnFighterGroup('red', 'Aggressor1',1, 'Beslan','air', 'CAP',false) I am getting an error to do with the Airbase (Beslan). Beslan is red and I have placed a zone over Beslan named 'Beslan'. Can anyone see any error in my call?

Excellent flying guys, well done!

I'm raising this again because the real problem is not with imposters. It's possible to change the imposter settings in the appropriate files and I can get a reasonable setup doing that. In fact the EDs options aren't so bad. The real problem is that the Model, not the imposter, fades out far too quickly and makes it impossible to keep the a/c visible in close dogfights. Typically in the 1nm region the a/c you are fighting simply disappears, first into a vague pale colour (NOT camouflage) them washed out altogether as it vanishes against the terrain. This is not a case of camouflage, it simply vanishes. Try it Sabre vs MiG even with imposters set to large. There's a mission attached. I have created imposters as large as a house but when I get close in the model takes over and the problem begins. Those of you familiar with the imposter files may think the distance at which the imposter takes over (and therefore could be used to 'overwrite' the model) can be set using the maxSize but it seems from all the tests I have done there is an overriding distance value within which the imposter simply will not be drawn. Curiously the effect is more apparent when aircraft are going away from me than when they are approaching. ED need to take a serious look at that. I know there are people who will say 'in RL a/c are hard to see' but not at a mile. Perhaps, as someone has suggested, this is inherited from DCS being largely a BVR/Radar driven sim with no need, prior to WWII/Korea, to consider near visibility too seriously. EDIT: The 'vanishing point' is actually about 1nm not .3nm, my mistake, That's for a MiG-15. Sabre vs Mig_24MP_No End.zip

UK

Thanks for the information guys. Yes, I can see now that the Options file captures the mission builders current setting so can enforce Small/Medium/Large. As pointed out, what that actually means can be overridden by the local imposters.lua values. Having played around with these settings it can definitely help or even hinder distant imposter detection. I think the vanilla settings aren't very good (WHY485's do seem better) but the ED enlargements go too far for the imposters, particularly on fade or lack of it. I know they will be popular for gameplay and that's fine for those that want to use them. However, for me, the more fundamental problem remains. The Models themselves are harder to see than in RL and that creates a real problem for eyeball dogfighting. I live 3 km from my local airport (light aircraft) and can see clearly the aircraft in the air against a clear sky and even quite well at 4km in the approach. Against cloud it is even easier. They are clearer than seen in DCS. They are not necessarily full contrasted and I may not be able to be sure what type it is but I have no problems picking the shapes out against the sky at 3-4km. ED seem to wash out the model contrast too much too quickly. Now if someone has a fix or that...... Also, they may be technically perfect on size but we all know the problems of monitors vs the Mk1 eyeball. I think the reason the vanilla imposters (imposters off) are too hard to see is that they start from the poor position of the Model contrast and are designed not to give a step increase in contrast when they kick in. As a result of the model visibility problem the step increase in contrast when the imposters do kick in can easily be seen in Enlargements, even with WHY485's universal imposter settings.

Why485, can you tell me if this mod is effective as a server-side setting or is it only 'local' to the PC I am flying on regardless of the server preferences?

Thanks blue_six (and yes I owe you a PM but life.....) It's hard to trim the stick 1.5" forward from the trim light when I 'hide' the stick but that's my fault. I will experiment with dabs of the trimmer - see below. I have gone some way to improving the trim by programming my HOTAS to give 0.1sec blips when I operate the Hat with a 0.25 sec delay before the next blip occurs. You may ask why 0.1sec? Why any specific time at all? Well, it's because we have no direct equivalent to the RL trim reaction or more to the point we have no way of equating the RL trim switch/elevator trim timing to the timing/effect of our HOTAS's. I think. I will continue to tweak the timing but my gut feeling is that the vanilla trim sensitivity doesn't reflect RL because the actual 'HOTAS time operated' is not necessary the same as in RL.... Belsimtek chip in please.

I am running 3 screens in three viewports too. Please can you explain: useAbsoluteFOV = true; useAbsoluteAnglesShift = true;

Can anyone explain why the game crashes completely when I try to reload the same mission on a timeout (3 hours). In Actions I do not "End Mission" but simply reload the same mission. Even if I did an "End Mission" before reloading I had the same result. Logs attached although I have no means of reading the dmp and crash files. Mission file also attached. Logs.zip Korea_Late_51.miz

Well, the ailerons were a real problem right from the start with ballooning fabric at high speed. Maybe the elevators weren't such a problem. They were always very sensitive anyway. I read somewhere that metal elevators came in with the Mk21 due to handling problems but may then have been retrofitted to older spits.

Hit Quote or New Reply and scroll down to and click on Manage attachments. Browse your folders for where you saved the chart file and upload it. Alternatively copy the link to the website and paste it into yiur reply.

Picking up on this 'Trim' thread for two reasons. 1. I agree about the overly sensitive trim. One (even fast) tap on the HAT and you go from a few degrees nose down and a healthy rate of descent to a few degrees nose up and a healthy ascent. It's not possible to trim it to within a reasonable point of level flight and it just doesn't seem right. You certainly can't use it for fairly fine formation flying and light stick work. 2. When I spawn the Sabre the tail is trimmed very nose-up (tailplane rear edge very high). On takeoff the a/c will lift off the ground with little effort at around 130kts but it immediately goes very nose high. If I trim the tail surface to be parallel to the curve of the rear fuselage (about 5 seconds of trim-press and it looks fairly neutral) it takes a good pull to get it off the ground but it doesn't then rear up. I can do this with full flap (around 130 kts) , no flap (around 150 kts) or about 2/5 flap (130kts). Another odd thing is that after takeoff with any amount of flap I raise the flaps and the nose rears up when it retracts through the last ~2/5 flaps then it settles down. I'm very familiar with the concept of change of attitude with flap but it all seems to happen with the last part of the flap travel, before which it is reasonably stable. Is this correct?

Doohhhh! Many thanks Steggles. I read somewhere that getUserFlag and setUserFlag had to be cast to string using ('..var..'). Of course, I realise now that clashes with the integers in the ME flag numbers. Works just fine now :)

I am having problems addressing the same Flag number value set in a lua script (Do script file) and the same Flag number value accessed from the Mission Editor Do Script. Do internal and external lua scripts create separate instances of the same Flag number and consequently return separate values?? For example, I "setUserFlag" 4001 = 1 in the lua script file and read it ("getUserFlag") in the do script box. I have debug messages in the lua file that say Flag 4001 = 1 while in the ME the do script value is returned as 4001 = 0.

Well it's been entertaining and we'll never achieve an agreeable answer because we are unlikely to have all those variants. Kurfurst, it's true the LW fighter production was huge in 1944 but you can't only compare the 109 production figures with Spitfires as a measure of combat scenarios because they were also fighting many P-47s, Lightnings and particularly P-51s in huge numbers. What really matters in this argument is how many 109Ks met the Spit IXc. I believe most 109Ks and many FW D9s were fighting the bomber escorts so hi alt P51 missions will be appropriate. The shorter range SpitIXs were much more likely to meet the other types which we don't have and is why this slightly OT strand has arisen. Still a few Spit XIVs might offer a historical balance and some 109Gs/FW190As will allow us to create some more realistic scenarios around 1943/44 and 2TAF.

Wow, I seem to have touched a nerve! :) It was only a semi-humorous thought but reflected the alleged unreliability of the 109K due to manufacturing (materials?, facilities?, sabotage?, whatever). Actually, with the complaints about the 109K not being a true numerical contemporary of the IXc (given that the only 109 available is the K) a minor 'Condition' of say 98% might be a historically balancing factor. Why should LW players have such an alleged "overpowering advantage" over the "poor old IXc" AND equality of numbers? Mind you, I don't recall Johnny Johnson complaining about 109Ks. Probably because by that time the LW was a spent force. And they didn't have the numbers to face up to the Allies anyway. Hmmm, ok, that's the answer, a 3:1 Allies advantage of numbers over the LW. Design your missions accordingly, sorry, historically. :) Look at it this way. If the Ks were to some degree unreliable and you had reliable 109G's available, what would you choose to fly? You'd have a choice with some historical risk attached to the 109Ks. And would mission designers limit the number of 109Ks available? I know these ideas won't be adopted but......