Pete Dowson

No, not particularly. I hate there to be problems, and wish I knew how to help more. At present all I can do is try to relay what information I actually know about the problem. Incidentally, after I sent the last reply, I loaded up FS2004 on my system with those Parhelia drivers I mentioned, and deliberately tried to reproduce a "black screen" problem again. After a number of swaps between full screen mode (which is over 3 monitors at 3840 x 1024) and normal single monitor maximised windowed (at 1280x 1024), I got no problem... However, one time when I was in maximised windowed mode I "restored" the window to a smaller size. That worked, but when I pressed ALT+ENTER to go to full screen mode from the smaller window, all that happened was that window went black and the mouse pointer sat on it fluttering like mad. I again pressed ALT+ENTER and got the same but with the menu. It seemed that FS2004 wasn't "hung" as such, but the 3D window view was certainly irrevocably turned black. I closed FS okay, but then got the usual "program crash, report to MS" window. According to the details in that it was D3D9.DLL (I think -- I may have mis-remembered it), certainly part of Direct 3D. So, I decided to upgrade to DX9b (from DX9a) after all ... I've done that, I'm now on DX9b, and I tried the exact same sequence again, and couldn't get the black screen this time. Not that whatever problem it is is necessarily fixed by DX9b, just that this particular instance of it is. Yes, well. Actually, to my knowledge, that sort of statement has been made with every version of Flight Sim, ever since I can remember. MSFS has always been the ultimate test of your system, its drivers, and so on. There have always been problems in systems shown up by the latest version of FS and nothing else. I'm truly sorry I have been of no help to you, but I've explained everything I know about this problem. I do hope you find the solution for your specific system. If I do find out anything else, I will be sure to let folks know, probably here. Regards, Pete

No. I don't think it is an FS9 problem but it is between DX9 and video drivers. It was able to be completely solved by everyone that I know of, eventually, by some combination of changing video drivers, video cards or DX version. In some cases it took a lot of hassle, chopping and changing, not always to later drivers, sometimes earlier. I'm sorry, but all the evidence I heard about, and experienced myself, does actually point that way. What else can I say? I know of no other theories. I think one of the top experts in this area is Katy Pluta. She frequents the FS2004 forum, near here. Perhaps you might like to post a question there and see whether she, or others there, can help? Sorry, I cannot really help further. I was certainly one of the sufferers of this problem -- very much so, using some earlier versions of the Matrox Parhelia drivers -- but the current 1.04 edition of the Parhelia drivers are standing up very well. I am still on DX9a -- I did consider updating to DX9b but I thought I'd leave well enough alone for now. :) Regards, Pete

The only way would be to use the button programming facilities in (a registered version of) FSUIPC and re-assign the Gear switch action to something else. Any re-programming in FSUIPC takes precedence over the default actions of the PFC switches and buttons. Go to the Buttons page in FSUIPC, operate the Gear switch, re-program it. Regards, Pete

Writing 1 byte from a row of bytes will only write the first byte, of course, as you surmised. Reading N bytes into any area in your program where you've only reserved N-1 or less bytes for the data will overwrite whatever follows. If the data area is on the Heap is could result in errors or crashes later, with heap links destroyed. If the data is declared globally or as "static" then it will again overwrite whatever follows it, which may be difficult to determine (look at a ".Map" file if your compiler provides one). If the data area is dynamic (i.e. declared locally in a procedure or subsection of code), then it is on the stack, and the extra bytes will overwrite other values and even possibly the return address for the procedure, so causing a crash later, when the procedure exits. All these things would be the same if you read more data from any source, for instance a file, into an area not big enough. None of it is specific to FSUIPC. Regards, Pete

Best way to identify them is to got to the FSUIPC Buttons page, and use it to pretend to program the buttons. When you press a button, the Joystick number and Button number will show on that page. Pete

Not so much numbering. Byte 0 just means the 1st byte, the one at relative address 0. And so on. If you were using an array of bytes BYTE bHotKey[4]; then byte 0 is bHotKey[0], .... byte 3 is bHotKey[3]. Ah, if you manipulate it as a 32-bit word, instead of 4 separately addressable bytes, then all you need to know is that in Intel processors (and their compatible non-Intel relations), the "least significant" comes first and the "most significant" comes last. this is termed "Lo-Hi" format. Motorola processors (68000) are Hi-Lo instead. Not sure about the others. So, your 32-bit value 0x12AB34CD is actually stored in memory in 4 successive bytes as 0xCD, 0x34, 0xAB, 0x12 making 0xCD byte 00x12 byte 3. Incidentally, this "numbering" method is also used for bit numbers. so "bit 0" is the Least Significant bit (value 1), and so on. Regards, Pete

Actually I'm hedging my bets. I've got two PCs I want to upgrade -- one I use with the Parhelia for airliner flying, and another with the Aerosoft GA28R which I use for VFR flights in a Piper. I can't easily use the same system for both because the equipment (the huge GA28R versus all that PFC Jetliner stuff) is too heavy! :o I was thinking of getting a complete new system and shuffling the others down one. The "weakest" (an Athlon 700) then sort of falls off the end and goes to a relative! :) But, I've been pricing things up and decided I can do it all by merely replacing motherboard, processor and memory, and do both the IFR and VFR systems together for much less than a complete new system! So, I'm looking at these two upgrades: IFR (with Parhelia): P4 3.2GHz with 800 MHz FSB, MSI 875P Neo IS2R mobo, with 2 x 512Mb PC3200 memory, matched pair for dual channel access. VFR (with nVidia Ti 4600): Athlon 3200+ with 400 MHz FSB, Asus A7N8X Deluxe Rev 2 mobo, also with 2 x 512Mb PC3200 memory, matched pair, dual channel These would replace a P4 2.4GHz and Athlon 1800+ respectively. As far as I can tell from reading through all the reviews these motherboards and RAM configurations are the fastest you can get at present. Problem at present is the Athlon 3200+ -- I can only get the 333MHz FSB version. The others are on a "long lead time". So maybe I'll only upgrade the one for now. And I will take note of the business of processor "affinity". Thanks! Regards, Pete

If you are the sole user, then really your proper course of action is to register FSUIPC. However, if this is freeware which may be distributed without profit, then you can get a free access key for it. Contact me on petedowson@btconnect.com (as requested in the sticky announcement on freeware keys, as well as in the original announcement about FSUIPC going payware), and I'll send you details of the registration system for applications. Regards, Pete

If the program you want to use is accredited for FSUIPC 3 then you don't need to register. If not, then you need to check with the author whether he is going to get it accredited or not. If not then you would need to register your copy of FSUIPC to use it. Regards, Pete

Leaving the box UNCHECKED, as it is by default, was supposed to leave the FS weather alone. It did, except for the wind smoothing. The reason the 3.049 Beta worked was that the mod I put in for that checkbox broke the wind smoothing altogether. I repaired that but, in the process, the wind smoothing activates itself for FS's own weather. It doesn't actually do anything, as the targets are the same as the current winds, but it seems that telling FS to set the exact same weather as it has already set constitutes "user-defined" weather. Oops. So, as well as leaving the box unchecked, uncheck the wind smoothing. I'll fix it soon enough. Sorry. Pete

These days the normal way would be to use USB devices instead of Game Ports. Isn't your SideWinder USB compatible? You can certainly have several joystick devices connected at once with USB. When motherboards sported a Game Port as well as Sound Cards you either had to disable one or the other, or make sure the sound card was one which could detect the other game port and configure its own to be on a different port. There also used to be multiple Game Port cards around -- I think there was one by Thrustmaster, for instance. But this is getting more difficult now. You may possibly find that adding another PCI sound card will do the job, but you will have lots of messing about to do to configure the drivers. I don't think the standard SB drivers cater for more than one card so you'd need a card with totally different and not incompatible drivers. If I were you I'd look at USB devices. It's a whole lot simpler, especially if you are using Windows XP. (Windows 98SE or Me work with USB devices, but can be awkward with more than one -- they seem to be prone to reassigning them differently each time you boot). Regards, Pete

I understand that, I was only giving advice for next time! Sorry you took it the wrong way. :cry: It also has statements on it where Enrico explains why. My name appears in lots of places it seems, but only this one is mine (well, its on loan to me, anyway. :) ). Sorry if it offended you, but I will correct the assertion that the Schiratti site is mine every time I see it, as otherwise I get all sorts of emails when people have downloading difficulties and so on. Any queries about any web site should be directed to the folks who own it or run it. Okay. I think you will find that SimMarket's customer service is excellent. You should have no problem, though they may well tell you off too! :D Regards, Pete

Sorry, I've really no idea. You want to talk to Luciano Napolitano, author of WidevieW, the main purpose of which was to link multiple FS's together smoothly. It did a better job than multiplayer, but I don't know if he's doing a version for FS2004. Regards, Pete

[quote name="SeanMcLeod Reason I thought it may be possible was because those appeared to be the only variables referencing flight control surface's positions' date=' plus the docs said they were 'writeable'. I assumed if they were really just 'indicators' then they would've been read-only.[/quote] Where does it say "writeable"? I don't normally say such things. Most things are writable, but that doesn't mean writing to them has any effect. For most indications whatever you write will simply get overwritten on the next frame as the sim re-computes it. Mind you, there have been surprises -- like writing to the accelerations can produce an acceleration. It is short lived, but it has been used to good effect for catapulting. They are the controls. I'm not talking about moving the joysticks themselves, I'm talking about the controls that the joysticks "actuate"! Exactly. You can also use those for "fly-by-wire" as I provide the inputs in another location. Like fly-by-wire. Disconnect the control inputs from the "actuators" and put your own algorithms in between. That's what those facilities are for. That's the way folks have used them. Yes, though I think most folks use the elevator trim instead, like the FS autopilot. If you want the plane to be ready trimmed when your A/P is disconnected I suppse you'd need to work out proper use of both. Who's FBW? Obviously if something else is doing the same as you there will be conflicts. Yes, that's what it says, more of less, isn't it? That's why the facilities are there. And not just elevator of course. If the input is connected, the input goes to the control. If you disconnect it, it doesn't. It is that simple. And I have never heard of any FBW in any MS aircraft. Regards, Pete

Yes, please see the Announcement called "Important". Regards, Pete

As explained in detail in the WideFS documentation, you get that effect when the client is timing out responses from the server and so re-connecting. You will also see what is happening if you look at the logs. They will be getting huge by now, by the sound of it. You have something very wrong on the Network for it to do that so much. You need to check the network for problems. Really all I know about this stuff is embodied in the documentation I provide. If ever I do learn something new, I add it. Regards, Pete

Actually, I don't have a "site" as such. mostly I direct people to Enrico Schiratti's site, as he has a page containing all my software. However, "WidevieW" is not mine, it is Luciano Napolitano's. Perhaps you meant WideFS? You really need to apply to SimMarket's customer service (http://www.simmarket.com) and explain the situation. Use exactly the same name and email address as you used for your order. They should be able to find you in their database. I'm not realy involved in the loop. Next time, keep at least the email receipts, or a backup of the FSUIPC.KEY file after you register, or both. As with any purchase, it gets a bit difficult otherwise. Regards, Pete

Do you have a spare button? Is it programmable in PFC.DLL? Have you checked the programmable button facilities in PFC.DLL and described in the documentation? If it isn't programmable in PFC.DLL and you have registered your copy of FSUIPC, you can program it in FSUIPC's "Buttons" page. Make sure you have enabled FSUIPC's Project Magenta controls and find the PM MCP heading select control in the drop down list. Regards, Pete

FSNav version 4.60 works fine with FSUIPC. I think there was a problem with the previous version. Pete

I don't think it actually uses FSUIPC at all, but certainly I've been told that it is doing some sort of check which failed in the previous version (4.5) if FSUIPC was installed. I really doubt whether it would make any difference whether FSUIPC was user registered or not, but I would be interested to hear confirmations one way or the other. Thanks, Pete

Sounds like you have a video driver problem, or possibly an bad installation of FS. FSUIPC isn't really going to start doing anything till well into the session. You can delay FSUIPC even further if you like by adding "InitDelay=n" to the [General] part of the FSUIPC.INI file (in the FS Modules folder) -- the default for 'n' is 3 (seconds). You could try anything up to 30 seconds there. The only other thing to consider is memory. I don't know how much you have, but FS2004 is *very* greedy for memory. If you have less than 512Mb I'd advice getting more. When you add FSUIPC it is needing another 1Mb+ and this may just be tipping things over the edge at the wrong time. Regards, Pete

Why not use Multiplayer? FSUIPC and WideFS synchronise many of the FS reads and writes to the FS frame rate for good reason -- it would make it quite unstable not to do so, and for most there's no point in doing it at other times in any case. I'm not sure what you mean by "screen refresh" other than frame rate, but you can make it faster by having more options off or a faster processor and video card, and you can slow it down by increasing complexity or running on a slower machine. You can also limit it using the frame rate limiter. If you want both copies to run at the same speed make sure they can both run really fast then limit the frame rate well below their capability. Regards, Peete

As I think it says somewhere, ALL the values in the second table in the document were found "by accident" in FS2000, some don't apply to FS2002 (or I've not found them), and probably many more in FS2004. I've not even got to them for checking yet for FS2004. And the reason there's no comment, nothing against them, is that I mostly have no idea what they are nor what units they are, even if they do work. When folks use them and tell me about them, I see if I can reasonably "promote" them to the first table -- but this gives me more word each FS release to try to find the things again, so I'm reluctant if there's already something similar. That's an INDICATOR, You can't move the elevators by modifying the indicator, nor for that matter changing the "elevator deflection" readout, which is probably the same thing in any case for all I know. To move the control surfaces you use the controls. Surely this should come as no surprise? Indicators indicate. Regards, Pete

It actually fidles the same values that I used to correct the "white outs" in FS2000. No, it isn't accessible through the IPC interface. I'm not sure it would be a good idea to let it be so -- it would really muck up what I am trying to achieve with the facilities. You need to switch all my stuff off. Regards, Pete

I am not surprised. I think the Flights menu is called "Flights" not "Flight", isn't it? Okay, that shows nothing added into FS apart from FSUIPC, so that's okay. Then FLControl is most definitely still being run. Are you starting this with a batch file, or what? Your FSUIPC INI doesn't have any Run Options set (or at least you didn't show any in the INI file), so how are you running that program? I'm really running out of ideas. All this is so far EXACTLY what happens with WindowBlinds. You must have something else running which is taking over the control of Window facilities like menus. All I can think of doing is trying to get a list of all the processes which are running, then looking at those, one by one. Do you think you could do this: 1. Ctrl+Alt+Del, get the task manager showing 2. Select "Applications", and make sure the window size is long enough to show the whole list 3. Press ALT+PrintScr. That puts a picture of that window onto the clipboard 4. Load up Paint (in the Programs-Accessories group) and paste in the snapshot by Shift+Insert. Save the picture of the Window as, say, "MyApplications.bmp" 5. Now select "Processes" in the Task Manager, stretch the window to show the whole list (there'll be a lot more) and do steps 3 and 4 again, saving it as, say "MyProcesses.bmp". Then either show both pictures here, or ZIP them up and send them to me at petedowson@btconnect.com. Regards, Pete