Understanding Forward Compatibility
Jump to navigation
Jump to search
 This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.
|
| Working together |
|---|
| The project as a whole: |
| Users and feature requests: |
| Communication: |
|
|
| Note maybe move this somewhere else ?? |
|
I see what you are trying to do there - but I think there are too many misconceptions here, you should stop doing that right now - what you are trying to do simply isn't feasible, and you are only doing it because you don't understand all the repercussions yet. That being said, Nasal is NOT the issue here - regardless if you are using 2.10, 2.12, 2.99 or even 2.0: The FlightGear binary will include an integrated Nasal interpreter. However, that's just one part of FlightGear - it works like JavaScript in your browser: as an embedded extension language, and the language has various bindings to other subsystems. So you cannot simply rip apart the simulator and put things back together afterwards - even if you were a really experienced C++ developer with 5+ years of FG experience, you wouldn't be doing that - simply because it's a bad idea, and there are better ways to solve such issues (such as using the latest binary, or fixing any issues that prevent you from running it). The bottom line being, you cannot simply take fgdata 2.99 and try to run it with a 2.10 binary and expect things to work |
|
|
|
Don't expect 2.6 aircraft, addons,... to work, "forward compatibility" isn't something that can done.
|
|
|
|
I don't think that's a particularly fair thing to ask, and I don't think you can run FSX airplanes on Microsoft FlightSim 8 (which is the proper comparison). FG is (in a limited way) backward compatible in such that a 2.9 binary runs many airplanes which have been released with 2.4. What you're asking however is forward compatibility, i.e. a 2.4 binary should be able to run airplanes for future releases - and that's just impossible to do. New airplanes rely on new features present in the binary - for example a lot of MFD and HUD technology is now being built around canvas. Cavas doen't exist in 2.4, so there is no way this can be supported properly, even if we wanted to. If you have 2.4, you'll need to use airplanes released for 2.4. |
|
|
|
This is not at all about "backward compatibility" - what you are asking for is sort of "forward compatibility". (see the [./images/smilies/icon_lol.gif linked image]) What you have basically done is creating a document in "Microsoft Office 2010", and now you expect to be able to open this document in "Microsoft Office 97". This is of course not possible. You have used new features that didn't exist in previous versions of FlightGear - FlightGear is improving, and you are basically complaining about the fact that these new features were not yet available in prior FlightGear versions. Backward "posthilit">compatibility is about supporting features of past software versions in new/future versions. You are asking for the reverse. To explain this even more bluntly: If users started to use YOUR aircraft now with FG 2.0, they would probably complain that YOUR aircraft was not implemented with backward "compatibility in mind - simply because your work doesn't work with older FG versions. Weird world, isn't it |
|
|
|
In other words, you cannot expect today's newspaper to show up in the archives of 2010 - that's all there's to it, really. Imagine for a second using "Photoshop 2013" - saving a file and trying to open it in "Photoshop 1999" - while the data is there, the program/code doesn't know how to deal with it. |
|
|
|
Sorry to say it so bluntly, but currently you are wasting your time, because you are trying to do stuff that simply isn't feasible, probably because you are too eager to do something, rather than spend some time reading through the docs (especially the wiki). Like I mentioned in your other thread, you are trying to solve issues that you ended up creating in the first place. We really welcome all contributors and contributions, but I really suggest to spend 2-3 weekends getting up to scratch with the docs to fill in some gaps - otherwise, you'll probably end up realizing way too late that you wasted your time... At the moment, you are obviously facing a bunch of issues that are completely unrelated to FlightGear - as can be seen by your previous comments WRT saving files with a custom file extension - Nasal's "nas" extension is completely custom and unlikely to be offered by any stock editor, unless it happens to have Nasal support (see the syntax highlighting link) - but that's a no-brainer really, you can always use a custom file extension (overwriting *.txt) or simply rename things afterwards (if using notepad). In summary, please spend 2-3 weekends digging through the wiki, and you'll quickly realize that you didn't understand the real problem, so that you were trying to solve issues that aren't there really, and that cannot be solved realistically the way you were hoping. |
|
|
|
We're not just talking about a "challenge" here - we're talking time machine-challenge when it comes to "forward compatibility"
|
|