What should future Tileproxy development focus on most?

[Guest cbuchner1]

Hmm, for TP is keeping up now with a learjet travelling at 250 knots (ground speed) on 3 LOD rings continuously, with Level of detail (Terrain) radius set to Medium. Occasionally it would start loading the 4th LOD ring, but get interrupted in the process. The terrain looked detailed to me from high altitude (34000 ft) throughout the flight.FYI LOD 15 - 1024x1024 pixels per ground square (approx 1 km squared) LOD 14 - 512x512 pixels 7th ring LOD 13 - 256x256 pixels 6th ring LOD 12 - 128x128 pixels 5th ring LOD 11 - 64x64 pixels 4th ring LOD 10 - 32x32 pixels 3rd ring LOD 9 - 16x16 pixels 2nd ring LOD 8 - 8x8 pixels 1st ringI noticed though that for this flight altitude a terrain radius of "High" would be much more satisfying. You could actually see how far the photo terrain extended - and that boundary looked ugly.Of course the Learjet is supposed to travel 450 knots, don't know what I did wrong. Throttle at max, flaps at minimum. Maybe I had much headwind - I was going west - and my ground speed was thusly much lower. ;)I have more plans for intelligent preloading in the pipe - think I can predict the plane tradectory and preload those ground squares that FSX is going to request in the following 30-60 seconds, but I won't get to work on this feature in January. I must keep up with my day job.What this flight path preloading will gain is simply that FSX will *never ever* have to wait for Tileproxy. FSX will only be limited by the speed it can collect tiles from the RAM disk-alike filter driver (which could not be accelerated much faster, other than by altering the way FSX handles FS9-style photo terrain).The only problem that remains is how to preload the terrain around the destination airport, such that when you descend, the airport and surrounding terrain will become crisp quickly enough. Maybe looking at a flight plan file would help in that process.Christian

[hilton 0]

Christian,I have just been looking at Google Earth and have come to the conclusion that the mesh information that GE has is better than FSX.If you look in 3D using the GE browser you will see what I mean.Try the Cape Verde Islands.You know what is coming - is there any chance that we could pick up this mesh from Google on the fly?Bernard

[Guest cbuchner1]

No mesh will be obtained from tile providers... ever. The reason being that their data format is different and meshes cannot be created "on the fly" in FSX.

[Guest flyalot]

Sure, tile proxy runs, but it doesn't fit the security concept. Two points come to mind immediately:1. In load.bat get rid of writing a file into c:program files.. to determine the disk drive. BTW 1: that trick didn't work in my case anyway for unknown reason. BTW 2: Thinking of it, why do you need the drive from the program files anyway? Don't you need the drive with the data? Well, kind of puzzeling actually.2. Deactivating virus protection is a very poor idea in the long run. Far, far, far too dangerous if you have an email program running (or forgot to close it), or just want to search for something in the internet which suddenly strucks your mind. After some time every average user will surely forget to turn on virus protection after using tile proxy or to close the email program which runs in the background or uses an internet browser although he/she definitely shouldn't do that without virus protection switched on. Just give us a few weeks until everything is routine and the mistakes will be made...So in my honest opinion security is the most important point. At least we need to set up something like a list of compatible virus protection software etc.

[Guest cbuchner1]

Since Beta 7 Preview 2 it looks at the registry entry. The command line override is no longer strictly required - you can remove it from load.bat easily.I will get rid of the load.bat script alltogether.BTW turning off user account control in Vista is still a _must_ because the proxyuser.exe program must open a communications port to the kernel mode driver. I am not sure how to aquire the rights to get past this restriction in an automated way.

[Guest flyalot]

>Since Beta 7 Preview 2 it looks at the registry entry. The>command line override is no longer strictly required - you can>remove it from load.bat easily.Excellent, Christian!! >BTW turning off user account control in Vista is still a>_must_ because the proxyuser.exe program must open a>communications port to the kernel mode driver. I am not sure>how to aquire the rights to get past this restriction in an>automated way.That is a very interesting point. I have to admit that I didn't work with C and C++ for quite a few years and since Windows is not exactly my world either, I was reluctant to take a glance at your code. Anyway, to me it looks like we need to talk about 32bit-Vista and 64bit-Vista separately, don't we? Didn't 64bit Vista require kernel drivers to be signed by one of just a few certification agencies? If I recall correctly that's not the case in 32bit Vista - and actually Tile Proxy seems to work alright on my 32bit Vista without switching off the user account control. Was this your point? But I agree, it looks like there will probably be no easy way to get a kernel mode driver signed. I guess going through the procedures to obtain such a certificate will be far beyond the possibilities of non-commercial developers. However, the virus protection issue could and should be addressed. IMHO there it's by far too risky to connect an unprotected system to the internet nowadays. It's just a question of time 'til the first mistake happens and the system is infected...

[Guest flyalot]

>BTW turning off user account control in Vista is still a>_must_ because the proxyuser.exe program must open a>communications port to the kernel mode driver. I am not sure>how to aquire the rights to get past this restriction in an>automated way.I thought about it again last night. My first reaction yesterday was "he can't mean what he is saying here" since there are mechanisms for user programs to talk with drivers. But I guess the complexity is that your kernel driver doesn't do (and probably can't do) all the work. Looks like it's just intercepting FSX's file access attempts and redirects the request to ProxyUser, which is actually a user space program - or this completely wrong?Well, I don't see clearly why it shouldn't be possible to use "standard driver communications" to talk to the kernel driver, but maybe something changed here completely since I worked on my last driver project (what is quite long ago).You know, if it's neccessary to run ProxyUser with administrator rights that's still quite OK in my opinion. At least it's no priority task to reconstruct everything in order to avoid it.My real concern is actually that running a virus scanner or other security software could interfere with tile proxy and has to be disabled. But I guess you know better than me that there is a kind of priority scheme to determine which driver gets control earlier or later in the chain. So it should be just a question of fine tuning to find a comfortable position in this load order.BTW, using beta 7 preview 2, I can say that the AVG free virus scanner seems to work fine with tile proxy. At least I don't see any difference running with or without the virus scanner switched on. Once you are comfortable with the kernel driver it may be a good time to ask the users for feedback regarding other virus scanners.

[Guest cbuchner1]

The standard methods to load and talk to drivers require certain privileges of the application. There is something called a "SeLoadDriverPrivilege", which you can give to specific user accounts (or programs?) through the system or group policy editor - but honestly: how many regular users have heard of these tools or used them previously? Of course the Administrator account would already have that privilege, but on Vista with UAC enabled the account is not actually running as Administrator. So you will be getting the dreaded UAC warning every time Tileproxy starts...The good news is that I have now dumped the load.bat script and everything that it has done is now handled internally by proxyUser.EXE - but I cannot get rid of all UAC warnings at this time.About the interference with virus scanners. The problem is two-fold:If the virus scanner has higher priority than Tileproxy, it might intercept and alter the I/O before TP has a chance to see it. Some virus scanners then like to access the file before TP and will perform reads on the file in Kernel mode. This means that Tileproxy will no longer see the original reads of the Flight Simulator - but also the reads initiated by the virus scanner's driver. TP may no longer be able to detect the original "intention" of FSX when it accessed a specific BMP tile and gets confused. TP has to know exactly which section of the file was accessed by FSX to determine the required graphics resolution. Otherwise you get garbled graphics.The other problem is that a virus scanner process running in the user space will often read and scan every single file that was opened by any application, including FSX and TileProxy. This is a HUGE performance hit and that is the reason I will print a warning message every time another application opened a BMP file in the Tileproxy Photoreal World folder.I find it no problem if you have to disable your virus scanner (NOT Firewall) as long as you refrain from:- using Internet Explorer- downloading and executing binaries from the Internet- starting programs from other untrusted mediawhile you are flying with TP. XP's and Vista's firewall will keep you safe from direct attacks over the network.Not every virus scanner is incompatible with TP. It might be worthwhile to perform some tests with Beta 7 later and make recommendations which products don't interfere.Christian

[Guest cbuchner1]

Speed has already been improved somewhat. A GUI for TileProxy and AutoGen are next on my list, along with further speed tweaks.Give me time until summer, this is hard. Autogen involves feature recognition and other tricky maths. Autogen will consume some CPU power, so quad cores are definitely a plus.Getting more speed means messing with FSX internals (no longer just attaching externally through the file system layer). A GUI is piece of cake, when done in .NET 2.0ChristianPS: the cake is a lie. ;-)