Jump to content
The simFlight Network Forums

martinE

Members
  • Posts

    48
  • Joined

  • Last visited

About martinE

  • Birthday 01/01/1970

Contact Methods

  • Website URL
    http://

martinE's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hello again, problem solved* For the benefit of the generations googling after us: It was indeed the aircraft's folder name (under ...FSX\SimObjects\Airplanes), which I had renamed (mainly because I hate spaces in filenames). After I have changed it back to its default name "feelThere Phenom 100" (two spaces!), the LoadManager now works as advertised: it shows the proper empty weight (BOW), calculates the correct ZFW, and changes aircraft.cfg accordingly. And how did I find out the default folder name after all* ? By poking around in the uninstaller EXE with an editor, never mind it's hex code... Thanks again to D.Scobie who did try to help ;-) Cheers, Martin * all by myself, I might add, as no one else seemed to be able to tell me the default name... B)
  2. Thanks for the reply! I had thought of that, but would prefer to avoid it, for fear of ending up in some "repeated registration" hassles... May be this is not a problem in this case, but ... :???: All done under an Admin account, and with "Run as Administrator", etc. Moreover, no problems with other planes using external Load/Fuel Managers etc. which also write across files. So it rather looks as if writing is not even attempted. But I'll double-check anyway. Thanks for the tips! Cheers, Martin
  3. Hmm, not a single reply in one week?? Am I asking in the wrong place? Could someone please let me know at least what the default folder name is for the Phenom aircraft installation, i.e. the NNN in ...\FSX\SimObjects\Airplanes\NNN Martin
  4. Two additional observations: 1. I am assuming that the LoadMgr should modify aircraft.cfg (specifically, the [weight_and_balance] section). This is however not happening either, in my case: Whatever PAX and cargo load I enter into the LM, the default numbers in aircraft.cfg (see below) remain unchanged (corresponding to 2 PAX and about 41% cargo). 2. When looking into the original aircraft.cfg (immediately after installation, no changes whatsoever made), the load entries in [weight_and_balance] look like this: station_load.0= 202.00, 12.00, 0.00, 2.00, Pilot station_load.1="360, 0.0, 0.0, 0.0, Passengers" station_load.2="475, 0.0, 0.0, 0.0, Cargo" Two things seem strange: -- the "label" as a fifth parameter of station_load.X (according to the SDK it should be in a separate property station_name.X) Perhaps this is an undocumented variant, but can anyone confirm this? -- Why the quotes for the station 1 and 2 entries, but not for station 0 ? Cheers, Martin
  5. Hello, I am trying to do the Introduction Flight with the Phenom, but am thwarted already when trying to set up the payload, and I can't find anything about this on the forum here: The Load Manager in the Config tools reports the PAX and the cargo weights correctly, but the BOW field (empty weight) is 0 (and can of course not be edited). So the LM comes up (for 4 PAX and 50% cargo) with a ZFW of 1,196 lbs when it should be (as per Manual) 8,147 lbs. What am I overlooking? I am wondering if the Config tool / LM is not properly talking to the aircaft.cfg file. But, if so, why not? It is possible (can't remember) that I have renamed the Phenom aircraft folder. It's in the normal location in the default FSX folder structure; I may just have changed the name. Could that be a factor? What is the default name for this folder? (I don't want to re-install just to find out, so as to avoid a registration mix-up) I also had a look at the Phenom.log file, but that seemd to be about the aircraft itself, not the Config tool. And in Phenom.ini I couldn't find any clues either so far. The Phenom itself is working perfectly (very nice, too). Thanks for any tips! Cheers, Martin
  6. Thanks again! Correct. I agree. :grin: (My problem is that I do not really understand the role of those IP subnets (the third number in the address); that's why I did not dare to change them back from 1 to 255 in the router. And I have no clue if, how, and why a change in the subgroup would make a difference.) I am always behind the times, because if I can help it, I don't want to take onboard too much FSX-related stuff which from my point of view is just ballast. :grin: But I'll check out the newer versions, thanks for the tip. Well, I had never tried that because my "legacy" setup has so far always worked. But I tested it now, and indeed, I can leave both ServerName and ServerIPAddress out, and still get a functioning connection. Excellent! Thanks again for the quick response; nothing beats support straight from the author. :) Cheers, Martin
  7. Wow, that was fast, thanks for the informative reply! What I had (stupidly) forgotten to mention was that I have indeed set up static DHCP, i.e. the boxes always get the same 192.168.1.55 (and *.66, resp.) address. OK, thanks, I knew I would learn something useful! Again, I was not precise enough. As said above, the 55 was set up by me in static DHCP also for the new router, hence the same as before. The different subgroup (192.168.1.* instead of the previous 192.168.255.*) came from the router presets the new ISP had done already, and which I did not dare to change back to the previous 192.168.255.* With a WideClient.ini entry of ServerName=AB1234 the client log now (with connection OK) shows 735 ... Okay, IP Address = 192.168.1.55 5547 Connection made okay! which is what I would expect. But if I use exactly the same IP number (instead of ServerName) ServerIPAddr=192.168.1.55 it does not work; the log gives me only ********* WideClient Log [version 6.615] Class=FS98MAIN ********* Date (dmy): 05/10/11, Time 16:00:43.437: Client name is AB1234 203 Opening GPSout port COM3, speed=9600 -- OK! 250 Attempting to connect now 672 Trying to locate server: Protocol not yet decided 672 Failed to connect: waiting to try again 2719 Attempting to connect now But no problem, I shall just stick to the ServerName parameter in the future. Cheers, Martin
  8. Hello, first off, please note: My problem is already solved :grin: This message is based on mere curiosity (also with a view to possible future related issues). I have been running (for years) a setup with FS9 on box A (locally 192.168.255.55) and all sorts of add-ons on Box B (192.168.255.66); both "connected" via WideFS. Has always worked like a charm. Today I found out it had ceased to do so: both WideFS server and client kept waiting for a connection, but none was ever made. The only change in the setup had been that due to an ISP change I had taken into use a new ADSL modem/router; same model as before, with almost same settings, except for the subnet 192.168.255.* addresses which now are 192.168.1.* (I realize that the router should be irrelevant for the WideFS connection anyway, as long as the boxes can see each other at all; but read on.) The WideClient.ini had so far contained only an entry for ServerIPaddr, and I had of course changed that from 192.168.255.55 to 192.168.1.55, i.e. to the new IP address of box A. Still no connection. More or less by lucky guess I then disabled the ServerIPaddr entry and added a ServerName=ABC one. And lo and behold! instant success -- everything works again. No changes in hardware/software firewall or NAT settings were required. This quite surprises me (hence the curiosity) -- I have always thought, explicit numerical IP addresses are the "safer bet" (because they don't require name resolving which can be an added source of problems.) How can that be? Why can my WideFS client not handle the server IP address any more, but will still run fine when given the server name instead? (BTW I did check with ping, and it worked OK for both IP address and machine name, so it's not a matter of me mis-associating numbers and names.) Inquiring minds want to know. Thanks in advance for any enlightenment! Cheers, Martin
  9. Greetings, Never believed otherwise, but just for completeness: Same alert ("Win32/Genetik trojan") received for: FSUIPC.dll (for FS9) v.3.9.0.0, time stamp 26.02.2009 15:37, size 251,008 byte which comes packaged with the Just Flight "Air Hauler" add-on. Alert generated by ESET NOD32 v.2.70.32, signature database 4015 (20090417) The Kaspersky online File Scanner gives the file a clean bill, unsurprisingly. Air Hauler is not using the Flight1 wrapper, though, so that can't be the (only) culprit. Cheers, Martin
  10. Well, MS tradition seems indeed to be to rely on file extensions to identify file types, even in cases where the rest of the world uses MIME types, etc. So, changing the extension should make the file (functionally) invisible. But who knows... Obviously, I should have cross-checked, by re-introducing AdvDisplay again, now that everything works; and I will do that -- but not right now, first need to drum up the courage to possibly break things again :-) . That is actually the most likely. Yes, I think so, too. I hadn't had any conspicuous crashes, but when running FS9 and RC4, my machine (2.6 GHz, 768 MB RAM) is already teetering on the brink of its performance all the time, and that can sometimes lead to problems even though nothing really crashes. In my view, no one ever knows what "state" an XP box really is in at any given time; there are nowadays too many unknowns and contingencies involved. Plus the basic problem of "accumulative garbage suffocation" (over session time, and also over computer lifetime). Most of the time XP admittedly handles it all very well, but if not, you're out of luck and rebooting (or re-installing Windows :-)) is your only resort indeed. In that sense, the greater stability (against crashing) of XP over earlier Windowses is indeed a mixed blessing: It "hangs in there" forever while perhaps letting go and making a fresh start would be the better way :-). Thanks again for the quick help! And Happy Holidays! Cheers, Martin
  11. Greetings, many thanks, Pete, for the very impressively prompt reply! First off, the problem is now solved! Second off, I don't know why. :-) Just for the record and those generations coming after us, here is what I did since I had the problem: -- checked the FS9 fonts: all there and working. -- moved the AdvDisplay files to another folder (before that, I had only renamed advdisplay.dll to advdisplay.Xll); -- changed FSUIPC to version 3.5.5.6 again; -- started FS9 and found that the standard messages (both "Paused", "Slew", etc. at the bottom, and ATIS etc. at the top) were now all back to normal; -- started RadarContact 4 and found that this now shows up as it should, in the new nice transparent FSUIPC window. So, basically "I didn't change a thing" (famous last words of the user :-)) but it all healed itself. I can only offer three possible explanations, take your pick: 1. The one thing I did change was moving away the AdvDisp files -- but is renaming a *.DLL to .XLL really not sufficient to put it put of business? Or did the advdisplay.ini (which I had not renamed) perhaps interfere while still in the Modules folder? or 2. Rebooting the whole machine (which I hadn't tried before) did the trick, for some reason or other. Doesn't make much sense to me, but hey, this is MS culture -- if in doubt, reboot; if still in doubt, re-install Windows. :-) Or maybe the box, same as me, just needed a good night's sleep? or 3. FSUIPC (or XP, or FS9) got scared when realizing that The Master himself, here on the forum, was already taking an interest in my troubles, immediately after my call for help. So it decided to better pull itself together right now, not to incur the Master's Wrath. :-) Thanks again for the quick help. This kind of fast response, even if not containing a direct solution, is always very important to keep one's courage up, and thus to keep one going! Cheers, Martin
  12. Greetings, after updating from FSUIPC (registered) version 3.5.3 to 3.5.5.6, I have the following strange issue: -- The standard FS9 message window backgrounds are visible (see the attached screenshot): - red, lower left (for e.g. "Simulation paused", "Parking Brake") - red, lower right (for e.g. "Slew") - green, top margin (for ATIS and ATC text) -- The new transparent (and nice!) FSUIPC window is also visible (with a bluish background; in the picture it's hard to see, between the radio stack and the overhead panel) BUT: -- None of these windows displays any text (not even the default FS9 windows any more). -- Sometimes I saw at least the ATIS ID (e.g. "PAPA") in the FS9 top message window, but later it disappeared and was never displayed again, even when the spoken text was repeated. I do not understand very well the two new display option buttons on the "About" tab of the FSUIPC dialog (e.g. the logic by which the lower button is sometimes available and sometimes not), but have tried all permutations without success. I have also set (in FSUIPC.ini) "WhiteMessages=Yes", ditto to no effect. Furthermore, I have disabled advdisplay.dll, but that didn't make a difference either. After going back to FSUIPC 3.5.3 (and re-activating advdisp.dll), I can now see e.g. RadarContact messages again (in the old AdvDisp window, of course), but the text in the default FS9 windows is still missing. How can that be? Does FSUIPC fiddle with sim1.dll (or wherever it was where those standard messages about Brake, Pause, Slew, etc. live)? How can I get these messages back? All very strange. What am I missing here?? My graphics card is an ATI Radeon 9800 Pro, but I don't think that's an issue: a friend of mine has the same and did not encounter these issues. (It may however be that he runs FSUIPC 3.5.5.3, not 3.5.5.6; could that make a difference? The release notes do talk about checkbox issues on the About tab, but it may be a different matter). Any ideas? Thanks in advance! Cheers, Martin
×
×
  • 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.