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.

OK guys,thanks to everyone who replied!I've essentially finished version 2 now, from my point of view everything is in there and should be working.Download it here: http://christoph.rosenkeller.org/fs/autower/autower2b.zipThe major changes now are:- automatic detection of scenery changes. No more manual deletion of autower.dat!- Much faster datafile creation- Completely rewritten code to handle the layers. Now all the AFCADs for an airport are considered, instead of only the first (highest) one found. In version 1, tower positions were sometimes not applied, if they were defined in a different ("lower") AFCAD. Thanks to Geoff for pointing this out!- Out-of-the-box compatibility with AlacrityPC (in other words: it also works when the "Server" service is turned off)- Possibility to force a tower position reset at every iteration, to work around situations where other addons (like FSHotSFX) muck around with it. To enable this, edit the configuration file.Could you please download that version and let me know if everything is working correctly?I'm still labeling it as a "beta" for now, but if I don't receive any complaints, this is what will be released as version 2 next Sunday.Thanks again for testing, let me know the outcome or any other suggestions you have!Chris

Thanks, John!Hmm, that sounds kind of weird. Let me recapitulate:- autower complains about a file (say, c:\programs\fs\...\EGKK\scenery\egkk.bgl) not existing- even after deleting c:\programs\fs\...\EGKK\scenery.dat the error persists.- the file actually exists (did you check in windows explorer?)Could you please send me the scenery.dat that refers to the file, and the complete filename it complains about? (by mail, or attachment)I'm not aware of any tools that allow looking at the scenery.dat files -- except for a hex editor :( , which is how I made sense ofthe bits that are important for autower. In a nutshell, they're index files to speed up figuring out what is where, and in which file.Thanks!PS @all: I'll be rather busy next week, so don't hold your breath for v2 to be released. But whenever I find the time, I'm working on some other substantialimprovements to the logic. I hope, as a rough guideline, to be done within the next couple of weeks.

Thanks!Does v2 also expose the problem with LSZH_GND_H1?

Hi John, thanks for the report! Now that's interesting in that it finds more airports... But I'm not worried about it :-) You couldn't, because v1 does not use the scenery.dat. That's where the speed improvement comes from in v2...However, could you elaborate on what exactly the error is? (Permission denied, file not found, ...) Yes, as I said, this is intended and will be fixed once I release a production version.Thanks again,Chris Yes.In case v1 doesn't work, can you still try v2 anyway? And if it also doesn't work, please report back on what kind of problems you're having.Thanks,ChrisEdit: sorry guys, no idea why the forum joined my two replies into one. Hope it makes sense anyway ;-)

Sure! Actually, I've just included the .exe now into the downloadable file -- didn't think it'd be useful before -- so if you could test it... :( --Chris

Hi Geoff,thanks for the suggestion. Code-wise, this is perfectly feasible, it probably takes one line to be added.It would still take a few seconds (the polling interval, but you could lower that too) to reset the position, but it's nobig deal at all.I'm just wondering whether this is always wanted behavior: a side effect would be that manual repositioningof the tower view is impossible - It may sometimes be desired...How about this: an option alwaysSetTowerLocation (or so) that is disabled per default (to leave the possibilityto fiddle around with the viewpoint), but can be enabled for "special circumstances" like yours?-- Chris

Hi all,I'm looking for people to help in testing the upcoming version 2 of autower.If you're already using autower (v1.0x), I'd be grateful if you could spare a few minutes to test-drive the new version.Version 2 is an almost complete overhaul of autower, focusing on some deficiencies of the previous version.Most notably, I'm trying to incorporate:(1) dramatically faster creation of the database(2) automatic reconstruction if scenery has changed(3) not aborting when FS9 takes a long time to load(4) handling obscure errors related to switching off the "Server" serviceThe bullets are in order of relevance and priority... Anyway, especially for topic 1, I'm not yet 100% sure that mysolution is correct (only 98% ;-) ), so I'd appreciate some help and feedback. If you'd like to help out, please downloadv2 alpha from http://christoph.rosenkeller.org/fs/autower/autower2a.zip and install it.The most important issue I'm wondering about is whether the optimized code still finds all airports, so please do the following:- BEFORE installing v2, delete autower.dat from v1 and restart. It should build its database. Please note the number of airports it finds,and (approximately) the time it took to finish.- overwrite autower.dll with v2 alpha and start again- Note the number of airports it finds. If it's not the same, please, by all means, let me know!- it should be considerably faster. To make sure it's not related to caching, please restart your computer and start FS up again(should be slower, but hopefully still much faster than v1)- from the actual functionality point of view, it should behave identically to v1.Please post your results (especially if something goes wrong or it doesn't find all airports!) in this thread.If there is anything else going wrong (error messages, crashes or so), also, by all means, please let me know.If you have been affected by problems (3) or (4) above, I'd also like to know whether they're fixed with the new version. Any other comments are of course welcome.Oh, and this might be a good time to ask for other features or improvements, if you have any suggestions ;-)Finally, please note that this is not intended to be a production version (yet). It does not use the database at all, and keeps the window open for a rather long time (20 seconds).Both of these are intentional, to ease testing, and will be modified in the release version.Thanks in advance for your help!Chris

>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'

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

>>>>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