Object becomes a box from distance

[Guest GerrishGray]

Hi MartinThere seem to be quite a few unintentional (?) differences between FS2000 and FS2002. I think that quite a lot of work was put in to the complete revision of the scenery engine - and continues to be so because the project will not be 'complete' until FS2004. This has resulted in quite a few "undocumented features". Also, making FS2002 a transitional version that supports both old and new stuff was always going to be a bit of a minefield, as the guys at Redmond should well know by now because they seem to get mired in that minefield over and over on many of their projects.As an example, there are a couple of inconsistencies in the way that FS2002 uses the scenery folder structure (as I'm sure you know!) - and at least one downright mistake. Integration with the more-or-less independant Autogen code hasn't helped either.BTW, the specific mistake I referred to is that FS2002 incorrectly looks for textures used by section 10 library objects in the texture folder partnering the BGL containing the section 9 calling code, rather than the one partnering the library BGL itself. Hence the need to place all textures used by shared libraries in the main texture folder, irrespective of where the library is installed. FS2000 did it correctly, so the code obviously got "accidentally" changed along the way and nobody noticed.CheersGerrish

[rhumbaflappy 113]

Hi Gerrish.I'm not seeing a problem with Library Object textures. For example:The 'cheklap_placement.bgl' calls the library object. It's in the "C:Program FilesMicrosoft GamesFS2002SCENEDBCitieshongkongScenery" folder.One of the library objects called is Veh10 from 'Vehicles.bgl', located in "C:Program FilesMicrosoft GamesFS2002SCENEDBVehiclesvehiclesScenery".The textures used are 'veh06a.bmp' and 'veh06a_lm.bmp' found in "C:Program FilesMicrosoft GamesFS2002SCENEDBVehiclesvehiclesTexture".So in this case, the textures are properly with the library object's twin texture sub-folder. And the placement BGL is nowhere near it.In this case, the Library BGL is not in the same folder as the placement BGL, so FS2002 finds these textures just fine.-------------------------------I can create a project folder on the desktop named "LibraryObjects", with twin sub-folders "scenery" and "texture". I place the library in "scenery" and it's textures in "texture".I create another Project folder on the desktop named "ObjectPlacement", also with twin sub-folders, and place the 'library object calling' BGL in that scenery sub-folder. "texture" contains nothing.I add both to the Scenery Library from within the sim, and make sure they are activated. The entry order doesn't seem to matter... probably controlled by the header bounds anyways.I go to the area, and the textures and objects show fine.Dick

[Guest GerrishGray]

Hi DickHmmm, very interesting and a bit worrying because you have me thinking that I must have got this one wrong?!?There have been a lot of problems with this - it results in library objects being displayed as white boxes with their textures missing. I got reports from users of my trees library as soon as FS2002 was released, and didn't believe it myself at first - everything had always worked fine in FS2000. Then I managed to reproduce it on my machine. I found that the problem was always instantly cured by transferring the textures to the main scenery folder. All this was over a year ago and I am recounting it now from memory. The problem continued to be reported and I always dealt with it in the same way without need for further testing. More recently, I released version 3 of the library with full instructions for cleaning up the messy installations that some people had ended up with (due to incorrect installation advice from 3rd party authors of sceneries using the library) and made sure that everyone now installed the library BGL in the main scenery folder and the textures in the main texture folder. I haven't had a single report of the problem since.Now that you have brought the subject up, I do recall that I was aware that the stock library objects didn't display the problem, but there were very few other shared libraries in circulation for comparison. So I acquired a sneaking suspiscion that the scenery engine had some special (i.e. hard-coded) knowledge about the stock objects, supported by its alleged ability to call them by name instead of by GUID. I didn't bother to investigate further because I had a simple cure available ... Your report now suggests that my diagnosis of the cause may actually have been wrong, which makes me feel a bit foolish!-----------------Regarding the location of library BGL's, it doesn't matter one jot which scenery folder they are installed in as long as that folder is listed somewhere (anywhere) in scenery.cfg, because FS scans the whole scenery database during start-up and makes a table of all BGL's in every 'active' folder referenced in scenery.cfg. The table includes data, taken from the BGL headers, about Lat/Lon bounds, max/min library object GUIDs, etc. When flying, this table is continually scanned to see which BGL's need to be loaded according to their Lat/Lon bounds. As for library objects, the table enables to engine to locate an object very quickly the first time that it is called, no matter where it is called from and which folder and BGL it is located in. The only significance of the priorities in scenery.cfg is to determine the 'layering' sequence for BGL's whose Lat/Lon bounds overlap - all BGL's are 'available' at all times, subject only to the current viewpoint being within their Lat/Lon bounds. And all library objects are similarly available at all times, although they will simply not be displayed if the Lat/Lon bounds of the containing BGL are out of range. The missing object problem only arises when the GUID is not found in any BGL in the active library, irrespective of any Lat/Lon bounds. The 'white-out' (missing texture) problem occurs when the object is found OK but its textures aren't - and FS is, of course, nowhere near as clever at finding textures as it is at finding BGL's. It will only search two folders to find a texture - the one it thinks it belongs in and the fallback of the main ('root') texture folder. There is just one exception to this - FS2002 can actually find the default ground textures from three different locations in some circumstances because of the operation of the Texture_ID flag in scenery.cfg.ThanksGerrish

[rhumbaflappy 113]

Hi Gerrish.I think it was Chris Wright that had a problem with some LWM BGLs not displaying.They were fine on my machine. He actually found the problem himself, when I walked him through my setup... It turned out his LWM folder had no twin "texture" folder. LWM's require no textures, but apparently his setup needed to have that folder.He called me a genius for finding the problem... I just kept my mouth shut. *:-* I had no idea LWMs might need a "texture" folder to display properly.Now I always use a twin "texture" folder, even if it's empty, with the singular exception of a Landclass project without custom or alternate textures...I just mention that, as it may be part of the texture problem. Perhaps the placement BGL needs to have a twin texture folder, even if nothing is in it.Dick

[Guest]

GerrishI also have never had any problems with custom library objects.My experience has been that as long as the Library scenery folder has an accompanying texture folder with the textures in it can be called from any scenery with no problems.Originally I would put libraries and textures in on of the existing standard locations low down the library list (scenedbvehiclesvehicles usually) thinking the old "libraries must be loaded before your scenery in order to be found" rules still applied.Now I just put them in the same folder as the scenery they are designed for. They still remain available for any other scenery to use as well.FS2002 does seem to mostly ignore the layering of the scenery library. One of the drawbacks is that exclude bgls now sometimes seem to exclude everything in the area (including the scenery you are trying to put in after excluding a default airport...) regardless of where they are in the layer list.

[Guest GerrishGray]

Hi Martin/DickWell, it seems pretty clear from your reports that FS2002 doesn't have the problem I thought and does find textures correctly from the texture folder partnering the folder containing the library BGL.My report was based on reports from users, and I clearly didn't check it out thoroughly enough myself (although I did reproduce it on my own machine at one point ... but now at 1 year+ range I can't be sure how I did that). I used to tell people to put the library and textures in their own pair of folders and this lead to these problems when FS2002 appeared. They are not easy to diagnose at this range but there was certainly no obvious simple explanation other than the one I deluded myself with. These users clearly had a correct scenery.cfg entry - otherwise they would have had 'missing object' problems rather than merely a loss of texturing, and they always said that they had the textures installed as well (the first question I always asked, of course). Anyway it is all cured very simply by recommending that shared library BGLs and their textures are put in the main scenery and texture folders - that way there is no need to get users involved in creating an extra scenery.cfg entry and, hopefully, one avoids the problem of users ending up with multiple copies in a variety of different folders. Multiple copies of a library BGL and its objects aren't, in fact, a significant problem because FS will just use the one with the earliest entry in the index it compiles during start-up. But the problem comes when you try to issue updates and users have still got older copies tucked away in some obscure folder as well ... Oh, the joys of supporting one's products!(I have just realised - there may be a clue here to an alternative explanation of the missing texture white-out problem. If a user had multiple copies of the library BGL in different places, and one of these didn't have the textures in its matching texture folder but happened to be the one that FS loaded the object from ... that would explain the behaviour and would also be cured by putting the textures into the main texture folder).-------I hadn't come across the error that you report, Martin, of an exclusion BGL excluding other scenery from the same layer number. Perhaps you have incorrect reports from users too :-) . I think that many users get very confused by the scenery.cfg file now because of the failure of FS2002 to sort the entries in the file physically into order when layers are moved - if I remember rightly (?!), FS2000 used to do that so why doesn't FS2002?CheersGerrish