Pete Dowson

That's what would be necessary in my case. I was only explaining why i had never followed it up. Sorry, I don't understand how an angle applies to moving forward and backward, Are you perhaps referring to pitch, controlled by elevator? So you just have a seat swinging about but the scenery view and instruments remaining static? I must admit i cannot imagine what you are doing, it makes no sense to me. If you cannot stop FS also displaying the pitch and bank in the scenery view, and the instruments are going up and down and left and right in front of you (relative to you and your seat), how can that be any sort of flight simulation? Sorry, I don't understand any of that. I cannot relate at all to wehat you are trying to do. 50 degrees of bank seems enormously out of any range I know for any sort of platform. Is your seat mounted on some sort of universal joint? How is it you don't fall out? I've never had any experience of a car with tilting seats, and i would worry that if it tilted as much even as 20% i would not be able to easily read the instruments nor see where I was going! No, only when it STARTS banking or pitching. If an aircraft continues banking or pitching at a fixed rate you do not feel the effect. Only accelerations are felt. It sounds as if you are getting the wash-out I mentioned, even if you didn't program it. You should surely be using accelerations, and once those settle, so then should the platform, move back to straight and level ready for the next effect. I am certain that all of the good motion platforms I have experienced are based on acceleration effects. That seems to be the whole point -- it is the ILLUSION you are after, not the real pitch or bank in your home. After all the instrumentation must remain static in front of you -- your chair swivelling about in front of everything really does seem ludicrous to me. I'm not trying to be insulting here, and maybe it is just that I don't understand what you are trying to achieve. It all sounds completely wrong to me. Regards Pete

Don't remove anything there. ASV6 merely comes with a version of FSUIPC in case you don't have one. It isn't doing any harm. Regards Pete

The calibration is not good then. Have you tried providing yourself with a null zone in FS? (It's one of the sliders). Normally I'd say the sensitivity should be max (full right) and the null zone full left, but for poor units a little null zone might help. You can do. FSUIPC does provide more precise and versatile calibrations. If you still have everything assigned in FS, you calibrate the throttle control, the one inside FS, rather than the Axis, so it is then irrelevant what the rest of the controls do. FSUIPC only calibrates axes directly when it is used to also assign them. Try the null zone first. It seems a bit expensive buying FSUIPC just for that one purpose. ON the other hand, install it and read the User Guide, see if it is something you'd find worthwhile in any case. You don't have to buy it. but you might then want to for other reasons. ;-) Regards Pete

I'm no expert on such matters, but surely there's no way, and no reason, to match pitch bank and yaw with the simulated aircraft. Apart from the crazy positions you might try to get into, I didn't think that was the point of motion platforms. Surely you are just after the "feel", so only accelerations are of use -- apart from vision and sound, which of course you have, it is really only the accelerations give any sense of change to the body. And then, to keep the platform from crazy attitudes you do a thing called wash-out (I think) which slowly returns the platform at constant speed so it is ready to move again. Really? I don't think there's anything but accelerations which would be useful at all. Trying to do any sort of match of actual pitch, bank, heading, and their rotations would simply be doomed as far as I can see, and not justified in the first place. The orientations and speeds of the aircraft aren't relevant if they aren't changing. How you program that, scale it, whatever, and then do the wash-out part, I've no idea. Although I've found it an interesting proposition in the past I've really never had the hardware to do anything with, and whilst I'd love it for my 737NG cockpit I don't think the floorboards will take the strain of a 2000 lb bulk moving about! ;-) Regards Pete

I think all the new PFC gear is now USB, with different drivers. They changed the control boards completely. I'm afraid I don't know anything about the GPS -- isn't it designed to work with specific add-on gauges or other software? Most of the FSX controls for the Garmin G1000 work reasonably well, I think. Maybe you should try those? I know TRC (the folks who make SimKits) have hardware G1000 look-alikes which work with FS, and I think they use those controls (but I'm not sure). As you can probably tell, I'm not really into GPS use on aircraft. I stick with the traditional cockpit instrumentation, the stuff in the 737NG's being modern enough for me! ;-) Regards Pete

In FS that part of the stack was never pre-programmed for GPS use. It does have alternative functions as an advanced MCP / Autopilot, and in fact the same unit is re-labelled for this purpose when obtained as part of the PFC centre console. The problem has always been that the FS GPS implementations haven't been very usable from keyboard or button operations, being very mouse-oriented. There are controls provided in the FS control repertoire (and listed in FSUIPC's drop-down assignments lists), but I never found them to work correctly or, in some cases, at all. No. All you can do it to try to assign, in FSUIPC (you'd need it registered), the buttons to their nearest equivalent FS GPS control, via the Buttons assignments dropdowns, and test them out. Maybe they work better in FSX than they did in earlier versions, I don't know. Regards Pete

Yes, nearly a year ago. Yes. The Lua files "ipcInit.lua" and "ipcReady.lua" are run automatically, the former early, when FSUIPC is first loaded and before the rest of FS is ready to fly, the latter when ready to fly. I'm not sure what you mean by 'calling one of the demo module "ipcInit.lua'", there's no such demo, it is the fixed name for an auto-run plug-in. If all yuo are doing is providing additional or specialised controls for your aircraft, the Lua module only need to be in the FS Modules folder. The user would then assign buttons or keypresses to it. If you want it to be running all the time then it would need to be instigated by the ipcInit or ipcReady modules, or you could request FSUIPC to load it in your code through the relevant FSUIPC offsets. Each Lua module runs in its own thread. Whether this gives you better performance or not I couldn't say. You'd need to try it. FSUIPC does force the threads to yield between each Lua statement, in case other essential tasks are running in the same core. What is "direct access to FS variables"? Do you mean SimConnect variables? If so, no, there's no direct interface to SimConnect, though, in fact, that would be easy enough to add, at least for reading named SimVars. I just never thought of it. I suppose I could allow writing to them too, returning the error should one occur, though the problem then is the asynchronous nature of the responses -- you get no "ok" response so you don't know when to allow the Lua program to continue. If you look through the Lua documentation provided you will see that for FSUIPC4 (FSX and ESP) there are facilities for reading and writing L:variables, which I believe are the named values used in XML gauges. There's even a sample program provided to list their values on screen and in the Log. Have you not yet perused any of the supplied documentation? Either way, please do NOT "unused offsets". There's really no such thing, or at least not in a way you can tell. If you need any for your own local and private purposes use those allocated for that at 66C0. Otherwise please apply for an allocation, to avoid clashes with other add-ons. Regards Pete

FSUIPC4 registration has been part of the Installation process for over two years. You don't register in FSX at all. Please do check the Installation and Registration instructions. Regards Pete

Er, what generic 4-engine set up? Before you've defined any there won't be any. If there's no profile assigned to the aircraft then it will use whatever settings you made before, the default settings. You do that when you are doing the Assignments and Calibrations. And then any other aircraft you load and assign the same Profile too. If it already has a Profile assigned, it will use that one, the one you set and saved above. if not it will use whatever non-specific defaluts you may have already done. Yes, of course. If you don't have a profile assigned, that's what will happen. Yes, unless you change the assignment or edit the INI file so it doesn't apply any more. Regards Pete

The one in the FS9 folder is only the default, not the one used. The active one will be that one in AppData/Roaming/Microsoft/FS9. What exactly did you do with it? If it is still occurring with no additional scenery, then there are only four areas left to ponder: 1) Some add-on scenery which has added itself to one of the default paths 2) A texture-based program like Ultimate Terrain or Active Sky's weather graphics program, which has added textures to the main sets of texture folders 3) Add-on aircraft used for AI traffic, or a faulty add-on traffic file 4) Other Add-In modules in the FS9 modules folder. Item 4 is still the easiest to check for. the others are pretty difficult. It might be worth your while renaming your FS9 folder for now, and move your FS9.CFG and Scenery.CFG file to a safe place -- so as not to lose anything, then install FS9 again (and the 9.1 update), in the original folder name. Check it before adding anything, then add FSUIPC and recheck it. If that's okay, you know it is something you've added, and you have the original texture and other scenery folders in FS9 to compare or replenish from. I always have a "virgin" (untouched by add-ons) installation as well as a fully-added to installation, and swap between them by folder renaming and FS9.CFG/Scenery.CFG exchanging. That way allows me to narrow down on these things a lot faster. Actually, mentioning 9.1 updates, I wonder if something did actually go wrong when you applied that -- you did mention that FSUIPC's installer couldn't find the Registry entry for it, which is a little suspicious. Regards Pete

My user guide won't mention detentes like that because not many levers have any. But it does advise you to always set both the minimum and maximum positions AWAY from the end stops. This is so that you can always reach the extremes. The actual vlaues returned ot FS can vary slightly, due to temperature, humidity, voltage levels and so on, that this precaution is almost always worth while. I am looking at ways of allowing user-specified "slopes" so that you can make two or more levers match in enough places along their travel that they are never very disparate. Regards Pete

Strange. FS is certainly closing "naturally". In other words, it isn't crashing -- FSUIPC is receiving and processing the correct call to ask it to close down, along with the rest of FS. I assume you checked the Modules folder for other non-FS add-in modules? If so, it is pointing more and more towards some sort of scenery or texture problem. The FSUIPC settings file is FSUIPC.INI -- and yes, a default file is created if one does not exist beforehand. The LOG file is always created from scratch each time you load. Well, that really is weird. Can you show me the INI file it generates? It should be merely a default set of parameters, for you to edit should you need to. Deleting the Log file shouldn't have any effect whatsoever, as it is created (overwritten) each time in any case. FSUIPC never reads it. To check for scenery problems, I always do it by halving and quartering, etc, the scenery detailed in the SCENERY.CFG file. Carefully make a copy of the file, then, in the original, delete all of the add-on entries -- i.e. the ones beyond (higher Priority numbers) than the FS default sceneries. Test. If that works, add half the ones you deleted, and so on. As soon as it fails again, remove the last half which failed and halve it again. etc etc. You narrow in on the culprit quite quickly that way. Regards Pete

Oh, right. I was misled by your statement You see, it isn't the copy or version of FSUIPC which is registered or unregistered, and nothing can make you unregistered unless it deletes your KEY file. There aren't "registered" and "unregistered" versions! Really? Where? :shock: :o Yes, but it is specific to your system, so we need to delve a lot deeper to find out why. There is certainly nothing at all in FSUIPC which cares or depends on day or night. The changes between day and night affect textures and video load, so it has simply got to be a timing issue where a small difference in milliseconds through an FSUIPC path, or a small difference in memory usage, is edging a situation which was close to failure onto failure. Really, whenever there has been any problem like this, in the whole history of FS, it has been a tweak here and a tweak there which fixes it. Unfortunately there are no texture or video tweaks in FSUIPC because FSUIPC has nothing to do with either, so it means looking at video drivers, video settings, scenery settings and so forth. Sorry, but there's really no other way. Regards Pete

Okasy, so it isn't a true CTD, which displays nothing. Aren't there any buttons on that window which allow you to get more information? The biggest clue would be the Module which is crashing -- it would show the area of problem, whether scenery, aircraft, FSUIPC or whatever. Okay. So you haven't tried 3.932 yet? The log shows everything loaded okay and FSUIPC is merely idling then waiting for something to do until it is closed tidily -- it isn't crashing, so it looks as if FS isn't actually crashing but closing purposefully, This is the point where FS has finished loading stuff -- 1m 43 secs after FSUIPC is loaded, so perhaps 2 minutes after you started FS. Is there nothing on screen but the initial splash screen all that time? 102773 FLIGHTS\OTHER\FLTSIM.flt 102960 AIRCRAFT\c172\Cessna172SP.air Then, about 20 seconds later, here is the point where FSUIPC receives a normal Close event from FS, indicating a normal close down: 124005 System time = 15/09/2009 22:33:23, FS2004 time = 22:33:08 (05:33Z) 124005 *** FSUIPC log file being closed It isn't really doing anything in between. I don't know what FS is doing. Yes, so FSUIPC is doing nothing until an add-on asks it to. This cannot be from an add-on aircraft as only the default C172 is loaded. I suspect it is a scenery-related issue, or possibly another non-FS module installed in the modules folder. Do you have any there, apart from FSUIPC? But none running when FS is loaded? The log shows 3.93 still, not 3.932. Can you try temporarily removing your FS9.CFG file (save it for restoration), so that FS loads with default settings. I think you'll find it in the ProgramData\Microsoft\FSX folder. Regards Pete

Phew! That was 18 months ago! So many changes since then ... Hmm. Did you do that all at once? If so, that's unwise. Add one thing at a time and check between each. Anyway, the questions are still there: when exactly does FS crash, and is it truly what they call a "CTD" (that is a crash to desktop with no error message, no indication, nothing, just a disappearing act), or is there some information? And is there an FSUIPC.LOG to show me? And is your FSUIPC registered, or do you just have it installed to interface some of your add-ons? Ignoring the scenery for now, which add-ons might be loading on the way to this crash? Some other (non-FS) DLLs installed in the modules folder? Add-on aircraft using FSUIPC? Generally, the changes between each release of FSUIPC are quite small. And there are interim updates in between. Each one represents a small increment and is well tested. I really need more information to be able to help at all. One thing to do to start with, so we are on the same page -- please download and install (i.e. copy into the Modules folder) the current increment -- 3.932, from the Updates Announcement above. Regards Pete

I have a lie-in some mornings, but i'm a night person. ;-) Anyway, the fix was easier than I thought -- I just had to tell the linker not to bind in the Manifest which tells Windows I'm dependent upon the updated library, which I'm not. So, after a re-link and final build, 4.534 is there, now. Regards Pete

Please see the thread "add-on 4.5.3.3". Pete

Okay, I think I've identified what the problem is. I changed my main development PC last week, and reinstalled all the compiler stuff. It looks like an automatic update from dear old Microsoft has updated my Microsoft C/C++ compiler system with SP1, which apparently involves an updated "redistributable" library which is only pre-installed on the latest MS operating systems (I assume Vista SP3 and Windows 7). I could refer folks to the Microsoft website to download and install the updated library, but that goes against my principles of keeping it simple. I could even include the damn thing in my installer, but that would make it even more massive. So, instead I'm going to try uninstalling the update which i didn't even ask for (and turn off Windows auto-updates which i stupidly forgot to do). Then I've got to recompile it all completely and make a new build. Sorry. It'll be tomorrow sometime nowFSUIPC 4.534. Meanwhile Ill withdraw 4.533. Regards Pete

Sounds like something else you have it conflicting with it. What add-ons do you have. At what exact point does this CTD occur? What is your defalut aircraft? Unfortunately if there's any useful information it would be in the FSUIPC.LOG file, not in the Installer log. It doesn't matter as it found the entry for 9.0, which I assume points to the right place? No. It seems likely to be related to some add-on which FS9 is starting up with. What might that be? What was the previous version of FSUIPC you were using? Unfortunately it looks like you ran the Installer before this log was produced, because it only found 3.93, so it doesn't tell me which one you were updating from. Regards Pete

You do know that throttle levers don't always line up for equal N1% in real aircraft too, don'yt you? Hmm. 10% might be reasonable, but 20% sounds too much. And the difference is between the two units, not between two levers on the same unit at all? Are these calibrated properly in Windows' Game controllers? That's the first thing to check. And I assume you assigned them in FSUIPC, not in FS? Or did you? Well it would be really a lucky coincidence if any of the slopes matched the response curve of the other unit. The only thing any joystick processing can do is calibrate by end points, unless you have something like the Slopes facility but with user-specified curves. Even with that it would take ages to get them lined up. The main thing to do is make sure the units are calibrated in every place they should be -- in windows, in any Saitek driver or manager you might have loaded, as well as in FSUIPC. I just looked at your FSUIPC calibrations: Now those all look like default values -- most unlikely to apply to any real axes. It looks like you've not actually performed the calibration steps at all, for any of the axes! If nothing does it, AFTER you actualy do the FSUIPC calibration properly, then it seems to me that the makers must have used a different type or make of potentiometer in one of the units, compared to the other. Did you buy them at the same time? I'd first of all bring this up on Saitek's support forum, and even directly contact them for advise. They are a reputable company. If it looks like you have a badly matched pair then I'm sure they'd be sympathetic. I could consider adding a "user-defined slope" facility, but I wouldn't consider doing that graphically -- only by a series of numerical values in the INI file. It would enable fine adjustments to be made at a larger number of points (FSUIPC's slopes use 128 but maybe some of those should be interpolated if user specified). But this would be quite hard work for you even if available. So, try the alternatives first then let me know. Regards Pete

Ouch. That's two reports. It works fine here on three different systems. Evidently i need to know more. What version of Windows are you using, please? And what update to FSX? [LATER] Please see the thread "add-on 4.5.3.3". Pete

Did FSX ask you to confirm that the module should be loaded? If so you must say yes. If not, please show me the FSUIPC4 Log file, which you will find in the FSX Modules folder. There is really very little difference between 4.53 and 4.533, just three small bug fixes. [LATER] I see there's another similar report. Strange, I cannot get it to fail here, and I've tried the download too. What is your Windows version, please, and is FSX fully updated or not? Regards Pete

It's simply got to be either a difference in the add-ons using FSUIPC, or simply a slight difference in timings of paths through FSUIPC or memory occupied. Without registration FSUIPC is simply a window for applications to talk to FS, nothing else. And the difference between day and night time flying is only a difference in video driver load and FS performance. Fair enough, but the same argument applies. Sorry, but FSUIPC is a scapegoat for all these sorts of things, and it does become rather tiring. It's been the same old argument for 10 years now. Since you are unregistered and actually need no support from me (you've sorted it yourself, at least to your satisfaction), there's really nothing else i can help you with, is there now? Regards Pete

Neither of those are supported. The minimum version number for any support is 4.53. It must be complete coincidence of timing. There is nothing in FSUIPC which knows anything about day or night, nor cares. Not only that, but an unregistered copy is actually doing nothing at all -- only passing on anything from your applications to FS via SimConnect. It is most likely to be a video driver problem, or simply that you have your settings rather too high. For some reason I've never fathomed, FS has always imposed much more of a load on the system with night renditions compared to day. Weird but true. Regards Pete

Actually there's no such configuration to perform at the Server end. WideServer merely responds to any request from any Client. That seems very strange. Are you saying you only need one transaction with each copy of FS? And/or you never need to talk to them all at the same time? There are no IP settings at the Server end in any case. What you are suggesting is no different from the practice now on any WideFS setup. I now realise that I have no real idea of what you want to do, so I can't really comment on such a proposal. If you've no need for simultaneous access to multiple Servers then there never has been any problem. If you want maintained simultaneous access, then you can simply run multiple copies of WideClient, at the same time, by using the ClassInstance parameter to set up each one with a different Window Classname. In your application you then adapt the code for the FSUIPC interface (the source of which is provided in the SDK) to send the same data to each resulting Window Class. This is what I suggested as your easiest solution a while back, but now it seems you don't actually want simultaneous or maintained access? So there never was any real problem? Regards Pete