Christoph Langguth

<EDIT>NOTE: To anyone *NOT* knowing about autower: please do NOT take part in this survey. This is only intended for (at least potential) users of autower. The survey will only be somewhat useful if it is limited to autower users. Thank you!</EDIT>Hi folks,here's just a few questions that appeared to me after recently refurbishing autower. In particular, I was wondering whether it makes sense to "launch" something like a global database for tower positions.All outcome of the poll is of course anonymous, but any direct feedback is also welcome.CheersChris

Hi,just to follow up on this: based on your replies, I've been experimenting a bit with the scenery.cfg to see how different changes are reflected in FS9 itself. What I've come up with is the following:The section name as such, in fact, does not matter at all. As long as it starts with "Area.", FS will consider it. For example, section names such as "Area.LIMC" are perfectly acceptable to FS, and are correctly considered. The ordering (in terms of priority, as shown in the built-in scenery library) is established solely through the "Layer" attributes of the individual sections.I realize that this information is probably not terribly relevant to the average user; however, it might be useful if you need to programmatically make sense of the scenery.cfg.Well, in any case, thanks again for your input!CheersChris

Hi everyone,first off, thanks for the kind words! It's motivating to see that this little thing is deemed useful ;-)I hope you don't mind downloading yet another new version... I recently ( http://forum.avsim.net/topic/352529-more-than-999-scenery-layers/ ) realized that autower was not always correctly determining the scenery layers when parsing scenery.cfg -- it may have missed some layers because it was limited to 999, or it might have gotten the ordering wrong in some unusual circumstances (if you want to know the gory details: I was relying on the number contained in the section name itself (e.g. "Area.542"), instead of using the "Layer" attribute, as FS itself does.In any case, I have fixed these issues, so the shiny new version is now 2.4.0; as always, binary and source archives are at https://christoph.rosenkeller.org/fs/autower/Also as always: if you have any trouble or suggestions concerning autower, let me know.Cheers,Chris

Cool, thank you both! :-)Chris

Hi everyone,while browsing around the posts here, I noticed how some people were discussing what happens when there is a LOT of addon scenery installed.My question isn't so much about what the maximum number of layers is with FS still working properly -- (that would still be an interesting aspect though, so feel free to answer and let's find out who has the most sceneries installed ). Personally, I'll probably never get anywhere close to 1000.Rather, it's about how they are actually represented in the scenery.cfg. The background is that I'm the author of autower, and autower reads the scenery.cfg. Because of the format of the section names (e.g. "Area.001") until now I was convinced that the maximum area number is 999 (and my program behaves accordingly). However, if more than 999 layers are supported (and installed), the consequence is that the program will simply be ignoring some layers -- which would be a bug.So, for those of you who have more than 999 layers installed -- could you please let me know how areas "beyond" 999 are named in the scenery.cfg? Is it as simple as "Area.1000", "Area.1001", etc.? Or is it encoded in some different manner? Maybe it's easiest if you can just post a corresponding snippet of the configuration file...Thanks for your help & cheers!Chris

It definitely does. There have been quite a few downloads already, and there are regularly new visits and downloads.Please let me know *exactly* what kind of problem you are encountering.

Hi all,just wanted to let you know that I've just finished version 2.3.0 of autower.In case you don't know what autower is -- it's a little addon that generally fixes the tower views in FS9 (moving the tower to the correct airport, and if possible positioning the tower view to the real-world position).For those of you who already use it, here's a summary of the most important new things:- For airports which do not define a tower position in the AFCAD (or define it wrong), you can now conveniently modify the tower coordinates in autower's configuration instead of editing the AFCAD.- Closed runways (as defined in the AFCAD) are now honored. This affects the calculation of available runway numbers, and thus (indirectly) the tower height for airports which don't have explicit tower altitudes. This affects more or less 500 airports in the stock configuration.The newest version and corresponding source code is available at https://christoph.rosenkeller.org/fs/autower/ .As always, if you find any bugs, or if you have questions or suggestions for improvement, please let me know.CheersChris

Not mine, but if you insist... "mutually exclusive" is a technical term mostly used in computer science and with clear semantics, roughly translatable to "conflicting". http://en.wikipedia.org/wiki/Mutual_exclusionhttp://www.thefreedictionary.com/mutually+exclusive:-)

Not trying to split hairs, just a comment because the use of the wording put me on the wrong track and might confuse others as well."mutually exclusive" is an "either or", meaning that things do NOT work together, so you can't use both at the same time.What you guys mean is "orthogonal", i.e., not influencing each other ;-)CheersChris

Hi Adrian,that sounds reasonable. Antivirus programs have a tendency to slow down system operation, especially if they're set to check every access to every file. And FS reads loads of files... Maybe just try completely disabling the program and see if it gets better. If it does, then you may want to check the settings for KIS, usually they have some possibility to explicitly disable monitoring of particular directories. Just a guess though, as I don't have that program.If that doesn't help, you could also try to run Sysinternals Filemon to see which programs are accessing which files, maybe that gives you more information.Ooops, just tried to find a link - filemon was obviously merged into a new program called "process monitor" which I didn't have a chance of trying out yet, but... just get it from here: http://technet.microsoft.com/en-us/sysinte...s/bb896645.aspxHTHChris

Well, maybe you just didn't even notice it because it's so well integrated? :( The attached screenshots should show the difference in behaviour ("traditional" vs integrated).If you don't see anything that looks like the second screenshot when re-indexing, then let me know.(edit: As indexing is relatively fast now, the progress window may disappear rather quickly. You can temporarily change the "ProgressDisplayDelay" setting in the .ini to make sure you get a chance to see it, and that it appears correctly)Cheers,Chris

Hi all,just wanted to let you know: there are a few other fixes and improvements that I incorporated during the last month.The latest release version is now 2.1.1.From my perspective, that's pretty much the final one (unless, of course, there are other bugs that remain tobe found, but hopefully that won't be the case :( ).Cheers,Chris

All right folks,it's out!I've just "officially" released version 2.0, available in binary and source at http://christoph.rosenkeller.org/fs/autower/Thank you all for your feedback!(of course, if there's anything new popping up, feel free to let me know...)Happy flying & cheers,Chris

Not the alpha, no. The beta is here: http://christoph.rosenkeller.org/fs/autower/autower2b.zipFor future readers of this thread: That link will also stop working at some point in time. But by then it will be released and you can download it via the homepage http://christoph.rosenkeller.org/fs/autower/CheersChris

http://img80.imageshack.us/i/18803668.jpg/ :-)The first link actually is correct, the forum just seems to HTML-encode part of the numbers for some reason unknown to me, which makes the link fail. Just copy/paste to the address bar and it works.