Pete Dowson

No, the default foldersfor installers are horrible long things which include Program Files (X86) or similar, and go into the Windows system drive. Pete

Evidently not true, it seems. Well, sorry, then. Evidently I don't have a clue. I've always had the Global section in, and absolutely thought that necessary. But if it still doesn't work for you, obviously I'm wrong. Sorry. Oh, and I never tried treating you as a "dunce" or a "beginner". I wasn't treating you as anything at all, only trying to be as helpful as possible on a matter which is really nothing to do with me. I find to your attitude rather insulting and will not respond again, as obviously any advice I give is unwanted as well as possibly incorrect.. Goodnight. Pete

Haha! As far as I can see, you have just as many declaration lines in this structure as in the original. You are simply replacing what should be there by the reference. And it would be complicated to implement without a partial rewrite of this area of FSUIPC. At present there is one routine which simply makes sure the right sections in the INI are being referenced -- i.e builds the string for the profile specific section needed. The routine which processes it only knows that section, that's its whole world. Nothing else is known. Referring to other sections entirely whilst processing the current one means some sort of recursive call -- first back to the routine which gets the right section, then back to the one which just called it. (It would need an infinite loop check) -- with some sort of special parameter saying "just this one line please", and then back out again. All this for every individual line with an alias. Ugh. It would be pretty slow and very much more complex code. And it looks like so much more work and thought needed by the user I can't see many folks using it. I suspect that something similar, but not aliassing specific assignment lines to another specific section, but referencing a named library of assignments (or whatever) would be a bit easier to implement, and also (hopefully) to understand. Like this, perhaps: [AxesLib.NameAsWish] 1=0X,32,D,1,0,0,0 2=0Y,32,D,2,0,0,0 3=1Z,128,D,4,0,0,0 4=1R,128,D,3,0,0,0 5=1U,128,D,5,0,0,0 6=1S,128,D,6,0,0,0 [Axes.BE58] Lib=NameAsWish 1=1R,128,D,11,0,0,0 2=1U,128,D,7,0,0,0 3=1S,128,D,9,0,0,0 [Axes.350] Lib=NameAsWish 1=1R,128,D,8,0,0,0 Here, the AxesLib "NameAsWish" is processed as if it were the current section (i.e. just the one recursion), followed by the specials for this section -- which may be additional, or overrides. Or, vice versa, the additions or overrides are processed first and remembered so that the Library versions are bypassed. I suspect it would be easier to do it the former way, as that is similar to what happens in buttons and keys sections when you have generic/default and specific settings for the same buttons or keys. the latter override the former. If this meets the need, I can certainly think more along those lines -- but maybe not till mid-January or so, after my NY hols. Regards Pete

I don't see how a purely local declaration in SimConnect.xml can provide any networked support. It is, as it implies, Local. It does not use the Address. So if you had it working before, it m ust have got changed. Yes, because I assumed you had SimConnect configured correctly, which was evidently not true. Why would your username be there? The address is simply the name of the computer, not you, OR its ip address, like 192.168.1.1. The computer name and its IP address are synonymous. Your user name is not involved. Pete

All FS spoiler (speedbrake) implementations are like that. It's a feature of FS. Flaps are the same. If you assign and calibrate in FSUIPC it will provide the correct range. Please note when calibrating that the "Arm" position occurs some way off 0 (about 4000 or so). If you are on the ground then, FS will usually immediately set full spoilers, as if after touchdown. So, calibrate in the air, paused or in slew mode. Pete

Yes, the Server certainly does. I think they provide the SimConnect install in case you don't have that version installed -- there are three valid versions of Simconnect for FSX. Okay -- that's fine as long as the Address is either your FS computer name, or its IP address. No reason to hide it. Local IP addresses are not usable outside your network. Most folks have the same ones in any case. That's okay for a local Simconnect connection, as used by OpusFSX's server, except that you do not specify Address or Port for the local connection. See where it says "Local" for the Scope? It's no good for anything over a network. Surely the documentation for networking REX tells you that you need addition to the SimConnect.xml? The file should read: <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="SimConnect" version="1,0"> <Descr>SimConnect</Descr> <Filename>SimConnect.xml</Filename> <Disabled>False</Disabled> <SimConnect.Comm> <Disabled>False</Disabled> <Protocol>IPv4</Protocol> <Scope>local</Scope> <Address></Address> <MaxClients>10</MaxClients> <Port></Port> <MaxRecvSize>8192</MaxRecvSize> <DisableNagle>False</DisableNagle> </SimConnect.Comm> <SimConnect.Comm> <Disabled>False</Disabled> <Protocol>IPv4</Protocol> <Scope>global</Scope> <Address>your FS PC's IP address </Address> <MaxClients>64</MaxClients> <Port>6600</Port> <MaxRecvSize>4096</MaxRecvSize> <DisableNagle>False</DisableNagle> </SimConnect.Comm> </SimBase.Document> See the Global support section added? You need to fill in the Address field. Pete

I am pretty sure that OpusFSX does its own Networking, same as WideFS. It uses SimConnect from the FSXServer.EXE into FSX, but I am pretty sure that all its Clients only talk to it, as the sefver, not to FSX via SimConnect. I think they must do that because of the networking support for views etc etc, none of which is provided by Simconnect. So, I would still bet on a Simconnect configuration issue. Maybe you should paste your SimConnect.xml file (from the same folder as your FSX.CFG), and the SimConnect.CFG (from the client PCs "Documents" folder, or in the same folder as the program (REX) you are trying to use. If there is one in both I suspect the one next to the program being run takes precedence. Regards Pete

Hmm. If WideFS works the I don't understand why SimConnect cannot. I suppose you've checked the SimConnect.xml file on the FS PC, and the SimConnect.cfg file on the other PC? Both the IP Addresses or PC Names should match the FS PC. Also they need the same port defined. I'm afraid I've been steering clear of Win8. I did install it briefly on a Notebook just to make sure it didn't mess any of my code up, but i was then swiftly back to Win7. Regards Pete

Phew! That's the 2006 edition! Are you using a very old SDK? You should download the current one. The document is okay (it covers FS2004 and before), but you need to keep up to date -- as you do with FSUIPC itself, which is now 3.999z8 (full install) and 3.999z9 (module only) -- see the Download Links subforum. If you are working with FSX or P3D you should use the FSUIPC4 Offsets Status document as well, as it updates the list for those sims. The current version of FSUIPC for FSX/P3D is 4.924a (but 4.925 is almost ready). With all recent FSUIPC installers the atest version of the Offsets lists have also been installed in the FSUIPC Documents folder, to save folks having to download complete SDKs just for minor changes. Regards Pete

You did not search for "aircraft model" or similar? The offsets list, installed in your FSUIPC documents folder, tells you it is offset 3500. I don't think Google delves into all the documentation as you can! ;-) Pete

Okay. Then please explain it to me in a way I can understand, maybe with examples. Because i gave up on your first explanation because i got lost and couldn't see how anyone else could understand it either. Sorry if i'm being thick. try shorter paragraphs and examples. Pete

Having written that and had more thoughts whilst walking my dog (I do a lot of thinking at such times <G>), I might have an easy (simple) way to do something like what you ask. In each routine which Loads or Saves data for the four relevant areas (Axes, Calibrations, Buttons and Keys), before doing anything it can just check if there is an FSUIPC4.INI file in the aircraft folder, and if so (when loading) whether it has the relevant section. (for saving it would create one if there isn't one already there). If so, then it just switches the paths for the rest of that operation (only). Each of the four sections would be independent for reading, but not for writing -- once you make a change and an Aircraft Folder INI is present, then that's the file which is updated no matter which of the four sections you are in. Anyway, that was my first thought. If you think it would be better to only deal with the Aircraft folder INI if it already has the needed section in it, even when modifying, then that may be possible, but I would then be worried about what happens when you decide to assign the aircraft which previously wasn't "profiled" to a profile. The section and Profile would have to be created in the Aircraft folder's INI, creating inconsistency and erven more confusion. So I think it best to be clear as in my first poposed way. I'm not completely sure of the ramifications for adding aircraft to Profiles or creating new Profiles, but I think this would then all occur in the particult INI file, not in the main one. My only worry about all this is that it will get MUCH more complicated to understand what is going on. I can see the support load increasing, not descreasing, and possibly quite markedly. So if i do it I may mark it clearly as "at user's own risk: limited support available", or some such. I still find it rather odd that you'd find such an arrangement easier, but each to his own. No promises, but something along these lines would be pretty easy to add. (Just not easy to document <G>). Regards Pete

Well, the obvious problem is that moved moved the controls, or had some Windows update with a different USB driver. Look: this is the new setup for joystick connections: [JoyNames] AutoAssignLetters=No 2=Saitek Pro Flight Throttle Quadrant 2.GUID={3EF75950-1554-11E2-8001-444553540000} 3=Saitek Pro Flight Rudder Pedals 3.GUID={065C59E0-8C89-11E2-8001-444553540000} 1=Saitek Pro Flight Yoke 1.GUID={FC749440-DB0A-11E1-8001-444553540000} and this is the old one: [JoyNames] AutoAssignLetters=No 2=Saitek Pro Flight Throttle Quadrant 2.GUID={3EF75950-1554-11E2-8001-444553540000} 3=Saitek Pro Flight Rudder Pedals 3.GUID={065C59E0-8C89-11E2-8001-444553540000} 0=Saitek Pro Flight Yoke 0.GUID={FC749440-DB0A-11E1-8001-444553540000} See? The yoke was joystick 0 but now it is joystick 1. If you want the ability for your settings to handle rearrangements of your controls you do really need to use the Joy Letters facility instead of numbers. You can make a start now. I suggest revising the new INI [JoyNames] section to be like this: [JoyNames] AutoAssignLetters=No 1=Saitek Pro Flight Yoke 1.GUID={FC749440-DB0A-11E1-8001-444553540000} Y=Saitek Pro Flight Yoke Y.GUID={FC749440-DB0A-11E1-8001-444553540000} 2=Saitek Pro Flight Throttle Quadrant 2.GUID={3EF75950-1554-11E2-8001-444553540000} T=Saitek Pro Flight Throttle Quadrant T.GUID={3EF75950-1554-11E2-8001-444553540000} 3=Saitek Pro Flight Rudder Pedals 3.GUID={065C59E0-8C89-11E2-8001-444553540000} R=Saitek Pro Flight Rudder Pedals R.GUID={065C59E0-8C89-11E2-8001-444553540000} Then, henceforth in the FSUIPC options you'll see 'Y' for Yoke, T for Throttle and R for Rudder pedals. Regards Pete

I'm completely confused here. Isn't this "custom event" assignable in the first place? What sort of event is it? Most "custom events" can be assigned directly in FSUIPC (where they are called controls rather than events). Only the Lua mouse library offers that facility, so it would need a plug-in. Ah, so the gauge is mouse-macro susceptible! Mouse macros don't actually issue mouse clicks at all. They simply call the same code in the gauge which your click would have called. Why are you assigning to a keypress? Why not directly to your harware switch or button? So you are wrinig a program, interfacing to FSUIPC, to connect your hardware? It isn't a standard joystick type connection? Offset 3200 is 12 bytes because it is for constructing a "PostMessag" call to FS's main window with the Message, WPARAM and LPARAM values all set as you might wish. All those values are 32 bits in length, and 4 x 32 = 128 = 12 bytes! To use the facility at 3200 you areexpected to be a programmer and to be able to look up the correct values to be used withWM_KEYDOWN and WM_KEYUP messages. And of course, unless you want the key to appear stuck down, you need to first send the correct KEYDWN message and then the correct KEYUP message. As you appear to be a programmer, I'm sure you must have references to Windows progrmming documentation on these matters. Why not simply tell FSUIPC to execute the macro directly, why do it via a keystroke? See offsets 0D70 and 0D6C. If you really really want to send a keystroke, it is much easier to send the FSUIPC control for a keypress and release (number 1070 in the list on about page 30 in the Advanced Users guide). You can send any controls via offset 3110. Regards Pete

The only way I know for FSUIPC to be such a cause if when a program is using its interface into FS and sets bad values. You'll probably need to do a process of elimination to find out which it is. Without actual information -- the stuff from the Windows event viewer, I can't really help further. The FSUIPC log file is also relevant, maybe showing what was happening then. It isn't here, and anyway I doubt that anything in there is relevant. If you want to show me files, best to paste their contents into the message. You can wrap them up using the <> button above to differentiate them and make longer ones scrolable in their own right. Better files to show are the Install Log and the main run-time FSUIPC4 log. But most important of all, for crashes, are the Windows event logss relating to the crash. They give error type, module and, most important, the offset in the module so pinpointing the position. I've not heard of that. Is is an FSUIPC client program? Pete

Quite honestly, this sounds like it will only ever be used by a few dedicated folks, because it's so complicated. I wouldn't know how to begin even documenting it for the average user! I don't understand how you finsih up like that in the first place. A profile does NOT have to have settings in every category. For all those aircraft which can use the exact same Axis settings why not simply have those settings as the default set and no profile sections for them at all? Same with calibrations. And if you do need variations you tell FSUIPC to base the new Axis section on the default. Button and Keys should be no problem, because your default set applies in any case exacept where overridden by specific assignments. The only reason this doesn't happen for axes is that axes are always active whilst buttons and keys are noly active when you use them. I am really really busy with FSUIPC stuff relating to ASN, P3Dv2 and so on. I need to get on and finish stuff before my family start arriving for Christmas. Then I'm away half of January. If there's something easy to do and depending on the load I have at the time I'll look at what can be done, but I'd rather simplify things than make them so much more complex. Regards Pete

Hmm. Those aren't in the Acceleration SimConnect SDK. Following the links you give takes me to the ESP SDK on-line. I used to have ESP but following its demise, and seeing my disk gradually fill up, I removed it. Are they actually in FSX as well, just undocumented? If I add offsets for variables which are only in ESP or later I need to say so, or I just get complaints that they don't work in FSX. There's still this confusion I see! Offsets are NOT controls and those aren't mapped, unless you find an offset which you think relates to these but without the word "launch" included (because that is what I searched on). Offsets are repositories for values. They can be read and sometimes written. Controls are things you assign buttons and keypresses to, or send via offset 3110, and are just messages to FS to tell it to do something. They are not values and cannot be read (except as messages by the receiving program, i.e. FSX). FSUIPC's assignment drop-downs always contain all of the fS controls, even non-working ones, because it s built from FS's own internal list inits CONTROLS.DLL. The names listed are the names from that DLL, and are the same as those used in FS's own control assignments XML files. Meanwhile, I've printed off the ESP list of SimVars so I can in future deal with folks' requests on these, presumably for P3D which is derived from ESP. Regards Pete

Okay. It was just terminology then. We tend to think of "modules" as DLLs, but EXE's as programs. When you said it was a module I naturally thought you meant a DLL, which did seem unlikely, as I suggested. Regards Pete

Ah, I see the problem, and it is actually yours. This is your problem: It appears you ddn't UNINSTALL P3D 1.4! You either deleted it or told P3Dv2 to install over the top of it, in the same folder. See that the Registry thinks P3D version 1 is installed in F:\P3D, but FSUIPC's Installer sees it is version 2 (build is 9448). Later we see the failure to find Prepar3D.CFG and therefore the place for the DLL.XML file: Thus the misleading error message. The installer on the one hand is pointing to Prepar3D version 1 folders, because it is the Registry telling it so, but it sees that the EXE file is version 2. I'm not sure I can do anything about this in the Installer. I think you should edit the Registry to remove the entries for P3D 1.4. You really should have uninstalled it instead if you no longer wanted it! Regards Pete

You don't seem to have a problem with the DLL.XML file. Doesn't it all run correctly? Is it just this spurious message which concerns you? When did it arise -- i.e what did the log window behind it show in its last displayed line at the time ths error appeared? Are you sure there's no other part of the Log which might relate to this. You seem to have extracted only part of it. Pete

When you say "separate little module" do you mean a DLL which runs inside FS? If not, if it is an extenal EXE program which just talks to FSUIPC, then there shouldn't be a problem, really. The FSUIPC interface is the same. Perhaps it doesn't like FSUIPC reporting a higher number in the offset which tells applications the version of FS. For ESP and P3D it will be higher than that for FSX. This could explain its "subscript out of range" problem if it was trying to use that number as an index. FSX was 8, ESP 9 and P3D 10 (in offset 3308). Use FSUIPC's "ipc Read" logging and see if it tries to read this value and stops with the error shortly afterwards. Maybe we can fiddle something to fool it into thinking it's FSX. Regards Pete

All is revealed in the document obscurely named "FSUIPC 4.924 changes since 4.92" which in included inside the downloadable ZIP for the 4.924/4.924a install release for precisely the reason that it explains these things. How did you miss it? Did you look? Pete

Oh, I see. Sounds like they are trying the wrong adapter? If so I really don't know how to direct them to use a specific correct one. There seems to be no way to choose that, though I can take another look through the Microsoft docs. I'm afraid it'll need to wait till tomorrow though. I'm just on my way out. Have you specified the Server and Protocol in the Client INI file(s), just as a test? Regards Pete

Please update. Version 4.90 hasn't been supported for months now. The current version is 4.924a. Hmm. I've always strongly suggested using only wired connections. the exchanges between WideFS PCs is almost contninuous and such traffic really does not suit wireless connections. They are good for one way traffic, and okay for shorter one-off things like file transfers. When you say "find each other", are you relying on the automatic linking WideFS provides, using broadcasts? Is so, try instead providing the IPaddress or name of the Server, and the Protocol to be used, in the WideClient.INI form. Then WideClient doesn't need to wait. Maybe broadcasts don't work so well over wireless. But in such actions the one end doesn't have to guess where the data is coming from, it doesn't need to wait for a broadcast and then send a message to get itself recognised. you tell Explorer specifically to copy from X to Y. You can do the same with WideFs by using parameters to tell the client. I don't understand that. Isn't the Internet connection on the router only? WideFS doesn't do anything complicated, It is using standard Microsoft facilities, with standard Microsoft code. I am no network expert, far from it. I just copied Microsoft examples. Regards Pete

I wasn't implying otherwise! It was simply that if you had copied it you'd have had the backup to compare to prove it hadn't been changed! No rush for files. It won't be anything I can do anything about, it will be something in your system. And I'm out this evening in any case. I was only interested in comparing the files so I could give you an explanation. Pete