Pete Dowson

Since you have not registered FSUIPC, and you have no add-ons using FSUIPC, it is actually not doing anything (not sure why you are even installing it). Just because you can make CTDs happen with it installed and not without, doesn't mean it is the 'cause'. It only means that, whatever true problem is actually occurring only results in a CTD when the timing and memory arrangements are just 'so', just as occurring with that partifcular version of FSUIPC installed and not a different one. This sort of thing has happened now and then through the life of FS and FSUIPC, and with and without other add-ons, and from your description is likely to be one of several things: 1. A video driver problem. It may be worth trying to change some of the settings, in the drivers and/or in FS -- things like "render to texture" in the display settings are often very sensitive in this way. It may also be worth trying different versions of the video drivers. Trial and error is the key. 2. A corrupted file. If you had the problem before, then re-formatted the HDD and re-installed everything and still get it, then this is less likely of course. But otherwise known causes are bad WX files, especially if loaded by the default flight (which you cannot stop loading without editing the FS9.CFG file), or a corrupt graphics file, either for scenery textures or aircraft. You could also try using the latest interim version of FSUIPC, 3.716, which can be downloaded from one of the Announcements above. There's as much difference between 3.71 and 3.716 as there was between 3.70 and 3.71 (3.716 will be released as 3.72 before the end of the month). You say: but the first is certainly different ("my fs9 ONLY crashes in MP sessions"), has no mention of FSUIPC at all, and the thread stops after the suggestion "You're not using internet explorer 7 are you? If so then just delete OLEACC.DLL in the FS2004 root folder.", which seems to suggest that this cleared it up. The second reference actually contradicts you in effectively showing it couldn't be FSUIPC: Of those add-ons, the PMDG aricraft and SB3 both use FSUIPC -- no CTDs. GE Pro does not use FSUIPC, it is pure graphics - CTD. That certainly suggests video driver problems or corrupted graphics files. The only posting related to FSUIPC in that thread is your own. You say there "Read pete's forums and other have same problem." but that is very misleading as the only un-resolved post here like that is yours. :-( You also said this I have nothing to do with SimFlight forums other than answering messages in this one and being able to delete and arrange them. Someone in Simflight deals with registrations and user IDs. Then you say but the first gave no other information and stopped immediately the suggestion from Bob arrived about the ATC bug in FS9 which certainly is a known cause of CTDs, and the second is the one you refer to above, which is not even in my Forum and doesn't mention FSUIPC, only GE Pro as the cause. I would be grateful if, when you want support, you always first try the latest updates -- the Announcements at the top of this forum always tell you what is going on, and provide updates which may be good but simply have not made it to full user release status yet. Regards Pete

Correct. It was becoming too much of a hassle. With SimConnect being the MS "preferred" FS interface for the future, and that being "free" (except for new development effort of course), I saw no point in forcing key checks for FSUIPC access any more. No process needed other than you telling your users to use the most recent versions of FSUIPC -- 3.71 or later. ;-) Regards Pete

Because all of FSUIPC4's "reads" are from an internal area populated by updates automatically sent by SimConnect when they change, variable reads are always valid. Actually 11D4 was the pointer to the SIM1 modules data area, and was zero when SIM1 wasn't loaded. Since FS2002 the SIM1 module has been resident, so it hasn't really been of much use. I did fiddle it in FS2002 days for internal use, but it really doesn't quite mean what you think it means now. It is actually marked as "not applicable" for FS2004 and it certainly isn't for FSX. The best "busy" indicators, which are more likely to show when FS is not changing values (in FS2004 or later especially) are those in bytes 3364 and 3365, which can be read as a 16-bit value and tested for zero. If you think it would be useful I could simply set 11D4 zero when 3364 or 3365 are non-zero and vice versa. Would that help? I'm not really sure what you mean by "post-read processing errors". Are you getting invalid values in some offsets? Yes, as documented. It is what SimConnect supplies, and I have retained the whole path in case there is a possibility of referring to aircraft outside the main FS path. Are you suggesting it isn't desirable? I could strip off the FS part if present, or leave it intact if not, but I would think it more generally usable as supplied. Ah! Great! Thank you very much! I assume you are working from the latest list, downloadable above and updated for FSUIPC 4.067? Regards Pete

I assume this is with FSX? Most things aren't controlled by "offsets" at all -- offsets are identifiers which represent programmable values, many dating back as far as FS98 and maintained for compatibility over all the FS releases since then. Most cockpit functions will be controlled by what I call "FS controls" and Microsoft refer to (internally at least) as events. You only had to ask, or better, use FSUIPC event logging and see what control does what. You could do the same here. They must be new controls in FSX as I don't recall any in previous versions for these functions -- those cockpit sporting such knobs were mouse-controlled as far as I recall (or maybe keyboard for add-ons like PMDG aircraft). There's a list of FSX controls installed in the FSX modules folder for you when you install FSUIPC4. However, I've glanced through that and I don't see anything useful for this. How do you do it in the FSX cockpit? If you can switch on FSUIPC's event logging and use the relevant keys (or that GoFlight unit) then you should be able to find out. If you can find the control numbers then they can be written to offset 3110, if your system can only work with offsets. Usually it is easier to program a button, switch or key. Regards Pete

I assume this is with FSX? Most things aren't controlled by "offsets" at all -- they are programmable values, most dating back as far as FS98 and maintained for compatibility over all the FS releases since then. Most cockpit functions will be controlled by what i call "FS controls" and Microsoft refer to (internally at least) as events. You only had to ask, or better, use FSUIPC event logging and see what control does what. You could do the same here. They must be new controls in FSX as I don't recall any in previous versions for these functions -- those cockpit sporting such knobs were mouse-controlled as far as I recall (or maybe keyboard for add-ons like PMDG aircraft). There's a list of FSX controls installed in the FSX modules folder for you when you install FSUIPC4. However, I've glanced through that and I don't see anything useful for this. How do you do it in the FSX cockpit? If you can switch on FSUIPC's event logging and use the relevant keys (or that GoFlight unit) then you should be able to find out. If you can find the control numbers then they can be written to offset 3110, if your system can only work with offsets. Usually it is easier to program a button, switch or key. Regards Pete

Thanks Nico for jumping in. But I'm still not clear. Okay. I assume he has instructions for that with his encoder ... Ah, so the positions are denoted by the individual bits, not the value itself. Ok, in that case, yes, that sounds fine. Are there only 6 range values supported in a 767? There are 8 in a 737NG (5nm to 640nm). Again, values 1, 2, 4, 8, 16, 32? Surely there are not 6 modes? The normal is 4 modes, APP, VOR. MAP, PLN. From what you've told me, yes. But I don't know the aircraft nor the offset usage. Sorry. Regards Pete

I'm afraid I know nothing about the LDS767 nor how it interfaces to anything at all. The only dumb questions are those that remain unasked. But I'm sorry, I don't know how to help with this question since I simply don't know anything about the aircraft and not very much about FSCONV. Most add-on aircraft either use mouseclicks for special functions, in which case programming is difficult (maybe needing Luciano Napolitano's Key2Mouse), or do have keyboard shortcuts assigned (as in the case of the PMDG aircraft). I think the LDS767 aircraft does have a software development kit (SDK) to allow control via FSUIPC, but that's about as far as I know. Hopefully some one else will be able to help. Is there an LDS forum? Or maybe one for FSCONV? Regards Pete

Sorry, I have absolutely no experience of any basic do-it-yourself cards since I stopped using EPIC. I do have some ready-made GoFlight modules with rotaries, toggles and buttons and they work well. Pete

They are really for programmers. There are some basic facilities to influence values from buttons or keypresses, but then the answer to your question, assuming you are not writing a program, is that it depends what you want to do. You can use the Offset controls listed in the control drop-down to do so, yes. But it is best to decide what you want to do first, then ask the question of how, if the method is not obvious. 99% of things you want to do are already supported by ready-made FS or FSUIPC controls in any case. The answer to all these is really that I couldn't possibly comment, as you give no indication about what you want to do. What are you miserable about? If you explained what you want to do, if you asked the direct questions, it would be easier for me to help. As I said, most things people want to do are already done. It is only a matter of recognising what name Microsoft have given to the control you want to use. And often simply perusing the FS controls list will suggest the answers in any case. Why the odd and rather obscure title to the thread by the way? Titles should really be such that other users may see from the thread list whether they are likely to be useful to them. Regards Pete

FSUIPC always produces a log -- just normally containing routine information which I need supplying on any support call. In normal circumstances it is not a problem. The Logging options are for exteas which do invariably make the Log very large indeed. You have problems with your FSX installation. Something is performing so poorly that data is not arriving in FSUIPC4 from SimConnect for so long that it is re-connecting. This is a problem. Here are the indications: Odd that this first happened about 2 minutes after everything started up okay. Have you got external SimConnect clients starting later? One or more of the subsequent restarts may be due to SimConnect not being able to continue supplying data within the 1-2 seconds FSUIPC4 expected in the release you have. Please download the latest interim release from the FSX downloads above and trying that. Check the Log. No, see above. You should not be seeing any SimConnect failures and re-connections, unless you are starting MultiPlayer mode, which is a known FSX bug and should be fixed in the first FSX update. Regards Pete

More information? What "fmc" is this? What software drives it? What does "drop out of function" mean? What does the FSUIPC Log show? The list of changes between each release is shown in the History document, which is in the FSUIPC.ZIP. Does that suggest anything? Have you tried the latest interim update available in the downloads (see announcements above)? Do any of the changes mentioned there suggest anything relevant to your device and/or software? Are you sure your fmc has anything to do with FSUIPC in the first place? [LATER] I just noticed you mention "PMDG" in the title. I'm afraid I've no idea what relationship the PMDG FMC has with FSUIPC -- I wouldn't have thought it had anything at all to do with it, as it is involved in flight plans and its own database system, areas completely unrelated to FSUIPC. Have you asked over in PMDG's support forum? Regards Pete

Because 99% is the same, and the differences don't matter a lot in any case. Right on the first page there are these clear statements: And the Installation section is clearly separated as far as the Server is concerned. The only joint section is for each Client, since Clients are independent of Server FS version. That is because it does NOT only apply to FS2004! The client is IDENTICAL no matter which FS version you use. That is the WHOLE point. I am rather taken aback that this could possibly be mixed up, especially when I tried so hard to make it clear! The heading "FS2004 or earlier" means for FS2004 or earlier. The heading "FSX or later" means for FSX or later. The heading "On each client PC" means for each client PC -- clients do not run FS. The version of FS is absolutely and completely and utterly irrelevant for the Clients! You said that's the way you understood it, but then somehow applied the earlier section headed FS2004 and earlier in any case. Why? And even with a different interpretation, there is no mention whatsoever of placing anything to do with WideServer under that "On each client PC" heading! Ah, so what was the problem? Actually placing WideServer.dll and ini files in the FSX Modules folder won't do any harm, it won't do anything at all in fact (except take a little more disk space of course). ;-) No problem, except I'd really like to know how, even after "several" readings, the Installation paragraphs confused you. Could you please point out the part you think is in error and I'll try to make it even clearer. I did think of keeping the original WideFS documentation unedited for FSX, and have a separate little "read me" explaining the small differences. This is what I did during the Beta stages of course. But it didn't seem like a good long-term solution, especially as the differences are so small. Regards Pete

You've not looked at the documentation? ::-( There are no separate WideServer files for FSX. WideServer is built into FSUIPC4. Please delete the WideServer.dll and INI files from the FSX modules folder. WideFs never has used shared folders and doesn't need anything shared at all. Did you enable WideServer in FSUIPC's About & Register options page (button bottom right)? Where's the WideServer.Log from the FSX Modules folder? It looks as if eiither FSUIPC4's WideServer option is not enabled, or you still have a firewall blocking access. Just because Windows Explorer can read and write shared files does not mean other programs are not blocked. Regards Pete

Yes, thanks. They sent me a copy too, for information, and say they are investigating. The odd thing here is -- what ARE these services? They don't appear in any of my PCs, so I can only assume they are from some add-on software you have. Do you know where they come from? Regards Pete

Best not to mess with things you don't understand. Next time delete the FSUIPC4.INI file from the FSX modules folder and start again. How would I know? You tell me! See what you've got it assigned to in FS. Have you never even used FS's joystick settings? You should have done all that long before even looking at FSUIPC! :-( The FSUIPC4 Joystick Settings options don't change assignments, they only show what FS tells it. They aren't reading your joystick, FS is. FSUIPC's calibrations work on the controls inside FS, not on the joystick values. If the prop pitch values are changing in FSUIPC it is because the prop pitch values are changing in FS. You can assign axes in FSUIPC4, through its axis assignments options, but all that is separate from FS altogether and really requires you to de-assign everything in FS. As a beginner, I'd advise you not to go there at all. Pete

But in my SECOND reply to you, specifically, I said this: and in your reply you said: So you actually had TWO extra firewalls installed -- McAfee, and Norton? Both being in addition to the built-in Windows firewall? Again this was from ragwood68 Posted: Fri Dec 29, 2006 1:40 pm Post subject: Erno. You are really confused! In the exact same message as where you said "looked at the SimConnect log and found lots of loads.", but a few paragraphs later, you said How is that not a contradiction? Regards Pete

The Mailslot use in WideFS is an addition. It isn't essential. I just wanted a way for the whole thing to work automatically, without users having to edit anything at all in any INI files. Just bung WideServer into FS, WideClient into each client, run everything and they all link automatically. The way I found to do this was by the Server sending regular mailslot packets (once a second by default), each containing its IP address and preferred Protocol. Any unconfigured Clients read mailslots regularly, and recognise one from a Server. That all works fine on XP and Win2K, but the service never existed in Win98 and so on. Not even NT as far as I know. So it isn't an essential part of WideFS. The original method of specifying the IP address or name of the Server in the Client INI file is still there. So there is no need for any "re-design of the WideFS/FSUIPC communication layer" really. I think I may have been doing that in any case. ;-) Best Regards Pete

So my placing links on the download page, and in the documentation, and even on the About+Register screen of FSUIPC Options, is all wasted on you, eh? I Support via the Support forum. I think you should take a look now and then, please, or you will miss out on most of the support. But wasn't all that was mentioned at the start, as well as in the FSUIPC Read Me (part of the download package)? It is even mentioned by Microsoft themselves in their own website. I don't understand how it took so many exchanges here over so many days before you did this. It sounds like the joysticks weren't assigned or enabled in FSX in the first place! I don't understand that. If they are calibrated and FSUIPC4 shows them providing a good OUT range (about -16000 or so to +16000 or so), for the rudder, then there's really no way FSX can ignore that. UNLESS you've gone to the Steering Tiller page in FSUIPC4 options and enabled that -- then you'd get little or no rudder steering on the ground, but it should still be operable in the air, or on the ground once you get up to speed. Isn't that another contradiction! Just above you said "I turned off the firewall, and ran the FSX program, looked at the SimConnect log and found lots of loads." Sorry. Things don't work like that. If you want updates you need to browse the Forums, see what's happening, download fixes, get advice, and so on. There's no waiter service here I'm afraid. It's only self-service. As I mentioned earlier, my slowest PC is 3.2Gb. That's the one I do development and debugging on mainly, and FSX runs on it usually in a smallish window so it gets enough frames per second. I have FSX installed also on an Athlon FX-57, an Athlon FX-62 and, my fastest, driving my main 737 cockpit, an Intel Extreme 6800, the fastest around when I bought it in September. I'm afraid I've no idea what their clock rates are these days. My FSX installations are tweaked like crazy to get decent performance. It takes a lot of time. Anyway, good flying for now! Regards Pete

So, WideFS should work across workgroups, except for the Mailslot Server broadcasting system I added which is, I believe, using a specific Service? Thanks, Pete

Sorry, I'm not up on all this stuff. What is a workgroup for then? But if the rules between workgroups are the same as within workgroups, what is the point? Isn't the same thing accomplished by just naming them sensibly. Like "FS-Left", "FS-Right", "Office-Server", "Office-Email", etc? Ahso you are saying they can't, or not easily, or what? I'm confused now. I think the main workgroup problem told to me was related to the mailslot system used by WideFS (for Win2K and WinXP systems only -- it wasn't provided before) for WideServer to broadcast its presence to Clients. But if the normal TCP, UDP or SPX protocols work across workgroups, then you could still use WideFS but you'd have to explicitly provide server and protocol details to each Client not on the same workgroup. Isn't that how it goes, or am I still confused? Maybe I'm mixing workgroups up with the "subnet", identified by the IP Addresses masked by the Subnet mask? I have all those the same too. Regards Pete

Yes of course. There's been no change in the data protocol for years -- there was only a need to match Client to Server versions in the early days, years ago, when it was all being developed. As long as there's not too much of a discrepancy between versions there's no problem. I just always advise to use the latest -- the latest formally issued versions, or the interim ones here. They are the only ones i can support in any case. Pete

WideClient is independent of FS version. Use the latest, prefereably. Regards Pete

I don't use TRC SimKits hardware and I don't know their software, nor what is meant by a TRC number. Sorry. Don't TRC provide support for their products? I think you should try there, or maybe in the Cockpit Builders Forum? Regards Pete

Okay. In that case, short of reformatting your hard disk and reinstalling windows and FS from scratch, I'm afraid I'm out of ideas. All the things I've advised you about have worked for others with SimConnect problems so far. I'm sorry that you are having these problems but I'm afraid it is now Microsoft support you need to talk to. I am sure that, compared with the many thousands of users of FSX and SimConnect, the ones with problems are very few, but it can be terribly frustrated when you are one of those few. I have reported, in detail, direct to my contacts in Microsoft, the several different problems that have been reported to me, and I know other add-on producers are doing exactly the same, whilst also losing their hair and becoming as bald as me in the process. My main problem in reporting the problems is that I have never managed to actually reproduce any of them, and I have FSX installed on four PCs or different types and ages. Emails? I haven't sent you any emails. How frustrating! So I go to all the trouble of getting SimFlight to set me up a Forum specifically because email support (as I used to provide over three years ago) is so inefficient and time consuming, and you bypass it all? Why? The Announcements themselves are there for a purpose, but, more importantly, by never bothering to peruse other threads and messages you miss all the hints, tips and solutions discussed with everyone else. I don't understand why you'd want to ignore such an advantage over email. So when you said above that repairing SimConnect made no difference, you were mistaken? In the last message there was no response to joysticks in FSUIPC4! What is going on? It sounds like it is all okay now? It won't do anything of the sort by itself. But let's take this one step at a time: 1. Do I now assume that ALL of your previous complaints are solved, done with, finished? If FSUIPC4 can see your joystick movements, then it is working, SimConnect is okay. Please confirm this is indeed what you mean after all this hiatus. 2. First, before trying to se FSUIPC4 for joystick calibration, get things working as well as you can in FSX itself. To start with you must calibrate your joysitcks and pedals in Windows "Game Controllers". Then check the assignments in FSX, and make sure that all the Sensitivity settings are at maximum and the null zones at or near minimum. This is all nothing to do with FSUIPC4. If you have things set correctly in FSX it should most certainly be as flyable as Microsoft intended. They don't sell FSX specifically for folks to add FSUIPC4 on to in order to fly it! 3. FSUIPC4 will not touch the values until you tell it it. The input values will simply be copied to the output values. To use FSUIPC's calibration, you must follw the step-by-step instructions in the User Guide. They are very easy, involving the use of mouse clicking as well as joystick movement. If you make a mess just close FSX, delete the FSUIPC4.INI file from the FSX Modules folder, and start again. Odd that you would give up after apparently solving everything you were complaining about in the first place. But as I said right at the beginning, maybe FSX was a mistake for you -- on a 3.2Gb PC you'd have to either turn most of the new stuff off, or spend many hours tweaking in any case. Your PC is, however, well suited to FS2004, which looks like remaining very popular for quite some time yet. Regards Pete

No. Well, if you truly have "NoAxisIntercepts=No" in the FSUIPC4.INI file, and FSUIPC4 still cannot see the axis values, then Simconnect is certainly being blocked. Can you show me the FSUIPC4.LOG for this (and the FSUIPC4.INI to double check). Is what, exactly, "UK humor"??? Sorry, you seem to be going completely off-topic. Can you explain what you are talking about? That should be okay. The Simconnect log files (up to 10 of them) should be created in your C:\ root folder when you run FSX. If it isn't, you certainly do have a broken SimConnect and need to try to do the repair as described in that FSX Help announcement. How do you actually manage to GET to the "post a reply" page (whatever that is, I don't see it) without going to the Forum first? I am really at a loss to understand how you could possibly MISS the Entire Forum, which is where you get to from any of my links. How did you first get here??? What has being 62 got to do with it? I am 64 this year. And I don't know how you are getting to these messages WITHOUT seeing the Announcements -- what sort of browser are you using that can do that? :-( Regards Pete