Jump to content
The simFlight Network Forums

GaryGB

Members
  • Posts

    3,123
  • Joined

  • Last visited

Posts posted by GaryGB

  1. Hi Francois:

    Just to clarify (and I know how it is to be heavily commited and short on time and patience to read everything! :wink: ), this page:

    http://www.simforums.com/forums/forum_pEmma+Field

    in the 6th post down by "shadowman76", Posted: 01 August 2006 at 12:50pm, therein lies the "abounding mystery" of the VOZ / Bear Gulch connection in this scenario!

    Ok, I think I nearly solved the problem. And, if yor read on, I am sure you will be as surprised as I was when I discovered what happened, especially with VOZ. Now from the beginning:

    As mentioned above, I was pretty sure that the problem was not texture-related, but that it was a conflict between two sceneries. As the problem does not occur with Bear Gulch deactivated, there had to be a BGL in Bear Gulch that caused the CTD. So I went on deactivating each BGL of Bear Gulch one after another, doing the test after each deactivation. Finally I got the beast, a file called BG_VTPH.bgl in the scenery folder of Bear Gulch. I don't exactly know every FS-scenery technique, but I know VTP has something do do with drawing lines (streams, roads) in the scenery. So this may explain the CTD in conjunction with Bear Gulch.

    Ok, second thing: VOZ. After sorting things out for Bear Gulch, I started installing VOZ, this time in steps. First I installed VOZ 1.1 and tested afterwards. No CTD with VOZ 1.1. Then I updated to VOZ 1.2 and - bang. CTD at 58%. So there had to be a BGL that caused the crash, too. I started scanning for files in my FS-directory matching the pattern *vtp*.bgl and to my surprise, I found a file called (guess it) BG_VTPH.bgl in the folder Addon Scenery\scenery. This file has definetly not been there before updating VOZ from 1.1 to 1.2, I crosschecked that. But that had not been the only surprise I had. I started investigating what VOZ 1.2 has put into my Addon Scenery\scenery folder and found that the complete Bear Gulch Scenery appeared there! Together with VOZ 1.2 the following files have been put there that definetly belong to Bear Gulch:

    000_wa38_excl.Bgl

    AF2_WA38.bgl

    AF2_WA39.bgl

    BG_LWM2.bgl

    BG_VTPH.BGL (<-- the one that causes the CTD on my system)

    BG_VTPL.bgl

    bglib.bgl

    bgsocks.BGL

    bgut.bgl

    wa38_grnd_hires.bgl

    wa38rwy.bgl

    These 11 files are exactly the ones I have in my Bear Gulch scenery that I installed before installing VOZ. The installer of VOZ 1.2 I have is dated to May 28, 2006. I am pretty sure that this is a mistake by the one who created the VOZ 1.2 installer, as the Bear Gulch scenery files have definetly nothing to do with australia and are even payware, that must not be distributed in a freeware addon!

    So, with this in mind I say the VOZ-problem is solved and the Bear Gulch problem is *nearly* solved. Now what I do not unterstand is why I get a CTD with the file BG_VTPH.bgl active, as I did chose the UT-compatible version of Bear Gulch during installation. But as Bear Gulch is not a Flight1-product, I don't know if this support issue is right-placed here in the forum. But perhaps some of you scenery gurus can explain me, what VTP is and why this file may cause a CTD?

    To all affected parties: Be sure to read the full page referenced and linked above! :idea:

    GaryGB

  2. Well I wonder what would happen if we could observe Pups :shock: :?: :lol: Would he still be here? Would he be someone else (like the wabbit)? Or would he just not be here and only be a post in the forum? :shock: :cry:

    LouP 8)

    Whoops! :shock:

    And what happens when we "observe" holidays?

    Do 2-day holidays recombine into 1?

    And would they "interfere" with days on either side of the holiday? :roll:

    GaryGB

  3. Hi Ed:

    If I (or any of us who had read the older thread on the last Emma CTD issue explored back in November 2006!) had remembered sooner the "Bear Gulch" reference you made, and if I would have been even more in depth (more than usual!) in my questions about what you had checked in the links referred to in my post on Page 1 of this thread, we might have saved you some extra trouble. :oops:

    I think we are all grateful, however, for the new insights we have all gained here through your ongoing diligence in pursuing this matter, since we have learned of some new variables to consider when troubleshooting Emma Field scenery conflicts with 3rd party add-in scenery.

    We should have made sure to bring to your attention this specific link (which was located on the page I had linked to in my post on page 1 of this thread); think of it as the "missing link": :wink:

    http://www.simforums.com/forums/forum_pEmma+Field

    On that Simforums UT-USA support forum page in question entitled "UTUSA: CTD when loading Emma Field", you will find a very relevant discussion and proposed fixes involving Bear Gulch files (installed by VOZ!) along with other scenery file adjustments which must be made when VOZ has been installed on one's system (which I believe Don Smith originally had in mind when he made his original suggestion to you based on how he had resolved his own Emma reinstall problem this last fall).

    Hope this helps (let us know how things end up for on this, if you would once again be so kind!) :D

    PS: As you can see, we all handle so much information in addition to the complexities in our personal and occupational "non-sim" lives, it is hard for any of us to remember all these things (even when they were dealt with as little as 2 months ago!), and we need indexed/hyperlinked Emma Field troubleshooting/support documents (preferably here at the EFFC forum with one master "sticky" thread containing a "problem/symptom index") with links to sub-documents on other pages of the forum storage area as a necessity of keeping Emma Field (and our sanity?) intact!

    Uh-oh, GaryGB steps up on his soapbox again...

    In addition, it would help to have a SimFlight Forum search engine which allows (and please correct me if I'm misunderstanding the existing search function here thus far, someone!) use of a multi-word query string in quotes to render specified results, so that instead of getting hits on all instances of the words in the query string, we only get hits based on a specific string in quotes.

    Yeah, everything costs money, but NOTHING (IMHO) is more expensive to one's wallet and one's quality of life than unfulfilling time expenditure and stress. If we need to start paying an annual subscription fee to upgrade the slow web page servers, limited search engine, and unreliable multiplayer servers at SimFlight, please let us know what is really needed to make it happen. I pay a monthly fee for a fast DSL connection for a reason: I don't like waiting for web pages to write my screen!

    Since late last June 2006, my experience browsing (worse yet when trying to post!) at SimFlight forums (and especially EFFC forum) has often felt like a dialup connection; this is less likely going to encourage people to actively "participate" in this forum all too often wanting for posts by the "silent majority" of our reported 1,000+ members.

    Please, I believe all Emma-ites would like to know what it would take to make this a faster and more gratifying web experience interacting here; perhaps we can all help make things even better than they already are! :idea:

    Thanks again, Ed (and everyone else who takes the time to post here) for sharing your insights with us, so we can document how to resolve these challenges as they occur! :roll:

    GaryGB

  4. Ok,

    Columbia River Gorge has been installed, the update that added Crown Point and some other objects was installed as well as the patch for Portland Zone02. Everything in that area works perfectly. Emma does not! I am still religated to unchecking Emma if Portland is installed.

    Hi Ed:

    Just to be sure I understand correctly: "Holger's scenery for Colombia River Gorge (CRG) with the patch for Portland Zone 02" means which patch was applied and tested on your system?

    1.) The "default CRG without UT-USA" compatiblity upgrade for Columbia River Gorge scenery to resolve compatibility issues with FZ02.

    http://www.flightscenery.com/phpBB2/viebd19260140

    OR...

    2.) The "both CRG and UT-USA installed" compatiblity upgrade for Columbia River Gorge scenery to resolve compatibility issues with FZ02.

    http://216.25.73.93/phpBB2/viewtopic.php?t=881

    And when you tested it on your system, were you saying that Emma does run properly with Holger's scenery for Colombia River Gorge with the (specified) patch for Portland Zone 02 installed, but Emma only works with CRG if Portland Zone 02 is disabled in the scenery library or via FSNav?

    Thanks again for your extra help following up on this for fellow Emma-ites! :D

    GaryGB

  5. Ok Pups. Are you in Seattle or Winnipeg? :)

    Hi Larry:

    If I may take an indecent liberty by commenting here...

    Pups is a virtual entity with unique attributes as an Avatar of Skinny Puppy. He is often affectionately addressed by his PUPS "nickname on top of an avatar name", and his latest peril/latest project pays homage to the movie "Sleepless in Seattle" by describing his "[circumstances]... in Seattle". :idea:

    He has numerous unusual powers, including a capacity for Time Dilation and inter-dimensional travel throughout the cosmos, always with peril matched only by his impunity (impudence?). :shock:

    His activities are also inspiration for wild-a$$ed improvisational story telling by yours truly when I get really inspired/really bored, and feel compelled (probably to the detriment of my overall credibility... alas, poor Icarus!) to shake things up here in the EFFC Forum with a goal of evoking at least a few laughs for disenfranchised simmers alone at their computers; and maybe if I'm really lucky, we see a few more posts trickle in here as a result! :lol:

    Although he is properly addressed as a "Winnipegger", given his unique cosmic capabilites, he could be at any one of several places at once according to his therapist, Dr. Heisenberg! :P

    A recent Pups Peril: http://forums.simflight.com/viewtopic.psc&start=0

    GaryGB

  6. NOPE: It appears that I can load both and enjoy only one, lol. If I stay at least 10nm away from Emma I can fly to my hearts content in and out of Portland or anywhere else for that matter.

    Hi Ed:

    Thanks for bringing that to the developers' attention... I'm confident it will only be a matter of time until a work around and/or internal fix is made available. :)

    In the mean time, do you plan to test out Holger's Colombia Gorge and associated compatibility patches (with and/or without UT-USA installed if you do/don't own it) and test it with Portland unchecked in the scenery library user interface to see if it also runs OK with Emma? :?:

    GaryGB

  7. As requested, here is the update after reinstalling the Portland Scenery. First off it would not allow an install to my add on scenery folder outside of FS9. I had to install to FS9 then cut and paste to my new addon folder.

    Hi Ed:

    Perhaps the FS install path registry trick I mentioned above would have allowed a Portland install to a "My Addon Scenery" folder external to FS . But since it is a rather sophisticated scenery, installing instead to a dummy FS folder tree might help detect anthing it also wrote to places other than the [FS install path]\Addon Scenery folder.

    Anyway, long story. . .short. . .Emma does not load with Portland Scenery installed. I unchecked it in the library, reran FS9 and Emma is fine. Also, this new install of Portland did not include reinstalling the Holger "Columbia River Gorge Scenery", so that was not a factor.

    Bummer... :? another Emma-incompatible scenery lots of people would like to also use! But at least there is an easy way to "turn off" the conflicting Portland scenery while flying an exclusive Emma Field session via the scenery library user interface.

    As you can now see, Emma is the "innocent bystander" to inadvertent errors and omissions on the part of numerous well-intended 3rd party scenery developers! :shock:

    Perhaps you could bring this to the attention of the Portland developers via their forum:

    http://www.flightscenery.com/phpBB2/viewforum.php?f=10

    They seem like very diligent folks, and would likely fix it ASAP. :wink:

    GaryGB

  8. I tried the restore points (and actually use it BEFORE any new program installation), but it does not solve the problem entirely, because you may get the SAME problem as before.. a restore corrupting a file... whether you copy/move them yourself via Explorer or a backup/restore program or have MS Restore do it, the action remains the same and so do the possible results.

    I run a few FS's (for development, testing and 'playing') and make lots of backups on the former two. Before installing a major update or program I make backups of the most important folders (such as scenery, texture, effects)... depending on what I will be working on/with.

    Hi Francois:

    How do you manage the "install-specific" files in the "C:\Documents and Settings\[user Account Name]\Application Data\Microsoft\FSX" folder, and the "standard template" files in the "C:\Documents and Settings\Administrator\Application Data\Microsoft\FSX" folder when you swap between active FSX installs? :?:

    Also, are you using the customized *.reg files technique to swap between the registry pointers to the different FS installs? :roll:

    GaryGB

  9. Hi Ed:

    I haven't tinkered with my copy of BEV in a while, but I believe conceptually what you are describing is actually the case.

    If you set one configuration that you like and don't go in the BEV configurator again to change it further, then one would reasonably expect that the system would remain unchanged until you personally intiate a change. :wink:

    As I recall, the BEV configurator was a stand alone utility capable of being updated independent of the texture files, and in theory should not be doing anything on its own, and could possibly even be removed; once you have configured a texture file set you like, FS abides by that info from resulting file changes that are native to its own operating parameters.

    But we must also bear in mind that by default, FS changes the date and time of day to keep current with the time that FS is started up, and thereby would be shuffling internal indexes and loading different texture files up according to the parameters of a given flight. It is possible that some of the CFG files involved could be damaged during read/write operations , and that may be why FS has a function which automatically restores from a standard "template" version of certain CFG files any such specific CFG file that becomes damaged or goes missing. :idea:

    FS obviously does not have a maintenance function to check other FS system or texture files and prompt for a restore from the installation CD/DVD media (although that might be a nice feature in the future... sort of a "FS-SFC" or system file checker that keeps an internal database of default install vs updated files in use when it is manually run!).

    I believe what Holger may have been describing is scenarios where FS texture files end up corrupted or missing, as an implication of some mishap occurring when texture files (or "file pointers" that point to them depending on the internal methodology used by programs such as BEV, GE, UT, MegaScenery etc.) are being re-named, or reassigned and/or re-indexed in a configurator program before being written back out for access by FS.

    I once saw a professional office database management program that would periodically "destroy" a file when it was running under Win98, but it would not do so when run under WinXP, so strange things can happen when software runs under different operating systems much less on different FS user computer systems with diverse configurations.

    IMHO it sometimes seems that Windows and 3rd party application functions involve "timing gambles" which assume based on the small probability of certain scenarios happening that it is OK to do something at a particular time, but the result is occasionally the damage or loss of a file or its references in memory, the registry, ini or cfg files, or the WinXP MFT (Master File Table; Win98 uses a FAT or File AllocationTable).

    So we just have to maintain good backups to stay a little safer from extensive re-installation headaches in case things go awry.

    Keeping as many files outside the FS folder tree/chain is, as Francois has said for many years, one's best insurance against problematic troubleshooting and/or re-installation scenarios, while maintaining a high level of controllability and configurability in FS.

    It seems like it would be a good idea to have a dummy FS installation folder chain which is kept empty so one can see what a given add-on program tried to put into FS, so it can be relocated outside the FS folder tree. One could also keep an exported *.reg file backup copy of the FS registry strings, so that a copy of it could be edited and imported temporarily to point to the dummy FS installation folder tree to force hard-coded FS add-on installers to write into that dummy location.

    This might allow one to at least try and locate the add-on to ones preferred location outside FS if possible. This obviously won't work with all add-ons if they have to replace FS default files or are hard coded to find specific files nested within the FS folder tree, but it might help with a majority of our add-ons! :roll:

    GaryGB

  10. Hi Holger:

    Thanks for clarifying that so well; I believe we could all benefit from checking our FS installations to ensure our configurations are compliant with those guidelines now and in the future. :idea:

    One more related question on this topic if I may:

    Is there a consistent naming scheme for landclass *.BGL files required by FS which can be used in a utility comparable to ScanAFD (or is there such a utility already available you are aware of) that could be used to search ones FS installation to identify landclass files (instead of AFCAD files), and check for whether it is improperly paired with an empty \Texture folder?

    In the event that there is no consistent naming convention for landclass files required by FS, would there be a consistent internal file code string which could be used to identify that BGL as a landclass file such that a "ScanLC" type of 'search and evaluate' utility might be created to help us more easily check our sometimes mind-numbingly complex installations and "functional" non-compressed FS backup images for inadvertently misconfigured landclass file/folder placements? :roll:

    Thanks for any additional help you could offer on this. :D

    GaryGB

  11. Hi Larry:

    Having an empty Texture folder under certain types of addons is only a no-no if they are landclass and mesh *.BGL files (there might be 1 or 2 other types of *.BGL files also which I forget!) which must exist solely in a \Scenery folder totally unaccompanied by a \Texture folder or else a looping FS search and load attempt trying to find texture files that aren't even required is started by the rendering engine, which affects performance and can even crash the sim. :idea:

    Perhaps Francois, Bill Leaming, Holger or others could comment here about which specific type of BGL file MUST exist solely in a \Scenery folder unaccompanied by a \Texture folder in FS9 and FSX? :roll:

    GaryGB

    PS: Fire up the Holger Signal! :lol:

    for that and more fun: http://forums.simflight.com/viewtopic.psc&start=0

    post-14010-128689492638_thumb.jpg

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.