Pete Dowson

It's just a misprint in the document. I'll fix it next time. All that group are for ADF2, as looks prertty obvious. The ADF1 switch is at 3107. Did you not search? Chester is only about 30 miles or so, less than an hour. My wife goes there shopping sometimes! :wink: Regards Pete

As I said, it actually Dowson, but please call me Pete. There are only the possibilities I listed above. Did you check each one? Regards, Pete

Ah, I see. It is actually the same as what it was supposed to do, ever since it was first implemented. The bug wasn't actually intended ( :roll:), and, oddly, wasn't even reported to me for the life of FS2000 and FS2002 put together! I actually fixed it within a few days of it being reported! I assume folks just assumed it was supposed to be like that. :? For most of that time the only proportional brakes I had were linked to my GA28R cockpit device and driven, correctly, by the Aerosoft driver that came with it. When I eventually got some PFC pedals with proportional brakes I was driving them via my PFC.DLL driver, again which worked okay. So my only source of information about behaviour with, for example, the CH USB pedals, was (and still is) by reports, though once receiving one I could reproduce this by assigning other axes, on an ordinary joystick, to brakes. That's how I tested the fix. Regards, Pete

It's "Dowson" actually, but call me Pete. There are three possible ways this can occur: 1. There are indeed duplicate versions, possibly with different names. Renaming FSUIPC to something else will not necessarily stop it being loaded by FS. If it still looks like a DLL it will load and run. 2. There's a copy of FSUIPC, by its own or another name, in the main FS folder. Not so long ago it was found that FS will sometimes actually try to load modules there as well in the Modules folder. 3. There is still an FS session running, without a Window. That happens when you thought you closed FS down and it appeared to, but something (usually one add-on -- an earlier version of Active Camera, for instance, did this) actually refuses to close, so Windows cannot remove the process. Check for this by using Ctrl-Alt-Del and looking at the list of Processes. There's really nothing else at all which I know of which can give the symptoms you mention. It has to be one of those three I think. Regards, Pete

Sorry, but with so little information to go on I really have no idea. I have heard of cases where assorted other processes installed and running in Windows (especially XP) can create strange effects in FS + Add-ons, but your original description didn't sound like one I'd heard of before. It only sounded like a Key problem. Regards, Pete

Assuming your pedals are analogue axes not just on/off switches, then what you describe was certainly a long-standing bug -- it was fixed in 3.201 as descibed in this paragraph of the History document: Regards, Pete

Ah, no. I never knew thatprobably because I've never really used those new axis controls. Does seem a little odd -- but, then, the button actions operate like my implementation. Of course, they would, really, because that's what I copied way back in FS2000, imitating the effect C00 and C01 had on FS98 (those were the Global offsets changed by F11/F12). I don't think the FS2002/FS2004 AXIS controls for brakes have the slower pressure release. Regards, Pete

All those values are listed with offsets in the Programmer's Guide. Have you checked? Which are you having difficulties with? Please, for such questions, just first check the Programmer's documentation in the SDK. Also, try using FSInterrogate which will display all these things for you. Regards, Pete

The only important thing happening when you minimise FS is that the true frame rate is reduced (not necessarily the one FS reports in 0274, though that does indeed go a bit screwy). Since FSUIPC is working in some amount of synchronicity to the frame rate, this reduces the freqeuncy of updates FSUIPC is supplying. However, that said, the Sim Rate at offset 0C1A most certainly stays reading the same value when FS is minimised. I don't know where you are reading the "seconds" value, but the clock seconds value is contained in a byte, so cannot be as big as you say. The double floating point value at offset 0310 is certainly still counting up correctly when FS is minimsed. Please check things using FSInterrogate, as I have just done -- that is why it is supplied! You don't need to trust your program, you can cross-check it easily. Regards, Pete

Unfortunately the amount of changes between the versions you are using and the latest ones does rather make it a waste of time trying to work out what is going on in your system. Looking at the WideServer log there are obviously problems with "Remus" which is blocking many attempts by the server to send things. Unfortunately the client logs you included do not correspond time-wise with the problems shown on the server, and so are totally unhelpful. It looks like to reloaded the clients and didn't bother to preserve the Logs showing the problems, only logs showing everything very good. Please use the latest versions before asking for any diagnosis. This always applies. It would be a waste of both our times trying anything on programs that have changed so much. Regards, Pete

What .cpp file is that then? I only know the .c one. I don't use C++ at all. Regards, Pete

Nice story! :) Thanks. Pete

Yes, local time changing is just like moving the hands on the clock in your house. It will read differently, but outside the day is the same. You have to change the Zulu time. It seems that FS has always been messed up in this area. It gets local and Zulu time and day and night mixed up quite easily. You always need to set all parts -- local time and Zulu time -- to get a change. This is one of the reasons why programs like FS Real Time are so popular, helping to sort the time out. They manage it quite well. Regards, Pete

Actually, I just read it again, and it isn't! There's some nonsense in it! Sorry. IF the brakes are calibrated in FSUIPC, then those controls are not getting through at all -- FSUIPC will be absorbing them in the process of making its own braking. This is okay, and what I said holds true, IF and only if the gauge event intercept occurs BEFORE the WM_COMMAND posting, which I think is highly unlikely. Basically, I suspect that with FSUIPC doing the braking you cannot do what you need to do via gauge even intercepts, only by WM_COMMAND intercepts like FSUIPC. But then the problem arises about who sees it first. Actually, if your code is in a gauge you will hook the FS window after FSUIPC so you will see the WM_COMMANDs first. But if this is in XML I don't suppose you'll be doing that sort of stuff? I think, in the end, your best bet would be to do what you say and tell the user not to calibrate brakes in FSUIPC at all. Regards, Pete

The former. FSUIPC has always performed proportional braking its own way -- this dates from FS2000 where there were no proportional braking facilities in FS. And I prefer the slower release of pressure my algorithm gives. Seems more realistic. :wink: It takes either 65721 (BRAKES_RIGHT) or 66388 (AXIS_BRAKE_RIGHT_SET) for right brakes, and either 65720 (BRAKES_LEFT) or 66387 (AXIS_BRAKE_LEFT_SET) for left brakes. But it also takes 65588 (BRAKES) as both brakes and operates them together, so you could simply convert the 66387 input into 65588 and leave the rest to FSUIPC. That's probably what I would do. This isn't possible if you are using the gauge event interception, though, as it doesn't seem to allow changes, so your method would then be best. But I'm not sure at present if that interception occurs AFTER the control has been through the WM_COMMAND message process or before -- it would make a difference because you'd not want the right brake copy altered by FSUIPC calibration twice. You could calibrate only left, though, and leave the right, or both, so I suppose it is solvable. Experimentation would show the best way. The axis logging facilities in FSUIPC may help too -- they occur not in the WM_COMMAND stage but the gauge interception. Regards, Pete

The ordinary "brakes" control (BRAKES) would do that -- operating left and right brakes simultaneously, but unfortunately it isn't recognised by FS2004 as an axis control, only a button control (it's the '.' key). So the only way would mean a change to FSUIPC to allow a nominated axis, such as AXIS_BRAKE_LEFT to operate both left and right -- in the same way as I already map Throttle 1, and so on, to other engine throttles. This isn't difficult to do, but unfortunately you ask at a bad time. Just last week I managed to finish up a number of important changes and get FSUIPC 3.47 out. I now have less than a week to tidy up some other things before my wife and I go on holiday. I may be able to look at this in April if you've not found another solution by then. Ask Bob Church if he knows of a ready-made solution already available (http://www.stickworks.com). Otherwise, get back to me, say mid-April, please. Regards, Pete

I must admit I hadn't thought of that one. At least you can pronounce it, just. :D Pete

Well, I can see the trouble there being when you get to version B and so on. They'll all be different products that way. You'd need a name separate from the version. But I'm afraid that I am exactly the wrong person to advise on names. Look at my terrible examples: FSUIPC (derived from the earlier FS6IPC by having a "U" for "Universal" instead of a version number), and WideFS, just because the original was piggy-backed onto WidevieW! And the confusion that has caused over the years :? Best regards Pete

Sorry. No need to shout at me. :cry: Seems you really need to discuss this with Dave, then, not I? I'm sure he will be able to sort it out, perhaps with some logging. Regards, Pete

In that case it is probably only possible through offset 3110, where you can send any FS control and most of the add-on FSUIPC ones too. Well you can send FS keypresses via offset 3200, but I really wouldn't recommend that when all FS keypresses are re-assignable (i.e. 'S' may not be assigned that way), and they are all available as controls in any case. There's a complete list of FS2004 controls included in the FSUIPC.ZIP. You need the numeric equivalent. I think 'S' is normally assigned to "VIEW_MODE". You can find out via the FS CFG file -- assignments are in the [KEYBOARD_MAIN] section. Regards, Pete

There's probably something wrong with the user Key, then. The checking of user keys was tightened up some time ago. So far, all the cases where a program has worked with FSUIPC non-user registered but not registered have turned out to be due to bad user keys. I can check yours here. Rather than send me the log, please just Zip up your normal FSUIPC.KEY file and send it to me at petedowson@btconnect.com. Regards, Pete

Thanks for the clarification Dave! Seems that some folks are still using very old versions! Best regards, Pete

By "the box" I assume you mean the FSUIPC options dialogue, via the Modules-FSUIPC menu item? That is a standard Windows dialogue, handled entirely by standard Windows libraries, and the sizes are not set by my programming but by Windows. The only times I've known it to go wrong in the way you describe is when the two standard libraries needed for dialogues do not match. Mostly this seems to be due to drivers (usually video drivers) installing an older or incompatible version of COMCTL32.DLL. You will need to see if you can re-install the correct Windows version of that standard library. If installing more up to date (WinXP) video drivers doesn't accomplish this, then perhaps Katy Pluta over in the FS2004 Forum may be able to help. She is very knowledgeable about Windows and will undoubtedly be able to tell you how to proceed. Regards, Pete

I think Enrico said he was away from Wednesday, but I don't know if that means he won't be answering emails. He seems to answer them wherever he is, unlike me! (When I'm away I am totally disconnected! :wink: ). Regards, Pete

It's just that Enrico hasn't updated the words themselves for a couple of years or so. I'll drop him a line. Yes, that's it. It only happens once. Probably you didn't see it and it disappeared. I see this attempt is 1075 seconds into the FS session (18 minutes). It's a little out of date then. I released 3.47 last week. :wink: Regards Pete