Pete Dowson

I've just checked them on FS2004 -- the 0BB8 and 0BB4 values simply stick at their last manual value (they don't go to 0), but the deflection values at 2EA8 and 2E98 are working fine, and change correctly exactly as they do in FSX when on A/P control. Please check again. Use the Monitoring facilities (right-hand side of the Logging tab) or FSInterrogate. You must be doing something wrong if you only see zeroes. Don't forget those deflections are in Float64 format. Pete

The aileron and elevator position indicators (0BB8, 0BB4) should help. Or you'd need to use the actual deflection angles, 2EA8 for Aileron, 2E98 for elevator. All these work fine with the autopilot in FSX, and should be okay in FS9, though you'd need to check that. Regards Pete

Well, I seem to be talking to myself here, but in case anyone is still interested, after investigating these reports as much as I can (I cannot reproduce the actual problem), it appears to be something to do with interaction between the latest version of ASX (SP3 can out whilst I was on holiday) and the facilities in FSUIPC4 to apply filters and to attempt to automatically remove spurious wind and temperature layers. So, if this is indeed the case, the interim work-around is to do one of two things. Either 1. Turn off the option to update FS's own weather. With version 4.28 this does NOT stop the wind, pressure and temperature smoothing options -- it was precisely to allow this that they were separated! In fact the option is defaulted off in any case, but you wouldn't know that from an existing installation where you had to have it enabled for wind smoothing (4.26 and 4.25). Or 2. Add the line "CustomWeatherRewrite=No" to the [General] section of the FSUIPC4.INI file, leaving the option for changing FS's own weather enabled. This will remove most of the "own weather updates" when custom weather is in force -- e.g. when ASX is in charge of it -- but still attempt to sort things out for FSX's own weather downloads, and themes and global weather. I am going to remove that option and replace it by "CustomWeatherModify" which will automatically appear in the INI file and will default to "No". It will actually be a little more drastic than the "Rewrite" one, which doesn't prevent all attempts. Look out for interim version 4.282 early next week. Regards Pete

If the GPS accepts NMEA 0183 or Aviation format position information. None of my three Garmin models do. For FS9 or earlier you need to download GPSout. For FSX you need a registered version of FSUIPC4. Then refer to the documentation. Regards Pete

It sounds like they are on USB ports with "power management" enabled. When Windows has that option it removes some USB power from devices which appear to be "asleep" until they wake up again, and this causes erratic readings initially. Regards Pete

Well, I don't think really it is FSUIPC's job, but a nice project for a utility or gauge. FSUIPC provides the tools -- the brakes can be disconnected by FSUIPC and controlled by program. Did you look at Thomas Richter's work in this area -- I gave you a link? Regards Pete

The INI file isn't relevant, and the Log shows FSUIPC4 is working fine. The other file which might have been relevant is the Install log, but it doesn't matter now. So, I'm afraid you need to report the error to the support of whichever program is producing it. As I said, it isn't a message from my software. Sorry. Regards Pete

Yes, somewhere. Ok, I'll have a deeper look at that. It's one of these "one missed checkbox deeeep in the system makes you go crazy"-thing :wink:. No, this is nothing whatsoever to do with any checkboxes. Engine 1 throttle should be assigned to Engine 1 Throttle. The ONLY throttle part of FSUIPC which has a "Map to 4 throttles" checkbox is the one for the generic default all-engine throttle, on the page with aileron, elevator and rudder. Honestly, this is what I did. Maybe you also have it assigned, in FS, to the main default throttle too. From what you posted first, you must have seen it operate on the first FSUIPC page to even think of the "map to 4 throttles" option, which is totally irrelevant when not using the generic throttle. What do you mean by "override"? If you assign axes in FS you can calibrate them in FSUIPC. If you assign axes in FSUIPC you MUST calibrate them in FSUIPC. If you assign axes in both places you will get a mixture. It's fully flexible. There are no hidden things, it is all obvious. Sounds like you have the axis assigned twice, one reversed compared to the other (usually spoilers need "REV" checked before calibrating). Check your FS assignments as well as those in FSUIPC. The only difference in FSUIPC is that it provides a "centre" position, used for an "ARM" zone. Without seeing what you are seeing I can't say, but if you follow the steps correctly you should be okay. As an example, with my test joystick lever assigned to Spoilers in FSUIPC, the calibration section (bottom left, page 6 of 11) shows: REV checked (spoilers need the axis direction reversing normally) -- do this first, else the calibration will be "upside down". Min -15560, Centre -978, 2465, Max 16384. (Your numbers will be different, of course) Don't set any curved slope -- that should be 0 (flat). Conflict? Not sure that's the right word -- the same axis for multiple uses does come in handy sometimes. You just need to decide what you are going to do and then do it. Incidentally, though probably more efficient, the FSUIPC axis assignments were intended for more advanced uses, or for axes not assignable in FS. In fact it was only recently those facilities were added -- the usual way of using FSUIPC's calibrations is to still assign in FS, then calibrate in FSUIPC. Then you can't get "conflicts" (or confuse yourself). If you do assign in FSUIPC you really need to double-check you are not also assigning for a "conflicting" use in FS. Regards Pete

For FSX, SimConnect has variables for these, a read-out in RPM. I could provide them for reading. You'd need to know the wheel radii to convert that to groundspeed to see if they were skidding, though. How you'd "simulate" anything I'm not sure -- there's no way to control to RPM except presumably by braking, so I'm not sure what you mean. Have you looked at Thomas Richter's autobrake simulation package at all? http://www.technical-service-richter.de/ You can't influence the wheel rotation directly. And unless you are viewing the wheels from outside you'd not notice it in any case. You'd need to create such effects by altering things like braking, groundspeed, position and so on. It's the effects you need to create, not the visual wheel rotation, surely? I can supply FSX wheel RPMs if useful, but i don't see how they'd help you. I think they're really intended for EICAS synoptics in 777 and 747s and Airbuses. Regards Pete

I suspect that TO/GA mode was applied and therefore the N1 limit came into operation. Usually this is set much lower than 100% for normal takeoffs. You don't often see pilots takeoff in a 737 without some A/T and A/P modes pre-set, even though the A/P is not actually engaged for quite a while -- the flight director is used for pitch and bank guidance, and the A/T with N1 limit for thrust control and engine protection -- during takeoff you need eyes up, not on the instruments, though the PNF (pilot not flying) will of course scan them to ensure nothing unwanted happens, as always. Regards Pete

You must have it assigned to the generic (all-engine) Throttle axis somewhere then! :roll: That would not be relevant, or even visible, if you were not assigning and calibrating the first throttle as the generic all-engine throttle. The "map to 4" option simply takes the normal (default FS) all-engine throttle input and converts it to 4 separate Engine N Throttle inputs, so it is entirely irrelevant when you don't use the all-engine assignment anywhere. You must assign throttle1 to engine 1 throttle, of course, just as you did with throttle 2 for Engine 2 throttle, when you want independent throttles. This applies whether you use FSUIPC or not -- please refer to FS's own assignments, which you seem to have overlooked. (I always recommend sorting yourself out in FS first, before moving on to FSUIPC refinements). Please explain it again more logically, as what you say does not draw any pictires at all. Possibly you are testing this on the ground? Don't -- when the lever goes into the "ARM" position is will deploy 100%. Test only in the air. Pete

If the highest Input value from your throttle is less than 16384, then you can edit the calibration figure for the maximum in the FSUIPC INI file (the JoystickCalibration section). to make it higher, so that is is never reached. To get 95% might be a matter of experimentation though. If your maximum input value is at 16384 or close then, no, there is no way. There should NEVER be a need for such a facility. The whole point of calibration is to make sure your inputs can reach the complete intended range designed into the particular aircraft model! Why "of course"? Many aircraft are supposed to reach values of 108 or 110% N1 at max thrust, for take off under difficult conditions or for emergencies. That's about right, and certainly not self-destructive unless maintained for too long. Anyway, you should be applying the N1 limit (via an instrument panel setting or via the FMC) appropriate to the conditions. If you really do want to reduce your 737's performance, to make it unrealistic, edit the Aircraft.CFG file instead. Your axes should ALWAYS be able to reach the complete range designed for the aircraft! Regards Pete

You can add serial ports to any PC with a USB port by using a USB Serial adapter, which are available quite cheaply (anything from 10 to 60 Euros for different qualities -- a cheap one would do). Make sure the 296 accepts NMEA or Aviation format inputs for position. I have three Garmin GPS units and none of them do. I think only the aviation-oriented ones will work. Regards Pete

That isn't a message from anything of mine. And what "versions" of FSUIPC are you trying? There is only one to suit your version of FS! :o I have no idea what an "ETARLPLA" flight is (do you mean some PLN from ETAR to LPLA)? The important thing you need to determine is which PROGRAM or ADD-ON it is which is producing this message, then go to their support. If you want me to suggest answers, I need to know FSUIPC version numbers and to see the FSUIPC log files (install and normal) before I can even hazard a guess as to whether FSUIPC can help. Regards Pete

Yes, that can be correct with many of them -- the write goes to one place, a procedure or further computation, or converted into an Event/ control which goes via a message queue, whilst the read reads whatever FS set last. If your write had the exact effect you asked, then you'd expect the read to match it at some stage later, but not necessarily immediately. Of course some locations are not really "writeable" to any useful effect, and the read back will then often merely give you what FS decided, not what you decide. Please do not be fooled by the view of it as a memory area being written to and read. The "offset" values are, these days, nearly all merely "tokens". This is all to preserve the operation as it was in FS98 days, when, yes, it was an area (much smaller of course, then) in "GLOBALS.DLL". FS hasn't worked like that for a long long time. Please note that version 3.75 is very much out of date and is unsupported. Refer to the Announcements above to keep abreast of supported version numbers. In FS2004 (it varies from FS to FS), your 0560/0568 values are actually written to FS via a routine I know as "SetLLAPBH", in the Aircraft container part of SIM1.DLL. Looking at the differences in the values you are reading from those you are writing it looks clear that the lower 16 bits are simply ignored in this routine, presumably as being of little consequence? Regards Pete

Ah, a version not supported for some time now. Please see the Announcements above which state the currently supported version numbers. Please ALWAYS check this before asking for support. No, as I think I already said, I know nothing at all about Services. Sorry. Well, I am not sure. The interface to FSUIPC is clear if you are a programmer as the sources are all provided. AhI see you have provided a log fragment ... Two things odd here: First, how on Earth is the millisecond elapsed time count getting to 49492000? That's nearly 14 hours! Did you really have FS running continuously for 14 hours? Second, I've never seen the OpenFileMapping call fail, not ever. Error 5 is "ACCESS DENIED", so it is looking like some sort of privilege thing. Maybe memory owned by Services cannot be shared -- a possibility of violating system integrity, maybe? Regards Pete

Sorry, the message didn't show up. Look in the ZIP!!! No. It is actually more a problem with FSUIPC3, not FSUIPC4, as FSX can only run on XP SP1 or later and that normally already has the "GlobalSign" data installed -- except Microsoft made a mistake with some foreign language versions of Windows. Why not read the documentation, which explains all this? In the Installation section, near the front of the User Guide, there is an "Important" boxed section explaining EXACTLY what to do. The GlobalSign fix is in the ZIP. Didn't you bother to look at all?? :-( Pete

You might not notice it, if it causes a flight to be loaded from a temporary flight file just saved. AutoSave saves files in the background without folks noticing, and reading one straight back would be fast as it would still be cached. When you save a flight, it gets saved as a FLT file. Try setting some payloads in the menus then saving a flight. Look at the flight file with any text editor. Search for "payload" or similar. Regards Pete

Maybe some, but they've not shared it. There's no "full SDK" for such things. If their payload settings do influence balance they may just have spent more time hacking into FS's code in that direction. I have had to spend my efforts over a wide base and it has been difficult to delve deeper into some areas, especially those I know nothing about. Have you actually checked? Does a poorly loaded aircraft using FS passengers become unbalanced, needed changes in trim or even becoming uncontrollable? Of course there are ways of simulating balance differences in any case, aren't there? Merely making additional adjustments to trim "behind the scenes" could generate similar effects to a certain extent. Or does FSPassengers simply change the FLT file and reload the flight? Aren't the current payload settings loaded from the FLT files, with the defaults being in the Aircraft.CFG file? Of course if I knew what to do I could do it. I just have never had the time, and now I must look forward more to FSX and beyond, not try to recover extra facilities for old simulator versions. I don't mind doing things for FS9 if they are easy, but it takes many hundreds of hours disassembling and tracing through new (i.e. unknown to me) parts of FS code to see what needs doing, and I am not going to do that for a simulator now nearly five years old. Sorry. Regards Pete

Yes. I don't think those other offsets are really writeable, they are outputs not inputs. Writing a value there will not, I think affect the aircraft balance. That's what others have said -- UNLESS you go into the payload menu, where you will see the values you set, and "OK" them to exit. I think there is some essential routines being carried out then which propogate the values to the places they are needed. I'm sorry, but I never had the time nor knowledge to follow this up in any meaningful sense. But the requirement to be able to do this properly was input to MS for FSX and I think (though it is not yet proven) that the facilities should all work as desired in FSX -- except there only the station name and weight is available (not the x/y/z). The payload weights (only) are writeable via SimConnect, so they should be propagated correctly, but this is my current comment in the Offsets Status document: When this has all been verified I will note that in the document. It's all as matter of finding time to do everything, or receiving feedback from those that know and try. Regards Pete

No. And I don't think it is controllable. There are no changes I made in the first place to "fix" it -- it is a bug in FSX which occurs as many temperature and cloud layers build up. That tends to happen faster with ASX than it would with FSX's own weather, and I think we decided that ASX's double Vis layers may also play a part. The only thing which APPEARED to work for you and other testers was my speeding up the layer-elimination operation that FSUIPC4 carries out -- and that is VERY timing dependent. The lower the frame rates, the less time FSUIPC gets, the more SimConnect has to do, the more the layers can build up before FSUIPC can "fix" them. This will also occur more in denser areas of weather stations (eg around Chicago or New York) because there are more possibilities of FSUIPC4 actually "missing" one of the three contributing each time, as these are more rapidly changing. I fly only in Europe, so have never seen this "super fog" in a real flight, despite using ASX all the time. Maybe I can tighten things up even further. I don't know. But it starts getting dangerous -- eventually I'd be deleting "real" layers" instead of spurious ones. However, I'll have a look -- but I'd need Weather logs again, please, as before, showing a sequence up to the "ZERO VIS" records in the log. Maybe also I could extend the "net" of weather stations I check to more than the 9 I do at present. The logging will show if this aspect is part of the problem. Increasing the number of stations decreases the frequency each is re-read and "fixed" so it's a balancing act. Regards Pete

Did you miss the explicit paragraph in the documentation for this, which I think explains everything you've reported? I don't know if it is better in FSX -- I should hope so. Pete

If it is "connected" it is working! WideFS has nothing whatsoever to do with Images! It is an extension of the FSUIPC interface to networked PCs so that FSUIPC application programs can be run there instead of on the FS PC. Maybe you got mixed up with WidevieW, which is a completely different program? WidevieW links FS's running on different PCs. Your WideClient is connecting. All it is waiting for is for you to run an FSUIPC application program. Regards Pete

No. Providing you don't actually RUN FS on the client, Wideclient will be okay. WideClient is INSTEAD of FS. Pete

This is not something I've ever used. Have you tried operating this though FSInterrogate? If it very useful to see things through that program before actually constructing code. Maybe pause needs releasing? One thing in your code I notice which is inefficient (though it shouldn't matter in this case) is having a separate Process call for each Write. It would be better to do both writes then the Process. Have you tried enabling the FSUIPC Logging to see what is happening? IPC read and write logging, plus maybe Event logging. You misread the documentation? You are interpreting the values incorrectly. They are in BCD (binary coded decimal) -- that is each decimal digit, 0-9, is in its own 4 bits. Express the values above in hexadecimal and you will see immediately that they are correct: 8853 = 0x2295 6544 = 0x1990 4144 = 0x1030 5760 = 0x1680 Please do try using the tools provided. Both the Logging in FSUIPC and FSInterrogate would have shown you your error immediately. Regards Pete