Jump to content

hjwalter

Registered Users
  • Posts

    565
  • Joined

  • Days Won

    3

Everything posted by hjwalter

  1. Roger, I'll send you some screen shots and more technical details tomorrow but I already have the feeling that there's a structural problem at play here, a problem which cannot easily be solved, except of cause to flatten the whole island and the sea around it, to zero feet !! However, in that case deleting the island and all it's "to and from" flight plans, would then be a better but sad option. Anyway, I'll first await your reactions to my screen shots, etc. Regards and stay safe. Hans
  2. Hi Guys, Now that we are in a corona lockdown anyway, it's become a good time to take another look at some of my older sceneries and one of those is the Hierro airfield (GCHI) on the Hierro island, which is part of the very well made Canary Island archipel, made by CanarySim quite some years ago. The (Scasm) airfield itself is also very well made but it has a "thorn in the eye" problem with sea water climbing up the island's cliffs, not only on the sea side of the airfield at 105 feet elevation but also everywhere around the island and mostly where cliffs meet the sea. This visible anomaly, especially around the airfield itself, is so great that even trying to somehow mask it, e.g. with Abacus EZ or RWY12 scenery objects, becomes impossible. It's most probably some kind of conflict between mesh and LC scenery, which seems especially bad because the island has a very jagged coastline. Small flattens at zero feet to remove the water walls on the sea side of the airfield do in fact work but these do not remove the water texture on the thus produced new cliff side(s). Ideas or solutions anyone ? Thanks in advance. Hans
  3. Can you please supply a file name for "Nicks Lights Vol 2" because I cannot find it via the name you have supplied. Thanks in advance. Hans
  4. Scott, I've sent you a private message about the Halo.bmp file problem. Hans
  5. Thanks again Greg for your above and second expert explanation. I went to one of my "white blotch" airports, now fully armed with my newly aquired knowledge and saw that it was in fact one of these very detailed addon ones. As now expected it had high resolution ground/apron/runway textures on top of a flattened airport terrain. Same for my next addon airport, etc. Testing by temporarily de-activating the BGLs which call for these textures did in fact work ...... BUT ...... at the same time I also discovered that I really prefer the distant very short white blotches to the complete absence of the detailed ground textures, e.g. when on or very close to these normally very well made airports. Masking with, e.g. trees, bushes, shrubs, etc now seems a more viable option, at least for me and especially because it was only a trivial problem to begin with. Nontheless, a very interesting subject and I learnt a lot from it. Thanks again guys and stay safely at home. Hans
  6. Greg, Your very logical (bottleneck) explanation has shot holes in my incorrect idea that such distant white ground blotches were caused by BGL calls for custom textures of which the last and least detailed mips were somehow still too far out of range to immediately be loaded/displayed. I had also assumed that while the custom ground textures were "waiting" to be loaded/displayed, the default ground polygons would pre-display instead of the white blotches. Anyway, thanks for your lesson but now another question emerges: Is it possible, after the "processing bottleneck" has cleared itself, that the speed at which such distant ground textures are then loaded/displayed, is somehow related to their sizes ? E.g. will 43Kb DXT1 textures always load faster than the larger DXT3 or higher detailed ones ? The reason I ask is that, e.g. mipped land class texture tiles in other areas, which all seem to be DXT1 of 43Kb, in fact never cause any temporarilly untextured blotches to appear in the distance. Regards to all and thanks for your reactions. Hans
  7. Hey there Tom, Quote: "But you cannot control when they switch". Surely, when any third party scenery developer creates, e.g. any airport texture, then in my mind he/she just must use some kind of software process for creating the possibly standard number of mips for any such texture. These should then normally all be "switched" at fixed distances, possibly being controlled by a set FS9.cfg entry and/or even a FSUIPC one. However, if this "distance switching" process is somehow controlled by individual developer's scenery BGL files, which have called for the mipped texture(s) concerned, then yes, the possibility exists that the "distance switching" process will never be or become a fixed entity. Oh well, I will agree with you all that my initially posted problem is definately not a serious one but nevertheless very interesting, while on the other end of the stick, suddenly popping up Abacus EZ-scenery objects at very short distances, certainly is another one. Comments are welcome and in the meantime, stay healthy. Hans
  8. Roger, I agree with your explanation completely but I think you are referring more to the causes of an effect called ground texture "shimmering", than to a possible mipped texture problem. Please correct me if I'm wrong but a theoretical possibility in my mind is that, e.g. the least detailed (mipped) versions of any addon airport's ground and other textures are rendered first when you are still relatively far form actually landing at that airport. As you get closer the the next more detailed texture versions are rendered and so on, until the most detailed versions are finally rendered just before landing. It's in fact a frame rate enhancing technique, which also makes life for graphics cards just that little easier. Now my more detailed questions: Are mipped textures ALWAYS mipped in exactly the same way with the same number of mipped versions per each texture ? Could it be that the least detailed versions of these airport textures are blank ? Is there a way of checking/editing any texture's mipped versions, other than such textures simply being mipped or not ? Or is it as dougu66 above says, that I just need to learn to live with this (rather trivial) problem ? Regards. Hans
  9. Hi Guys, When approaching some of my airports in clear weather, a white blotch suddenly appears on the ground in the distance and which then very unrealistically, gets filled with the related textures as one gets closer. The most obvious way of decreasing this problem is to mask it as much as possible by decreasing the visual distance via e.g. weather, but is there any structural way of increasing the distance at which these still untextured airports appear ? E.g. in the FS9.cfg file ? Could this problem somehow be texture mipmap related ? Looking forward to any reactions/solutions. Hans
  10. O.K. guys, I've found the culprit. The horrible looking Mooney tail light is/was caused by a texture file by the name of: "Halo.bmp" and can be found in the main FS9 texture folder. After quite some hours of trial and error testing by deleting/restoring large groups of main FS9 texture files with testing in between, suddenly the Mooney's tail light was no longer there. This rather quickly led to the above mentioned texture file as being the culprit. I replaced it by a very old and very different version from one of my old backups and PRESTO. Problem solved !! The tail light is still there but it now at least looks very much more realistic. The problem was caused by my quite recently downloaded and installed new halo lighting effects, which in fact did look quite good here and there but which evidently also had some negative side effects of which this was one of them. I hope this helps anyone else with the same problem(s). Happy landings. Hans
  11. Hey there Tom, That's strange. My default Mooney's tail light is also very bright, white and large, completely different to the correct looking one in your screen pic. Not only that but my Mooney has no landing lights, like your's does seem to have, either. If I temporarily de-activate all lights in my Mooney's aircraft.cfg's [Lights] section, the white tail light remains unchanged and can only be switched on/off via my keyboard "L" key and via my third party cockpit "Nav-lights" switch. You are therefore correct in saying that this light is selected/positioned by the Mooney's model file, is not part of the aircraft.cfg [Lights] section and can therfore not be directly edited. Great pity. However, I've been testing some other of my (addon and default) aircraft and it now seems that with quite some of them, different selections of their lights are also part of their model files but these at least all look and work normally. Going back to the Mooney, the only thing I can now think of is that it's horrible looking tail light texture has at some time in the past automatically been edited or somehow redirected to another lights texture, most likely by an automatic installer program for another aircraft. Can you think of any way of finding the offending lights texture itself because I must now hope that it's no longer one of those contained in the standard fx_2.bmp lights texture. However, if all fails then the only possibility as I see it now, will be to replace the Mooney's model file by the one from one of the installation CDs. Regards Hans
  12. Whats wrong with your ailerons ? Is your plane unsteerable ? Yolk or stick problem maybe ? Do any other of your planes have the same problem ? More information is needed so that I/we can help you. Your downloaded file name would be helpful as well, so that I/we can try it ourselves. Regards Hans
  13. If you have installed into the default folders, which is very easy to do, you run the risk of all kinds of unpredictable problems caused by Windows security processes and your specific problem could be one of the many possibilities. If you have in fact installed into the default folders I would want to suggest that you uninstall completely, remove any residual files/folders and then to re-install but this time into so called "custom" folders, preferrably in a partition outside that in which you Windows lives. If you have already done that, then please supply more information as James has already asked. Regards Hans
  14. Hey there Tom, Join the SBuilder frustration club !! You can count on my vote for you to become it's first chairman !! LOL. However, it must also be said that Roger's latest suggestion does seem to work but not in all cases and especially not where coastlines are in close proximity. These seem to have the same adverse effects on polygon edges as roads. But anyhow, I've now created correct grassy backgrounds for six of my older addon airports/airfields but these have then created even more "problems", in that they were then just asking to be enhanced and improved even more !! Yep, SBuilder is indirectly addictive as well !! LOL. Regards and stay healthy. Hans
  15. I've had this same issue a few years back on my Waikato carrier and in the end it turned out to be that the relatively small 3D geographically positioned catapult sensitive deck area (Cat zone as you call it) had somehow (been) moved. In my Carrier Operations (COPS by Rob Barendregt) system, it remains necessary to get the nose wheel exactly in this small catapult area and only then will you get catapulted off the deck when you release the brakes. My trapping area was also influenced but because this is much larger than the catapult sensitive area, this was not immediately noticed. The whole problem (and many others) was caused by a "magnetic North deviation update" which I had found somewhere and had installed. Needless to say but I reverted back to the original file rather pronto. Could something like this also be your problem ? Good luck. Hans
  16. Hi there Roger, Yes, SBuilder does have quite some strange "ifs and buts", not only in it's relations between default roads and polygons but also with LC scenery, most probably because LC scenery normally exists as a scenery layer "on top of" any SBuilder polygon(s) and which then need non_SBuilder solutions. A fine example of conflicts between polygons and default roads is on one of my addon Greek airports, which has a default looking (maintenance) road running all around it's perimiter. A (grass) SBuilder polygon background was also necessary here, so I made a nice big (test) one covering the whole airport and with a wide margin all along the outside of this road. The result was a correct polygon background but also a non-polygon covered margin on both sides of the road all around the airport !! I then made a new polygon with the road itself as it's borders but even then the polygon edges kept their distance from the road all around. My end solution in this specific case was to draw an Afcad (or ADE) road on top of the default one and to then mask the void between that and the polygon edges with shrubs, fences, etc. Problem solved. And then, on to my next problem airport. My initial "road problem" with which I began this thread is now also solved by covering the area concerned with forests and other objects. However, thanks again for another of your "nudges" in the correct direction and I will certainly try this one during my now ongoing general check of all my 600+ addon airport backgrounds and especially on the older ones, where the background problems are most prevelent. The covid19 scare is keeping me inside and off the streets anyway. Thanks again. Hans
  17. Roger, No apologies necessary Roger because your instructions successfully got me going on my illusive road, which for me was now no longer a scenery issue but far more an SBuilder "find out how to" issue. Moreover, after your "nudge" and help I now at least know some basics around how this SBuilder program works, what it's limitations are and last but not least, what the differences are between "paintable" addon scenery ground tiles and the default autogen ones. Out of pure inquisitiveness, combined with covid19 boredom, I've now dived back into SBuilder again and have successfully used my new polygon "know how" for creating missing grassy terrains on two of my addon airports. Roads ? Huh. Who needs roads !! Regards and thanks again for your help. Hans Netherlands
  18. After another few hours of messing around with this SBuilder program in trying to get my road to become visible via the "line" drawing procedure, I kept running up against a new problem, in that my road only became partially visible. It only became fully visible along it's whole length after I had (temporarily) dis-abled the scenery's existing VTPP file, the file which creates the airfield's grass surface polygon. Clearly another conflict situation between SBuilder files and which now causes me to opt out of this program all together. It can most probably do a lot for many of you scenery experts out there but it's conflicts and further unpredictabilities are just too much, at least for a beginner like me. Thanks anyway for all your help guys. Hans
  19. Thanks Roger for your answer. Yes, I had seen the "line" option in SBuilder but in trying it I had gotten myself all tangled up in what to do next in relation to what I had already done. Making my thin (road-like) polygon was then my next best option, not knowing that this could "bite" my already existing harbor area polygon. However, I'll now have another go at it and will report back. Yes, I already found out yesterday that the plane's position is or should be, the starting point from which to begin drawing my road and that following points should then lead the road up the valley all the way up to the airfield. All this while dodging autogen and my own added trees/buildings as well. By the way Roger, I purposely did not send you an e-mail because otherwise this thread could run the risk of ending in the status "open ended". Regards. Hans
  20. Hi Guys, After trying to find my way around in this rather difficult to use SBuilder program, I was, after much sweat, finally able to create a grainy and scraggy edged sandy beach-like VTP polygon for my coastal harbor area. Not really a problem because such areas are not meant to be viewed from close up anyway. However, the road from this new harbor area upto the airfield was a different matter altogether but I was finally able, after a lot more sweat, to construct it via a very narrow and winding separate VTP polygon. But even although the road had now actually become visible, my sandy harbor area had disappeared. Further testing revealed that it was either the now active harbor- OR the road VTP.bgl file, which showed up correctly in the scenery, but not both together. Roger, I think I now need an SBuilder "nudge" from you because in my mind there just must be a better way of creating the road and in such a way that both these separate polygons can become visible at the same time. Thanks in advance. Regards Hans
  21. O.K. Guys, I get it. As I've never done anything like this before, I was initially under the impression that I needed to paint a specific (default) ground scenery tile, which covered the related area and that locating/selecting that specific tile was the first hurdle to cross. Sorry about this mis-understanding. I will dive further into SBuilder tomorrow, in which I've already discovered that co-ordinates are used in geographical positions, independant of underlying ground scenery tiles and/or mesh. Thanks Roger for your help offer but please let me do some SBuilder sweating first, so that when possibly contacting you for a "nudge", I will at least be able to know what I'm talking about. Yes Tom, I now also understand that even although it would somehow be possible to paint a road onto one of the default ground scenery tiles, this tile, together with it's new road, would then be repeated all over the FS9 world. Thanks for the lesson guys. Hans
  22. Thanks Roger for your reaction but my primary problem at this moment is somehow first locating the texture(s) concerned and after that I will only be too pleased to accept your SBuilder "nudge". By the way: have you ever used a program called GIMP for this kind of thing instead of SBuilder ? It seems to be able to do the same and even more than SBuilder. Hans
  23. Hi Guys, I've just finished installing the small and very nice looking Greek island airfield Kastelorizo (LGKJ), made by Emmanuel Mwandosya and have added many other not true to real life objects via my Abacus EZ program, just to improve further on it's looks, e.g. many new trees and a small harbor with some buildings/houses, etc. The airfield itself is situated at an elevation of 474 feet but my harbor is at sea level and I would like to draw/paint some kind of road leading from the harbor to the airfield but this is not possible via Afcad or ADE because of the elevation difference. I assume that the only way of doing this is to paint the road onto one or more of the existing ground textures for the area, most probably included somewhere in the main World/texture folder. My question is therfore, how can I find and select the (nnnnnnnnnnnnnnnsu.bmp) texture(s) concerned ? Is there some kind of geographical positioning code in these World texture names ? Any help is appreciated. Regards Hans
  24. John, Quote: "Just checked my stock install. No add-ons." ?? Do you mean that your problem becomes apparent immediately after a fresh install from your four CDs ? If so then the first thing you should do is to uninstall your FS9 completely and delete any residual folders/files. After that you must re-install completely but NOT in the default folders, preferrably in a separate HD partition outside that in which your windows lives. Then install the NO-CD patch and lastly install the FS9 update. Installing FS9 in it's default folders results in unpredictable errors due to certain normal FS9 processes being seen by windows as safety threats and are as such either only partially performed or not at all. Your observations are indeed very strange and for which, other than the above, I have no further suggestions. Good luck, Hans Netherlands
×
×
  • Create New...