#Flightgear scenery editor code

#Flightgear scenery editor code

code duplication, you end up with duplicate code bases that need to be kept in sync manually) - core developers like zakalawe have already acknowledged, that they are working towards pursuing this approach, simply because it is most effective in the long run: Seriously, I am absolutely convinced that if you can come up with 5-12 essential features, that I could come up with a list of corresponding FlightGear enhancements, that would achieve 80-90% of what you need in less than half the time required if you were to do the same thing from scratch in a completely standalone program.įor example, just consider the approach taken by the 'fgpanel' addon at the moment (i.e. So this could also work to come up with a down stripped startup mode for FlightGear, where subsystems would no longer be loaded and run automatically, but rather on demand. For example, when you run fgfs in a non-scenery area (ocean) with the ufo, it isn't resource hungry at all, simply because there's lots of code that isn't even getting invoked. Regarding resource usage, you have to keep in mind that it is proportional to the features and code being used. While you would obviously add to an existing code base, many systems, and thus, code paths would never be utilized at all. You would not end up with a 'code monster' if you make FlightGear more configurable, my making more of its subsystems optional and making them more runtime configurable, too. The main problem for any such tool is implementing features quickly, this requires a fair amount of preexisting infrastructure and supporting code. This has also been discussed 1.5 years ago on the devel list in response to some requests made by former FG core developer David Megginson. But overall, this doesn't sound impossible, because that's basically the same approach as taken by the local weather system. Obviously, you would need to make some subsystems optional that are currently running by default. So this would probably be all about adding a 5-10 new scripting commands and exposing some more properties and making some more things configurable that way. This should be quite possible to do and much easier than creating something from scratch. I think the simplest and most promising approach would be building this on top of FG itself, FlightGear is internally already able to process all important file formats (scenery, aircraft, BTG, STG, XML etc), so you could probably hack FlightGear to support a different startup mode so that it can become an editor for creating scenery, cockpit panels, instruments and such - even GUI files (dialogs) etc. Most of this should be fine to implement in scripting space. Can geolocate graphic files (manually or if the format provides data, automatically) and generate local scenery textures from them Imports various data types, particularly graphic formats for textures, different height grids, maybe even different 3D object formats airports, roads, objects, textures, height data, etc. Fully unified - handles ALL aspects of scenery, e.g. 3D mode using FG rendering engine for instant preview and e.g. roads, runways, place objects, modify city boundaries, AI patterns (!!!), etc. 2D mode with maplike display for drawing e.g. can open, modify and save the files in $FG_SCENERY So here's my 2ct on that (in order of importance) I wanna exchange ideas with other would-be scenery designers but also hope that maybe someone gets a flash and thinks 'hey, that's actually a cool idea, I'm gonna start coding'. Having been active in the MSFS world quite a bit and knowing my fair share of BGL-editors, I'd like to start a thread to collect some ideas how the 'perfect' scenery editor would look like.