Pete Dowson

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

By "current" do you mean 4.953 or 4.954c? Both are concurrently available, the latter being an interim update with additions and fixes. Sorry, not without more information, no. Where are these assigned, and what to, exactly? How are you proposing the intercept these axes in SimConnect? FSUIPC is doing the same of course, as with all controls (events). So do PMDG aircraft, and I assume others. And finally, why are your throttles normally only giving -7040 to +7040? If calibrated in Windows they should give -16k to +16k. Are you taking some raw data instead? (Most digital types give such a range in any case without calibration.) Pete

Always crashing, FSX and P3D? If this was happening to everyone the Forum would be littered with nothing else. What does the crash actually say -- what module, what offset? The stack is little use as it looks like it is corrupt. FSUIPC might be the last DLL standing because it tried to tidy up, sending termination notices etc. What "stuff" of yours is running which might interact so? Pete

Oh dear. :-( Registration has not been done in FS/P3D for many many years! Please PLEASE read the Installing and Registration guide, the document actually packaged in the same ZIP as the installer and which you have apparently completely ignored! Pete

I never said it was a problem, I said I don't know why the other encoders aren't being seen, that other controllers I've used and seen used work with that Lua plug-in. Maybe the only way I'd understand what is going on with it would be to analyse the binary data being received on the USB cable to see why the extra encoders, over two, are not being seen. The function being used -- "com.gethidbuttons" -- may not understand the data it sees. Perhaps it is a completely valid set of data, but just in a format I did not know when I wrote that function some years back. All I can think of doing is to add a lot more code to the Lua, or maybe into FSUIPC itself, to get and log the actual data being received, for you to run and test each rotary in turn, then send me the log so I can match up what happened to what was expected. There you go again. the PROBLEM is not the card, the problem is not knowing why it is different, or in what way this is going wrong. I have been trying to help you sort it out, but if you read back it's only been these last hours where we are finally coming to the conclusion I stated, which you seem to consider as me accusing the card of being or having a problem! I do not know the Pokeys system, I have no idea what it is or what it does, and I cannot possibly know about all the possible interfaces out there. All I can do is try to help. I do not want to have to buy a card just to see. The Lua plug-in system is supposed to alleviate the load on me meeting user requests, by allowing them to do their own thing rather than me add more and more to FSUIPC. If you wish to carry on, when I have a little more time (which I certainly haven't since last Thursday, whilst working with an engineer on my cockpit trying to sort my own problems out), I will look at code needed to find out more about what is happening. I can't really look at that before Wednesday. Pete

No no! I didn't suggest that. I said assign the same FS control for "press" and "realeae", because the rotary does a "press" on one click and a "release" on the next -- or at all the rotaries I've ever met do. So you only get ONE increment per click. There are TWO actions on each rotary -- clockwise and anticlockwise. They signal separately -- otherwise how can they be distinguished? Well, in that case I would say it is something to do with the interface you are using. If I had it here I would you a USB analyser program on it to find out what it is doing, because it is not acting in a standard way. Are all the rotaries recognised as buttons on Joy #2? P="Press", "U" = "Unpress" (couldn't use "R" for release because that's used for "Repeat whilst pressed") All this is explained in the FSUIPC4 documentation, in the section in the Advanced guide which explains button assignment formats. Pete

Okay. But something is making such heavy use of SimConnect that is slows to a crawl. That doesn't necessarily relate to frame rate, though the two are sometimes connected. It could be related to memory, but with it starting to happen within, what 70 minutes or so from the start, that seems unlikely (though not impossible). Here is where the problem starts: 4639734 **** No SimConnect events or states being received! Re-connecting now ... **** 4639828 SimConnect_Open succeeded: waiting to check version okay 4639828 Running in "Lockheed Martin® Prepar3D® v3", Version: 3.2.3.2 (SimConnect: 3.2.0.0) 4639828 Initialising SimConnect data requests now then again only 5 minutes later: 4946953 **** No SimConnect events or states being received! Re-connecting now ... **** and so on, till no response at all. I don't know what FSUIPC applications you have running, but at the possible cost of adversely affecting them you could try increasing the SimConnect timeout in FSUIPC4.INI. The parameter is SimConnectStallTime. Read about it on page 11 of the FSUIPC4 Advanced Users manual. Pete

Sorry, somehow I was unable to continue my last message , so continue here: The button flags supplied by the USB deviceare defined here. You list pairs 1,2 and 3,4, and 5,6. Without seeing the input from your USB connnection I cannot tell, but you could try: Rotaries = { 1,2,3,4,5,6,7,8,9,10 } There's no "buttonbit = 4", only a "buttonbit = 4 * buttonbit", which shifts the bit up 2 places to address the next rotary acion. Remember it needs 2 bits per direction for each rotary (bits = button numbers). And anyway, you don't have a "lack of Joy#64". That parameter is ONLY for the main [Buttons] section. You must still have an entry somewhere with "j" in it, maybe your use of j.b earler. Search for all instances of j, or show me the complete INI/ Pete