Correct and precise lat/lon calculation?

[Christoph Langguth 0]

Hi all,I'm currently about to code an add-on to create custom views in FS9. For example, I want to create a view which sits at the tail of the plane (kind of like the real cams that the big birds seem to have).Much of the hacking has been done, but I somehow don't get the calculations entirely correct.Simply put, the problem is the following: get the current aircraft position and heading (more precisely, it probably gets the COG of the plane), and given this information calculate the correct position for setting the camera, say, 38 meters behind. As long as I'm heading north/south or staying close to the equator, it all works beatifully, but as I approach the poles my calculations are somewhat off. Please see the screenshots for examples of correct (and wrong) results of the current code.The code now looks as follows:[...]if (hdg > 180.0) hdg -= 360.0;double length = GetConf("len"); // 38.0 meters right now for the B747double rHdg = DEG2RAD(hdg) + PI; // turn the heading around towards the taillon += length * sin(rHdg) * cos(DEG2RAD(lat)) / 1852.01 / 60.0;lat += length * cos(rHdg) / 1852.01 / 60.0;[...]The rationale of the calculations is (from the information I have accumulated so far):* The length is in meters, so all results must be divided by 1852.01 to get to nm, then by 60 to get to lat/lon degrees.* The latitude increase is dictated by the cosine of the heading, the longitude by the sine.* The longitude is additionally adjusted by the cosine of the latitude, as the longitude circles get smaller towards the poles.IMO, this formula should be right, but it doesn't seem so - my calculations seem to get more and more distorted as I approach the poles... (again, see the screenshots)So... can anyone tell me what I have overlooked or where I went wrong?Thanks a lot in advance!!!Cheers, ChrisOh, happy new year, BTW ;-)

[Guest jimcooper1]

Chris,You are essentially assuming flat-earth at the the point you make your calculations. Near the equator this is OK but at the poles the curvature is quite marked so your reverse bearing will be incorrect.The formulas you need can be found here:http://www.movable-type.co.uk/scripts/LatLong.htmlhttp://www.codeguru.com/Cpp/Cpp/algorithms...php/c5115/#moreRegardsJim

[Christoph Langguth 0]

Woohoo!Thanks a ton, Jim! This did the trick... I bookmarked the page right away as it will certainly come in handy again... Yeah, by now I even found out all the other formulas to take into account pitch, bank etc - lots of head-scratching, but now my camera is always nicely glued to the tail of the plane ;-)And now to some related but different questions, as there seem to be quite some helpful gurus around, maybe someone can answer some of the questions here:1. Does anyone know how to get a view window to be positioned in front of the panel? The idea is to make the view "integrate" into the panel as some kind of "camera gauge". I have been able to move and resize the FS98CHILD window that is the view. I have also been able to "logically" set it to the front of the panel by using SetWindowPos (i.e. clicking and dragging on the bounds will move the view window, not do anything on the panel), but the actual *contents* of the view window is still obscured by the panel. Weird stuff... ;-) but maybe someone has a clue?Alternatively, if this proves to be impossible, would it be possible to have something like a complete "hole" in the panel, so that the view would be seen through? I haven't experimented with this, so I'm just asking if it is possible at all to have parts of the panel (including the panel background) entirely transparent - maybe someone has some experience with that.2. Is there a way to find out the heading of the steering nose wheel? I assume that it might be somehow related to the rudder variables, because that's how the wheel is controlled, but I don't really know how to get what I want. The basic idea is the same as above: have a view that is glued to the front wheel so that taxiing gets easier... so this view should of course follow the heading of the wheel, not of the plane itself.3. It also would be neat to automatically determine the correct position for the various cameras. (By now, they're hard-coded in some configuration file and I found them out by trial and error). So, is there a way of determining, say, the "highest point" of the plane (this, or somewhere close, is probably where the tail view camera should go), or the location of the front gear? Ideally, all this should be determined at runtime by looking at the (compiled) aircraft model, errm... somehow. I'm not afraid of hex editors, but I'd need some hints where to look for what ;-)Again, any help is much appreciated - thanks in advance!If you're wondering what the heck I'm programming here - it should be something like this: http://www.airliners.net/open.file?id=0957...&sok=&photo_nr=CheersChris

[Guest jimcooper1]

I have created a camera view by making a black (0,0,0) rectangle on the panel bitmap - this makes it transparent. I then created a new view..... and designated it as a SPOT VIEW. This was then dragged and resized to fit in the rectangle, and Position '2' selected on the number pad to place the camera behind the aircraft. The Spot view is then edited using the VIEW OPTIONS.Select the appropriate Window and check the Spot Plane button, turn off Gradual Transition, set the Zoom, Distance and Altitude to bring the Camera exactly where you want it. You can set up many camera views like this. When you have it configured as you want it.. Save the flight and next time you select this flight all the cameras will be set up for you.RegardsJim

[Christoph Langguth 0]

>I have created a camera view by making a black (0,0,0)>rectangle on the panel bitmap - this makes it transparent.Cool - good to know this works, so I'll probably go for this way.> I>then created a new view..... and designated it as a SPOT VIEW.> This was then dragged and resized to fit in the rectangle,>and Position '2' selected on the number pad to place the>camera behind the aircraft. The Spot view is then edited>using the VIEW OPTIONS.>Select the appropriate Window and check the Spot Plane button,>turn off Gradual Transition, set the Zoom, Distance and>Altitude to bring the Camera exactly where you want it. >>You can set up many camera views like this. When you have it>configured as you want it.. Save the flight and next time you>select this flight all the cameras will be set up for you.>Actually, my approach is slightly different, because all the built-in views are all somewhat "automated" in that they always calculate at least the viewpoint direction, angle etc. so they're not fully customizable. For example, you wouldn't be able to set up something like a "wheel cam" looking away from your plane...The solution that I have now (in an experimental version) allows me to have arbitrary, fully custom views where I can programatically control camera lat / lon / alt / hdg / pitch / bank / zoom. It's taken me a couple of days, but it works :-)For those interested, it is done by patching some of the internal FS9 code at runtime, first allowing for an arbitrary number of "view types" instead of only the five built-in ones. For handling the custom views, the code is patched to jump into my module, where I can set the desired values, then is handed back to FS9 and there treated as if it was a tower view, and FS happily uses the values I have assigned ;-)The tail/wheel camera is actually just an application using the custom views, but it's one that I always wanted, and it helps me find some open issues and fix them. Ultimately, I will make both available to the community when they're ready.If anybody is interested in alpha/beta-testing this, you're very welcome to post here, or to send me a PM or a mail. For the beginning, I would be grateful to get my hands on a couple of window.dll from non-english FS9 (only FS9!), because that is where I have to patch the FS code, and I'm not sure whether my approach will work with these as well -- the offsets to patch might very well be different in other versions of the DLL.)CheersChris

[WarpD 824]

So... you're hacking into the core FS code and physically changing it after it's loaded up?Aside from the various legal issues... sounds dangerously dicy at best. Good luck!

[Christoph Langguth 0]

>So... you're hacking into the core FS code and physically>changing it after it's loaded up?Yup.>>Aside from the various legal issues... sounds dangerously dicy>at best. Good luck!As to the first topic - this is perfectly legal where I live; there are still countries where people do have some rights. BTW, I doubt that without reverse engineering FSUIPC would exist, just to give an example.Concerning the second: If you know what you're doing, there is no problem whatsoever. I'm simply extending the program by making it behave as I want, to overcome some limitations. I'm aware of what every single byte in my patch does, and I designed it in a way that it can't harm normal FS operation. You can of course crash any program by doing the wrong things, but I'm through the "trying things and crashing the proggy with it" phase - it's rock stable here.Finally, thanks for the "good luck" :-)

[n4gix 4,947]

So, you are designing something for FS9 that now exists in FSX... custom camera views...There is a very big difference between what Pete did with FSUIPC... It's one thing to 'peek and poke in the executables' to determine memory pointers; quite another to physically modify the runtime module(s).That said, John Stottlemire (RIP) did much the same with his release of a "taxi speed utility" that would modify the runtime module......or the one recently released for FSX. Thus far at least, there's been no reaction from MS/ACES regarding them. Of course, in John's case there's no recourse possible since he died just a few weeks after releasing his utility...

[WarpD 824]

>>As to the first topic - this is perfectly legal where I live;>there are still countries where people do have some rights.>BTW, I doubt that without reverse engineering FSUIPC would>exist, just to give an example.>FSUIPC reads/writes variable memory locations in the DLLs. It doesn't modify any core FS code.As for the phrase "perfectly legal where I live"... I suggest you go read your EULA. The EULA specifically states what jurisdiction you agree to be legally bound to upon acceptance. So, don't be so certain. ;)As an FS user, I personally hate when an add-on uses "out of the box" methods to accomplish something. The primary reason... it's worthless with the very next version of FS released. The secondary reason, a patch release from MS can render it defunct. This is one of the reasons I have no weather radar on any aircraft. ;)

[Rocky 128]

Hi Christoph,I tried to do the same some time ago. I had the possibility to place the camero wherever I wanted, but the problem I had was that the camera was still looking in the direction of the aircraft COG. It seems that you solved this problem...I had another problem that may be more difficult: I wanted to provide a panel file that includes the camera view, and it appears this is impossible. The panel configuration is stored in panel.cfg and the view configuration that defines the camera view is stored in the saved flight file (xxx.flt). In other words, if you want to let anyone use your work, each user will have to define its own view configuration for the camera view integration in the panel. Or you can provide a .flt file but the camera will work with this flight file only. Not easy...Eric

[Christoph Langguth 0]

>>>>As to the first topic - this is perfectly legal where I>live;>>there are still countries where people do have some rights.>>BTW, I doubt that without reverse engineering FSUIPC would>>exist, just to give an example.>>>>FSUIPC reads/writes variable memory locations in the DLLs. It>doesn't modify any core FS code.Yes, primarily. However AFAIK it also provides functionality e.g. for disabling the resizing of gauges/views etc. This can only be done by intercepting calls to the corresponding window by using hooks or altering the WindowProc. Although I agree that this still doesn't involve altering the code itself, it does alter the program flow in just the same way as I'm doing. Had there been a less low-level way to get to where I wanted to get, be sure I would have used it. ;-)>>As for the phrase "perfectly legal where I live"... I suggest>you go read your EULA. The EULA specifically states what>jurisdiction you agree to be legally bound to upon acceptance.> So, don't be so certain. ;)Oh, don't worry - I am certain ;-)I am legally bound only to the jurisdiction of the country where I physically am, and (if it's coming to capital crime) to the laws of my home country. And in the same way that a brazilian company will not be able to impose brazilian law to you in the US (even if they try), a US -based company cannot impose US law to me here.Actually, they *are* aware of that; these are parts of the EULA:[...]Limitations on Reverse Engineering, Decompilation, and Disassembly. You may not reverse engineer, decompile, or disassemble the SOFTWARE PRODUCT, except and only to the extent that such activity is expressly permitted by applicable law notwithstanding this limitation. [...]If this SOFTWARE PRODUCT was acquired outside the United States, then local law may apply.[...]Did you see them mentioning "applicable law" and "local law"? In a nutshell, the EULA states what the company (in this case Microsoft) would like to disallow. However, if this contradicts the local laws in the country where the end-user is living, then the corresponding parts of the license agreement are simply void.And since I fortunately live in a country where laws are being made to protect the consumer's rights (not only the big companies' rights), I'm quite well off.To finish with this legal discussion, I'd like to point out that even from the "common-sense" view, I consider myself a good guy, not a bad one: I'm not doing anything evil here - I'm simply *adding* (IMO useful) functionality to the program.>>As an FS user, I personally hate when an add-on uses "out of>the box" methods to accomplish something. The primary>reason... it's worthless with the very next version of FS>released. The secondary reason, a patch release from MS can>render it defunct. This is one of the reasons I have no>weather radar on any aircraft. ;)I see your point and I actually agree with it. As said - had there been another way to accomplish things, I would have gone for it. But I simply didn't see one. And yes, of course I'm binding myself to a single version of the program (FS9.1 currently), but I doubt that there will be any future upgrades anymore, and obviously with FSX there is no need for it anymore anyway. And I explicitly want to test and see if this works also with other internationalized versions of the program, which is why I wrote this "want to get my hands on non-english window.dll" thing.Cheers,Chris

[Christoph Langguth 0]

Hi Eric,>Hi Christoph,>>I tried to do the same some time ago. I had the possibility to>place the camero wherever I wanted, but the problem I had was>that the camera was still looking in the direction of the>aircraft COG. It seems that you solved this problem...Hehe, yes. It was quite tricky though :-)>>I had another problem that may be more difficult: I wanted to>provide a panel file that includes the camera view, and it>appears this is impossible. The panel configuration is stored>in panel.cfg and the view configuration that defines the>camera view is stored in the saved flight file (xxx.flt). In>other words, if you want to let anyone use your work, each>user will have to define its own view configuration for the>camera view integration in the panel. Or you can provide a>.flt file but the camera will work with this flight file only.>Not easy...Agreed, this is one of the tougher parts. Actually, when loading a saved flight, the view window will still be there, but with a default view instead of a custom one. I have not coded this yet, but I think I have an approach to detect this, i.e. simply close the concerning view and re-open a custom one.To give you an rough understanding of how the stuff I coded is organized:I have a "generic" module called customview.dll which does the dirty, low-level work and provides a DLL function (CreateCustomView) to register a custom view.Then other modules (i.e. viewgauge.dll) call this function, passing it a pointer to a callback function. It is this callback function in the gauge's code which ultimately receives the "viewInfo" structure and manipulates the position and attitude of the camera.The real problem lies in keeping the state of the custom views. For the camera position, in my particular case it is not an issue because it directly depends only on the aircraft position/attitude. However the setting *which* view type it was (i.e. "none","tail view", "gear view") is probably lost, because it is stored in an internal variable in my gauge module, which is re-initialized when the gauge is reloaded.So... what would be nice to have is something like a facility to declare variables that persist state in a saved flight... I don't use them right now, but I was thinking about "named variables", as they're called in the SDK -- i.e. the ones that are used with [tt]register_var_by_name[/tt] and similar. Do you know if their state is persisted?Thanks & cheersChrisPS: Eric, tu n'aurais pas par hasard une version fran

[Rocky 128]

Hi Christoph,As far as I know, the named variables are not persisted. I already used them in the past and never noticed they were saved in the flight file. I think the best solution would be to save it in a file that you create especially for this purpose.EricPS. Bien qu'

[Christoph Langguth 0]

>Hi Christoph,>>As far as I know, the named variables are not persisted. I>already used them in the past and never noticed they were>saved in the flight file. I think the best solution would be>to save it in a file that you create especially for this>purpose.>>EricHmm... ok, I just abandoned the thought of persisting this state. I guess it would cause more problems than it solves, since it would involve finding a "good" place for storing these things in one way or another. After all, restoring the camera is just one click for the user on reload of the flight.BTW, for those interested in testing it, I have a beta version here:http://christoph.rosenkeller.org/fs/dev/ (some screenshots there as well) - I encourage everyone to try it and report any issues, feedback will be very much appreciated!It also seems that all FS 9.1 versions share the same window.dll (at least I had some german users reporting that it works fine with the german v9.1), so the only question left is whether 9.0 behaves differently.>>PS. Bien qu'