hjwalter

cj75s,

As johnhinson already points out, this is not as easy as you may think. I have no experience with what leuen above writes.

These basics will already make it extremely difficult, if not impossible, to create a working AI helipad as part of any addon scenery object and that includes offshore platforms. The main reasons for this is because any AI VTOL take off/landing will always need to take place via a specially created "airport runway" and as far as I know that's the only way. However, the FS9 definition of a runway is rather "flexable" in that it can technically be made very short but can also be made to be invisible so that the underlying visible scenery is not disturbed. You will also need a specially dedicated parking position somewhere and a taxiway including a "hold short position" just before that runway. Also, don't forget the two so called "start positions" and (most important) that the helipad itself will need to be hardened, otherwise any heli, AI or flyable, will always fall through it.

There are methods for "hardening" such an addon scenery object's helipad but such a helpad can then only be used for flyable VTOL heli's and does not need to be classified as an official airfield.

However, having active AI VTOL heli's take off and land anywhere at all, is at existing airfields/airports, which must then include one or more specifically created (parking coded) parking positions.

Good luck

Hans

Hi there Wobbie and Defaid,

Wobbie, I'm jealous about you living in Cape Town and especially every time I see that blue Table Mountain (without its normal table cloth) in your logo. In my younger days and that was many many moons ago, my family and I used to live in an appartment along Kloof Street, if that still exists. I grew up further in the city of Bulawayo in the at that time still named Southern Rhodesia and came to the Netherlands in 1962 to further my studies.

Now then, back to FPS business:

My basic knowledge about any kind of electronic apparatus with a picture screen, is that it's frame (or refresh) rate was always standardized at the 50 FPS (European) AC frequencies or 60 FPS (USA) and which needed to be synchronised with the so called "frame pulses" contained in the incoming picture signal. Between each such "frame pulse" 650 (European) picture lines were written on a screen from top left to bottom right corners and if I remember correctly, it was 465 lines in the USA.

However, when I saw that my TV monitor was quoting (some kind of) basic refresh rate at 60 and that Defaid had seen the same on his monitor -----. Well, I immediately thought that not much had changed through the years as far as the steering of such screens was concerned. On the other hand, I was not able to imagine how any kind of monitor would under those "stone age" circumstances, be able to handle the type of sometimes "unlimited" and extremely variable FPS values coming from our FS9 Sims. Hence my rather shy reactions about modern TVs and monitors having been improved substantially so that they can handle such extremes without protests of any kind.

Defaid, you may have a very good point there about synchronising maximum FS9 FPS with our monitor's or TV's refresh rates and I'm all ears about any further developments in those very technical new possibilities.

Regards

Hans

defaid,

If your monitor is being fed by a DC power supply then your "refresh rate" of 59/60Hz is most probably being created within your monitor itself. In this respect my information has in the meantime also changed, e.g. that all modern TV sets, like I'm using as a monitor, have also become independant from, not only their AC supply voltages but also from their AC frequencies. Commercial production standardization maybe ?? Anyway, if you are happy with your existing monitor -------

Today I've been experimenting intensely with my FS9 hardware FPS display settings for the very first time in many years, all the way from 10 upto unlimited but at 10 the stuttering was intense, especially when panning around in "heavy" sceneries and via different flyable aircrafts in external views. However, at my traditional setting of 30, everything was smooth again, while at "unlimited" my FPS never came below 40 and sometimes even reached as high as 100+, which convinced me that 30 was (at least for my FS9/hardware setup) a good setting. The 60Hz information on your monitor and on my TV, can only be some kind of default and/or of informational value.

P.S. I still believe that structurally mipping all scenery and AI aircraft textures is a good practice.

Regards

Hans

Hi defaid,

Your remark that you have locked your FPS at 60 in order to match that of your monitor has suddenly got me sitting upright and wide awake because as far as I know the standard FPS of any monitor (or TV set) is directly steered by the AC frequency. Therefore 60 Hz in the USA and 50 Hz in Europe.

My monitor (= a Panasonic 60Hz. TV set), which is therefore most probably a USA version, while my European AC power supply is 50Hz. ....... and all that while I'm supplying it with an FS9 maximum output of 30Hz ???

However, you are completely correct in saying that the FPS supplied by FS9 can vary strongly dependant on load etc. so, why everything in that hardware area keeps working correctly remains a mystery, at least to me. It may have something to do with a HDMI (type) connection, which seems to override evrything related to AC/FPS frequencies.

Tomorrow I'm now going to set my maximum FS9 FPS at 60 to see what happens and then at 50 but my expectations are not high because 30 FPS has seemingly already worked problem free for years in my setup.

Anyway, a very interesting thread indeed and ....... Long Live FS9 !!

Hans

Would just changing the wind direction and strength not help if this is saved with all at SOCH saved departure flights ?

Hans

defaid,

Thanks very much for your in depth technical explanations but it remains my opinion that when it concernes the general mipping of scenery textures this should increase my frame rates and that then becomes my way to go, even if my more "modern" hardware setup would not "struggle" without such textures being mipped. My frame rate has even been maximised at 30 FPS for many years already, which theoretically leaves more capacity for other FS9 (background) work.

However, comments remain welcome.

Regards

Hans

defaid,

I've now done some tests with three different flyable aircraft, each of them fully DXT3 textured and done with and without mips. However, I did not see the crispness differences as in your two pics above. So, the only thing I can now think of is that you and I have different graphics cards and/or display screens.

My graphics card is an AMD Radion HD 7900 series, which outputs to a large Panasonic TV set (resolution 1920 X 1080) connected up via a HDMI cable. However, I must also admit that this very modern TV set has a whole series of it's own built in adjustment possibilities and some of those include picture "sharpness", colors, contrasts, etc. etc. All this is most probably the reason why I was originally not directly referring to flyable aircraft texture mipmaps but far more to those of scenery textures about which I've had my own mipmap theories for many years.

One of these theories is still that the highest possible frame rates should always be sought after and mipping scenery and AI plane textures were one of the surest ways to attain this but a few display problems remained here and there and the questions I had about these were the subject of my original posting in this thread. However, judging by your reactions and those of Alan, I have now understood that my few scenery problems still remaining are not very easy to rectify but because they are so few, it doesn't really remain a problem.

Anyway guys, thanks for your reactions, I learned a lot from them.

Regards

Hans

alanmerry,

From your reaction above and especially from your "Mip Maps unticked" remark I conclude that you structurally remove scenery/texture Mip Maps wherever you can ???

Does this not defeat the very purpose of Mip Map technology, i.e. that your scenery items/objects are only visible at short distances and that they suddenly/unrealistically pop up when you approach them ?

Quite some of my own (airport/airfield) scenery objects keep popping up at such short distances, even although I have structurally added Mip Maps to all their textures ???

I use the same softwares as you evidently do but I ONLY "untick Mip Maps" for my flyable aircraft textures because firstly, these then remain somewhat smaller and secondly, they are never viewed from longer distances.

Keep the comments coming guys because this thread is becoming more and more interesting !!

Regards

Hans

jmie,

What I need to be able to help you is the name of your complete and originally downloaded B787-8 file, which contains it's dedicated model folder, air file, at least one complete texture folder and it's complete dedicated aircraft.cfg file
I need to be able to see in external view, the aircraft standing on it's wheels (or floating), while at the same time having the same aircraft's aircraft.cfg file visibly available. Only then can I edit the contact point section in order to stop it from "floating" or sinking into the ground, etc. This is because it remains a so called "trial and error" activity and is not the same for, e.g. B787-8s with different model/texture files.

Regards

Hans

chris_eve,

My main FS2004 folder is 135 Gb, in size, it contains a total of 1.029.131 files in 8288 sub folders. I also have 1356 AI aircraft/paints of all sorts and sizes flying around all over the world, mostly between my very much edited/expanded (only for personal use) addon sceneries. Additionally, my FS2004 has, through the years, been very strongly compacted and edited to get rid of all kinds of unnessesary ballast. This also includes the structural size reduction of far too highly detailed scenery textures (mostly --> DXT3/DXT1) wherever possible. This is in fact where I  began to run up against the subject of this thread, namely a number of not (yet) fully understood mipmap issues and of cause, quite some black alpha-channel transparrency problems.

Almost all my sceneries and especially the smaller tropical ones, have been strongly expanded, mostly to make them look less deserted but all of them based on pure fantasy on my part, e.g. extra tropical palms/coconut/trees/buildings/vehicles and self made local paint static aircraft, vehicles, etc. For this I have extensively used the EZ object placement program and mostly by using so called library file senery objects.

I'm still using the very original DVD copy of Win-7 64bit Professional, which has in fact never been updated, simply because my FS9 machine has never had any internet connections and I prefer to keep it that way because "If it's not broke then why fix it or have it fixed" !! RAM 32.0 Gb but sadly, FS9 only uses a very small part of this. CPU i7-3930K 3.8 GHz.

3 SSDs, two of which (25Gb each), contain my C partition (Win-7 etc) in RAID-0 setup, while the third one (D = 850Gb) contains my whole FS9 and most of it's supporting programs.

I also use this machine (and most of it's RAM) for the video processing of, e.g. self shot video movies and for finally burning them onto DVDs.

And yes, my real world crop dusting flying experiences many years ago, combined with an international ICT carreer has got me "hooked" onto flight-simming and FS2004 was the definite choice I made after FS98/FS2002) and mostly because of all it's supporting software, etc. etc. It has most certainly kept me off the streets and out of sleasy bars through all thos years. LOL !!

Regards and long live FS2004/FS9

Hans

Hi Guys,

After much research within my own massive FS9, I've now concluded that structurally replacing/adding mipmaps to all my existing scenery and AI plane textures, can cause unpredictable visible irregularities here and there, more often concerning those textures which are called for by addon BGL files from older sim versions.

Moreover, some scenery authors also seem to have omitted/forgotten the BGL programming for the handling of mipped textures and which then automatically means that editing/adding unnecessary mipmaps to the related textures, can have further unpredictable results as well. At least that's the way it all now very strongly seems.

Anyway Guys, thanks for your reactions and long live FS9 !!

Hans

jmie,

Could you please quote the exact file name of your "floating" B787-8 aircraft, so that I can download it myself in order to test your problem and to possibly solve it for you.

I hope it's not payware though.

Regards

Hans

Hi Guys,

Right from the very beginning when FS9 was first launched, I've embraced the general theory that ... ALL ... (standard and addon) scenery BMP textures found anywhere within FS9 and which are all viewed from variable distances, should be mipped, no matter how they are compressed as DXT1, DXT3, etc. This also includes all AI aircraft textures, standard or addon.

The only possible exemptions would be those textures related to flyable aircraft and which are in external view, normally never viewed from any great distances.

To check and to edit all such textures I've been extensively using a program called "MipMapManager v.0.03", which can firstly delete all mipmaps from any selected (and previously backed up) texture folder, followed in a second run by replacing them in it's own standard way.

However, it sometimes seems that the newly mipped BMP files are not always welcomed by certain BGL files, mostly by those originating from older sim versions and which can then cause blurries and other strange visible effects, e.g. scenery objects unrealistically popping up at far too short distances.

My questions are therefore:

Is it possible that some possibly older BGL files, have some kind of inbuilt mechanism for creating their own mipmap-like effects when using their own specific textures and which therefore do not need "extra" mipmaps ?

Are BMP file mipmaps always standard, whatever that "standard" may be ?

Any comments on my general mipmapping theory ?

Regards

Hans

In the meantime I've compared my active main texture folder contents with backup versions and found that there were certainly more unexpected and/or strange texture compression differences. I also found some textures which were missing their previously existing alpha channels.

I now no longer trust this folder and will proceed to overwrite it's textures by all those from an older backup, while for safety reasons, leaving any newer ones, which were not (yet) backed-up.

I'm still trying to figure out what had caused this absolutely huge folder to have become edited in such a structural way and without me ever noticing it.

Long live FS2004 !!

Hans

Thanks a million chris-eve and defaid for your help.

I copied/pasted all default and other FS9 texture names beginning with "taxi ......", from my oldest backup (2016) into my main texture folder, overwrote anything found there and that immediately solved my problem.

And yes, my problem seems to have been caused by a recent automatic scenery installer, even although I always install those into a special safety folder nowhere near any of my active FS9 folders. In any case never directly into my FS9.

Thanks again Guys.

Hans

Hi All,

I've recently and very unexpectedly run up against a new FS9 problem in that solid center and edge taxiway lines, which are all drawn by my trusty old AFCAD program, have suddenly become dashed when viewed from around 100 meters/yards and further. At closer ranges the lines are all rendered correctly but the problem moves along in front of me as I taxi in any aircraft and at any airport. In fact, a really terrible sight, also when approaching.

I've tried editing all display options from within my FS9 and also those of the graphics card itself but nothing seems to help.

This all now causes me to suspect the AFCAD textures themselves, e.g. no mipmaps and/or incorrect DXT compression but wherever I search, I just cannot find where these very specific AFCAD textures are stored nor can I find their names from within the AFCAD program itself.

Can any of you experts point my nose into the correct direction .... Please !!

Any reactions/help will be strongly apreciated.

Regards and thanks in advance.

Hans

Mark,

I'm still using the very original Win7 64bit from the original DVDs for my huge but efficiently organized FS9. This totally to FS9 dedicated machine has never even had any kind of internet connection, so never any issues after Win7 updates. However, these sudden and unexpected keyboard issues have been bugging me right from the very beginning but I've learned to get used to them. I suspect that they have something to do with my keyboard itself but cannot find any way to prove it because other keyboards display the same problems.

Long live FS9 !!

Hans

I sometimes have the same problem, in that some keyboard functions suddenly and unexpectedly, no longer work. I solve the problem every time by re-storing my FS9.cfg from re-named backups in the same folder and as soon as everything works correctly again, I copy/paste my FS9.cfg file a few times and rename the copies into, e.g. FS9.txt, FS9.new, FS9.xxxx, etc.

Why and how this occurs remains a mystery.

Hans

Thanks chris_eve for your reply.

It only confirms the developing notion, which I already had on this Guernsey subject. Too bad but the colouring of the foto scenery itself is seasonal and the summer ones tend to look somewhat greener/better.

Now then, on to Jersey, where I've already seen some mesh and coastline issues.

Anyway, thanks again for your reply and confirmation.

Hans

Hi All ye experts,

I've had all three of the addon (UK) Channel island airports for a long time already and I recently found good looking "cover all" satellite photo sceneries for both Guernsey and Jersey in the the library. I downloaded/installed both of them but the colours of the Guernsey airport terrain were not really to my liking because they were just too bright yellowish/brown.

No problem I thought, so I made my own SBuildrer terrain polygon for the whole Guernsey airport area, like I've done for so many others before .... BUT .... my new terrain (= VTTP file) doesn't show up in this particular scenery, most probably because it remains hidden under the photo terrain. However, the Adcad aprons, taxiways, runway, etc. do show up and work correctly.

I've already tried to place my VTTP file in a separate higher priority folder but that doesn't help in any way.

Does anyone have a solution for this problem, so that my VTTP polygon actually appears on top of the overall photo scenery ?

Thanks for any suggestions/solutions.

Regards

Hans

Baron Fritz,

Your first impressions about the Model Converter X complexities are evidently more or less the same as mine. On top of that I regard really diving into this program only for my external gear view issue, as a completely separate adventure and in my specific case, with a rather low priority.

In the meantime I will perform experiments with jgf's items 8 and 9.

Regards and good luck.

Hans

Baron Fritz and jgf,

I found and downloaded all three of the mentioned programs and took a quick "sneak-peek" into each of them, with my nosewheel problem kept in the back of my mind.

However, my very first impression was that the sheer volume of complexities and choices, especially within the ModelConverterX program, made me initially agree with jgf and even more so because copying/pasting (= cheating) the necessary parameters from other FS9 aircraft's contact point lines, worked just as well .... and .... a lot quicker. Therefore my sincere compliments to those developers who actually went through all those complexities to get their contact point parameters so close to the real world actualities and also very much so for the pioneering specialists at MS, who made this all possible in the first place.

I will certainly take another good look at the ModelConverterX program as advised by Tom Gibson but now only as a possibility for improving gear suspensions ..... without ..... any wheels sinking through concrete runways/taxiways. On top of all that you never know what else I might run up against.

Hans

Hey Guys,

Yes, this whole aircraft.cfg "Contact Point" section certainly seems to keep us on our toes, mainly because of their inter-actions with other entries within the same section and even with parts within the lines themselves.

It's in fact one of the very first things I always check after downloading any new plane (AI and/or flyable) and am often surprised by the amount of tweaking necessary to get the new plane to visibly and correctly stand "on it's three wheels". To check this I press my "Y" key with the new plane in external view and I just keep on tweaking and pressing my "Y" key until the aircraft no longer moves.

However, I've never even looked at issues like suspension, etc. and never really deemed those to be important untill by pure chance suddenly seeing an otherwise correctly tweaked nose wheel sinking into the concrete while braking. This had made me very inquisitive as to possible technical solutions, other than just making the nose wheel 100% "stiff" (= cheating).

Regards

Hans

Hi there Tom,

You are always way ahead of most of us armchair pilots with your deep technical knowhow on many FS/PC fronts and because of that, the saying remains true that flight simming, is far more complex for most of us than real world flying.

My nose wheel sinking through the runway/taxiway problem, was definitely not a serious issue but was far more born out of my inquisitiveness based on the notion that runway/taxiway surfaces should generally be as hard as concrete and in no way should let gear wheels sink through them. In my mind there were therefore other processes involved eminating from the aircraft in question and especially from it's "contact points", some parts of which will always remain a mystery, at least for me.

In the end I managed to solve my "issue" by what I called "cheating" but why and how this actually worked remains unclear, on top of which I have absolutely no experience and/or knowledge about the software you are evidently using but in the meantime I will certainly try to find the "ModelconverterX" program and will have a go at seeing what it does and/or can do.

Anyway Tom, thanks for your strongly professional reaction and .... Long Live FS2004 .... !!

Regards

Hans

Jgf,

Thanks very much for your kind explanations, which only add to my personal experiences which are that "contact point" sections are extremely difficult to fully comprehend because different parts within each line, seem to influence other parts within the same line. So, after endlessly messing around with my Warthog's nose strut/wheel specifications without any form of success, I finally decided to CHEAT !!

I've had a navy Grumman fighter jet in my collection for many years and which I predominantly use for carrier operations (= hard landings/cable trappings/catapult launches, etc.). That aircraft did not display any of my Warthog's problems so, I copied/pasted the non nose wheel strut positioning part of it's first contact point line into the same Warthog's line and PRESTO !! That seems to have done the trick, with only a remaining acceptable part of my Warthog's nose wheel tire still visibly sinking below a runway/taxiway surface, while braking.

Only problem now left for me is to try to understand the why and how, including in this specific case, the possible influence of the Warthog's model (MDL) file.

Thanks again and regards

Hans