I just tried this last night. Curt, this rocks. I think you have to give serious thought to enabling this by default, either by adding it to the fgfs binary or by having fgfs spawn it as a child. It turns the job of downloading, installing and updating scenery from an annoying sysadmin chore into a trivial noop that your proverbial grandmother could use. This is a huge, huge win. Hiding it inside a separate executable and requiring special command line arguments is doing casual users a major disservice -- they *want* this feature. (Sure, some will want the ability to disable it. But the majority of users will see a lot of benefit from having it on by default.)
Nits and thoughts: It would be good if FlightGear could "retry" scenery loadings if it doesn't find the file the first time. In situations where terrasync can't keep up (see below for notes on that), you end up with giant, permanent holes in the ground. If that hole happens to contain your destination airport, you have a problem. Just keeping a list of "failed but still needed" tile paths and retrying them every N seconds should be cheap and easy -- most OSes are really fast at failing to load missing directories. :) If terrasync gets merged into fgfs, you could do a synchronous load/update of the tile(s) containing the starting airport at startup. This would eliminate the chicken-and-egg issue in a simple and user-friendly way. IMHO, the most important feature of terrasync (and something that didn't occur to me until I tried it) isn't that it loads scenery automatically; it's that it automatically guarantees you have the most recent scenery available wherever you are. Future enhancements (like runway lighting) that require scenery updates will be much easier to push out for testing, and less likely to be ignored by folks on modem connections. This should make hacking at the scenery system more productive. Related to the above, you'll probably want to segregate a "release" scenery directory from the "development" scenery to prevent incompatible changes from being pushed to users without current code. It occurs to me that if fgfs tries to load a scenery tile while rsync is still pulling, you will get corrupt tile and (worst case) crash the tile parser. Is there a need for locking or protection against this sort of thing? Just a mail-spool-style "dot lock" should be sufficient -- if FlightGear sees a ".terrasync-in-progress" file, it can refuse to load the directory. [This is the cue for someone to jump in with a discussion about all the dangers and pitfalls of different locking mechanisms on different filesystems.] Apologies if a feature like this is already in there, I haven't read the code. The suggestion to "nice" the terrasync process didn't work well for me. The niced rsyncs simply weren't getting enough CPU to do their job, and were falling behind the airplane. With nice on, it was topping out at about 2-3k per second and falling behind in "complicated" areas. I took off and headed east from SFO. Over the central valley, it was fine, but it started having trouble when I hit the rockies. Turning nice off, it cranked up to a healty 50k/s on typical transfers and had no problems at all. I wasn't able to detect any frame rate difference during transfers. Scheduler behavior is likely to vary with OS (or even from kernel to kernel), with hardware and with driver architecture. It's fair to assume that the rync process is waiting on IO most of the time, but whether an OpenGL application looks "CPU bound" or "IO bound" depends on the driver architecture. If it goes through the kernel every frame, then it will probably look realtime and get more CPU. But I know that early DRI Voodoo drivers did all their card IO via PIO and never touched the kernel. They looked like 100% CPU processes and the kernel scheduler liked to "deschedule" them for 2-3 seconds at a time to give other processes a chance to run in realtime. Dunno, but unless the niceness is required for some situations, I'd suggest taking it out of the documentation. Again, magnificent feature. I love it. Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
