Pete Dowson

Not much use for us who fly outside North America where such charts are either not available for such devices, or are very expenssive. I assume you cannot mean iGMapHD for iPad, as that follows your position in FS. Doesn't FS Kneeboard follow your position? If you just want a good moving map, try FSXFollow. I use that on the iPad. For other things like instrumentation and I can also recommend AirTrack, which I use on both iPad and iPhone. There's even an FSXcontrol which allows you to control FS from an iPhone or iPad. I don't think anything a complex as WideFS would be needed for such a trivial improvement to FS Kneeboard, if that is indeed the program you mean. I think you should ask the authors, or changeover to FSXFollow or iGMapHD. Blimey, another one? Not seen that one before -- but I'd recommend that you investigate some of the other programs I mention. The one you found looks an expensive way to go even if you do fly in North America. Regards Pete

Yes for airspeed, heading, altitude, most anything intrinsic to FS. No for waypoints, or at least no way I know which works consistently. Theoretically if the plan is loaded into FS then the next waypoint should be readable but I don't know how to do it consistently. The "GPS" info I can get hold of in FS9 doesn't always work, and it isn't available in FSX.. If you are always using RC then if RC could deposit next waypoint information into a specific offset, then that could also be displayed, but that would mean a change to RC. Alternatively it might be possible to decode part of RC's usual menu display to get that information. If you can ennumerate the exact fields you need and how they have to be displayed and operated to drive your Braille converter, I'll see what I can do. Regards Pete

It seems you are using FSUIPC4 and FSX, but you are not referring to the Offsets Status documentation for FSUIPC4. The decimal value 16842752 is hexadecimal 0x01010000, which gives: 0000 in the 2-byte offset 0830 01 in the 1 byte offset 0832 01 in the 1 byte offset 0833 all of which seems to agree perfectly with the correct 'manual', for "crash detection on" and "crash detection with other aircraft" on. Please do refer to the correct documents. Pete

I replied to you in the AVSIM FSX Forum, as follows: I'm afraid disabling controllers in FSX also disables that facility. No idea why they did that. In FS9 it was separate -- as were each controller, so you could pick and choose. The only suggestions I can make are to re-enable controllers in FSX and either 1. Make sure all assignments in FSX are delete those entries assigned in FSUIPC, or 2. Assign in FSX in any case. You can still calibrate in FSUIPC. The FSUIPC axis assignments are useful for assigning different controllers for different aircraft, and for a few other things (and such assignment, when used "direct to FSUIPC calibration" can be more efficient), but you should be able to get good results either way. I did have a look at implementing mouse look in FSUIPC but didn't get very far. EZCA does it well, using the centre mouse button (press the wheel on a wheel mouse), so there is a way. I might take another look. I have just had another look, and I think I might be able to add Mouse Look as an option in FSUIPC4, switched by the same FS control "Mouse Look Toggle" (with a parameter 0 (toggle), 1 (on) or 2 (off)), or possibly by holding the centre button down.. No promises though. Regards Pete

No, it's the same, and works fine here -- tested via FSInterrogate. What do the logs show? (Log IPC writes and Events). With PAUSE FSUIPC4 uses the FS PAUSE SET control with the parameter dictated by offset 0262, so that should work regardless of timing. however, for SLEW it can only use the FS SLEW TOGGLE control, and since it getting the slew state from SimConnect asynchronously, it is possible that it is switching it on when you are asking for it to be switched off. This could happen, for instance, if you sent your writes in too quickly (too close together). The log should show you what is going on. Also try monitoring 0262 and 05DC to the normal log. That will log SimConnect reads and writes to those, also. Pete

I don't know. It isn't to do with the com library but to do with Lua string formats. Did it work when you tried it, or did you get the string literally as typed? Without referring to the Lua references I can't say whether Lua supports \x type string exceptions or not. It does do \nnn for decimal, though. So you could use "\254\081" to get the values you wanted, or even string.char(0xfe, 0x51) which would be clearer though obviously a little less efficient because of the extra function call. Regards Pete

Well, I'm glad you solved it. But I obviously didn't actually help, because I didn't have any information. What turned out to be the problem and solution, please? It is good to tell us because it may help others. Regards Pete

As already posted in an almost identical thread, where action (2) was successful:: Assuming the PC's date is set correctly (check please), it is probably the result of a recent Win7 update which tightens security even further on the Registry. There are two things which may overcome this: 1. Re-run the Installer but by right-clicking on it and selecting "Run as administrator", or 2. Download the latest interim update (currently up to 3.997b) from the Download Links subforum and copy it into the FS Modules folder. If neither action helps, please paste the FSUIPC log file (not the Install log) here, after closing FS down. Regards Pete

Ah, good -- that is good news, indeed. Regards, Pete

Yes, I think you must be. The AlsoSave facility is completely unmanaged. The "AlsoManage" facilities simply adds other files to those deleted when the normal Autrosave cycle operates. Pete

Yes, of course. But you would be better off doing all your displays after all your reads, and ONE process. That's all I mean. I'm not sure here what you mean by "need it". But one way of implementing things efficiently is to have a thread which reads everything you need every so often (eg. every 50 or 100 or 250 mSecs), with the one process call needed, and stores them all ready for access. Your other threads simply read the values they need, when they need them. They will never be more than 50, 100, or 250 mSecs out of date, whatever. If what you have works wel, and, importantly, doesn't slow FS or interfere with other programs, then don't re-design everything for this. I am only trying to point out ways of making things really efficient. There is more time spent in process switches because of "FSUIPC_Process" than anything else you might be doing. If performance is not "of the essence" I wouldn't worry too much. Regards Pete

Well there would be if he used the User guide. There is a dependency, because what you can assign depends on which mode you select. And in my experience with computers as a professinal since 1964 I have to disagree with you. There are many many dialogues where the options available change according to mode selections. Unless you seect "No reverse zones" the calibration screen shows reverse -- idle - max. So your confusion seems strange. Why not look at what you are doing -- it would be clearer then! I only mentioned "minimum" to refer to a minimum lever setting (i.e. pulled right back), the position which inputs the minimum arithmetic value, which is why I mentioned it. And where is the Forum full of such confused posts? The main postings have always been about how NOT to assign a reverse zone because throttle quadrants like the Saitek have a button for reverse instead -- hence the more recent addition of the No Reverse Zone option. Quite honestly, as a self-confessed computer professional it seems to be that you are going out of your way to be deliberately critical in areas which do not deserve it. If that's what you want to do, that's what FSUIPC assignments are good for. But it is not a general need -- you are trying to be an "advanced user" and for some reason being deliberately blind to what is in front of you. I was explaining "normal" use. I'm not. You are reading things in such a defensive and strange manner you are misinterpreting just about everything I say. Before finishing, I should add that this diatribe started after I simply suggested that you "try changing the three affected axes to "direct to FSUIPC calibration", to see if that helps". And in return for such an attempt to help, I get crucified. It really isn't worth it, and I'm too old to risk shortening my life further by the sort of stress you seem to enjoy causing. So, sorry, but this is it. I've had enough. I give in. You must be right, you are the customer. I'm evidently completely wrong. And I've wasted enough of my time trying to convince you otherwise. I suggest you read the manual again (which you probably should have done before even buying FSUIPC and so could could have avoided the expenditure). If you have further criticisms and accusations, or even, amazingly, new requests for help, I hope someone else with more patience for folks like you will chip in. Good bye. Pete

Same as FS does -- all FS controls have always been sent as Windows messages (WM_COMMANDs). And with multi-threaded programs it makes it a lot easier to have them all running asynchronously. Regards Pete

But the parameter there is the parameter there, it is the same for offset controls and all others. There aren't different tables internally, everything is the same, following the "WPARAM, LPARAM" Windows message method used for all FS controls and added FSUIPC controls. The FSUIPC offset controls encode the control and the offset into the 32-bit control number (WPARAM) and the parameter is still 32-bits (LPARAM). Changing to strings would mean allocating memory, passing a pointer in the messages, and subsequently freeing memory, all in such a way that there are no leaks and no access violations, between multiple threads all operating asynchronously. It would be an upheaval and a lot of work, and could add so many difficult-to-find bugs that I'd not be able to release it for months. Sorry, but as I said, there is no way I can undertake such changes at this end stage of FSUIPC development. Regards Pete

Think about it. They have to be. The choice in the assignment is only possible with the mode currently selected. If you changed modes with an assignment altready made I'd have to delete that assignment, and then folks would be complaining that they lost assignments without meaning to just because they clicked a radio button. The "greying out" in almost all Windows programs is to prevent silly or impossible combinations. That's all. And the User Guide does actually tell you: To change between the three methods you will have to de-assign the axis controls first. Do this by removing the check mark to the left of each assignment. Incidentally, it has been this way in FSUIPC now for 12 years, with yours the first ever complaint! What was the problem? There's no secret. You assign to separate throttles (in FSX -- or if you have good reason, in FSUIPC) then, in the 4-throttles tab in Calibrations you calibrate minimum (=max reverse) to idle, a small central idle zone, then max for full thrust. Everything is labelled and the instructions have been clear enough for most folks for many years. In fact unless you deliberately select "No Reverse Zone" (the option for those using a button for reverse), you cannot avoid having a reverse zone with those calibrations. All you need to do is position your idle zone where it suits. You are not. But then a "newbie" isn't really expected to be doing things like assigning axes in FSUIPC. Why are you doing it in any case? That facility was originally added for those needing different assignments for different aircraft and wanting them changing automatically. Of course anyone can use any of the facilities in FSUIPC if they wish. They should surely have some idea WHY they are doing so, though, don't you think? Just like any toolkit. But it is NOT! It lists ALL functions present in whatever version of FS you are using. You are completely misunderstanding what FSUIPC does! It exposes all of the innards of FS for you to take advantage of. It gets the complete list of all the controls FS itself contains -- these are in the part of FS called "CONTROLS.DLL". they are NOT listed by FSUIPC but by FS. FSUIPC has no place excluding some and including others. some do some things some do others. some are misnamed or misspelt. Some don't work. There's no way i can document the hundreds of FS controls. I don't even know what many of them do myself! Which ones are deprecated? None by me, for sure. Who's to say what should or should not be used? Some work better with some aircraft, others are essential for others. Pete

You can certainly write strings to offsets, via the Lua ipc library or via the normal FSUIPC application interface. Regards Pete

No, that is most certainly not true. I never run FS9 or FSX "as administrator" and I don't advise anyone else to do so either. What makes you think this is so in the first place? Perhaps you should describe the problem you have rather than assume a cause, incorrectly in this case. Regards Pete

Sorry, I don't understand what you are asking. Why would you add any such entries in the name of the AlsoSave file if you don't want the values they stand for? So just don't use any of the facilities? I don't understand why you'd even ask. No one is forcing you to type %D or whatever into the filename. You choose whatever name you want. If you want it to include the aircraft name, so you have one saved per aircraft, use %A, if you want it to include the day of the week so you have a maximum of seven, use %W. If you only ever want one file, don't use any of those. And so on. Isn't that obvious? Is it really so badly described? Doesn't the word "optional" come across? :-( Pete

No way. Sorry. It would be almost a complete rewrite. Pete

So, why not try 10 secs or 20? That sounds like gusts and variance. Are you sure you've disabled those? You can do that both in FSUIPC and in ASX. Since I've never heard of the symptoms you get -- no one else has ever reported having them -- I can't really advise. I think you should perhaps seek advise from other ASX users., over in that forum. Regards Pete

Why not? You can accumulate up to 30 kbytes worth of requests for any one Process call. I've never heard of any application even coming close to that. There's only 65k bytes worth of data available, maximum, in any case, and a lot isn't used yet. No. I means that you should request all the data you want in one regular Process call. It doesn't matter where or how many or how often you do FSUIPC_Read and FSUIPC_Write calls. It's only the Process call which is switching control from your program to FS and back. Doing that for every little bit of individual data is insanely inefficient. Regards Pete

Well, there's no specific restriction in my code over where the connection comes from. So you could try. How you'd do it I'm not sure. If they are on the same network then what's likely to be the problem? Sorry, that confuses me somewhat. There's only the ip address! You'd need to make sure the port used wasn't being blocked (8002 by default). You don't need 9002 as well, that's just for the Server to broadcast its presence, and that certainly doesn't work even outside a local WorkGroup let alone over the Internet. Regards Pete

Okay. Go get FSUIPC 4.711 from the Download Links subforum. Regards Pete

You purchased a license for FSUIPC3. That covers you for ALL FSUIPC3 versions, forever. You'd only need to purchase again if you changed to FSX and therefore needed FSUIPC4. I prefer all users to keep up to date in any case, as I cannot support old versions! Regards Pete

Hmm. Odd, you'd think it would show up as what it is -- a joystick type device -- like any other yoke. Why not try the GoFlight software which must have come with it first? You'd have to pay for a user registration to use the FSUIPC facilities. Seems odd to do that before first seeing if it works okay for you without. There's no reason i know of that it won't work perfectly, out of the box, with their software. Regards Pete