kuusmi3 Posted March 14, 2003 Report Posted March 14, 2003 The problem is that PIC uses it's own variables for autopilot parameters so I don't have an access to the MCP's selected altitude variable. I thought that the latest patch would have added this kind of support. I however heard that I would need somekind of a special DLL to get access to these special varibales which I naturally don't have. I sent a message to PIC support forum about this but didn't get any replys. I'm afraid that, unless you want to hack into their code then that is the only way you'll get what you want. I thought that was the whole point of the 1.3 update, to provide program access to their panel programming. But they don't talk to me, and I've never seen anything helpful from them I'm afraid. Is there a way to get it via FSUIPC Sorry, no. FSUIPC knows nothing about any of the third party panels stuff. The only one which has supplied adequate documentation for me to add controls for is Project Magenta. Regards, Pete
Pete Dowson Posted March 15, 2003 Report Posted March 15, 2003 Sorry, you can see I'm new at this forum stuff. I seem to have managed, somehow, to have replaced your original message with my reply! I hope it is still useful, but it does make this thread look a bit silly now! Regards, Pete
kuusmi3 Posted March 15, 2003 Author Report Posted March 15, 2003 I'm afraid that, unless you want to hack into their code then that is the only way you'll get what you want. Could you give me a little hint of how would the hacking be done? What programs would I need? I tried to attach FS to VC++'s debugger and even managed to find the memory area for the particular gauge. But I'm not sure if that helps me at all. Does the same DLL (gauges are in fact DLL's) always have the same memory area in use? If not how could I make the gauge always find the right memory address to be used? Anyway the memory area of the gauge is pretty large so I would have to scan through it somehow to find the right memory address which is used to store the MCP's altitude value. I don't know very much about the way memory for DLLs is handled so I hope that someone wiser on this subject could help me out a little.
Pete Dowson Posted March 15, 2003 Report Posted March 15, 2003 Could you give me a little hint of how would the hacking be done? Er, no, sorry. I learned programming from the hardware up, starting in 1963. Getting into other folks' code without their help and their source first means learning assembler code, then using a disassembler such as IDA Pro (which I use) and a debugger such of Soft-Ice (which I also use, at least a very old version of -- can't afford updates to this expensive item!). Does the same DLL (gauges are in fact DLL's) always have the same memory area in use? It is not likely, at least for gauges, no. If not how could I make the gauge always find the right memory address to be used? You can get the memory address from Windows. Use LoadLibrary. In the 32-bit windows world the handle that returns is actually the base address of the DLL. Anyway the memory area of the gauge is pretty large so I would have to scan through it somehow to find the right memory address which is used to store the MCP's altitude value. If indeed it is stored withon that space. It may allocate memory and store it there, in heap space. You'd need to find a pointer to it then instead. It takes a lot of work analysing disassembled code. I have to do this sort of stuff all the time, to make FSUIPC work inside FS, and it takes many many hours -- months and months for complex things like the FS weather. Regards, Pete
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