Luke Kolin

As a disclaimer, I'm 99% certain that this is NOT a FSUIPC issue. However, since I'm diagnosing it via FSUIPC and there are some experts here on FS Control values, I figure I'd throw it out there. I have a 3-lever CH Yoke, and the aileron axis returns values between -16384 and 16384. The Yoke was caliberated just the other day, and from the XP Control Panel it appers to be OK and centered. When I rotate the yoke left and right the values change in the FSUIPC calibration screen, but when the yoke stops moving and is held at a particular position, FSUIPC reports that it's geting an IN value of 785. Essentially, if I turn the yoke left for full left bank, I see the IN values decrease below -16000, and then a 1/4 second later I see 785 IN. I do NOT see this behavior in Control Panel when I move the yoke around so I believe that the yoke is sending the correct values into FS9, but before FS9 passes them to FSUIPC for display, it does something funny. Does that seem reasonable? Anyone have any ideas as to why this would be happenning, or a possible solution. My first instinct is to nuke FS9.CFG, but before I do that I'd want to double check if there's any less invasive way to fix this. Cheers! Luke

Because we're not masochists, or because sometimes we have a conceptual misunderstanding that prevents us from solving the problem, or perhaps it's far more efficient to ask than to suffer and then create a suboptimal solution. In my work I see a lot of people attempt to tough things out, and what they often end up with is something that barely works but it works nonetheless. It's not much better than copy and paste, since they don't know why it all works and is like "Cargo Cult" engineering. Cheers! Luke

What are these "guidelines" that you speak of? :) It might make things easier for misbehaving software, yes. But when it comes to filenames, there are no "guidelines". Either the filename is valid, or it is not - and if it is valid it is expected that it is supported. (Please note that I have not read the above thread in years, and am not commenting on anything beyond your post.) Cheers! Luke

That's because it *is* a PC. ;) Cheers! Luke

Even if WideFS ran on a mac, why would your FS applications? Cheers! Luke

Thanks for the prompt response! I will dig up my list of offsets at home to get a feel for what we need to do. I think most things will involve a read operation from a particular offset, but there are one or two writes I have in mind. I'll drop you a line this evening. Out of curiosity, what part of Toronto are you in? Cheers! Luke

Is there any known way to read/write FSUIPC offsets from XML gauges? I am trying to put together a simple ACARS status gauge that communicates with our ACARS package via a small group of offsets, and I have insufficient hair left to contemplate relearning C. I believe Doug Dawson wrote something called dsd_xml2ipc but I have yet to find any documentation or explanation for this gauge. Does anyone have any resources or suggestions in this area? Cheers! Luke

(This is coming from memory so please pardon me in advance if it's not accurate.) If I recall correctly Peter, FSUIPC will allow external programs to set the weather directly, with very little checking in between. This can lead to a crash in WEATHER.DLL if an invalid cloud type is specified and the necessary bitmaps aren't present. While I don't get these crashes often, they are annoying especially near the end of a long flight. Would it be possible to add an option to the registered version to filter out cloud types that are "invalid" - perhaps an INI setting that sets allowable values, and if the option is enabled then FSUIPC would check to make sure that the value it gets for a cloud layer when setting local weather is in the list of acceptable values. This seems like a reasonably easy (well, easy for me - I'm just brainstorming and not actually writing anything!) way to improve the reliability of the sim and weather packages. Cheers! Luke

It seems like the F-104 install is overwriting your copy of FSUIPC. Have you attempted to overwrite the FSUIPC.DLL file after you have installed the F-104? Cheers! Luke

I would multiply by 360# first, and then do the two divides. Cheers! Luke

Thanks for the change. I will create a special build and send it off to the user who was pretty consistently able to reproduce the issue. I should hear back in a few days. Cheers! Luke

That makes sense. The transient value from load might not get cleared until the aircraft gets off the ground for the first time. If I could make a suggestion - you may wish to annotate the documentation noting that the value is undefined and unpredictable before the aircraft becomes airborne. I read all of the values from FSUIPC and then stuff them info an "FDR data" object internally, and only then do I start picking and choosing what bits of data I want to examine - so you are absolutely correct, I don't really need to know the value. However, I think that knowing that the offset result can be unpredictable before the aircraft becomes airborne is of value. I was curious wether these interesting values were expected behavior, especially since the functionality is so new. That might be the best solution from a data perspective, but I at least have a workaround currently. Thanks again for you help and the information provided (and by the way, most importantly for that new feature in 3.53!) Cheers! Luke

Yes, this number is after conversion, and I'm 99.9% sure I'm not doing any limitation. The code is not with me right now, but iirc I am dumping a warning message when the absolute value of this number exceeds 6000. Since this is only happenning on the ground for this user before he has ever gotten airborne, it makes me wonder if I'm getting back an uninitialized value. When FS starts, does FSUIPC zero out this offset? What value should I expect to see in this offset if the aircraft has never gotten off the ground? I might ask him to do this right as the aircraft starts, as the problem we are getting is visible before takeoff. Upon landing it appears to be working just fine. Thanks again for your assistance. Cheers! Luke

We are using offset 030C to get touchdown speed, as introduced in 3.522. We have encountered some strange issues with one user where this offset is reporting some exceptionally strange numbers. While the offset is a 32-bit value, we store the values as 16-bit signed integer, as we do with vertical speed. We've had one user complaining of data overflows, and when we updated the code to preserve the data width and log "unusual" values, he is reporting numerous results where 030C is reporting back a touchdown speed of -59999 ft/min, while taxying. This is ocurring with different aircraft and at different airports, but appears to be only occurring with one user. He is not reporting any problems at all with vertical speed, which remains within the 16-bit limits of +/- 32767; it's only touchdown speed, and only while on the ground. Pete, Is there any reason you can think of why FSUIPC might be writing such unusual values into the offset, or even why FS9 might be generating such strange values? Cheers! Luke

I am currently using FSUIPC to restore an FS9 saved flight via the 3F00/3F04 offsets. Once FS9 is started and an aircraft is loaded, this works perfectly, but loading a flight does not work from the "Create Flight" menu. Is this expected behavior? When checking offsets 3364 and 3365 they clearly indicate that FS is "busy" and in a dialog, so I'm not surprised that this facility does not operate, but I would want to check if this is expected behavior. Cheers! Luke

I think what Peter is attempting to state is that you should NOT attempt to talk to WideServer directly via a TCP/IP stream unless you want to reverse-engineer the whole protocol. You're far better off developing assuming you're on a single box, and then let WideClient/WideServer abstract away the network layer for you. I maintain and extend software that uses WideServer; as far as I am concerned I'm just dealing with FSUIPC and FS on a local box and if there's a network between me and FS9 I am blissfully unaware and unconcerned. Cheers! Luke

That dialog box sounds familiar. What add-on is it, and are you sure it isn't responding to the fact that FS9 has crashed? cheers! Luke

Fair enough. I did a quick smoke test changing the offsets to read and it appears to work well. I do have one question - offset 0x2000 in the SDK refers to N1, whereas 0x2010 describes "corrected" N1. What does "corrected" mean? Cheers! Luke

I have been reading turbine N1 from 0x898 for jets, but I'm getting bad values on turboprop aircraft since this apparently returns back the prop RPM instead. I notice that there's an N1 value at 0x2000 that returns this data for jets and turboprops. I assume it's safe to use this offset instead? Out of curiosity, why are there different offsets that seem to return the same data? Cheers! Luke

I think you might end up having to write some sort of JNI interface either into FSUIPC, or into a custom DLL of your own that then talks to FSUIPC. To me, anything with JNI is a special and perverse form of masochism, bur your mileage may vary. Cheers! Luke

Is it any "fairer" for Peter to cut his prices by 35% based on depreciation in the US dollar? Welcome to the wonderful world of exchange rate risk - if you have a problem with the sagging dollar, there's an address on Pennsylvania Ave. you can send the letter to. ;) Cheers! Luke

If I recall correctly, Eric Marciano's A320 and A330 panels are freeware, but the A340 panel is not. Cheers! Luke

Ah, that explains it. I *think* I'm at zero, but probably just a touch above and so F2 works but not the mixture control. I added a touch of a null zone in the throttle and that did the trick perfectly. Thanks for your assistance and your patience! Cheers! Luke

I'll give it a whirl when I get home today and set the minimum value for the throttle a touch further forward. I haven't calibrated the throttle in FSUIPC at all (just the mixture axis). Out of curiosity, is the fact that I can engage reversers via the keyboard (using F2) significant? I tried the keyboard specifically to check for the reverser interlock, or does FSUIPC impose its own restriction in addition to what FS provides? I just wanted to make sure what to expect on the OUT value so I know that the proper numbers are coming out of FSUIPC to FS9. I'm sorry to pester you with so many questions, but I'm trying to learn this so I can get it working right in the future without assistance..... Cheers! Luke

OK, I tried reversing things and even this didn't solve matters. No matter what I do, either full forward or backwards, the reversers don't want to deploy. What OUT value will deploy them? I go from a minimum of -5404 to 0, and at no setting do the reversers deploy. Cheers! Luke