Would creating a NAV solution really require a new client? Assuming a live connection, and running simulatious GE instances. it could be accomplished with api control over placemarks (quickly browsing the GE api info, im not seeing anything). Create a temporary placemark representing current positition, Query the server for driving directions to the target placemark, Then quickly fly through the directions and create a path file. Every few seconds a new path file would be created. assuming even further that the path file can be broken down into a list of lat/long coordinates, the current position could be continiously tested to see if it falls outside some set range of any of the points making up the generated path. Once outside the path (deviating from directions), the second instance of GE could requery the server for directions and generate a new path.
this could all be nonsense
David: No, if I can change it from within Google Earth that is good enough for me.
d2: Ok, well, then it might be possible with a GEMod type program. I have never looked at the GE API so I have no idea how extensive it is. Can you really query things like "# of displayed placemarks"? In anycase, all SKINbedder does is send keystrokes. I have no plans to ever make it recieve data from other programs. It would be impossible to make that "universal" for use with any program.
Well, it is possible. Its called plugins. But this would increase the complexity of SB exponentially. Maybe if we get more people on the Sb team (hint hint)Originally Posted by RPM_VR4
RPM: the feature set in SKINbedder is great the way it is, sending keypresses and embedding applications. the things i was mentioning would work for an additional app, or as addons to GooPs. The GE api has strong view based refresh parameters that would handle poi's nicely.
instead of just postulating features, im going to start implementing some. going to read up on the ge api to see what is possible. david- if you need help devloping i offer my time, RPM- im not sure how much i could help with skinbedder, no real imaging skills
Google earth supports static image overlays (image stays in place, map moves) with variable transparancy. im thinking there is a screen capture or zoom application out there that will be able to capture an image of a running window (GPS status windows in Iguidance or zorro's GPS speedo or any other app showing sat info). Set the app to (or code the app to) capture the window at some refresh rate, then have GE overlay the static image in the corner or whatever. Could have real-time sat info (delayed as much as GE is) displayed in the lower right over the google logo.
0 l 3 3 l - your zoom app seems lke it could be adapted to capture a window and dump to image file. (hint)
My zoom app can only capture a window hidden behind itself unless I want to mess around with other window's properties. And I bet I'd run into some trouble there.
RPM, I tried that. The WindowClass is "QWidget" and the WindowTitle is "Warning". I created a folder called GENag and put the information in there. Then in GoogleEarth.ini, I wait for 15 seconds, embed GENag then send Enter key to get rid of it. In theory, it should work but I got a very different result. It works like a couple of times then in other times, I got tons of GE window popping up.b8: Use AutoIt Window Tool to find the name/class of the "nag" window. Copy the GooPsWindow sub-dir and rename it to GENag. Rename the INI file too and edit it to reflect the proper window name/class. In the startup script, add Embed(GENag:20000) an then add Type(I) so it will auto press the ignore button. Let me know if you have any trouble.
Could you help with that please. Like I said, all you need to do is disconnect your Internet and you should see the nag screen. Thanks.
I also have a hysteresis style algorithm working. With hysteresis you must exceed the speed range of the current zoom level by a set amount (say 3mph) before it will change zoom levels. This technique is used to avoid false triggering (triggering on noise) on oscilloscopes. I should have a release within the next couple of days.
sounds great, the more robust the control the better. the compilation of alot of apparently small features like this is what makes up a great application.
With the upcoming release, the only remaining problem i have is equally small.
as mentioned earlier, i dont always get an accurate heading when at a stop. if maping the heading as 'up' this results in 'spinning', obviously happens in Iguidance too, but more visually distracting in GE due to the nature of the maps. Since GooPs has control over the rotate, it would be nice if it there was a heading buffer that would remember the correct heading as as i slow down, and disable the autorotate when at a stop to prevent the spining effect. Speed up and autorotate would be re-enabled. I understand this may be signifigantly more difficult to implement that the autozoom dampening (functionally, right after a stop there are typically heading changes associated with actual turns) a slightly larger rotate delay for an actual turn (waiting until up to speed to reinit autorotate) may be acceptable since there is already an inherant delay.
to reiterate:
GooPs is a wonderful application right now. No further development could be done and I would continue to use it for the life of the carputer. I appreciate the quick update schedule, and taking the time to implement requested features
Would it be possible to somehow add an option to auto dial a connection? What I'm thinking is when you launch your program it autodials a bluetooth dial up networking connection (to your gprs phone).
Current Vehicle: 2007 Dodge Nitro
Second Vehicle: Sold it :( 2005 Dodge Ram 1500 Quad Cab
First Vehicle: 2003 Ford Ranger
Posting Permissions
LinkBack URL
About LinkBacks
Reply With Quote
Bookmarks