Pete Dowson

Why are you posting the same original question? Please see the answers already given, above! Pete

But I thought you said CS was working with PM? If so then presumably the offsets it uses are still configured in its driver CFG? OH control by PM is in pmSystems, so the offsets are listed in SYSVAR.TXT, as I said. You can log IPC reads and writes, if CS is only using those, but the log might get very big. Make sure nothing else is running which uses FSUIPC offsets. Pete

AP Master is assignable in FSUIPC! All FS controls, plus others added by FSUIPC, are assignable in FSUIPC! It provides a big superset of controls! There's a complete list if FS controls supported in the FSUIPC documents folder. Your second question is very confused. Which axis didn't work? You need to try to be clearer. Also the PMDG 737 and 777 addons do not use the FS autopilot, they implement their own. You will probably need to use whatever keystrokes they assign -- or the custom controls they have provided and listed in their SDK, which is installed with the aircraft I think. And for some of your questions you'd really be better off in the PMDG support forum. Pete

Also you can download the PM offsets list from the PM website. http://www.projectmagenta.com/downloads/?category=1 The details of the areas used specifically by pmSystems are listed in the SYSVAR.TXT file included with pmSystems. Those two documents are all I ever had for PM, and when I converted to ProSim737 (which otherwise has its own hardware drivers) I simply reused or adapted the same ones. Pete

Not really. The best would be the debuggers withing software development tools, like Visual Studio. But in cases like this you wouldn't know where to begin, and WarpD has already trapped the error at least once in a debugger and hasn't figured it out. The only way I know, especially with the sorts of errors which are due to unallocated memory access, is to undertake a thorough process of elimination. From what you found earlier I think you may have pretty much done that -- it's likely to be either bad data (especially indicated because of that comment of yours " I tried deleting this in the FMS flight plan and got an immediate crash", which in fact eliminates FSUIPC straight away because there is no way FSUIPC is involved in private interactions between you and any aircraft's FMS). Again, the other comment where you got a much earlier crash after changing something involving FMS data reinforces this (" I restarted the sim and this time tried to modify the ALTO altitude constraint from 2580A to 1000A. The sim crashed rolling down the runway on takeoff"). This so much points towards a possible error in the FMS treatment of data, or possibly erroneous data, that I'm rather surprised that WarpD hasn't decided to put some additional logging into that code in order to narrow it down within. That's what I'd do. Pete

If they are analogue brakes, then this is most likely because they are reversed. Nearly all the toe brakes I know are full on when released, full off when fully depressed. Just use the REV facility in calibration. "couldn't find it"? What what is wrong with "AP MASTER"? That operates the FS default A/P master switch. If you are using an add-on aircraft, you probably need to refer to its documentation. For FSUIPC always test on a default aircraft. ALL of the systems controlled by FS controls operate on FS aircraft, but not all work on add-on aircraft, especially the more sophisticated ones which do their own things entirely. Pete

All the above results seem to immediately point to something related to the database handling, yet at the end you conclude: The only likely difference in any recent version of FSUIPC is that the memory arrangement of data is likely to be different. If there is an error somewhere else which references incorrect memory locations, perhaps because of data poointer corruptions or uninitialised variables, then whether a crash results depends purely on whether the memory so referenced is actually valid in the current process -- i.e. it is an allocated region of memory and has appropriate read/write access enabled. Small differences in memory arrangments because of updated modules can make the difference betwen such erroors crashing or just possibly creating a blip which goes unnoticed. BTW I cannot support versions earlier than the current released installer package, which is 4.953. There is a later one available in the Download Links subforum (4.954c) which you could also try. You never know, another small change in meory arrangement could make another difference. Pete

Assign them, do you mean? Do you have trouble finding the correct assignment, or what If they are analogue axes, assign in Axis Assignment to Axis left brake set and Axis right brake set. If they are just on/off buttons, assign in Buttons to Brakes left and Brakes right. Not so hard. The controls are mostly nsmed for what they do! Assign in Axis assignments to the oddly named control called "Pan view". Strange, eh? ;-) Pete

Okay. Then idomething else is doing it. In that case, WHERE are you assigning the controls, and what to? FSUIPC can calibrate even if you leave controllers assigned and enabled in FS. You only need to disable controllers in FS if you are assigning in FSUIPC, otherwise the two will conflict. If you haven't assigned them anywhere at all, then they won't work -- unless you've installed an external driver for them which works directly. Did you say they were GoFlight? If so, perhaps you are using their driver? I think you have to sort things out there if so. Pete

So, you are assigning in FSUIPC, and you've disabled controllers completely in FS? When you say "always going back to centre", what exactly do you mean? Is this in the calibration tab in FSUIPC, or in FS? Can you move the FS aileron and elevator surfaces with the yoke? If you let the yoke go, the springs or elastic bands will take it back to centre -- you don't fly "hands off" without autopilot. Pete

I've installed it and taken a look. Apart from it being 64-bit (which would be a total new development for FSUIPC or similar), and looking like it is using similar files and structures to FSX, its code is organised totally differently, mostly in one monolithic EXE by the look of it. I doubt whether there's any way of getting a third party module to load, let alone run, and there's no sign of any usable external interface like SimConnect, thogh it may simply be that I don't know how to get to it. I think Dovetail have already said there won't be an SDK.. Things might change with the promised DoveTail Flight Simulator, of course, but I think Flight School must be regarded as an entity on its own, though probably expandable in the scenery and aircraft areas. But even the Flight Simulator would, if possible, need a completely new 64-bit version of FSUIPC. With the sorts of things FSUIPC does it is anything but a simple re-compilation. Whether it will be worth doing remains to be seen. A future 64-bit Prepar3D may be the better target to concentrate on. We'll see. [LATER] Reading some of the answers from Dovetail about their Flight Simulator, this is one very important quote: "FSUIPC will not be supported because we want to make sure it is not needed in the first place." So, there you have it. It will not be needed, and that saves me a helluva lot of work! ;-) Pete

I'm downloading it now, to have a look tomorrow. So far it is looking familiar, in file structure in any case. May it is a straight FSX derivative after all, unlike MS Flight. Pete

Is it released already? I didn't know. I'll take a look later this week.

No. And I very much doubt it is open to any sort of additions internally. Do you have a copy already? Dovetail haven't been in touch with me at all. I suspect it's a contained setup like MS Flight. was Pete

Yes, milliseconds. Pete

Is this specifically related to FSUIPC? How are you assigning the steering on the ground? Just via rudder or via steering tiller? Where are you assigning this -- in FS or in FSUIPC? And what to? As it is specific to the one aircraft, have you tried their support? Pete

If the 0-1023 range gives 1024 discrete values, is an excellent result for a domestic analogue input. They must be using a lot better pots -- or maybe it's optical? e.g. with a disk? The Saitek Quadrant, the one with 3 levers, only has 256 discrete positions -- that's much more common. But even the much more expensive PFC one I had only has 128 (0-127)! Anyway, glad you found the problem. That's why I did ask earlier where it was assigned. Looking at the axis assignments tab instead of calibration would have shown this too, of course. Pete

Okay. I rigged up an old device I had with more than 8 buttons (no rotaries, bt for this test it didn't matter), and tested the "Rotaries.lua" on it with debug tracing enabled. And I found the problem. The distributed Rotaries.lua has a bug. Find this line: ipc.togglebitsUB(offset, thisbutton) and change the "UB" into "UD". i.e. ipc.togglebitsUD(offset, thisbutton) I don't know when this got changed in the Examples package, but in my original, it was correct. otherwise I'd have spotted it earlier! "UB" means Unsigned Byte. "UD" is Unsigned Double wrod. A byte has 8 bits (8 buttons), a double word has 32. Each joystick allows 32 buttons, but this error restricted the plug-in to just the 8! I've fixed the distributed copy -- it will be installed with the next main update, but meanwhile you only need to change that one character. Pete

That looks okay. I assume all your rotaries are connected as two buttons + common each? The other connections available are all analologue, for potentiometers and the like. So it supports 32 buttons, contiguously arranged in bits 6-37. It should all work fine. Tomorrow, or even maybe later today if I get time, I will have something which logs what I see coming in. There may be some logging already built in which will do the job, i shall check for that first. Pete

Ah, well, the FSUIPC setting didn't make the difference then. it's the autosave. With some aircraft the data for the save has to be collected from all the subsystems, and the add-on freezes the sim whilst it does this so all the data relates to one instant, and then the files created are quite big too. This can actually affect all the PMDG aircraft. It's usually first noticed by the hesitations or pauses during flight. Pete

One thing you can do which might help is run HidScanner and show me the contents of the related file -- not all of it, just the entry for Pokeys. Get HidScanner from the "Useful Additional Programs" thread in the Download Links subforum. Pete

That is not Spam, and it is nothing to do with me. You must have checked the option to follow threads or messages in this forum. You have to stop that yourself, and be more careful what you click on in future! (See top right, above the forum contents, where it says follow or otherwise). Pete

Do you really mean 1, because it defaults to 1 in any case? It can only be set from 1 to 9, so 1 is the shortest! Pete

Aren't the crashes logged in the Windows event log, seen in the Event Viewer? Doesn't that identify the module? The stack address is just somewhere in a Windows DLL I expect. All that upper region of virtual memory is reserved for that stuff. As for FSUPIC4.DLL!14698623() For the address here to mean anything to me I need the FSUIPC base address -- see if you still have the FSUIPC4 Log, because it is logged in there. Maybe, if it is FSUIPC4, it will tell me which Windows API function it's in at the time. Pete

"Main page"? Oh, you mean the Schiratti site? Yes, that only shows main releases, and even then the description is usually out of date. It isn't my page, it is Enrico Schiratti's (author of Project Magenta), who has historically had Links to my stuff there since FS2000 days. I have no control over that, I just try to get him to update the words occasionally. I have no website. But the links there point here, to the SimFlight place where I can upload. The "Download Links" subforum above has links to much more, and often interim updates too. That's why I always need version numbers. Ah, Saitek. Yes they seem sometimes to install odd registry entries for their devices which have odd results, even only giving half the range or only two values as if digital not analogue. Right click the device in windows'"Device and Printers", select "Game Controller Settings", then "Properties", then "Settings" then "Calibrate". Follow the wizard instructions, but check "Display raw data" when you see it. The axes should give values 0-255. That is the full range. That value CAN be read by FSUIPC in "RAW" mode. Normal mode actually gives you the raw value x 128, centred on zero: i.e y = (x - 128) * 128. The Direct Input keywords for the two modes are DIPROPCALIBRATIONMODE_RAW and DIPROPCALIBRATIONMODE_COOKED, respectively. On top of this, FS assignment apply what they call "sensitivity", which entails scaling the value yet again, and another slider which creates a null zone. Applying either of those will give unreal values too. Assignment in FSUIPC bypasses those two, of course. If you've calibrated in Windows, and get 0-255 as I am pretty sure you should, then with the slider set to max sensitivity in FS, you should get the full range -16k to +16k. Hmm. This priority system in SimConnect is very confusing. For axes I normally use SIMCONNECT_GROUP_PRIORITY_HIGHEST_MASKABLE, which allows me to stop the values being passed on in case I am calibrating. If I didn't do that then my calibrated values and the originals would both be received at lower priority levels. If I am calibrating I modify the values, obviously, if I am not, I leave them be. I don't recall whether "HIGHEST" is higher or lower than that. Either way, I send them on, either using SimConnect_TransmitClientEvent or just sending them to FS as a command. If they are calibrated they will be sent on as "THROTTLEn_SET" events, not "AXIS_THROTTLE" events, because those older events allow a reverse zone whilst the ew ones don't. There IS an INI file option, for Non-Reverse-Zone calibration, to only use the AXIS_THROTTLE events. Maybe your system needs that set? I know several add-on aircraft do. See "UseAxisControlsForNRZ" on page 2 of the FSUIPC4 Advanced Users document. However, that wouldn't do anything when the axis isn't calibrated, and the value I receive and pass on when the axis isn't even assigned in FSUIPC should be just whatever I get. Can you look at the values shown in the calibration tab again, make sure the button above the In/Out values reads "Set" so that the axis is NOT processed, and tell me the range of In values then? There, for a Windows-calibrated Saitek Throttle Quadrant, with FS sensitivity at max, I get either 0-16k or -16k to +16k (the two axes I tried are actually different even though all the settings and calibrations everywhere are the same! I think this is a Saitek registry data difference, and one of the things I have to deal with regularly from FSUIPC users with Saitek equipment! :-( ). BTW, even if not assigning in FSUIPC, the Assignment tab gives you the Input value read, not from SimConnect, but using DirectInput. So that shows you what is being read by FS, bypassing the sliders. So, with the sensitivity slider set half way, say, I still get the -16k to +16k OR 0-16k in the Assignment tab, but -8k to +8k or 0-8k in the calibrations tab. I've been experimenting here, and without calibration enabled, FSUIPC is definitely ONLY passing on the value it gets, the one shown on the "In" box on the Calibration tabs. So I'm wondering is you have the sensitivity slide down a bit below half way, giving you 7k instead of 16k, but somehow the way you are reading or transmitting it gives the full value? You can use FSUIPC's axis logging to see the controls and values being received at FS action levels. Otherwise, sorry, I can't explain it. But I do tell folks who want to use FSUIPC it make sure those FS sliders are set right (maxsensitivity, min null zone). Pete