[Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Hi all, there was a fly-in today in New Zealand, and even though a lot of us flew the same plane from the same author, we could only see each other as gliders. Why ? Because in the past couple months, some aircraft used today have undergone model file name changes as well as set file name changes, breaking compatibility for MP visualization purposes with previous versions (and preventing older versions of seeing the new ones also). MP being an heterogeneous environment as far as FGFS versions are concerned, I thought I'd point it out, and that some thought should go into renaming set and model files to avoid this kind of situation. The specific culprits today are Syd Adams (dhc2, for sure and dhc6 also, I think) and Gerard Robin (PBY-Catalina). There might have been more cases today, and I think we have a few more a/c in cvs who exhibit those symptoms :) This can be done by having the old set files and model files point to new ones in updated versions, so compat is maintained with older versions, for people flying the new one. Someone who knows the system more intimately can confirm whether it's just the set file, the model file or both that needs to be setup for this to work. Albeit, for people with older version, it seems they'll have to add the same kind of aliases for the new set and model files to see updated versions... I think this is a strong case for NOT needlessly changing set and model file names just to clean up things... Or, if the aircraft now exists in cvs and externally maintained versions, the considerate thing would be to rename the externally maintained version's folder so interested parties can have their cake and eat it : have both versions installed in the case of the Catalina (and other a/c maintained by Gerard which are both in cvs and his hangar). Not sure why this wasn't done for all of Gerard's a/c from the get go, as I seem to recall he changed folder names in at least one instance when he stopped maintaining the CVS versions. Or any other solution agreed upon by the community as how to deal with that particular MP issue. I'm sure it was all unintentional and a simple lack of foresight on the consequences such changes might have, but there we have it. Thanks for reading, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Yes , I'm one of the culprits , and it's not a lack of foresight ,I've done it for a reason. MP is not my biggest concern , I did these aircraft for my own purposes , not entirely with gamers in mind ... but Im glad some like them all the same. These aircraft use one fuselage model now , with gear and other aircraft specific options selected depending on type or name, with cockpit and internals separated to be selected within a certain distance.So there IS no dhc2floats or dhc2wheels. It can be set so the model is visible with older versions ,by adding another animation xml file with those names and adding the neccesary ac model bits ,but in my opinion adds more garbage to the folder. I,ve been updating the dhc-2 for more realistic behavior, (sorry gamers);), so it's nearly ready for another commit, and I can add the old versions , but there's also the option of adding these to the AI/Aircraft .Any idea on which option we should take from the rest of the modellers ? (My problem with that is you end up with two aircraft to maintain, and I tend to forget about the AI version). The specific culprits today are Syd Adams (dhc2, for sure and dhc6 also, I think) and Gerard Robin (PBY-Catalina). There might have been more cases today, and I think we have a few more a/c in cvs who exhibit those symptoms :) I'm sure it was all unintentional and a simple lack of foresight on the consequences such changes might have, but there we have it. Thanks for reading, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Mathias Fröhlich wrote: Hi Tim, On Thursday 25 June 2009 23:58:42 Tim Moore wrote: Mathias Fröhlich wrote: Hi Tim, Seriously, I didn't realize that reducing dependencies on OSG in simgear is a design goal. That's fine, but I would really prefer to not think about whether I need to pass an SGVec3d or an osg::Vec3d to a function, or whether a smart pointer should be an osg::ref_ptr or an SGSharedPtr or... I see you point. I would not tell that a hard requirement. But we definitely have parts in a simulation that just do not need to know that they run on osg/OpenGL. Imagine you want to change the viewer library. All the physics is still the same. By mixing osg classes into everything without any type abstraction in between, you need to rewrite the whole pile of code. Even for parts that do not depend on any viewing crap at all. I already did so when I started to switch to osg and plenty of that work was almost only for that reason we have all the sg types directly spread around. So please avoid having osg::whatever spread around in the whole application ... I understand the desire, it's just that I thought of simgear as a glue layer between OSG and flightgear, and thus OK to use OSG datatypes everywhere. I'll be more restrained in the future. Anyway, I screwed around a bit with making the SGVec types more directly compatible with OSG functions. Conversion operators don't help much; making osg::Vec types be public superclasses of SGVec helps a lot of course, but I can understand if you don't want to go that route. In the end, I can live with the status quo for my purposes. Appart from that, having more separate code paths in general for the simulation parts and the viewer/scene parts would help for plenty of our scalability problems a lot. So just thinking about general software design ... So nothing is set in stone here, but it makes sense IMO to head into that separation where possible/sensible. More in detail for the reference counting. I do not like the referenced implementation of osg. That is already very heavyweight. Has some members we do not need in any way in something simulation dependent. The observed_ptr stuff is not thread safe, also that observer implementation does not scale well if you have many observers. Referenced already has a vtable. Just to name a few ... What we have is a very weak thing that could be used in the same basic way but is way more flexible even for smaller objects. I would prefer to keep that own implementation. The same goes for the osg vectors. They are neat, but inconsistent over the member types. Also the collision system is missing there. We can now rely on std::tr1:shared_ptr and its cousins, through Boost if need be, so perhaps we could come up with some nice templates to paper over the differences between OSG pointers an our own. Just to be more flexible with extensions in this area we might need, I would like to have our own stuff. So I do not need to introduce a change to Robert and then wait a few months before I can rely on people having that change available in flightgear ... I can find many more benefits of this stuff we have already. The rule of thumb when to use what is simple: If you are in the scene graph most probably osg::... might be a good thing to use. If you are in the simulation, network, input system, property system, wherever not scene graph dependent, use simgears own classes. So I would not tell that a hard design goal. But If we can make that I believe that we will get a benefit in doing so in the mid/long term. Sounds reasonable. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Thanks a lot for adding the model files to CVS, I was just done posting my own version of them on the forums :) I meant nothing by culprits, in case that wasn't clear, just as an example of what his us today : I'm a fan of your work on the Beaver and Twin Otter. I had completely forgotten about the Beaver model change, even though I had seen the cvs logs and wondered about it. The catalina, I didn't get around to having a fix around before today and warning people about it. Just wanted to bring this (back) to attention, as not all the userbase will dig deeper if the same aircraft with the same author doesn't work right away in MP ;) It would indeed be nice to hear what the modellers and devs have to say on how this should be tackled. Cheers, Nic On Sun, Jul 5, 2009 at 3:56 PM, syd adams adams@gmail.com wrote: Yes , I'm one of the culprits , and it's not a lack of foresight ,I've done it for a reason. MP is not my biggest concern , I did these aircraft for my own purposes , not entirely with gamers in mind ... but Im glad some like them all the same. These aircraft use one fuselage model now , with gear and other aircraft specific options selected depending on type or name, with cockpit and internals separated to be selected within a certain distance.So there IS no dhc2floats or dhc2wheels. It can be set so the model is visible with older versions ,by adding another animation xml file with those names and adding the neccesary ac model bits ,but in my opinion adds more garbage to the folder. I,ve been updating the dhc-2 for more realistic behavior, (sorry gamers);), so it's nearly ready for another commit, and I can add the old versions , but there's also the option of adding these to the AI/Aircraft .Any idea on which option we should take from the rest of the modellers ? (My problem with that is you end up with two aircraft to maintain, and I tend to forget about the AI version). The specific culprits today are Syd Adams (dhc2, for sure and dhc6 also, I think) and Gerard Robin (PBY-Catalina). There might have been more cases today, and I think we have a few more a/c in cvs who exhibit those symptoms :) I'm sure it was all unintentional and a simple lack of foresight on the consequences such changes might have, but there we have it. Thanks for reading, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous
Hi Nicolas, Nicolas Quijano wrote: The specific culprits today are Syd Adams (dhc2, for sure and dhc6 also, I think) and Gerard Robin (PBY-Catalina). There might have been more cases today, and I think we have a few more a/c in cvs who exhibit those symptoms [...] Or, if the aircraft now exists in cvs and externally maintained versions, the considerate thing would be to rename the externally maintained version's folder [...] If you're expecting a 'stable' setup, please make sure that everyone's using either the latest release or current CVS. I don't see why aircraft developers should maintain backward compataibility in a development !! tree just for users/gamers pleasure. Well, and If you're using aircraft which are maintained externally nobody but you is responsible for your choice. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
I'll fix the dhc-6 , but have to go back through cvs file to remember what the original names were . Im not crazy about people putting different verions of my aircraft on the forum as it kind of makes my work pointless , but it's bound to happen. I think I prefer to do it in the aircraft model folder rather than AI , since it will be easier to remember to remove when no longer needed. Cheers On Sun, Jul 5, 2009 at 2:18 PM, Nicolas Quijano nquij...@gmail.com wrote: Thanks a lot for adding the model files to CVS, I was just done posting my own version of them on the forums :) I meant nothing by culprits, in case that wasn't clear, just as an example of what his us today : I'm a fan of your work on the Beaver and Twin Otter. I had completely forgotten about the Beaver model change, even though I had seen the cvs logs and wondered about it. The catalina, I didn't get around to having a fix around before today and warning people about it. Just wanted to bring this (back) to attention, as not all the userbase will dig deeper if the same aircraft with the same author doesn't work right away in MP ;) It would indeed be nice to hear what the modellers and devs have to say on how this should be tackled. Cheers, Nic On Sun, Jul 5, 2009 at 3:56 PM, syd adams adams@gmail.com wrote: Yes , I'm one of the culprits , and it's not a lack of foresight ,I've done it for a reason. MP is not my biggest concern , I did these aircraft for my own purposes , not entirely with gamers in mind ... but Im glad some like them all the same. These aircraft use one fuselage model now , with gear and other aircraft specific options selected depending on type or name, with cockpit and internals separated to be selected within a certain distance.So there IS no dhc2floats or dhc2wheels. It can be set so the model is visible with older versions ,by adding another animation xml file with those names and adding the neccesary ac model bits ,but in my opinion adds more garbage to the folder. I,ve been updating the dhc-2 for more realistic behavior, (sorry gamers);), so it's nearly ready for another commit, and I can add the old versions , but there's also the option of adding these to the AI/Aircraft .Any idea on which option we should take from the rest of the modellers ? (My problem with that is you end up with two aircraft to maintain, and I tend to forget about the AI version). The specific culprits today are Syd Adams (dhc2, for sure and dhc6 also, I think) and Gerard Robin (PBY-Catalina). There might have been more cases today, and I think we have a few more a/c in cvs who exhibit those symptoms :) I'm sure it was all unintentional and a simple lack of foresight on the consequences such changes might have, but there we have it. Thanks for reading, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Sorry, I was going to send you the changes right after posting, should have done it the other way around. But your commits made it all moot, so I removed the archive attachment in my forum post. Thanks for doing something about it with that much speed, Cheers, Nic On Sun, Jul 5, 2009 at 5:37 PM, syd adams adams@gmail.com wrote: I'll fix the dhc-6 , but have to go back through cvs file to remember what the original names were . Im not crazy about people putting different verions of my aircraft on the forum as it kind of makes my work pointless , but it's bound to happen. I think I prefer to do it in the aircraft model folder rather than AI , since it will be easier to remember to remove when no longer needed. Cheers -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Nic, It's also worth pointing out (again!) that users of CVS must accept that FG and its associated models are constant works-in-progress. Issues like you describe are easily fixable prior to an official release, but are difficult to manage in the constant state of flux between them. I'm in agreement with Syd that the benefits from changes which simplify an aircraft model's delivery outweigh the relatively small and temporary annoyance that comes with them. Cheers, -R. Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu From: Nicolas Quijano nquij...@gmail.com To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Sunday, July 5, 2009 5:18:00 PM Subject: Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts Thanks a lot for adding the model files to CVS, I was just done posting my own version of them on the forums :) I meant nothing by culprits, in case that wasn't clear, just as an example of what his us today : I'm a fan of your work on the Beaver and Twin Otter. I had completely forgotten about the Beaver model change, even though I had seen the cvs logs and wondered about it. The catalina, I didn't get around to having a fix around before today and warning people about it. Just wanted to bring this (back) to attention, as not all the userbase will dig deeper if the same aircraft with the same author doesn't work right away in MP ;) It would indeed be nice to hear what the modellers and devs have to say on how this should be tackled. Cheers, Nic On Sun, Jul 5, 2009 at 3:56 PM, syd adams adams@gmail.com wrote: Yes , I'm one of the culprits , and it's not a lack of foresight ,I've done it for a reason. MP is not my biggest concern , I did these aircraft for my own purposes , not entirely with gamers in mind ... but Im glad some like them all the same. These aircraft use one fuselage model now , with gear and other aircraft specific options selected depending on type or name, with cockpit and internals separated to be selected within a certain distance.So there IS no dhc2floats or dhc2wheels. It can be set so the model is visible with older versions ,by adding another animation xml file with those names and adding the neccesary ac model bits ,but in my opinion adds more garbage to the folder. I,ve been updating the dhc-2 for more realistic behavior, (sorry gamers);), so it's nearly ready for another commit, and I can add the old versions , but there's also the option of adding these to the AI/Aircraft .Any idea on which option we should take from the rest of the modellers ? (My problem with that is you end up with two aircraft to maintain, and I tend to forget about the AI version). The specific culprits today are Syd Adams (dhc2, for sure and dhc6 also, I think) and Gerard Robin (PBY-Catalina). There might have been more cases today, and I think we have a few more a/c in cvs who exhibit those symptoms :) I'm sure it was all unintentional and a simple lack of foresight on the consequences such changes might have, but there we have it. Thanks for reading, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
