Pete Dowson

The joystick selector should not be recognised. That's the main problem. Currently you have to use it only to select the mode you want to program BEFORE going into FSUIPC options. Anyway, best to wait as some of the button numbers in FSUIPC will need to change. Regards Pete

Okay, I've looked at this and there are a few problems I can see. First is that the mode changing joystick needs to be allowed to talk to the SerialFP2 driver even in FSUIPC's Buttons & Switches programming tab. Otherwise it doesn't get the instruction to change modes, and this prevents the new button assignments working. In the current FSUIPC implementation you have to select the mode first, before going into FSUIPC options. I'll change that. Then there are 4 modes: AP/C, AP/M, USR and RADIO. RADIO is left alone by FSUIPC, for reasons I already gave. AP/C mode needs some fixing. The buttons don't send messages in this mode in any case, they just sleect the control value to be changed. But the white button should be programmable ("BARHOLD" is missing), and the adjuster knob isn't right for "VVS" or "BAR". For those it is only recognised as one button. For the others ("ALT", "SPD" and "HDG" it's okay -- 4 buttons, two in each direction, fast and slow. AP/M mode has "APMAT" not recognised, nor "APMMST" (the white button). Also the knob should be 4 buttons and it isn't, its only one. USR mode had the Knob only seen as one button, not 4, and none of the other buttons are seen. I'll fix all this in an interim update later today. (It is much easier sorting these things out with the unit actually here -- before now I was trying to do it by interpreting logs from others, mainly Andy (thanks Andy)). Regards Pete

Hmm. That's really strange because it works okay here. I don't understand why it won't there. The only thing which seems inconsistent is the initial length (height) of the window. I think it's related to the "expansion" mode -- the way it can grow in height to suit data. I suspect the value i provide is a max, though why it sometimes comes up with that height initially then makes less sense. The top left corner and the width seem consistent here. The saving to the INI file is done whenever the window is closed. I simply detect that and read the Window details using standard Windows API calls then write to the INI. Those are never re-read this session -- the FS Window detail is only created once, when first used. Thereafter the closings and openings are merely done by calls into FS. Maybe FS, in its wisdom, is doing something different each time I call it to re-display the same created Window, though that doesn't make much sense to me. If you have a foolproof procedure to demonstrate how it goes wrong, perhaps you could tell me exactly what the steps are. If I can reproduce it here maybe I could track it through the FS code a little further (though it gets very convoluted very quickly -- and asynchronous due to message use). Regards Pete

I just received my M-Panel yesterday so I'll be looking at this today or tomorrow, but if I recall what happens correctly from the logs I've seen from Andy, those buttons do different things according to your selection on the little joystick. Of all the possible inputs I omitted the radio setting facilities because they are really best left the way they are. If you tell me which button modes and what the log shows for the buttons, for those you wish to re-program, I can check. Maybe I've not put them all in yet. If not that is easily rectified. There would be about 20 different inputs from 5 buttons, but probably no inputs till you've chosen a mode. Regards Pete

Really? That's very odd. It works perfectly with that command line in two of my PCs -- one running Win7 Ultimate 64 and the other Win XP 32. I wish you'd given me some feedback on VSPE command line problems so I could have put some warnings in the final documentation. If they are consistent on your system I think you ought to report them to Eterlogic so they can fix them. In my case the odd numbering came about because Windows seems to allocate real COM numbers rather randomly. For instance the MCP-Combi came up as COM5 no matter where I connected it, whilst the M-Panel (which arrived yesterday) came up as COM7. Weird. I have some other COM devices too. You have to be careful to assign truly free ones to VSPE. Maybe this is the problem here responsible for "cannot load configuration"? Best to go into Device Manager and find out which COM ports are free. Alternatively I suppose you could start using virtual port numbers at some high value, like 20, to keep well clear of real ports. As for FSX freezing -- I cannot imagine anything in any of this which could possibly freeze FSX, as everything is done is separate threads. There's nothing on any COM ports handled in FSUIPC's main FS thread routines. I'd like to see the log as far as it got -- because nothing VRInsight-wise is done in FSUIPC until FSX is "ready to fly". That doesn't at all relate to a "cannot load configuration" problem in VSPE, which would have occurred many minutes beforehand, surely? Best Regards Pete

Did you try calibrating them in FSUIPC without also assigning them there? How are you assigning them? i.e. by which method in FSUIPC's axis assignments? Have you presses the left hand "SET" button (so it changes to "RESET")? Only then are the calibration facilities active. Please use an up-to-date supported version, currently only 3.98 or 3.98a for FS9 and before. You can always find out what versions are supported by referring to the Supported Versions list in the Announcements. Come back after you've got yourself up to date. Pete

FBW? Fly-By-Wire? Do you mean the Airbus stuff? There are three FS controls which you can assign. I don't know whether they work. I think they relate to switches on the Airbus overhead: FLY_BY_WIRE_ELAC_TOGGLE Turn on or off the fly by wire Elevators and Ailerons computer. FLY_BY_WIRE_FAC_TOGGLE Turn on or off the fly by wire Flight Augmentation computer. FLY_BY_WIRE_SEC_TOGGLE Turn on or off the fly by wire Spoilers and Elevators computer. These are also mapped to FSUIPC4 offsets 07B6 to 07BB including "failed" flags. Autotrim? What aircraft is that implemented in? There's no sign of any access to an autotrim facility in SimConnect. Does it work? Regards Pete

never heard of them. I only used 16384 as 10% because FS uses that values for many of its "percentage" values internally. It's an arbitrary decision in any case, it isn't signigficant. No idea, sorry. i merely read the values using standard Windows API calls. Since you are the only one that wanted this facility and you don't seem to like it or think it works, I should remove it? I really have made it work the best I can without knowing how to make FS do exactly what i want. And it seems okay here. Why are you specinding so much time messing about with it anyway? Regards Pete

I would have thought the nearest you'd get to that would be the "on ground" flag. What do you mean by "absolute altitude"? There's the altitude AMSL of the aircraft datum point, wherever that it, at 0570 and the ground altitude under the datum point at 0020. I still think that's the same as the "on ground" flag. Regards Pete

You probably got the DLL.XML file messed up in all that. Not all installers / uninstallers treat that file properly. I think you are using Windows Explorer with that default option set to hide filetypes it knows like .EXE, .INI, .CFG, .LOG and .DLL. That FSUIPC4 must be FSUIPC4.DLL -- look at the column in Explorer headed "Type". What does it say there? If you want to see the REAL filename, so you won't confuse yourself, then in Explorer select Tools- Folder Options - View , and uncheck "Hide extensions for known file types". You mean DLL.XML, and now you aren't making sense because earlier onin this thread, when "guenseli" kindly answered you whilst I was away, you said: How could you confirm that the DLL.XML file entry was okay if you couldn't find it? Don't you see that makes no sense, or have you just forgotten? The Install log (which did NOT show anything wrong even though you said it did) gives the location of the DLL.XML (it is in the same folder as FSX.CFG), i.e. here: C:\Users\Heikki Soini\AppData\Roaming\Microsoft\FSX You do NOT want to mess about with any of that. Why would you think that? Leave it alone! Not too much intelligence is needed, just more careful reading really. Regards Pete

I know. you said that already. But there is no problem shown in the Installer log file as you seemed to think. I asked when was "before" -- i.e. when did you last see FSUIPC in the Add-Ons menu? That was one question. The other was to find the FSUIPC4. LOG file and show me it. When what "stopped function"? What happened between when it was there and was not? Taking all files away and reinstalling would make no difference in any case, other than possibly losing any infomation relevant to the original problem, and maybe losing your Registration if it was registered. If by "FSUIPC4" you really mean "FSUIPC4.DLL", then of course it is a binary file, not text -- it is the module which is run in FS and called "FSUIPC4". It is program, not text. If there is no log file at all (nor any INI file by the look of your list), then FSUIPC4 is not being loaded at all. That means the DLL.XML file is corrupted. Try deleting it and then re-installing FSUIPC4. (If you have any other SimConnect modules loading, best make a safe copy of it first). Regards Pete

I don't know what "directplay" is, but for FS9 or before, for multiplayer, I think you need the FS MP SDK. I don't know about FSX -- I thought most programs used SimConnect and managed their "MP" traffic as AI creations? Sorry, it isn't my area of expertise at all. I think you'll need to ask elsewhere. Regards Pete

Sorry I'm lost here. I was asking who is developing a new Multiplayer interface? I could refer others to them if so. I remember Jose Oliveira did a program called "AIBridge" which did some clever interfacing in order to get MP aircraft data out of MP and into FSUIPC's TCAS tables, but I've no idea how that worked. I'm really not involved at all in MP and wouldn't want to get started down such an unknown route myself at this stage. Pete

Interesting. I think that points me in the right direction. I also have FDC Live Cockpit and when it connects to FS, I believe it uses the FSUIPC Display to show a message along the lines of "FDC is ready". I'll see what happens when I start FDC after RC. Either way, I have yet to see "[Window.FSUIPC Display]" or something like that appear. Only [Window.Radar Contact] so far and of course, that's not being enforced, if the window's titled differently. At least, that's what I'm seeing here. When you get a windows showing "FSUIPC Display" just toggle it off and on again and its details should be saved. Pete

Who is "you" in this context? How are they doing this? Regards Pete

Yes, 3.96 is out of date and not supported. 3.98 is the earliest supported version as stated in the Announcements. Pete

Is there an FSUIPC4 LOG file in the modules folder? When you say "disappeared", what do you mean? When was it last there? Looks okay to me. What do you think is wrong? The only odd things is that there was no older FSUIPC4 to be replaced, yet you maintain there was one before which has "disappeared"! Regards Pete

Sorry, you need to explain more. By "reverse thrust levers" what do you mean -- separate levers on some sort of joystick or quadrant? What software are you using? FS? FSUIPC? How are you trying to assign them? You need to be a little more specific. And what does "max reverse an 2 times the idle" mean? It makes no sense at all to me, I'm afraid. You have something blocking your quadrant levers? Are they faulty? What make are they? There is no plane which will check whether you have a working reverse thrust and if not with refuse to take off. For taking off aircraft only need forward thrust, reverse is not relevant. Ah, now you tell us more. Yes, you can either have a reverse range on the normal thrust levers, or you can assign separate reversers, either one reverser for all engines or a separate reverser lever for each. Once correctly calibrated either method will allow you to achieve full reverse. the maximum reverse power for each aircraft varies and is defined in its AIRCRAFT.CFG file. Regards Pete

Sorry, I have no idea. Maybe BerndS can help -- see previous messages in this thread. He seems to have made it work okay. Regards Pete

You can have as many client PCs as you like. I have 7 regularly connected on my system, sometimes 9. Pete

There is no "dedicated RC window" until you move to RCV5, one day when it is finished. The window is named by the first program which opens it. The default name is "FSUIPC Display". If it hadn't been opened before RC is run then RC's supplied name would stick. Other programs might name it other things. When it is closed it is saved with whatever name it has. The name cannot be changed more than the once. Regards Pete

Unless you are using an out-of-date install of FSX (i.e. one not up tp SP2 or Acceleration levels), the state of the Windows firewall cannot affect the local connection between FSUIPC applications and FSUIPC. It only ever affected the earlier SimConnect implementations which used TCP/IP for the connection. Regards Pete

I thought you said you controlled taxi speed with prop pitch, or not throttle. Why aren't you not simply putting the throttle lever into the correct zone and leaving it there?. Sorry, this thread is ultra confusing. I really think you need to sort out what the aircraft designer intended with him or her. But the levers on the TQ6 are no different to any levers at all on any similar device. They are simply analogue inputs. Which is why I have been continually suggesting the use of the FSUIPC facilities to set discrete zones with fixed separate resulting control values going to the sim. FSUIPC is not an AIR file editor, that is why. However, it does have facilities you either do not want to use or do not understand. I cannot really help further, I have tried my best. Yet keyboard control is comparatively discrete, not continuous. Are you sure the aircraft designer has just made an impossible design after all? Regards Pete

The data is saved every time the window is closed. If FS closes normally the Window should get closed beforehand by FSUIPC, but there might be a timing element there which means FSUIPC is closing before the Window gets forcibly closed. It really depends on how RC was using it at the time. If the Window is effectively aborted rather than properly closed then FSUIPC won't get the chance to read its details and save anything. Pete

Well a difference in privilege levels is the only cause I know of for the problem you are seeing. No connection at all simply means that the code in your applications cannot get a message to FSUIPC, that the shared memory cannot be established. By all means check the FSUIPC log file to make sure there's nothing odd reported there, but otherwise i really have no other suggestions. It just has got to be a privilege problem. As a test try running FSX normally (not as administrator) and running one of the standard FSUIPC client programs I provide, like WeatherSet2 or TrafficLook, also normally, no privilege. BTW you say on the one hand there's no connection, but on the other hand that the location derived from FSUIPC is zero. Those two things are actually contradictory. If the programs cannot connect they will say so -- they'll simply timeout trying to connect and never get any data whatsoever. That is what "no connection" means. They'll come up with an error message. If you don't really mean that, if they are connecting but getting zero data, then that's an entirely different matter. That's a sign normally of a signature or key problem. Maybe your key is not valid. Try temporarily removing your FSUIPC4.KEY file from the FSX Modules folder. If that fixes it you either have a bad key (maybe pirated), or your Windows system date is incorrect, before the date of purchase of your key and so making it look invalid. I'm away from now till Monday, but if you'd like to paste a copy of your FSUIPC4 log file in a message here I'll look at it then. Make sure you close FSX first. Regards Pete