Pete Dowson

As long as you aren't doing a "Process" call for each individual one, they are blocked up for you in terms of the actual transfer of data. Except for some red tape added for each read the only saving you make by using one read instead of several is in the calls to the read function (which is in your program). However, that said, I myself far prefer to read data in structures, such as the "LLAPBH" one you mention (LLAPBH = Lat Lon Alt Pitch Bank Heading, and is actually a structure inside FS's own code). In some cases you really do need to write data as one block too, or else the order gets critical and timing becomes an issue. Where all the values are of the same type you presumably use an array. Even the LLAPBH set could be read as an array of 9 integers -- but then you'd have to be careful to join up the high and low parts of the 64-bit values carefully, and take care of those parts which are signed and those that are unsigned. I think VB has some difficulties with unsigned numbers. In most languages you can define structures, which are just collections of values of possibly different types, in a defined arrangement. I don't know if VB supports such things or not. Ah, now you've lost me. There's a "Get" as well as a "Read"? What's the token for? I assume this is something to do with the fact that VB.NET is "managed" or "interpreted" rather than real native code? Isn't the interface package provided by Paul Henty of use here? See viewtopic.php?f=54&t=53255 Regards Pete

Blank, or grey divided into rectangles representing button positions but with no labels? If there's no labels it normally just means it thinks it isn't connected. I've just tried it here on Vista and it works fine, so it isn't anything to do with Vista. Well, you have two "ButtonScreen=Yes" lines, but that shouldn't matter. I've just tried your INI file here, but without the Protocol=TCP and ServerName=Quadcore parameters, which shouldn't be needed if you are in the same WorkGroup as the server. I see you have a "UseTCPIP" parameter, which is long discontinued -- the only parameter for that has been "Protocol=TCP" for a long long time now. Are you sure you aren't using an out of date version of WideClient on that Vista PC? If you are not sure let me see the Log file. Looking at your INI file there are parameters there which are out of date and even discontinued, and some of those which should be there are missing, so I would guess you are well out of date with that installation. I expect it is a version pre-dating the Button Screen facility. I think you should delete the INI file, install the latest WideClient, and try again. You'll find a very recent one in the Downloads announcements above. You should really also have the "Size=" parameter in the ButtonScreen section, to configure the button array to suit your needs. Regards Pete

It would do, but it appears to only switch one button on and all the other 287 off. And if another application is also using virtual buttons you could easily interfere with their operations quite severely, because you are writing all 288 button bits. I don't know Java, but wouldn't something like this be better, just to change the one byte you need to? public void setButton(int joystick, int button) { // joystick 64-72 // button 0-31 byte data = new byte; joystick -= 64; int offset = 0x3340 + (joystick * 4) + (button / 8); fsuipc_wrapper.ReadData(offset, 1, data); data = data | (byte) Math.pow(2, button % 8); // Here I am assuming logical "OR" is '|' as in C -- if not change it // If you have shifts in Java then it would be more efficient to comput the value by "1 << (button%8)" where << is left shift fsuipc_wrapper.WriteData(offset, 1, data); } The clear button routine would be the same except you'd use Logical AND instead of OR, with the logicl NOT of the computed value, and you could have a Toggle gacility by using "Exclusive Or" with the computed value. I'm assuming Java has some Logical facilities in its repetoire, else you'd need to do everything using maths which is pretty horrible. If you know you have exlusive use of a range of 8 buttons then you wouldn't need to read them and manipulate them this way, you could simply set whatever combination you liked the way you are doing it but for 1 byte not 36. Writing all 288 buttons every time is not only uncooperative but it also prevents you using more than one button in your own program, at least without some changes. Regards Pete

I must say i can't blame you for that. I think I would do the same. Regards Pete

I've never seen that error, but a quick "Google" on the error number, 11004, finds this: http://forum.teamspeak.com/showthread.php?t=14420 which suggests using the IP address instead of the name. This is obviously a work-around, not a fix to whatever problem you have. A more explicit explanation of the error appears further down that thread: Why you have misconfigured DNS entries I don't know -- presumably that's something to do with your router or switch settings? Incidentally, why are you specifying the server name and protocol in the WideClient.INI? Didn't the automatic identification of the Server work either? It should be fine with XP/Vista systems, unless your Workgroup names don't match. Regards Pete

I think this is the same question answered in an earlier thread, here: viewtopic.php?f=54&t=72264 Can you check and see if that helps? Regards Pete

Fixed in version 3.827, now available in the Other Downloads announcement above. Thanks for the notification and useful information supplied with it! Regards Pete

Ouch! Somehow it's swapped to using the AXIS_ version of the FS controls! How odd. I have no idea how that happened, but I will go and fix it directly! Thanks & Regards Pete

I can understand them needing re-calibrating in FSUIPC, but surely the Manager program didn't re-direct axes to different Windows axes, i.e. swap them all about? That would be crazy. If ity did that then you'd certainly need to delete the [Axes] sections or else have a right mess to deal with. There's an "aircraft specific" box for Axis, Calibration , Buttons and Keys tabs, so saying it is the aircraft specific box again doesn't clarify anything I'm afraid. But in any of those cases FSUIPC would not (could not) specifically distinguish a Learjet from any other aircraft, it only goes by the name which is saved in the [Axes.] heading for the settings. If it thought there was no specific settings then the name couldn't have been matched. Regards Pete

I don't think you "receive" keys in any sense you probably mean. You have to go to your account at SimMarket and retrieve them. At least this is what happens to me for every other package I've ever bought from SimMarket, and i'm fairly sure the instructions tell you this as well. Regards Pete

Erfirst, why are you editing the [buttons] section of the INI file? Are you saying you want one button permanently assigned to set a COM1 standby frequency of 121.50? It can be done but I don't see the point. And to do that you'd be using an Offset control with the fixed frequency 121.50 being written to one of the Offsets I listed for you. That can be done more easily and with less errors by assigning the button in the FSUIPC Options, on the Buttons tab. That is what the on-line options are for, to save you all the hassle of editing the INI file. You only need to do the latter to add conditions or multiple actions. If you genuinely want to do such an odd thing I can certainly explain how, but via the Options dialogue preferably, as that is where you should be doing it. Otherwise, to get from 118.0 to 121.50 via increments you'd use one or other of the assorted COM1 increment controls supplied by FS itself. They are all assignable also in FSUIPC's dropdowns, for Buttons or Keys, but also most if not all of these FS controls are assignable in FS's own assignments. In FSUIPC the COM1 controls are named "Com radio fract inc", "Com radio fract inc carry", "com radio whole inc". There are decrement versions too. I'm sure you'll find similar descriptions in the FS assignments list as they are all standard FS controls. Why did you mention "offset" in your title and question? What are you thinking of when you say this word? I think I need to try to understand you before you are going to get close to any answer you are happy with. The level of misunderstanding here seems to go rather deep. Regards Pete

I have no idea how any separate program can make a mess of FSUIPC settings. It is never impossible to reset anything in FSUIPC -- if you want to reset everything to default simply delete the FSUIPC INI file. Everything you do is recorded in there. Or find the Axes or JoystickCalibration sections in that file and delete just those. It really couldn't be easier! What box? "aircraft specific"? That has to be checked by you, not FSUIPC! I really cannot imagine how you got into such a mess. There's nothing magic or clever about any of that in FSUIPC. It just does what you ask -- it sounds like you were misunderstanding some of the indicatiions. If the CH control manager is assigning FS controls, then you cannot assign them also in FSUIPC, though you should be able to calibrate any axes assigned to FS controls by any program. The axis assignments in FSUIPC are simply done by those axes which FSUIPC can see changing. The only way they cannot be assigned is if FSUIPC cannot see them changing. In FSUIPC3 that could only be because the CH Manager does not support the standard Windows "joystick" interface. In FSUIPC4 is seems more unlikely as it would mean it doesn't support the "DirectInput" interface. Regards Pete

Well, SimMarket could sort it out for you, via their "Problem Ticket" system, or you can write to me at petedowson@btconnect.com. Include all the details you have for both Registrations -- name, email, key, date -- and state which one you want changed. Regards Pete

The offsets I listed ARE where you write the standby frequencies before making them active! That's what is meant by "STANDBY" frequency!! You can write new values there and they are placed into the standby frequency which is the standby frequency shown before you make it active. How many other standby frequencies do you think there are? There's just one for each radio, not many! There are no offsets 1030-1045 except as part of the path and filename reading facility which occupies offsets 0FF0 through to 115D, inclusive. I think you must be totally confused. Maybe you are referring to the added FSUIPC controls 1030-1045, which are never used by those numbers but by their names in the drop-down Buttons and Keys assignments list, like "Com1 use whole inc" etc. All of those added INC/DEC controls were provided only because the ones provided by FS only operate on the standby frequency. Obviously it is not necessary for FSUIPC to add new controls to do the exact same thing as controls FS already provide. Please just use the FS ones, the same ones you can assign in FS. If it is these controls you are referring to, then I've no idea why you are using FSUIPC control numbers and so wrongly calling them "offsets", when their only use is for encoding button and key parameters in the INI file -- you should be using the drop-down assignments by name. That is why they all have names. For FS's own controls, refer to the complete list of FS controls supplied separately. Regards Pete

Of course. How have you looked? A simple search using the word "standby" reveals these straight-away: 311A COM1 standby frequency 311C COM2 standby frequency 311E NAV1 standby frequency 3120 NAV2 standby frequency Even searching for "frequency" would find them. Please do use the search facility in your word processor. It does make life easier! Pete

Well, except the part about wanting a visible button or switch, with FSUIPC that's easy already, of course. A lot of programs use the FSUIPC hot button and/or hot key facilities, which work locally and to a Client via WideFS. But maybe you want to write your own interface? Why? Because you are writing a payware program and you don't want to pay license fees, or some other motive? For a visible button or switch the Gauge is the only sensible way, really. That can still be combined with use of FSUIPC so that a networked PC can be used. Regards Pete

I think you'll face really big big problems, as your .NET application is presumably managed (interpreted) code whilst FS is all native Intel processor code. I really have no idea how you'd integrate the two opposite ways of doing things in one Process. Regards Pete

If you assigned all the axes via FSUIPC, you must also calibrate them in FSUIPC. All you really need beforehand to do is ensure the initial windows driver calibration is adequate to allow the full range to be used and to make sure the centre (for those axes with centres) is close enough to where it should be. After that the precise calibration, and response curves, can be set in FSUIPC. Ah, sorry, I don't know CH Control manager. Maybe someone else can advise there -- but did you refer to the "FSUIPC Guide for CH Users " sticky near the top of this Forum? Regards Pete

Thanks for the info! Pete

FSInterrogate is a useful tool for experimenting with known offsets, but it isn't the reference for what is available. You should be referring to the FSUIPC4 Offsets Status document for that. I do try to keep the FSI file for FSInterrogate up to date, but it certainly isn't guaranteed, and hasn't got anywhere near as much infirmation in it as the offset documentation. As it happens, the values actually called "Ignition switches" are not currently available through FSUIPC -- they never were and they've never been requested before. Things like that tend to be added by request. I've looked at the SimConnect interface, and there are separate ignition switches numbered 1 through 4, with 1 and 2 corresponding to your Left and Right, so I'll add them in the interim FSUIPC4 update planned for later today. I'll add these to the TURB ENG set of values, as follows: 208C (4 bytes) Turb eng 1 ignition switch, 1=on 0=off 218C (4 bytes) Turb eng 2 ignition switch, 1=on 0=off 228C (4 bytes) Turb eng 3 ignition switch, 1=on 0=off 238C (4 bytes) Turb eng 4 ignition switch, 1=on 0=off Currently the latest version is 4.305 -- look out for 4.306 later today or maybe tomorrow. (In case you hadn't noticed, interim releases and updated information are always provided via the Announcements above). Regards Pete

No point in that. All your client arrangements can stay the same, no matter which FS version is running on the server. Didn't you ever notice that you were downloading the same client EXE twice? Regards Pete

There's only one version of WideClient. It has always been completely FS version independent. You will note that the current incremental release of WideClient is version 6.767 in both the FSX and Other downloads Announcement above. They are identical. You never need to change the Clients at all when changing FS versions, from FS98 through to and including FSX and ESP. Look out for the next incremental release in one of the Downloads Announcements above. Probably in the next day or three. Regards Pete

I don't have such an option in WideClient at present, but it wouldn't be hard to add it as an INI file option. Maybe "Visible=OnTop", and "Visible=MaxOnTop"? Pete

I decided against allowing that directly because the macro file references are not fixed -- the names are assigned in the FSUIPC.INI file, so the control numbers to instigate the macros within would vary from installation to installation. For instance, many folks still run FS9 and FSX. I didn't want unpredictable things happening because the macro files just happened to have different reference numbers in the two installations. But it can be done. The best way, and one which overcomes the above problem altogether, is to use the virtual button facilities -- offsets 3340 and following. Instead of sending a control via 3110, toggle a bit representing a virtual button, and program that to operate your macro. in the normal Buttons way. Regards Pete

What does that mean? You need to explain what happens, what you see, not terms like "takes out" which means only something like "murdered" or "removed from" depending what sort of films you watch. And how is an install incomplete? Does it say "i am not complete"? Else how do you tell? And has this anything to do with anything I deal with here? I'm pretty sure FDC uses FSUIPC, so that makes sense. Why would you want to try it without FSUIPC in any case? Nothing you say makes sense. Can you explain why you are trying FDC without FSUIPC? Corrupt? What does that mean? What does the FSUIPC log file say (you'll find it in the Modules folder)? Why are you even talking about FSUIPC in the first place? Why do you arrive here instead of at FDC or PMDG support? Regards Pete