Pete Dowson

Well, if the BRAKES control is being sent but ignored by the model, it must surely have something to do with the specific model you are using. However, you say "my problem is with a standard FSX plane", so it is indeed a puzzle. But one thing I do notice, and that is the final Left Brake axis value is 56675 *** AXIS: Cntrl= 66387 (0x00010353), Param= -16193 (0xffffc0bf) AXIS_LEFT_BRAKE_SET which is not actually "off"! Why not try proper calibration so that the differential brakes do go completely off ( i.e. -16383 or -16384, never quite sure which). Maybe the BRAKES can't operate normally when a differential brake pressure is still actively applied. That wouldn't surprise me so much, really. Certainly FSUIPC only uses the BRAKES control when both pressures are the same. Pete

There's nothing I know of which is suddenly stopping the normal "Brakes" control working -- that's the one assigned to the '.' button by default. I'd check what your other add-ons are doing if i were you. FSUIPC actually used both -- it sends the Brakes control when the pressure on both pedals (after calibration) is equal. Use FSUIPC's logging to see what is going on. Pete

All those values are available. Just check the offsets list installed in your FSUIPC documents folder, inside the FS modules folder. Regards Pete

Sounds like a corrupted length field. Try using the logging in FSUIPC to see what is going on -- though I think that error is detected in the FSUIPC_Read or Write functions built into your code, before FSUIPC sees them. Pete

Please always quote version numbers -- many folks say "latest" meanng "the latest one they noticed". The currently supported version for FSX and P3D is 4.936, for FS9 and before it is 3.999z8 or z9. Is this with FS9, FSX or P3D or some earlier FS? You need to say really. It sounds exactly like a dual assignment. You don't say where you assigned the axes nor to which actual controls. If you are assigning in FSUIPC you should disable controllers in FS to avoid conflicts. You can use FSUIPC's logging to see what is going on. Pete

Sorry. FSUIPC really only handles axes fully if they are assigned in FSUIPC. If you disable controllers in P3D they should remain dfisabled? Pete

All writing to 05DC does is cause FSUIPC to send "Slew on" or "Slew off" controls, but only if the value written is different from the last read. And it works fine here with P3D 2.3 -- I just tested it. Use FSUIPC's event logging to see what is going on. I think you must be doing something wrong. "Y" uses Slew toggle controls. That's the only difference. Actually 05DE does nothing in FSUIPC4 --it's actually removed from the offsets list. The remaining reference, in the 05DC slot, is an error. Offsets 05E4 to 05EF all result only is Axis slew events being sent, just like the real axes, and as far as the 310B offset is concerned, the result is indistinguishable. They simply look like inputs from the axes you want to suppress. But there should not be a real problem. Provided your real axes are not changing their values will be ignored. Just set zeroes to the 05E4-05EE offsets first then set slew mode. Pete

Do not confuse the FSUIPC offsets with actual offsets in a DLL. That is historical -- it was like that in FS98 where all FS's interesting values were stored in one area in "GLOBALS.DLL". Even then the offsets were not from the start of that DLL in memory, but from the start of a tabler withing it which was found by other means. These days the offset values are offsets to a data area inside FSUIPC itself -- or more accurately one of two data areas dependng whether you are reading or writing -- , and the data itself is either populated at asynchronous intervals compared to user requests, or obtained. set on request. The offset numbers should really be regarded as "tokens" or just identifiers for the data. For 32-bit programs the base address of modules is actually used as the handle. There's no one base address. each module -- the EXE and every DLL -- has it's own. I don't know where you think the sound levels can be controlled, but these will probably not be in the EXE but in one of the separate DLLs. If you do know where the sounds can be controlled and you'd rather it be a facility in FSUIPC, then let me know the details and I'll see if I can add such facilities. I'm afraid these days I'm rather past hacking. It used to be fun, when I was younger! ;-) Pete

Sorry, this is certainly a bug in that application and needs to be reported to the publisher or author. Pete

Sorry, I don't seem to be able to search on topic numbers. Can't you show me the script? And have you checked the FSUIPC4.LOG file to see if there are any errors. There's absolutely no difference between P3D and FSX in this area -- the sound facilities are entirely independent of the FS version. Didn't you say the sound was in the Prepar3D sound folder? There won't be one of those on a client PC will there? Pete

Sorry, but you need to give more details. What is the actual version number of FSUIPC, and where is the Lua script? Have you tested it properly? Has it ever worked? I really cannot help solve your problems without your help. FSUIPC's Lua libraries have not changed for a long time and work fine. Pete

Two points. First, 4.935a does NOT work with P3D 2.3, you MUST use the currently supported version, 4.936. Second, there has been no change whatsoever in any offset facilities in any version of FSUIPC for many years. If there is any change it is in P3D 2.3, not in FSUIPC. The offsets you mention are the SimConnect variables "RECIP ENG FUEL FLOW:1" and "RECIP ENG FUEL FLOW:2" and their definition in FSUIPC has not changed in any way since FSUIPC 4.0 when FSX was released in 2006. Pete

The problem I have is in understanding your words. "Install the control section" means nothing to me. You use the word "install" very frequently and I don't know how you are using it. I am trying to understand whether you really mean "assign the control" or not. In your first message, which was quite honestly a complete meaningless jumble, there were parts in it referring to a failure to actually run the FSUIPC4 Installer correctly. This needs clarifying. Have you downloaded the complete FSUIPC package (and it should be version 4.936 now as I support no older one for FSX), and then read the Installation document inside the ZIP? That's the first step. Tell me when you've done the first step and we'll proceed. BTW I am out from 3pm UTC today until Sunday, and then again from Thursday 28th August until 7th September. Downloading the ZIP does not install the program. It will not work until it is installed. If it is installed, then, as very clearly documented, there will be an Add Ons menu entry named FSUIPC in the FS menu bar when you are ready to fly. It is there where you start doing things like assigning controls -- but you can only do that if you have purchased a registration code and registered FSUIPC4 when installing it. Full documentation is supplied and installed with the product. I would very strongly recommend you actually have a look at it. Pete

It certainly isn't. Maybe that is why WidevieW doesn't do it? That would be the best place for it to be done, after all it is already extracting user aircraft data and using it to control the clients/slaves. This would just be more of the same. Why piggy-back on FSUIPC's reading of the data from SimConnect? If someone is going to learn enough to deal correctly with Multiplayer (something I've certainly never looked at), then the easier task of interfacing to SimConnect should be a doddle and it would be more efficient that going through FSUIPC, which itself reads from SimConnect. I don't know how "synchronised" it would be. How often will you read the traffic? FSUIPC reads it at quite sparse intervals, at most once per second and then it splits it up to avoid ruining FSX performance or overloading SimConnect. I had such events reported recently which gave rise to reductions in this area in FSUIPC. Someone had SimConnect overloading at an airport with lots of ground traffic, both airport vehicles and aircraft. I don't have any experience at all with multiplayer. Do you? Does VATSIM, for instance, run into MP overloads at fly-ins? It might be worth asking over in VATSIM type forums to see what the experience is. I would have thought trying to control the hundreds of AI most folks like to have (as I do, for instance, for a realistic EGLL, EHAM or LFPG) frequently enough to achieve near synchronicity would be pretty near impossible. Maybe if you accept them jumping into new positions on each individual update cycle that would be possible, but horrible. If you could limit the faster updating to only those in view, or nearly so, on the other PCs it might be a little easier. But that's a complex job computing 3D cones of view. And then there's the increase in Network traffic. Not that the Network itself wouldn't be capable, it's more the processing of the TCP/IP queues on each PC, which Queues are also used for external SimConnect connections. Maybe. Difficult? Certainly. I think there's a lot to be thought about before anyone rushes into this. Regards Pete

Leave off the ,1 and ,2 and supply that as the parameter in your assignment. Pete

Where are you reading thes numbers in any case? Whatever range you get doesn't matter at all for calibration. FSUIPC maps the range you do get, whether it be 0-127 (as in the case of PFC devices) or 200-9000 or whatever, it's the calibration process which maps it to the values needed in FS. I suspect you are misunderstanding something. Have you read the relevant part of the User Guide? I recommend you refer to the Joystick Calibration chapter and follow the numbered steps there. Pete

Okay. So the DLLs and EXE's being loaded are: DLLs: P:\FSX\ORBX\FTX_AU\FTXAA_YBAS\Scenery\ObjectFlow_YBAS.dll P:\FSX\ORBX\FTX_AU\FTXAA_YMML\Scenery\ObjectFlow_YMML.dll P:\FSX\bglmanx.dll P:\FSX\PMDG\DLLs\PMDG_Interface.dll P:.\RAASPRO\RAASPRO.dll P:\FSX\VistaMare\ViMaCoreX.dll P:\FSX\PMDG\DLLs\PMDG_HUD_interface.dll P:\FSX\Modules\FSUIPC4.dll P:\FSX\as_srv\as_btstrp.dll EXEs: P:\FSX\fsdreamteam\couatl\couatl.exe C:\Program Files (x86)\EZCA\EZCA.exe P:\FSX\\Flight One Software\Ultimate Traffic 2\UT2Services.exe Now I don't think the EXE's are likely to be responsible as then the crash would more likely be in their process, not in FSX's. Of the DLLs I have no idea which try to use the internet (and hence "mshtml.dll"), but there are two ways to stop them running. Easiest is probably simply to rename them -- change the DLL ending to, say, DLX. Try doing this initially with all except FSUIPC4 (no need to change that one as you've already tried without). If you get no crash, enable each in turn, testing after each one. I use several of those listed -- AS_BTSTRP (part of ASN), BGLMANX, VIMACOREX and RAASPRO. I've a feeling BGLMANX might access the internet in order to check for updates. Not sure about the others. Pete

No, this is still nothing related specifically to FSUIPC. "mshtml.dll" is used by Internet Explorer and other browsers. FSUIPC doesn't touch the Internet and has nothing to do with HTML. Your problems are from other add-ins you are running. You need to go through a process of elimination. If you find your DLL.XML and EXE.XML files and paste those here I can point out how to do this for those programs loading automatically. Pete Pete

Please ALWAYS post support questions in the Support Forum, not in subforums such as "Download Links" which are for things like download links! It finds the Prepar3D install path in the Registry as B:\Program Files (x86)\Lockheed Martin\Prepar 3D V2 This is where it is looking for "Prepar3D.exe". Check yourself to see if it there. If not you have a bad P3D installation. When it can't find it, it prompts you to find it. Where did you find it when it asked you? The log you show appears to be truncated -- there should be at least one more line. What does it say? Pete

If you installed it and used it without my PFCFSX driver, then it is not a serial port quadrant, but some new one I know nothing about. So you do not need any of my software. Your support is PFC themselves. It is just that I have never seen nor heard of such a PFC quadrant. It must be a recent product. They don't keep me in the loop these days. Pete

You cannot set it to "FSUIPC direct" because it is an FS control, not an FSUIPC direct control. You cannot assign to controls which aren't listed. Pete

Very few gauge actions in the default aircraft are susceptible to this method. The format is not correct. Please check "Macros to change Lvars" on about page 40 of the Advanced User's guide: there is no separate name, the L:var name IS the name. Where the name is too long (and this one is close, but I think should fit) you'd need to write the action as a short Lua plug-in instead, and invoke that by assignment instead. Pete

FSUIPC has not crashed, nor is it causing the crash. In fact the log you supply shows FSUIPC terminating normally, no problems. However, it isn't actually starting -- it isn't supplying any services at all -- at least in the first 27 seconds. .You might have a corrupted Flight or Weather file. Without FSUIPC loaded, try selecting a different default flight. However, that doesn't explain the crash you have logged which is in nothing used by either FSX or FSUIPC. Whether the system is crashing with or without add-ons such as FSUIPC is often to do with timing differences and memory arrangements affecting other parts. The module which is crashing is mscorlib.ni.dll, of which I know nothing. In fact it doesn't even exist on my system, so I suspect it is installed and used by another add-on you are using within FSX. You may need to do a process of elimination to find out which. Googling that module I find: Hope this helps, Pete

SimMarket have NEVER supplied FSUIPC, they only sell the registration keys! You get FSUIPC from wherever you got it from in the first place, as linked from the SimMarket page or any of my documentation, as well as in the Download Links subforum here! Most folks get it from the Schiratti site but that points back to the Download Links packages in any case. Pete

Your FSX looks like P3D renamed as FSX! How did you manage that: FSUIPC will not work properly with a P3D exe renamed as FSX or vice versa. It looks like your installation, whether it be FSX or P3D, is in a mess. Is there a Prepar3D.exe file in E:|FSX? That would probably do it! Maybe the FSUIPC install log will show what has happened. All I can see from the FSUIPC log is that everything is wrong. If the A2A service checker has made this mess I suggest you report back to them how dangerously corruptive it is! Pete