Board index FlightGear Development AI Traffic

AI Systems / Compatibility

Intelligent, computer controlled vehicles that drive/fly over the planet!

AI Systems / Compatibility

Postby Thorsten » Sat Feb 20, 2010 12:04 pm

As some of you may know, I'm currently interested in weather phenomena and am experimenting with various kinds of cloud models in AI scenarios with the ultimate aim of creating a more realistic weather experience (e.g. approaching a rainfront from the side, no rain but shafts of sunlight in breaks in the cloud layer, in general a realistic change in cloud types for an approaching weather front, ...). For this purpose, it would be nice to accurately know what AI systems are available and how they are controlled.

In the current documentation in the Wiki, I find for example the following description of the aircraft AI system type

<entry>
<type>aircraft</type>
<class>light</class>
<model>Aircraft/a4/Models/a4-blue.xml</model>
<speed-ktas type="double">320.0</speed-ktas>
<altitude-ft type="double">7000.0</altitude-ft>
<longitude type="double">-122.6</longitude>
<latitude type="double">37.9</latitude>
<heading type="double">210.0</heading>
<bank type="double">-15.0</bank>
</entry>


The problem is that this does not work with Flightgear 1.9.1 - I needed to change altitude-ft into altitude and speed-ktas into speed in order to get it right (yes, I had a cloud pose as an aircraft - since a Cirrus cloud needs neither turbulence nor thermal lift that seemed the best available type). I suspect that the Wiki documents the state of Flightgear 0.9x.

I could of course simply fix that, Wiki being Wiki, but it's indicative of a deeper problem I'm hitting more and more as I look into how to do my own things in Flightgear - development doesn't go hand in hand with version management and documentation. From my own experience with coding, I know that a third of the work is creating a piece of code which does what you want, the second third is making it backward and cross compatible with the conditions others might run it, and the third part is to document it properly. And currently what is done stops somewhere inbetween.

Frankly, I don't understand a development philosophy which changes altitude-ft into altitude in the first place - it doesn't lead to more clarity in the description, all it does is render older scenarios nonfunctional. And as this thread seems to indicate, the problem continues with 1.9.1 vs. current CVS - presumably Flightgear 2.0 will thus render a lot of stuff which currently run just fine non-functional.

Maybe the majority of people here has no problem with this - some are just users, and others develop for and use CVS anyway. But I think the wish to develop for and work with stable code is not unreasonable - presumably, there are also people like me who don't have the time to get into what goes on in the developer's mailing list, but want to contribute anyway. To put it bluntly, I suspect the lack of proper documentation and the lack of compatibility tends to keep people out who'd want to help, but not on the level of fully getting into the source code development. I also think that in the long term, the community will not benefit from lack of backward compatibility for things that were developed for stable code - suppose someone spends a year developing an aircraft model - is he then expected to stay with Flightgear for life in order to adapt it to every new version? Or do we accept that things run for a year, and then are lost? My personal impression is that if Nasal scripts, aircraft models and AI-scenarios developed for stable versions do not run in future versions, that is a problem on the development side of the main program, not the problem of scenario and aircraft developers. Look at the comparison between Linux and Windows - Linux always had a huge amount of backward compatibility - I can still run things like xterm and vi which lead back right to the time when computers ran in text mode only - this feature has made Linux very attractive for various purposes where working code simply needs to run - people with a working IT environment do not usually want to upgrade every few years and restructure every procedure new.

Well, I don't want to end on a complaining note only - I'd be willing to update the AI systems wiki, but in order to do so properly, I'd need to know what AI systems with what xml-tags are currently supported in version 1.9.1 and what will be supported in 2.x.
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

Re: AI Systems / Compatibility

Postby HHS » Sat Feb 20, 2010 12:48 pm

First: the wiki is not the official documentation for code changes etc.!.

The official documentation you will find always under data/Docs and is usually updated to the last version in CVS!

As this sim is free (you don't have to pay) the concentration on backward compatibilty is minor. I think we have discussed this here in the forum quite often.

FlightGear as an OpenSource project has a different way to develope as commercial products like MSFS. (And btw. even there is no backward compatibilty given as we can see with FSX).
All new developements lands in CVS- we can call this also as Developer System, so if we wants to develope and improve things for the next Release it is recommended to use CVS. It is possible for all platforms, some easier some not. For win32 Frederic Bouvier, Vivian Meazza and Laniel provides more or less regular snapshots, for Ubuntu/debian (?) there is a script available to get CVS easily, and for others it should be not that hard as well.

But I think the wish to develop for and work with stable code is not unreasonable - presumably, there are also people like me who don't have the time to get into what goes on in the developer's mailing list, but want to contribute anyway.

Well, how do you want to contribute if you don't know if it maybe has been developed or fixed?
The Developer-list, not the forum is and was always the place for that. But the forum can and is the place for developing ideas and pushing forward. As an example the ridge-lift started here.

To put it bluntly, I suspect the lack of proper documentation and the lack of compatibility tends to keep people out who'd want to help, but not on the level of fully getting into the source code development. I also think that in the long term, the community will not benefit from lack of backward compatibility for things that were developed for stable code - suppose someone spends a year developing an aircraft model - is he then expected to stay with Flightgear for life in order to adapt it to every new version?


As I said, the wiki is the place for user, not developer. But this has been changed to be wishy-washy badly.
In software developement you aren't always able to keep backward compatibilty. And as the FlightGear is and will be like all softwares, a product in developement, you can't prevent this. Developing is like climbing mountains: for reaching the top you have sometimes run through deep valleys.

Well, I don't want to end on a complaining note only - I'd be willing to update the AI systems wiki, but in order to do so properly, I'd need to know what AI systems with what xml-tags are currently supported in version 1.9.1 and what will be supported in 2.x.

Just read the latest Documentation: http://cvs.flightgear.org/viewvc/data/Docs/AI_doc.html?revision=1.3&view=markup

I'm currently interested in weather phenomena and am experimenting with various kinds of cloud models in AI scenarios with the ultimate aim of creating a more realistic weather experience (e.g. approaching a rainfront from the side, no rain but shafts of sunlight in breaks in the cloud layer, in general a realistic change in cloud types for an approaching weather front, ...)


Yes, this are things which make flying as it is- not that easy like driving in a car. But weather simulation in desktop simulation is not easy.
I don't want to stop you, but I think using AI for that isn't really straightforward and a good solution. MSFS as an example is already able to simulate shafts of sunlight and to my knowledge it is just another type of shader. As we have a more easily support of shaders i could imagine that this also a solution for FGFS.

And for the other weather effects I think the current code needs just be developed further. I would already be happy with moving clouds.
Up, up and away
User avatar
HHS
Retired
 
Posts: 3624
Joined: Thu Jul 19, 2007 8:09 am
Version: GIT

Re: AI Systems / Compatibility

Postby Thorsten » Sat Feb 20, 2010 1:02 pm

Basically, you're encouraging me to just leave it be and remain a user, if I don't want to become a full-scale developer working on the C++ level. Which works fine for me - I don't need anyone to like or to run stuff I write (I have it myself already), it's just more work for me to do so. :D
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

Re: AI Systems / Compatibility

Postby HHS » Sat Feb 20, 2010 1:15 pm

Thorsten wrote:Basically, you're encouraging me to just leave it be and remain a user, if I don't want to become a full-scale developer working on the C++ level. Which works fine for me - I don't need anyone to like or to run stuff I write (I have it myself already), it's just more work for me to do so. :D


The last paragraph is just my own opinion, but your ideas behind your clouds system is quite nice. I just saw your idea about cirrus clouds and yes it should be possible to make for Stuart or others with shader knowledge.

In FGFS very often ideas started this way and ended in a implementation in the hard code.
Up, up and away
User avatar
HHS
Retired
 
Posts: 3624
Joined: Thu Jul 19, 2007 8:09 am
Version: GIT

Re: AI Systems / Compatibility

Postby Thorsten » Sun Feb 21, 2010 8:04 am

With a bit more time on my hands, perhaps I'd like to reply to a few points in more detail.

As this sim is free (you don't have to pay) the concentration on backward compatibilty is minor. I think we have discussed this here in the forum quite often. FlightGear as an OpenSource project has a different way to develope as commercial products like MSFS. (And btw. even there is no backward compatibilty given as we can see with FSX).


I don't understand what you are arguing. I think it's fairly obvious that commercial software has no interest in backward compatibility - Microsoft gets to sell a new version of Word if the old one is not supported by the new Windows - so why should the new Windows support old software? But why should the open source community take Microsoft as a reference? Lack of backward compatibility is manifestly not what 'Open Source Projects' typically do - Linux with huge backward compatibility is the prime counterexample. It is what the Flightgear community decided to do.

Which is, in my opinion, a pity. Flightgear has this multilayered structure with C++, Nasal and xml structures side by side. The fact that someone can make a sophisticated aircraft systems model without ever going to or knowing of the C++ level is a feature - which could be used to even more advantage than it is now.

What you argue (and what is done) is that everything is developed at once in the CVS version and discussed on the developers list. What I argue is that there is no structural reason why this should be so - the structure of Flightgear allows that some people push the C++ code forward while others never see that and develop Aircraft and Scenarios in Nasal. All that would require is that things written for stable C++ version continue to be supported - and there could be a much larger number of people coding interesting things, just because there is a huge barrier between getting somewhat involved and getting fullscale involved.

Currently, what you say is that the work of a developer spending the last year improving the C++ level is so much more important than the work of another person spending the last year writing e.g. a Nasal internal aircraft systems model that after a new release the Nasal simply might not work and that's just bad luck - the Nasal person just has to rewrite, because the C++ person doesn't care about backward compatibility. But that's a choice of doing things, not something predetermined, and in my opinion it is not a good choice. However, since I seem to be a minority opinion, I fully well realize that what I say won't change a thing, and things run in a way well enough as they are right now, so we can leave it here.

The last paragraph is just my own opinion, but your ideas behind your clouds system is quite nice. I just saw your idea about cirrus clouds and yes it should be possible to make for Stuart or others with shader knowledge.


That's precisely my point... There's nothing I can write in Nasal that I or someone else couldn't write in C++ (in fact the pure code I need I could write much faster in C - just interfacing it with the rest of Flightgear is way easier for me from Nasal). What development for me means is not writing code - it is finding the algorithm I want to code, the idea beind the effect I want to create. Once I have that, I or anyone else can implement it in C++, Fortran, Nasal or anything. But the flexibility of Nasal allows you to try algorithms and see what works to the desired effect quickly - without going into the complications of everything else that it going on on CVS.

Naturally I would hope that eventually some parts of the weather are coded on the hard level (for others, I think there is no point). But that is much easier if you know the algorithm already :)

As for how I want to contribute if I don't know if it has already been developed or fixed - I'm a researcher, I do things because they catch my interest. I don't care so much if Microsoft or another developer has found a way to implement something I'm interested in, I'd still try to work out my own solution, and that has some chance of being better than what is already there. Again, that's the strength of Open Source - you can explore different way of solving the same problem and in the end choose what works best - commercial software rarely has this freedom in exploring alternatives.
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

Re: AI Systems / Compatibility

Postby HHS » Sun Feb 21, 2010 11:55 am

Thorsten wrote:With a bit more time on my hands, perhaps I'd like to reply to a few points in more detail.

I don't understand what you are arguing. I think it's fairly obvious that commercial software has no interest in backward compatibility - Microsoft gets to sell a new version of Word if the old one is not supported by the new Windows - so why should the new Windows support old software? But why should the open source community take Microsoft as a reference? Lack of backward compatibility is manifestly not what 'Open Source Projects' typically do - Linux with huge backward compatibility is the prime counterexample. It is what the Flightgear community decided to do.


You are mixing things badly here.

You were talking about compatibility among different FGFS versions.
Now you are talking about compatibility of FGFS related to OS. That's an huge difference.

To be sure: FGFS runs is regarding OS on older OS as well. As an example: FGFS, if 2.0.0 or 0.9.9 runs well on Vista, Windows 7 and XP. The same for Linux.
That's really not a problem of FGFS- backward compatibility with OS is no problem.

Which is, in my opinion, a pity. Flightgear has this multilayered structure with C++, Nasal and xml structures side by side. The fact that someone can make a sophisticated aircraft systems model without ever going to or knowing of the C++ level is a feature - which could be used to even more advantage than it is now.

FGFS is a work in progress. Sometimes it comes out, that certain things done could be in a other way be better. I do know that the devlopers then try to have backward compatibility where possible. But sometimes it is not possible. If we want to have things better we have then to tolerate this.

What you argue (and what is done) is that everything is developed at once in the CVS version and discussed on the developers list. What I argue is that there is no structural reason why this should be so - the structure of Flightgear allows that some people push the C++ code forward while others never see that and develop Aircraft and Scenarios in Nasal. All that would require is that things written for stable C++ version continue to be supported - and there could be a much larger number of people coding interesting things, just because there is a huge barrier between getting somewhat involved and getting fullscale involved.

I do know a lot of OpenSource Programs which has a similar or equal way to develope.
And it is not true, that pushed codes can't be seen for Aircraft Developers:

-You can browse CVS easily with your webbrowser
-You can receive the CVS-changelogs every day per Email if wanted
-You can read the developers-list were all changes, things are discussed.

It is up to the Aircraft developers if they want to follow or not.

Currently, what you say is that the work of a developer spending the last year improving the C++ level is so much more important than the work of another person spending the last year writing e.g. a Nasal internal aircraft systems model that after a new release the Nasal simply might not work and that's just bad luck - the Nasal person just has to rewrite, because the C++ person doesn't care about backward compatibility.

Yep, as all Aircraft, systems etc. decay on C++ and as I said, backward compatibility can't be given all the time.
But you let an impression here as all things are completly broken, FGFS developement is a chaos... Sorry, but you remember me a bit of the indian(?) guy here, who uses an very, very old version of FGFS but wants to use new features....

That's precisely my point... There's nothing I can write in Nasal that I or someone else couldn't write in C++ (in fact the pure code I need I could write much faster in C - just interfacing it with the rest of Flightgear is way easier for me from Nasal). What development for me means is not writing code - it is finding the algorithm I want to code, the idea beind the effect I want to create. Once I have that, I or anyone else can implement it in C++, Fortran, Nasal or anything. But the flexibility of Nasal allows you to try algorithms and see what works to the desired effect quickly - without going into the complications of everything else that it going on on CVS.

Naturally I would hope that eventually some parts of the weather are coded on the hard level (for others, I think there is no point). But that is much easier if you know the algorithm already :)

As for how I want to contribute if I don't know if it has already been developed or fixed - I'm a researcher, I do things because they catch my interest. I don't care so much if Microsoft or another developer has found a way to implement something I'm interested in, I'd still try to work out my own solution, and that has some chance of being better than what is already there. Again, that's the strength of Open Source - you can explore different way of solving the same problem and in the end choose what works best - commercial software rarely has this freedom in exploring alternatives.


Yep, but when the ideas and algorithm disappears and not be visible to the ones who would like to improve, it doesn't help much. The wiki isn't the best place for it- it should go on to the devel-list as well, if you want to see your ideas anytime in FGFS.
Up, up and away
User avatar
HHS
Retired
 
Posts: 3624
Joined: Thu Jul 19, 2007 8:09 am
Version: GIT

Re: AI Systems / Compatibility

Postby Thorsten » Mon Feb 22, 2010 8:43 am

You are mixing things badly here.

You were talking about compatibility among different FGFS versions.
Now you are talking about compatibility of FGFS related to OS. That's an huge difference.


I'm not mixing anything :D I'm talking development philosophies. Linux is to Flightgear what Flightgear C++ code is to the Nasal code of aircraft and scenarios - an environment in which they run. If the Flightgear C++ crew changes the assignment of properties and the parsing of Nasal code, Nasal code ceases to run and must be rewritten. If the developers of OpenSceneGraph make a new version without backward compatibility, Flightgear ceases to run and the C++ code needs to rewritten (and that wouldn't be very pleasant I guess). The virtue of backwad compatibility is not to force people who rely on your code to rewrite theirs all the time - holds for an OS as well as for Flightgear.

FGFS is a work in progress. Sometimes it comes out, that certain things done could be in a other way be better. I do know that the devlopers then try to have backward compatibility where possible. But sometimes it is not possible.


You're seriously telling me there was no way altitude-ft in the AI scenario properties I quoted above could have remained that way instead of being renamed into altitude or an optional choice between the two?

I do know a lot of OpenSource Programs which has a similar or equal way to develope.
And it is not true, that pushed codes can't be seen for Aircraft Developers:


Please read what I wrote: I never said it can't be seen - quite obviously it can be seen. If I had no job, no family and plenty of time, I would browse through the CVS at my leisure and read daily changelog emails. As it is, I have a limited amount of time, I have (probably, maybe, you judge yourself...) good ideas, and I would like to contribute them (and I'm probably not alone in this) - but I have a limited amount of time - either I can study all that goes on in CVS, or I can simply code things based on a stable version where I do not need to keep track of all changes (just imagine all C++ developers had to follow all the developments on the Linux distribution lists and all announcements by Microsoft and Apple to ensure that Flightgear works with the next OS version, all the OpenSceneGraph developments and indeed all other packages flightgear relies on! - how much could they get done?). The same way as Flightgear developers probably rely on the next Linux version being able to run Flightgear, I would like to be able to rely on Flightgear running Nasal developed for a stable version.

It is up to the Aircraft developers if they want to follow or not.


Right... only, if they don't, the code doesn't necessarily work.

But you let an impression here as all things are completly broken, FGFS developement is a chaos...


You may not like my opinion, that's okay - but please be fair - I never said things are completely broken and FGFS development is a chaos, what I actually said above is 'things run in a way well enough as they are right now'.

Well - my experience so far is that none of the stuff which I tried that works fine for 1.9.1 appears to work with CVS and that I often encounter mismatches between documented property assignments and reality (which may be my fault, but is indicative of frequent changes). So please just prove me wrong and help me understand! Maybe it is just me...

You have already tried my thunderstorm scenario which I can run in 1.9.1 - so please by all means let's get together, dissect the thing and understand why it doesn't run in CVS and why and how this incompatibility is for the greater benefit for FGFS! Maybe I just wrote very bad code - then I'll post an apology here, learn for the future and be quiet.

Yep, but when the ideas and algorithm disappears and not be visible to the ones who would like to improve, it doesn't help much. The wiki isn't the best place for it- it should go on to the devel-list as well, if you want to see your ideas anytime in FGFS.


Quite the contrary - I see my ideas already in FGFS - just the rest of you don't necessarily 8) . I told you before - I'm a researcher - I want to work things out, then I document what I have found. I'm not the person to bring anything into mass production - if you don't want the ideas and algorithms, you don't want them. I get this in real life all the time, and it doesn't bother me at all. By the time you decide that, I probably have long moved on to the next project (I might try to really write a real-time cloud fluid dynamics description after all - if you dispense with elegant programming, desktop machines are amazingly fast... 8) )

It is quite okay if you don't want people like me to contribute who have not the time to become involved full-scale and have a different way of doing things. All I'm saying is that I think that is a pity - the structure of Flightgear with the property tree and Nasal scripting is so ingenious - it would certainly allow people like me to get involved more. Look, I'm a theoretical physicist with 10 years experience in scientific computing and large-scale numerical projects, I have been working at supercomputing centers with my projects, I run 30.000 CPU hour jobs in grid computing for a living - I think I could actually contribute one or the other thing to Flightgear, and I would offer to - but I don't have the time for the full-scale involvement and following everything that goes on in CVS you have in mind - so it's the communities call if it wants to open the way or not.
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

Re: AI Systems / Compatibility

Postby HHS » Mon Feb 22, 2010 11:25 am

Some last notes from me:

You're seriously telling me there was no way altitude-ft in the AI scenario properties I quoted above could have remained that way instead of being renamed into altitude or an optional choice between the two?


And where is your problem to change altitude-ft to just altitude? I don't know why this decision was made, as I didn't wrote this code or was involved in this decision. If you want to know why, you have to go on the devel-list, as the developer responsible for that don't read the forums. But yep, it seem you really didn't understand developement here- the affected Scenarios were adjusted in CVS, and if you want to add new codes etc. you need to use CVS.

The forum is the wrong place for such discussions, and anything related to code developement aka Software developement should go into the devel-list- that's the rule in our project here. Btw- the last topic "Software developement" say this clear! Decisions on Developement philosophies don't come in the forum but the devel-list. That's why it is called "Developers"-list! :wink:

I'm not the main developer or head. I'm just a small aircraft developer and as all other developers I have a reallife as well. I didn't made the decision I just trying to be helpfull the way how you could contribute.

It seems you can't see that so I can't help you.

Bye
Up, up and away
User avatar
HHS
Retired
 
Posts: 3624
Joined: Thu Jul 19, 2007 8:09 am
Version: GIT

Re: AI Systems / Compatibility

Postby Thorsten » Tue Feb 23, 2010 8:08 am

And where is your problem to change altitude-ft to just altitude?


*sigh* None with a single thing which I know. Obviously the problem is adjusting many things when I don't know what has been changed. To which you reply that I could follow the developer's list, then I would know. To which I reply that this takes a lot of time, and if things were organized in such a way as to allow to develop for stable code and be certain it runs later, I wouldn't need to. And so on, repeat the loop of arguments by going back to 'And where...'

I am sorry, obviously I am stupid enough to do a bad job explaining an idea which seems really simple to me.

Just think of Wikipedia - if adding scenery to Flightgear would be as easy as contributing to Wikipedia, I'm guessing the Flightgear world would be quite crowded. If Wikipedia standards would change every year and old articles could not be displayed any more on the other hand, few people would bother bringing their articles up to date all the time and Wikipedia would be emptier.

But yep, it seem you really didn't understand developement here- the affected Scenarios were adjusted in CVS, and if you want to add new codes etc. you need to use CVS.


You have this way of getting on the personal level, like comparing me to this Indian person and ascribing opinions to me which I never stated. So now it's my lack of insight. May I kindly ask you not to descend to this level, whatever difference of opinion you see?

I assure you, I understand perfectly well how development here works at the moment - I just don't happen to share the opinion that this is the best way to organize things. I also realize perfectly well that things don't change just because I would like them to be different - I am content with a few folks thinking about what I say - and one or the other reading this may also be on the developer's list.

Decisions on Developement philosophies don't come in the forum but the devel-list. That's why it is called "Developers"-list!


I'll leave that decision if the discussion is really inappropriate here to a Mod since I don't really know - but I am reluctant to flood the mailing list with questions of general development philosophy, since it's not a concrete 'patch, addition, bug fix, or code question'.

It seems you can't see that so I can't help you.


Well, I did ask you to prove me wrong, and I did ask for your help to do so in a concrete case, so it's perhaps more to the point that you won't help me. I never asked you to single-handedly change the way Flightgear development is organized (I am not delusional...). :D
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

Re: AI Systems / Compatibility

Postby HHS » Tue Feb 23, 2010 6:57 pm

Thorsten wrote:Just think of Wikipedia - if adding scenery to Flightgear would be as easy as contributing to Wikipedia, I'm guessing the Flightgear world would be quite crowded. If Wikipedia standards would change every year and old articles could not be displayed any more on the other hand, few people would bother bringing their articles up to date all the time and Wikipedia would be emptier.


Well, to be honest, as long you keep to the rules of contributing to scenery-database, it is very easy. What isn't easy to get is the origin datas etc. for your objetcs- size, position etc. Of course you can allways add just white untextured cubes into- nobody will ever mind it! ;-)

And that's exactly the opposite way to wikipedia were things a bit more complex....

Of course it is bad if there is absolutly no backward compatibility. But Nasal and the AI-scenarios have been the only things which has been changed this way and all what I know there was no better solution. But with that some really nasty things has been improved and fixed.

You really let the image here, that every version of FGFS is 100% not-backward compatible- and that's not true.

You have this way of getting on the personal level, like comparing me to this Indian person and ascribing opinions to me which I never stated. So now it's my lack of insight. May I kindly ask you not to descend to this level, whatever difference of opinion you see?


It isn't going down to a personal level when I see that you don't understand how our project is working and I say this clear to you. And the example of the indian guy had to be to show you how you are already acting here.

All things I say here are ment and said in a objective way- not as an affront.
Up, up and away
User avatar
HHS
Retired
 
Posts: 3624
Joined: Thu Jul 19, 2007 8:09 am
Version: GIT

Re: AI Systems / Compatibility

Postby Thorsten » Thu Feb 25, 2010 8:17 am

You really let the image here, that every version of FGFS is 100% not-backward compatible- and that's not true.


If my statements can be read that way, it is not my intention, and I apologize if I created the impression that FGFS is not at all backward compatible or that development is a mess. I repeat again - things run in a way well enough the way they are right now.

So, let's see what runs and what doesn't without changes in 2.0 before talking further about backward compatibility.

And the example of the indian guy had to be to show you how you are already acting here.


Quite frankly, 'this had to be' is almost always wrong. Maybe try kindness instead - it is not your place to teach me how to conduct myself here, you are neither Mod nor Admin, and there's nothing you can gain by antagonizing me or making me angry - all that can happen is that I stop to listen to what you say. But there's a lot that can be gained with a smile. :D
Thorsten
 
Posts: 11470
Joined: Mon Nov 02, 2009 8:33 am

Re: AI Systems / Compatibility

Postby HHS » Thu Feb 25, 2010 2:32 pm

Thorsten wrote:
Quite frankly, 'this had to be' is almost always wrong. Maybe try kindness instead - it is not your place to teach me how to conduct myself here, you are neither Mod nor Admin, and there's nothing you can gain by antagonizing me or making me angry - all that can happen is that I stop to listen to what you say. But there's a lot that can be gained with a smile. :D


You are right, I'm not a Mod or Admin. But as I was one part of this discussion, and was not to made you angry or anything like that. But just to show you why anger about some things isn't recommended and even to show you has been looking in this discussion.

And well, even you stop listening, then I have to live with. I can't , won't and don't want nobody to force to listem to me, as I'm not the one with the 100% truth.
I just wanted to tell you that being angry about certain things hwo FGFS works isn't recommended and certainly the forum not the best place for.
Up, up and away
User avatar
HHS
Retired
 
Posts: 3624
Joined: Thu Jul 19, 2007 8:09 am
Version: GIT

Re: AI Systems / Compatibility

Postby Hooray » Thu Feb 25, 2010 4:11 pm

Actually, I do absolutely agree with you, Thorsten.

Simply phasing out features that were available in previous releases without documenting this or without at least providing a migration path, is a very unfortunate thing, at best.

But it is also important to realize that many people in the FlightGear community do not natively speak English as their first language, so not everybody may realize it when he sounds impolite or even rude.

I am sure, that this is only rarely -if ever- intended.

Most of us share a certain passion for flight, flight simulation and FlightGear/open source in particular.

It is probably this very passion that also sometimes makes some people sound defensive or even offensive, when the knee jerk reaction kicks in and the "FlightGear defense mode" is activated ;-)

So, personally I really wouldn't bother participating in any crusades or flame wars in the FlightGear community.

All of us are here because we appreciate FlightGear and the work that everybody is putting into it.

Even those among us who frequently find words of criticism to describe some annoying FlightGear glitches or issues, do so out of a certain degree of passion: You don't critize something if you don't care about it!

Most of us have specific areas of interest and visions for using FlightGear in one way or another, sometimes it's frustrating to see how others do things that appear counter intuitive to achieving a certain goal and so we have to voice our opinion, sometimes we fail at doing that tactfully.

I really don't know if that particular "attitude-ft" property has been deliberately renamed or what the reasoning behind omittin the suffix really was (you might be able to check the CVS logs).

But I do agree that -at first glance- it seems very counter intuitive to remove a suffix that seems otherwise fairly common practice (and actually a convention) in the rest of FlightGear.

As HHS has already pointed out, he is not a core developer - he is primarily an aircraft developer, and a very skilled one I may add, he has created very impressive aircraft with amazing levels of detail for FlightGear (I don't know though, if he has meanwhile been given CVS write access to the base package, he would certainly deserve it!).

So he doesn't necessarily speak on behalf of the developers, even though he is certainly trying to help by posting here ;-)

Few developers will actually check back here and post to these forums. If they do, you may not even identify them as such, at least not without also tracking the CVS commit logs (though, sometimes their cvs handle may be different from their forum nick).

As HHS has rightly said previously, these forums are primarily meant to be used by users and not necessarily intended for development related discussion.

Development related feedback is better requested and provided using the official communications channels, which is the FlightGear devel mailing list.

I tend to forget this myself every now and then, but I also think that development would be more transparent if all discussions took place using these forums. After all, not even the mailing lists are a guarantee to get feedback at all - sometimes even there, questions end up without replies.

The nature and high degree of technical topics that you are bringing up here Thorsten, is probably really better dealt with on the developers mailing list, where more people will be able to understand your questions and actually provide reliable feedback and constructive suggestions.

Also, so far only long-time users and base package contributors actually bothered to reply to this thread, which is certainly because it is so technical in nature.

HHS is also right in saying that the wiki is not meant to be the primary source for reliable information about core development, fgfs core features are indeed usually documented in the $FG_ROOT/Docs directory (in the form of plain text files).

However, speaking realistically: the wiki is the most accessible and the most regularly updated source of information about FlightGear, it is completely community driven and anybody can get involved to improve things. So it is understandable that you were looking for reliable information there, in many aspects the wiki provides much higher quality documentation than any other sources.

A good compromise might be to start tagging and branching wiki articles, so that wiki articles are frozen for each release and branched for CVS development, so that the stable release is being documented using a frozen tagged article, while CVS development progress would be documented in the branch.

HHS has also said that he appreciates the work you are doing Thorsten, so I think he was mostly trying to explain to you how FlightGear development "works".

And that is in fact quite a complicated issue, I am sure that even some of the long time contributors cannot easily summarize the "development philosophy" (if there is such a thing at all) of the FlightGear project easily.

To be honest, I don't think that there is anything like a "development philosophy" written down somewhere, or that the FlightGear "development model" is actually documented anywhere.
Just recently, it was brought up in another discussion, how the FlightGear "goals" page was totally outdated: viewtopic.php?f=5&t=7065

And the closest thing to it, would be the "long term goals" page, which is ironically hosted on the wiki and doesn't seem to be written by core developers.

So, as a newcomer it is admittedly hard to understand how FlightGear development is working behind the scenes.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11605
Joined: Tue Mar 25, 2008 8:40 am


Return to AI Traffic

Who is online

Users browsing this forum: No registered users and 0 guests