aqui Posted August 4, 2003 Report Share Posted August 4, 2003 Hi! I'm a new FSUIPC 3.03 registered user. I've a problem using this new version. When I try to read at $132C memory location (NAV/GPS Switch), I read always the value that indicates the GPS is Active. If I write in that location, the setting is accepted by FS2002/FS2004, but if I retry to read it, it seems to be at GPS Active setting. The write operation is functional, but the read operation isn't. The second problem (tha major) is this: when I write on $800 (Autopilot Approach Hold) and on $7FC (Autopilot GlideSlope Hold) the command that enables APPR and GS, FS2002/FS2004 manage this operation on the right mode. But when I release these commands in FS2004 (FS2002 doesn't have problems), the command is not released by FS2004. Why? The last question is: when it will be released the new documentation of the SDK of FSUIPC? Regards Aqui :) Link to comment Share on other sites More sharing options...
Pete Dowson Posted August 4, 2003 Report Share Posted August 4, 2003 Right. I've managed to look at both these things now. On checking back I see that the mapping of offset 132C to the GPS/NAV switch was done just after 3.03 went out. It is fixed here and will be okay in 3.04, due soon. The second question is more difficult. It looks like FS2004 is interlocking the GS and Localiser switches. You seem to be able to set them separately, but they have to be cleared together, which is not so easy through the IPC interface because each of the locations invokes a different action. I'll try to work out a solution to this and incorporate it into version 3.04. Thanks for the feedback! As for the SDKhmm. I'll get to start on it soon I hope. Pete Link to comment Share on other sites More sharing options...
aqui Posted August 4, 2003 Author Report Share Posted August 4, 2003 Thank you for the responses! I have programmed in Delphi a little software that modifies the values of $0800 & $07FC. With FSUIPC 3.00 and FSUIPC 3.03, the WRITE operation take a bad effect: always assigns 1 to these variables. For example, if I write a 0, the value will be 1. This problem comes both with FS2002 and FS2004. I stay tuned here for FSUIPC upgrades. Thanx!!! Link to comment Share on other sites More sharing options...
Pete Dowson Posted August 4, 2003 Report Share Posted August 4, 2003 I have programmed in Delphi a little software that modifies the values of $0800 & $07FC. With FSUIPC 3.00 and FSUIPC 3.03, the WRITE operation take a bad effect: always assigns 1 to these variables. For example, if I write a 0, the value will be 1. This problem comes both with FS2002 and FS2004. Sorry, now you have me confused. All I will try to do is make it all operate exactly alike both on FS2002 and FS2004. If I don't do this there are lots of applications which will break. If you are saying that it works exactly as it does on FS2002 already, then that is how it should be, isn't it? I've not changed FS2002 behavior in FSUIPC 3. Please clarify. Make a list of all possibilities or state / read /write / result for both FS2002 and FS2004. Please verify all this with FSInterrogate -- I don't want to spend a lot of time on this if it is just a little problem in your program. Note that I don't think FS has a mode for GS without LOC. You han have LOC on its own, LOC + GS or LOC + B/C, but I don't think there's a mode with GS only. Perhaps that is what is confusing the issue? If you set GS or BC then LOC willl have to be 1 too I think. All FSUIPC is doing when you WRITE is send the appropriate controls to FS. When you read you are seeing the indicators as they are. FSUIPC offsets do not operate like memory, that is but an illusion. Okay? Please let me know what you find now, with this understanding ... Pete Link to comment Share on other sites More sharing options...
aqui Posted August 4, 2003 Author Report Share Posted August 4, 2003 Sorry for my bad english :oops: My little program is only a debugger that helps me to find the bug writing on $07FC and $ 0800. I've found the problem! The bug is this: when you write a value on $07FC or $0800, this value is changed always to 1. For example: if I want to disengage APPR, I write on $0800 and on $07FC a "0". The bug changes the "0" to "1", so I can't disable APPR because the "1" value enables the APPR! :o This bug is present from version 3.00 of FSUIPC and affects both FS2002 and FS2004. Excuse me for my english !!! Do you understand now? Aqui Link to comment Share on other sites More sharing options...
aqui Posted August 4, 2003 Author Report Share Posted August 4, 2003 The problem affects all programs! Link to comment Share on other sites More sharing options...
Pete Dowson Posted August 4, 2003 Report Share Posted August 4, 2003 My little program is only a debugger that helps me to find the bug writing on $07FC and $ 0800. I've found the problem! The bug is this: when you write a value on $07FC or $0800, this value is changed always to 1.For example: if I want to disengage APPR, I write on $0800 and on $07FC a "0". The bug changes the "0" to "1", so I can't disable APPR because the "1" value enables the APPR! :o This bug is present from version 3.00 of FSUIPC and affects both FS2002 and FS2004. I am sorry, this simply is not true. Please try it using FSInterrogate and prove it to yourself. It is working fine, and has done for a long time. I don't know what you have wrong in your program, but please re-check it more thoroughly. These offsets are written to by programs driving PFC and Aerosoft MCP devices, and probably many others, and they work now in FS2002 and FS2004 just as they have for several years. Please re-check. Do some tests with FSInterrogate. If you think there's some sort of incorrect interlocking going on, then fine, let's investigate. But merely stating that YOUR program gets these results without any substantiation and no cross-checking on your part does not help I'm afraid. If you like, please use the IPC read/write logging facilities in FSUIPC, and show my the part of the log which proves your point, or show me the part of your program and I'll try to see the error in it. Meanwhile I cannot hold up the release of FSUIPC 3.04, which does correct some genuine errors and omissions, any longer. Regards, Pete Link to comment Share on other sites More sharing options...
aqui Posted August 4, 2003 Author Report Share Posted August 4, 2003 My little debugger program is simple and it is fully functional on FSUIPC v.2.xx. There is a problem with new version of FSUIPC from v.3.00. Why my program is OK with older versions and with 3.00 not? Link to comment Share on other sites More sharing options...
Pete Dowson Posted August 4, 2003 Report Share Posted August 4, 2003 My little debugger program is simple and it is fully functional on FSUIPC v.2.xx. There is a problem with new version of FSUIPC from v.3.00. Why my program is OK with older versions and with 3.00 not? I have no idea, but I cannot help find out if you persist in not cross-checking things, and not even providing log files to show what you mean. All the tests I can do here show it is working the same. There is no change in any of the code in FSUIPC for FS2002 in the areas concerned with A/P in any case, and the conversion to the FS2004 A/P is working fine in all respects according to all my tests, and is confirmed by using FSInterrogate.. I am quite prepared to help, and most certainly to correct anything that is wrong, but if you take this attitude and refuse to go into any more details, or to do any cross checking, I'm sorry, but it just isn't going to get any further, now, is it? What else do you expect? Please be reasonable. Regards, Pete Link to comment Share on other sites More sharing options...
aqui Posted August 4, 2003 Author Report Share Posted August 4, 2003 The problem is both in FS2002 and FS2004!!! I have this problem using the new version 3.xx of FSUIPC. With older versions (2.xx) the bug wasn't present. This is the LOG. I press the APPR and I release with a simple program: ********* FSUIPC, Version 3.03 by Pete Dowson ********* User Name= User Addr= FSUIPC Key= WideFS Key="" WIDEFS not user registered, or expired ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E WeatherOptions(Orig)=40003605[40003605] InitDelay: 3 seconds 1109 System time = 02:08:08 Internal Debug Code 15 1109 G:\FS2004\ 1796 C:\Documents and Settings\Aqui\Documenti\Flight Simulator Files\default.flt 1812 AIRCRAFT\beech_king_air_350\Beech_King_Air_350.air 5968 System time = 02:08:13, FS2004 time = 02:08:09 (00:08Z) 6250 Advanced Weather Interface Enabled 6343 Monitor IPC:0800 (U32) = 0x0 6343 Monitor IPC:07FC (U32) = 0x0 12671 C:\Documents and Settings\Aqui\Documenti\Flight Simulator Files\UI generated flight.flt 14015 Clear All Weather requested: external weather discarded 40656 Client Application: "FS Custom Panel v" (Id=3788) 40656 F:\FS2002\FS Custom Panel v.1.8\FS Custom Panel v.1.8.exe 60640 READ0 0E8C, 2 bytes: CE 0E 60640 READ0 0BE0, 4 bytes: 00 00 00 00 60640 READ0 0BDC, 2 bytes: 00 00 60640 READ0 0BDE, 2 bytes: 00 00 61640 READ0 0BE0, 4 bytes: 00 00 00 00 61640 READ0 0BDC, 2 bytes: 00 00 61640 READ0 0BDE, 2 bytes: 00 00 62640 READ0 0BE0, 4 bytes: 00 00 00 00 62640 READ0 0BDC, 2 bytes: 00 00 62640 READ0 0BDE, 2 bytes: 00 00 63640 READ0 0BE0, 4 bytes: 00 00 00 00 63640 READ0 0BDC, 2 bytes: 00 00 63640 READ0 0BDE, 2 bytes: 00 00 64640 READ0 0BE0, 4 bytes: 00 00 00 00 64640 READ0 0BDC, 2 bytes: 00 00 64640 READ0 0BDE, 2 bytes: 00 00 64843 WeatherOptions set, now 40003605 (timer=0) 65656 READ0 0E8C, 2 bytes: DD 0E 65703 READ0 0BE0, 4 bytes: 00 00 00 00 65718 READ0 0BDC, 2 bytes: 00 00 65718 READ0 0BDE, 2 bytes: 00 00 66656 READ0 0BE0, 4 bytes: 00 00 00 00 66671 READ0 0BDC, 2 bytes: 00 00 66671 READ0 0BDE, 2 bytes: 00 00 67640 READ0 0BE0, 4 bytes: 00 00 00 00 67671 READ0 0BDC, 2 bytes: 00 00 67671 READ0 0BDE, 2 bytes: 00 00 68656 READ0 0BE0, 4 bytes: 00 00 00 00 68656 READ0 0BDC, 2 bytes: 00 00 68656 READ0 0BDE, 2 bytes: 00 00 68750 READ0 132C, 4 bytes: 02 00 00 00 68906 READ0 132C, 4 bytes: 02 00 00 00 69406 READ0 07BC, 4 bytes: 01 00 00 00 69437 READ0 07C0, 4 bytes: 01 00 00 00 69453 READ0 0800, 4 bytes: 00 00 00 00 69484 READ0 0804, 4 bytes: 00 00 00 00 69500 READ0 07C8, 4 bytes: 00 00 00 00 69531 READ0 07D0, 4 bytes: 00 00 00 00 69546 READ0 07C4, 4 bytes: 00 00 00 00 69656 READ0 0BE0, 4 bytes: 00 00 00 00 69671 READ0 0BDC, 2 bytes: 00 00 69671 READ0 0BDE, 2 bytes: 00 00 70640 READ0 0E8C, 2 bytes: EC 0E 70687 READ0 0BE0, 4 bytes: 00 00 00 00 70703 READ0 0BDC, 2 bytes: 00 00 70703 READ0 0BDE, 2 bytes: 00 00 71640 READ0 0BE0, 4 bytes: 00 00 00 00 71671 READ0 0BDC, 2 bytes: 00 00 71671 READ0 0BDE, 2 bytes: 00 00 72640 READ0 0BE0, 4 bytes: 00 00 00 00 72671 READ0 0BDC, 2 bytes: 00 00 72671 READ0 0BDE, 2 bytes: 00 00 72671 READ0 0264, 2 bytes: 00 00 72687 READ0 2EE0, 4 bytes: 00 00 00 00 72718 READ0 07BC, 4 bytes: 01 00 00 00 72734 WRITE0 0800, 4 bytes: 01 00 00 00 72750 Monitor IPC:0800 (U32) = 0x1 72859 WRITE0 07FC, 4 bytes: 01 00 00 00 72890 Monitor IPC:07FC (U32) = 0x1 73265 READ0 07C0, 4 bytes: 01 00 00 00 73281 READ0 07C4, 4 bytes: 00 00 00 00 73312 READ0 0804, 4 bytes: 00 00 00 00 73328 READ0 07C8, 4 bytes: 00 00 00 00 73640 READ0 0BE0, 4 bytes: 00 00 00 00 73671 READ0 0BDC, 2 bytes: 00 00 73671 READ0 0BDE, 2 bytes: 00 00 74656 READ0 0BE0, 4 bytes: 00 00 00 00 74671 READ0 0BDC, 2 bytes: 00 00 74671 READ0 0BDE, 2 bytes: 00 00 75640 READ0 0E8C, 2 bytes: ED 0E 75687 READ0 0BE0, 4 bytes: 00 00 00 00 75687 READ0 0BDC, 2 bytes: 00 00 75687 READ0 0BDE, 2 bytes: 00 00 76515 READ0 0264, 2 bytes: 00 00 76546 READ0 2EE0, 4 bytes: 00 00 00 00 76562 READ0 07BC, 4 bytes: 01 00 00 00 76593 WRITE0 0800, 4 bytes: 00 00 00 00 76640 READ0 0BE0, 4 bytes: 00 00 00 00 76656 READ0 0BDC, 2 bytes: 00 00 76656 READ0 0BDE, 2 bytes: 00 00 76703 WRITE0 07FC, 4 bytes: 00 00 00 00 77125 READ0 07C0, 4 bytes: 01 00 00 00 77140 READ0 07C4, 4 bytes: 00 00 00 00 77171 READ0 0804, 4 bytes: 00 00 00 00 77187 READ0 07C8, 4 bytes: 00 00 00 00 77640 READ0 0BE0, 4 bytes: 00 00 00 00 77656 READ0 0BDC, 2 bytes: 00 00 77656 READ0 0BDE, 2 bytes: 00 00 77859 READ0 07D0, 4 bytes: 00 00 00 00 77875 READ0 07F2, 2 bytes: 00 00 78656 READ0 0BE0, 4 bytes: 00 00 00 00 78671 READ0 0BDC, 2 bytes: 00 00 78671 READ0 0BDE, 2 bytes: 00 00 79640 READ0 0BE0, 4 bytes: 00 00 00 00 79656 READ0 0BDC, 2 bytes: 00 00 79656 READ0 0BDE, 2 bytes: 00 00 80656 READ0 0E8C, 2 bytes: EE 0E 80671 READ0 0BE0, 4 bytes: 00 00 00 00 80703 READ0 0BDC, 2 bytes: 00 00 80703 READ0 0BDE, 2 bytes: 00 00 82031 READ0 0BE0, 4 bytes: 00 00 00 00 82031 READ0 0BDC, 2 bytes: 00 00 82031 READ0 0BDE, 2 bytes: 00 00 82640 READ0 0BE0, 4 bytes: 00 00 00 00 82640 READ0 0BDC, 2 bytes: 00 00 82640 READ0 0BDE, 2 bytes: 00 00 82859 READ0 07D0, 4 bytes: 00 00 00 00 82859 READ0 07F2, 2 bytes: 00 00 83921 READ0 0BE0, 4 bytes: 00 00 00 00 83921 READ0 0BDC, 2 bytes: 00 00 83921 READ0 0BDE, 2 bytes: 00 00 84640 READ0 0BE0, 4 bytes: 00 00 00 00 84640 READ0 0BDC, 2 bytes: 00 00 84640 READ0 0BDE, 2 bytes: 00 00 85640 READ0 0E8C, 2 bytes: EE 0E 85640 READ0 0BE0, 4 bytes: 00 00 00 00 85640 READ0 0BDC, 2 bytes: 00 00 85640 READ0 0BDE, 2 bytes: 00 00 86640 READ0 0BE0, 4 bytes: 00 00 00 00 86640 READ0 0BDC, 2 bytes: 00 00 86640 READ0 0BDE, 2 bytes: 00 00 When I release the APPR, Monitor not indicates that!!! Link to comment Share on other sites More sharing options...
Pete Dowson Posted August 5, 2003 Report Share Posted August 5, 2003 This is the LOG Ahwe come full circle! If you just strip out the relevant parts of your log: 6343 Monitor IPC:0800 (U32) = 0x0 6343 Monitor IPC:07FC (U32) = 0x0 72734 WRITE0 0800, 4 bytes: 01 00 00 00 72750 Monitor IPC:0800 (U32) = 0x1 72859 WRITE0 07FC, 4 bytes: 01 00 00 00 72890 Monitor IPC:07FC (U32) = 0x1 76593 WRITE0 0800, 4 bytes: 00 00 00 00 76703 WRITE0 07FC, 4 bytes: 00 00 00 00 then we see, it is that interlock problem I mentioned right at the beginning. it is NOT that whatever you write is sets it to 1. It is the problem that setting GS requires LOC as well, and the IPC interface is not able to switch both together, as I said. Individually the switching certainly works. It is actually a matter of timing, take a look at this (FSUIPC 3.03 + FS2004): 450765 Monitor IPC:07FC (S32) = 0 450765 Monitor IPC:0800 (S32) = 0 452531 WRITEex 0800, 4 bytes: 01 00 00 00 452531 WRITEex 07FC, 4 bytes: 01 00 00 00 452593 Monitor IPC:07FC (S32) = 1 452593 Monitor IPC:0800 (S32) = 1 454359 WRITEex 0800, 4 bytes: 00 00 00 00 454359 WRITEex 07FC, 4 bytes: 00 00 00 00 454421 Monitor IPC:07FC (S32) = 0 454421 Monitor IPC:0800 (S32) = 0 Here each pair of reads/writes are done together, in one FSUIPC_Process. I think changing them both in one FS frame defeats the interlock well, but otherwise each interlocks the other. It is certainly a matter of timing, not a logic change. If the only way to be sure is to make sure the changes are done together, then I think that will be the only solution. I'll add a note to that effect to the programming guide. All the programs i have here do change them in one FSUIPC_Process call, so they work consistently. Hence the earlier confusion. Otherwise I may need to add some strange logic or memory of previous writes, and I'd rather not really. There might be other effects which I don't foresee. After some other testing, I find that, yes, it it EXACTLY the same in FS2002 with FSUIPC 2.975, setting 800, then 7FC, then clearing 800 and clearing 7FC. If these pairs are done quickly enough, it works, if not it doesn't. It is just the double interlock. The timing is slightly different in FSUIPC 3 compared to FSUIPC 2.9xx. Your program is just coincidentally with timings set to be between one and the other. Make the changes more slowly and it will fail in both, make them faster and it will work in both. My advice therefore is to change them both in the same FSUIPC_Process call. This ensures that they get processed in the same FS frame. I shall add a note to this effect in the SDK. Thanks, Pete Link to comment Share on other sites More sharing options...
aqui Posted August 5, 2003 Author Report Share Posted August 5, 2003 Thank you for the solution! Now I send only one FSUIPC_process after setted $0800 & $07FC. It will be right! Now I'm waiting for FSUIPC 3.04 that resolves the NAV/GPS Switch bug. Regards Aqui Link to comment Share on other sites More sharing options...
Pete Dowson Posted August 5, 2003 Report Share Posted August 5, 2003 Now I'm waiting for FSUIPC 3.04 that resolves the NAV/GPS Switch bug. Sorry, but it isn't a "bug" as such. It was one of the many things that have moved in FS2004 and which I had not found until recently. There are many more. I could not test and find everything in the short time I had between receiving FS2004 and it going on general release. In fact there's no way I can test everything in any case -- a lot of it I don't even understand (I am a programmer not an aircraft engineer). I am dependent upon feedback from other developers, programmers and users. I doubt if I will have completely solved all the differences between FS2002 and FS2004 even by this time next year. All I can hope to do is deal with those that matter, and that's based on feedback. So thanks for your feedback, but please don't call them bugs. They are differences. If I do find real bugs I will admit to them, as always. :) Version 3.04 will be ready today. Regards, Pete Link to comment Share on other sites More sharing options...
aqui Posted August 5, 2003 Author Report Share Posted August 5, 2003 Excuse me for the improper word :oops: THX !!! :D Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now