Pete Dowson

Thanks for the suggestion. The brake problem appears to only occur if you have calibrated the separate Throttle 1 in FSUIPC's Joysticks section. I have now found the error -- a silly typo -- and fixed it. It will be okay in the next release, but if you want an interim update with it fixed, let me know. I cannot attach it here I'm afraid, it just exceeds the limit of file sizes in the Forum. Regards, Pete

Ah, but WidevieW isn't mine either! It's by Luciano Napolitano. See http://www.wideview.it/index.htm. :wink: Regards, Pete

Please check things out with FSInterrogate. You'll find it in the FSUIPC SDK. It is provided so folks can cross-check their own programming. Also use the FSUIPC IPC logging -- just checking the Log for your Reads will show what is actually being supplied to your program. Then you will know how to look. BTW FSInterrogate was written in Delphi. FSUIPC can do that for you, whether you are doing it from a Module or an external program. Check the section in the Programmer's Guide entitled "MODULES MENU access for Applications". There are step by step instructions there. You shouldn't need anyone else to actually code it for you, it's that detailed it's almost code already. :wink: Regards, Pete

Good. thanks for letting me know. Regards, Pete

Not my subject, sorry. Maybe someone here may know, but it seems more a general programming question. Perhaps something in http://www.gamedev.net/reference/programming may help? Regards, Pete

FSUIPC doesn't feed anyone anything. It provides an interface that a program can use to get such information, but the programs have to actively ask for it. There are not only pitch bank and heading values but also velocities and accelerations in all six axes. For a motion platform I would have thought it was the accelerations you'd be interested in more than actual positions. Download the FSUIPC SDK (from http://www.schiratti.com/dowson) and browse the information therein. That's the best way for you to determine answers to such questions. Regards, Pete

Not here at all, you are in the wrong place! Try http://www.wideview.it/index.htm Regards, Pete

With DLL 3.45 you mean :wink: Okay. The other person who reported this found the same a while ago and tried disabling each Joystick calibration in turn. It seems that the problem occurs if you calibrate the separate throttle 1 setting, nothing else. This was a good clue which helped me locate a typo in the code. I sent him a version to try, but I don't expect I'll hear back from him till tomorrow (we are both in the UK and it is getting late). So I'm emailing you a copy to try too. Please let me know. You are now mixing up INI and DLL files. You said you installed 2 DLLs, not INIs. :) Anyway, let me know how you get on with the update and your original INI. Regards, Pete Regards, Pete

I don't know Delphi, but don't you think it might be a little dangerous to read two bytes into space for only one? You will surely be corrupting something! For 2 bytes you need something bigger than a Byte. I don't know what they are called in Delphi, but in C they would be "short" or "unsigned short" or "WORD". Pete

Sorry, I am nothing to do with FSNavigator. You are in the wrong place. Doesn't the author have his own support arrangements? BTW please turn off your CAPS lock. Regards, Pete

Both FSUIPC.DLL files??? There is only ever ONE FSUIPC.DLL. In any case you cannot have two files with the same name in the same folder in any case! What is this other one you are moving? If you cannot find the INI file and so remove it (you'll be the first ever!!), then the only way to do this will be to go to each of the Buttons, Keys and Joystick pages in FSUIPC options and write down every single setting you have made, so we can try eliminating them one by one. It will be much quicker with the INI file, believe me!!! Pete

I think there's an option in the FS CFG file for that. Check out the FS2004 FAQ -- I think there's a link in the FS2004 Forum. There's a parameter something like "pan in cockpit mode". Why are you using FSUIPC for this? Have you tried the normal hat settings in FS itself? I think they are designed to do panning. FSUIPC breaks a hat into 4 or 8 buttons. I'm sure that wouldn't be what you'd want for panning. I actually hate the panning in 2D cockpit mode, because it gets disorienting with the scenery shifting outside which the cockpit and aircraft standing still, so the first thing I try to do is turn panning off -- or rather I used to when I had something with a hat. I'm pretty sure the default settings for a hat give panning, so you've presumably changed something. Regards, Pete

I need more information. That's very weird. It's rock solid here and is basically the 6.447 release tidued up and which has been running well on msany systems for a while. I'll re-enable the error trapping and email you a test version of WideClient to run, please. I'll include some instructions for Logging too. You'll need to Zip up the log and send it by email attachment. Regards, Pete

Oh, one other thing. as well as checking FSUIPC will all defaults (i.e. remove your INI file), can you see if a work-around will work. Go the FSUIPC's Buttons page and program the button for the "Brakes" control there? Please advise. Regards, Pete

Well, the actual EXE code, by the time it is running in the process, is the same in the end -- this is how the crackers crack it. The huge size of the CD checking version is down to all the protection that is added -- not only CD verfication, but complex anti-hacking scrambling, and also code to spawn another process entirely, with a weird name, whose sole job seems to be to watch for debuggers. But this is really mostly irrelevant in this case, as the sizing and moving business is done though windows message intercepts. That's why is seemed strange to me. Regards, Pete

The default buttons don't affect joystick assignments at all. I think it must be related to something either in the button programming or, more likely, joystick calibrations pages. This is why I asked you to try it with NO FSUIPC.INI file (save your copy), so that FSUIPC starts off with no preprogrammed anything. If that makes the brakes work, then we look at the various things you have set in the Buttons and Joysticks pages. Okay? I am poring throgh the code now, but it would help enormously if we could narrow it down like this. Thanks, Pete

I have had one other such report, but I cannot reproduce it here, and I have not made any change which I know of which can cause this. Basically it doesn't care at all about the ordinary Brakes control. The new facilities in the "Fix control acceleration" option are identical for both keyboard and joystick controls and in any case don't do anything unless enabled. Since I cannot reproduce it, I am stuck in an information collecting mode at present on this. Can you tell me more. Like all default aircraft? Anything programmed in FSUIPC? Can you make a safe copy of your FSUIPC.INI file and delete it from the FS Modules folder, so that FSUIPC runs with defaults only? Is it user registered or not? Anything else which may be relevant that you can think of? Can you turn FF off in FS? Does that make any difference? Regards, Pete

Of course that is the reason. The only way it has of identifying the internal caller is by tracing the return address on the stack, looking for an address within a loaded GAU or DLL file. This is why, in the full log you saw, it gets all the addresses of all the modules loaded. Then it backtracks the stack till it finds an address corresponding to a listed Gauge or Module. That is how it identifies gauges and DLLs from internal calls, except for those programs which use the automatic registration systems supported (as this one certainly does not). Now on both my WinXP installation and my Win98SE installation, this process works well with the F16 gauge, the exact one I attached earlier. But on your system the stack is completely and hopelessly indecipherable. If finds no modules or gauges and cannot therefore identify the caller. Did you check out the Lee Hetherington TCAS gauge? Regards, Pete

Hmmm. Very strange. Thanks for letting me know. Regards, Pete

If you've lost it completely, please see the sticky thread above entitled READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys. If your registered install is still registered and working then the data is in the FSUIPC.KEY file. It is a text file. Regards, Pete

Sorry, I get no such result here. where are you seeing this? Check with FSInterrogate, or using the FSUIPC Monitor (on the logging page). By "disconnect"/"reconnect", do you simply mean FSUIPC_Close and FSUIPC_Open? Are you doing this from an EXE program? Pr a gauge or module? There is absolutely no way that influences the data being read or written. For an EXE program it merely closes a memory-mapped file and creates a new one. FSUIPC knows nothing much about that. In the case of an internal gauge or module, the Close does nothing but clear a pointer value (set from your data pointer in the Open2 call) which causes Reads and Writes to fail till you Open2 again. Please do some cross-checking, and some logging perhaps (FSUIPC does provide IPC read and write logging you know). If you still don't understand, please provide more information. Regards, Pete

Great! All's well thatwell, you know the line. :) Regards, Pete

Well FSUI is the Microsoft standard User Interface DLL. From your logs and all the other stuff, though, it certainly seems that FSUIPC is working well with FS2004 on your system. I just have no idea why that gauge isn't working. Sorry. Did you look to see if the Lee Hetherington one will work for you? I suspect there's something else installed on your system, a non-standard or different library someplace maybe, which makes that Gauge run rather differently. Your log shows no trace of it on the stack when it calls FSUIPC. Possibly it is calling it from a different thread than the main FS one, but this is unlikely and in any case it would be a problem then here too. Regards, Pete

No, they are wrong. I merely advised programmers that they could do it themselves. The electrical system is exposed in the FSUIPC interface. It doesn't take a genius to work out how to stop the battery voltage falling too far, just a reasonably competent programmer. Sorry, for users this option is just one of the many benefits of purchasing FSUIPC. I add more all the time, but I cannot really erode these. In any case it wouldn't be fair to those who purchased it already. Regards, Pete

Erthose two statements are not compatible. Show me this "normal" WideClient log please. You say "after like 2 mins", but in fact WideServer was only active for 84 seconds. Are you sure you gave PM enough time to initialise itself before closing FS down as you did? I find that the PFD in particular takes at least that long before it is in real interaction with FS in any case. When you say "crashed and shutted down", which do you actually mean? What sort of crash? How was it visible as a crash? How did it shut down then? I need to get a full picture. Have you changed any of the WideClient or WideServer INI file parameters, apart from the ServerName or IPAddr in the client? The changes in this version actually enable PM modules to connect more rapidly and reliably, so something seems very strange with you seeing the very opposite. Regards, Pete