Pete Dowson

I've got one other report of this (making two only out of many thousands of registrations over the three years). I'd like to know if there's anything in common between your two machines, so I'm emailing you. Regards, Pete

It has not really been decided yet, but certainly the registration would need renewing (i.e. you'd need a new key). What sort of discounting there will be for recent subscribers needs to be worked out. A lot really depends how much work the new version turns out to be -- I wouldn't feel right charging folks again if I didn't have to do any work to make it happen, but equally I wouldn't want to have to work all hours for months, as I did last time, for no income. I expect some compromise will be decided upon which makes it fair to recent purchasers, but again I have no idea what "recent" would mean yet. And is FSX coming out as late as December or as early as September? You see, there are too many imponderables at present for me to help you decide. All I can say is that I'd certainly want things to be fair, in whatever circumstances exist by then. Regards Pete

Hmmm. Very strange. The registration window is just another standard windows dialogue. It sounds like it may either be a bug in the video driver you are using, or possibly a hardware problem such as faulty memory. Otherwise possibly something else, like "window blinds" is somehow interfering with the standard dialogue process. Are you running anything at the same time as FS? Do you have anything installed which changes Windows behaviour in any way? Sorry, I don't know what to suggest at present. See if you can find a different (more up to date perhaps?) video driver first. If you cannot find anything which clears this up, please get back to me and I'll see if I can add some extra code to give more information about what is happening. There's been no change in this area for three years, and, as I say, it is a standard Windows call to display the dialogue, so it is very puzzling. Regards, Pete

As I said, it's in the FSUIPC SDK. All information about programming ands interfacing to FSUIPC is in the SDK. That's what it is for. and it is on the Schiratti site, as it always has been, with all my other FS programs. Regards, Pete

With some space in FSUIPC offsets, you could simply assign a bit for each function and let your users assign buttons or keys to Set, Clear or Toggle the appropriate offset bits. You'd need to work out how may bits you needed (but I don't allocate less than 16 bytes at a time anyway, so that's 128 functions already) and ask me (petedowson@btconnect.com) for an offset allocation. Then explain to your users how to program Offset (Byte Word or Dword) Togglebits in the FSUIPC Keys or Buttons page. (See FSUIPC Advanced Users guide). I reaise this may look a little confusing but I feel it is far less so than assigning different FS controls with misleading names. Regards Pete

As well as what Patrick says, if it's an offset you need to change rather than a button or key to program, look at offset 2DC6. A simple search through the Programmer's guide (from the FSUIPC SDK) on the word "governor" would have found it straight away -- that's all I did. ;-) Regards, Pete

Not in any way I know, I'm afraid. Except maybe by reading the FS9.CFG file yourself? Unfortunately, for standard assignments for joysticks I think it leaves that in the default Devices CFG files. Of course, those are part of the FSUIPC Hot Button facilities (there are Hot Key facilities too). All this stuff is documented in the Programmer's Guide for FSUIPC, which is the prime reference document in the SDK. Surely you've seen it??? :-( Please don't rely on notes and comments in FSInterrogate files as the main reference. It isn't complete, it is abbreviated beyond recognition in places, and it certainly isn't guaranteed to be maintained nor accurate, though I do try hard. On the other hand the Programmer's documentation is meticulously maintained. Regards, Pete

Hmmm, an FSUIPC registration would help there then. I didn't realise you hadn't even bought FSUIPC! :-( Pete

No, I mean do one (1) process call for ALL the reads you want to do this cycle, not just arbitrarily bach them still with multiple calls to FS for no good reason. would you take separate trips to the supermarket to get three different things if you knew you wanted them all before you went the first time? You only need to separate them if you need the results of one read to decide what else to read, or to decide upon something to write. But that's a VB error, and the VB compiler or debugger will tell you precisely what is wrong, surely? That is why you use such a terrible language (my opinion, of course), isn't it? Because it is supposed to be easy? Surely it doesn't give obscure compile or runtime errors with no explanation? Sorry, but I cannot help with VB. Try me on C. Maybe someone else will help, but if VB never tells you where it failed I don't see how you can use it in the first place. :-( Regards, Pete

Sorry, I don't know about the mismatch (doesn't the compiler or debugger even tell you which line or variable has such a mismatch?), but your code is really enormously inefficient! Why are you calling FS for each little item of data separately? Please do all the FSUIPC_Reads, then one FSUIPC_Process at the end. The reads and writes cost nothing in PC terms, but every process call is swapping to Flight Sim, processing your requests, then swapping back to you. That's really dreadful! :-( The whole point of separating the actual request to FS from all the individual items is to enable you to write efficient programs. Think of the Reads and Writes being your shopping list, with the Process call being the check-out. Pete

I get that on some projects. Never found out why, and doing as it says ("NODEFAULTLIB") seems to make things worse. The warning doesn't seem to affect anything adversely so I learned to ignore it. Since I upgraded to Visual Studio .NET 2005 it doesn't happen any more, but that's an expensive solution if, like me, you want/need the Pro version because of the superior optimisations. In fact, considering I only use the C/C++ Native code part, and of course the Debugger, the whole package is ridiculously expensive, but you can't get the good optimising compiler on its own any more. :-( Regards, Pete

Please do make sure your users know, else they will just come here to complain! ;-) Regards, Pete

Sorry, I have no idea. Not having any CH gear nor, of course, the CH manager, I am not in a position to judge whether it does anything better or not. If no one else chips in with advice or experiences maybe you should visit Bob "Sticky" Church's place, http://www.ch-hangar.com. Regards, Pete

Hmm. I found this in one of the Microsoft headers: /* * VK_L* & VK_R* - left and right Alt, Ctrl and Shift virtual keys. * Used only as parameters to GetAsyncKeyState() and GetKeyState(). * No other API or message will distinguish left and right keys in this way. */ #define VK_LSHIFT 0xA0 #define VK_RSHIFT 0xA1 #define VK_LCONTROL 0xA2 #define VK_RCONTROL 0xA3 #define VK_LMENU 0xA4 #define VK_RMENU 0xA5 which would make Left Control 162 in decimal. You could try that, but I cannot guarantee it as it seems to imply that the API I'm using won't support it. It may just work if it passes through the values I give it unmolested. Otherwise, is it not possible to change the program's assignment? Regards, Pete

Erthat certainly sounds very unlikely. Are you really saying that you changed the DEFAULT flight to use these different aircraft and restarted FS each time, and it failed at the start each time? If so then it is more likely to be a DLL you have added in the Modules folder. Very few aircraft gauges use FSUIPC -- except in the very sophisticated add-ons. The main type of FSUIPC-using gauge folks add on to the default aircraft are TCAS ones (which should be easy to identify) and, possibly, pushback or fuel control ones. But certainly you would have had to add these yourself to the default aircraft. It sounds like either you are not changing the default flight -- the one loaded BEFORE you even get to the main menu selection where you can choose another -- or, in fact, you have some add-on DLL which is the culprit. Pete

FSUIPC always logs details of flights and aircraft loaded. This part shows the problem: The aircraft you have specified in your default flight is using a Gauge which is using FSUIPC completely wrongly. It is using an incorrect access method, which can occasionally work (by fluke) but is inherently dangerous. The only way to reliably use such a bad gauge is to register FSUIPC as a user (i.e. pay for it), as that allows FSUIPC to bypass these access checks. However, that may not prevent later problems. If you ever have two such bad gauges, or a module doing the same sort of thing, then they will be exchanging data with FSUIPC using the same memory area and they will corrupt each other causing unpredictable results. Even if this gauge is a freeware one it is not possible for it to use an access key as it is using an illegal access method. Furthermore, it is impossible for me to tell you which gauge it is as the access method makes it look like it is FS9 itself. Your best bet is to run FS past that point and change to a different aircraft, then save a new default flight. Then find the culprit aircraft, and its PANEL.CFG file, and see which gauge it may be that is using FSUIPC so wrongly. Edit the panel.CFG to get rid of it. You may have to do this first if you can't get FS past it (because the gauge in question crashes FS, perhaps -- though it doesn't look as if it does). A more drastic alternative is to delete your FS9.CFG file and let FS build a new one, so it uses its default flights. Regards, Pete

If you are getting the same error, then you most certainly have not installed version 3.65. Please simply copy the new DLL into the FS modules folder. There's nothing else needed to be done! I don't need a log for that error. All you need to do is change to version 3.65. I cannot support old versions in any case. I'm not sure what the relevance of that is. Are you saying it was okay before you did that? Sounds like either that installed an old version again or it was a bad aircraft in any case -- but if so it wouldn't be an FSUIPC error you were getting. Pete

Why not just show me here? It's only a simplw text file. If you keep the FS session short it will be a short log in any case! Haven't you looked at it yourself? It might be obvious what the problem is. Pete

If the standard command doesn't work, then the A310 code is continuously sending commands to disable it. I can't do anything about that. Why not simply also assign your yoke aileron axis to the rudder in FSUIPC's Axis Assignments, and calibrate it in FSUIPC joystick calibrations. Then it will act as aileron via FS and rudder via FSUIPC. You'd need to experiment with the calibration to get the coordination correct (for flying), but it will be fine for steering on the ground. Regards, Pete

Sorry, that was an error in an earlier version. Please just download the current supported version (3.65) from http://www.schiratti.com/dowson and you'll be okay. Pete

Sorry, I am not involved in that process. Please see the sticky thread near the top somehow obscurely entitled "READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys" Regards, Pete

Not negative. It's just that you are asking for something I don't know how to provide without spending many many hours trying to look for something I don't really understand, in parts of FS I've never been before. And, on top of this, it is after three years of FS2004 when I really have to look forward to FSX instead. I've been "tidying up" all my modules over a period, ready, and hope to issue to another FSUIPC and WideFS update by the end of this week, hopefully the last before FSX. No, I'm not upset at all. I don't know how you read that. I am only saying if you or someone you know can tell me how to do it, I'll do it, but otherwise I'm afraid is isn't going to happen. Possibly someone has, but if so they've presumably kept it to themselves. There are a lot of commercial add-ons which do some very clever things (Aerosoft being one, RealityXP another), but they keep the things they've discovered secret for obvious commercial reasons. Sorry. If any reader here knows about these things and is willing to divulge details, please come forward. Regards, Pete

So you have the correct Token Variable name for it? If it is as you say then it should be easy enough for someone to write a Gauge to control it. By "area" I mean "graphics" as opposed to, say, aircraft position or engine data or weather and so on. See, you know much more about that stuff than I do. If you can locate the information you need to read (and write?) I'll be glad to map it to an FSUIPC offset for you, but it will need someone who understands that subject (I used area before and you misunderstood me) to go find it and know how to use it. This is how many things have been built in FSUIPC. I have spent many thousands of hours hacking and tracing through disassembled parts of FS to find things, but always things I would be able to recognise if I saw them. Other folks have contributed for other areas, and so the edifice has been built, over time. If it is so easy, please go ahead and let me know. Thanks! Regards, Pete

It means your FSUIPC is not user registered and you are trying to run one or more programs, gauges or modules which are trying to use FSUIPC but which have no access permission. If you look in the FSUIPC LOG file, which you will find in the FS Modules folder, it will contain more details of the problem. If you want any further help identifying the culprit(s) just show me that. Regards, Pete

No, not with FSUIPC which is intricately tied into FS. Please apply to Project Magenta support, who I think will have the answer (but it may not come cheaply!). You'd need to do some programming in any case. Regards, Pete