Ground polygons - appearing white, why?

[Shaka 2]

Well, I've been designing scenery for awhile, and I would say that it would not be possible without all the help I've receieved here. So I come to you again with yet-another-problem....I designed this scenery for Bangkok. It's had a few thousand downloads, and occaisionally a user will write me with a bug in the scenery that I always make a point of fixing. There's one problem that I can't seem to figure out. A certain texture that is used for a ground polygon will not load, leaving the polygon appearing white (see picture at bottom).I've had only two people report this to me, and I have been unable to duplicate it myself. None of the people that I had test my scenery ever reported anything like this. Careful discussion with the people who reported this problem indicates that they are experienced users and that the scenery was installed correctly, and all the textures are in place. So, it must be something particular to their system, right? Maybe thier video cards? I don't know for sure, but I do know that scenery designed for one system "should" work on all systems. One user reported that the Irish-scenery-guys had a similar problem, but they are a little vague on exactly what was happening.So the question is "Does anyone know why this happens, and how do I fix it?".- I have tried different file formats (DXT1,DXT non nVidea, 8-bit, etc).- the filename has 9 letters plus the extension (shouldn't be a problem, right?).- Martin

[rhumbaflappy 113]

Hi Martin.Did the simmers with the problem tell you their operating system?The reason I ask, is that some time ago there was a "virus" reported, and the "cure" was to delete a certain Windows98 system file. The virus was a hoax. And deleting that file left the users without the ability to use long names with Windows98.I had a friend that deleted this file. He then added it back to the system folder, after I told him NOT to delete it. That didn't work quite right... and eventually he had to reinstall the OS to fix it properly.What's this got to do with this problem? I suspect their OS has been altered somehow, and that might be the reason for the missing, long-named texture. ===================There is another possibility. WindowsXP will unzip files pretty well. But Windows98 requires a 3rd party utility to unzip files... and some unzip utilities do not properly unzip files with long names.[link:support.microsoft.com/default.aspx?scid=kb;en-us;152443]unzipDick

[Shaka 2]

Thanks for the quick reply!There are many other textures that use long filenames in the scenery, so their system can handle it. However, this is the only long-filename texture that is used as a ground polygon - all the other textures are used to texture buildings and such.I've tried compiling the scenery without the offending texture - using a default one instead, but I haven't heard back yet. I'm a technical guy, so this random "guessing" to fix the problem is getting to me.- Martin

[rhumbaflappy 113]

Hi Martin.Hopefully these 2 simmers will respond again, so you can track down the problem.My understanding of the unzipping problem is that it is not easily reproduced, and it doesn't affect all longnamed files... just an occasional longnamed file that somehow is not accounted for correctly with pkunzip, on a specific machine.I do know that some of the US government agencies stubbornly refuse to use zipped files.... instead using the 'tar' type compression, because they do not feel that zipped files are reliable.You should be able to get them an uncompressed BGL and an uncompressed texture... and that would eliminate that possibility. Perhaps they could attach to e-mail the bgl and texture they have, so you can see if there is something wrong with their files.If the files are fine, then it must be their computers.Dick

[Shaka 2]

Thanks again.Just to make sure they actually had the file, I had previously emailed them a copy of the evil texture, and when I did that, I didn't even bother to zip it. They are both running XP anyway, and at least one has an nVidea card, which I think has more to do with it.So, anyway, since it doesn't matter which format of bitmap I sent them, I decided to change the bitmap. When I recompiled using a default using a default texture, it all work fine.This still bugs me. Keep in mind that the scenery "works" fine. The only thing I could narrow it down to was "on very few systems, FS would not load a texture if it was used for a ground polygon if it didn't use a 8.3 filename.". I'm curious now whether they would see the same texture if it were on the side of a building...Well, thanks again.- Martin

[rhumbaflappy 113]

Hi Martin.Hopefully, someone with more experience with ground polygons can help. I loaded your scenery, and it's fine on my system. I noted the poly is DXT1 opaque 512x512, mipped, if anyone knows of a problem with that type of bitmap and ground polys.Dick

[Shaka 2]

>>I noted the poly is DXT1 opaque 512x512, mipped, if anyone >knows of a problem with that type of bitmap and ground >polys. I also tried using a regular 8-bit texture, but that didn't work either so I determined that it wasn't a file-format issue. However, I recompiled the scenery and istead substituted a default bitmap with the old 8.3 filename and this did work.I also gave them a file that would put a large cube covered with the texture at the airport. This would test to see if the texture would load at all. Of course it did, so this confirms that the problem only affects ground polygons.Anyway, without really understanding what is happening, I at least know what to avoid in the future. Thanks again for all your help.- Martin

[arno 1]

I think I know why this happened (I helped Sebastian solving a similar problem).In that case the following happened:The texture names had long file names. He used the Airport design program and instead of using the entire texture name airport used names like mytext~1.bmp. So Airport referent to the 8.3 name for the long file name.Then the problem was caused by the fact that the designer had more textures in his folder then where distributed. So let's say you have 15 textures or so, then the last one would be called mytex~15.bmp. This is the one Airport refers to, but with the scenery you distribute only 15 textures, which means that the user will not have a texture with this 8.3 name.Instead of renaming the texture, you could also make sure that the long filename is in the SCASM bitmap command (that's no problem for SCASM).Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[Shaka 2]

>In that case the following happened: >The texture names had long file names. He used the Airport >design program and instead of using the entire texture name >airport used names like mytext~1.bmp. So Airport referent to >the 8.3 name for the long file name. This is very interesting, however, it is not exactly what happened in my case. While I was testing the problem with the users, I sent them many different emails trying to verify what was going on. I had considered that there might be a texture in one of their folders that was interefering somehow, but the texture had a unique enough name that it would only have come from me. Eventually, I sent them a test file that would load the texture onto a building, and at the same time try to load the texture onto a ground polygon.The texture loaded onto the building correctly, and still failed to load onto the ground polygon. Even as I am writing this, I realize how pointless it is since .api's are obviously handled differently than the ground polygons are.- Martin

[Shaka 2]

>The texture names had long file names. He used the Airport >design program and instead of using the entire texture name >airport used names like mytext~1.bmp. So Airport referent to >the 8.3 name for the long file name. >Then the problem was caused by the fact that the designer >had more textures in his folder then where distributed. So >let's say you have 15 textures or so, then the last one >would be called mytex~15.bmp. This is the one Airport refers >to, but with the scenery you distribute only 15 textures, >which means that the user will not have a texture with this >8.3 name. Well, the more I thought about this the more I got confused. It is true that I used airport to make the scenery, and yes, it converts the filenames to the 8.3 format. I have to admit that I am completely ignorant as to how airport/scasm "remembers" what the original filename was called. Perhaps someone could enlighten me as to how this worked exactly? Arno - maybe you could provide me with some more details of the problem you mention? I am a bit unclear as to why the number of files in my folder would affect the output from scasm of the file name.- Martin

[arno 1]

It does not remember the DOS names, that's the problem. Let me explain.If the long filename is stored in the (Load)Bitmap command then there is no problem obviously. Then it will work fine on any PC.However if the 8.3 filename is stored, then you might have a problem. Let's assume you have 4 textures in your texture map:texture01.bmptexture02.bmptexture03.bmptexture04.bmpThe DOS filenames of these would become:textur~1.bmptextur~2.bmptextur~3.bmptextur~4.bmpThis are also the names that are stored in the SCASM file (and thus in the BGL).In your final scenery you only used 3 of the 4 textures, so you only send them with the scenery. Let's assume they are:texture01.bmptexture02.bmptexture04.bmpIn the DOS format this would become:textur~1.bmptextur~2.bmptextur~3.bmpNow the conflict is clear. The texture texture04.bmp is refered to as textur~4.bmp in the BGL, but that DOS name can not be found on the users computer (as it is textur~3.bmp there).I am not sure if this happens on any OS (then you would probably had more reports from users), but in the other case where I found it that was what happend in some cases.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[Shaka 2]

Ok, now I get. You make it sound so simple! This also explains why the texture would display properly on a building (from an .api) and not on a ground polygon (directly in airport).The thing is, the texture DOES work on many computers without any problems. So, I'm kind of believing that airport/scasm did their filename magic correctly. What do you think about that? Why would it work perfectly fine on thousands of computers, but not on those two that reported the problem to me?Well, I know the easy way to fix it - use 8.3 filenames in the rare occurance where I need a ground polygon.Thanks again Arno.- Martin

[arno 1]

>Why would it work perfectly fine on >thousands of computers, but not on those two that reported >the problem to me? That's the thing I still don't understand completely. It could be that the type of OS (updates?) has an influence. Or maybe these few users did a different type of install (putting an other file together with it, meshing up the 8.3 names).Maybe we must just say "It still are computers and sometimes we can't understand them" :-lol>Well, I know the easy way to fix it - use 8.3 filenames in >the rare occurance where I need a ground polygon. Or just change the SCASM code so it uses the complete name and doesn't set it to 8.3 :). I don't use Airport that much anymore, but if I remember correct it uses the Bitmap command by default (if you don't use seasons). If you force it to use LoadBitmap the problem was also solved (then it doesn't force 8.3 if I rememeber correct :)).Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[rhumbaflappy 113]

Hi Arno.Perhaps this is not related, but the use of a 16-bit program with a 32-bit OS will cause exactly that problem. I sometimes use a program called "locbgl.exe". It is old 16 bit program, by Chuck Dome, that reads the headerbounds of BGLs to see if a certain Lat-Long location is covered in a directory full of BGLs.It displays only the 8.3 name format with the same problem Martin may have found.It occurs to me that a 16-bit program running at the same time as FS2002 might cause a problem with filenames... perhaps just 8.3 formatted names.This is a shot in the dark, but if the 2 users could give Martin a list of other programs running in the background while using FS2002, there might be a clue there.Obviously, something is different about their OS or the backgound programs running... and I'd be willing to bet they have had problems with programs other than just FS2002.Dick