BGL Compat

[PhilTaylor 45]

Community,we are considering snipping BGL so that it is only a container system, no rendering behavior.what beside the category system and seasonal variation is currently in use by 3PDs?thanks!

[Mace 1,927]

>Community,>>we are considering snipping BGL so that it is only a container>system, no rendering behavior.>>what beside the category system and seasonal variation is>currently in use by 3PDs?>This post almost slipped by me.Phil this might be best asked over at FSDev or a site like that. Maybe you have done that already.I'm not quite sure what you are asking. I can tell you what I have used in my scenery design projects, that is in bgl:TimeZoneSeasonLandclassWaterclassSceneryObject/MDL/gmax/3ds/obx dataVector data/cvx dataAI/TrafficAirport data/apxDEM/elevation dataWhat else have I used? Can't recall offhand.A container system. How interesting! I'll have to think about that some...RhettAMD 3700+ (@2585 mhz), eVGA 7800GT 256 (Guru3D 93.71), ASUS A8N-E, PC Power 510 SLI, 2gb Corsair XMS 3-3-3-8 (1T), WD 150 gig 10000rpm Raptor, WD 250gig 7200rpm SATA2, Seagate 120gb 5400 rpm external HD, CoolerMaster Praetorian

[PhilTaylor 45]

it is posted here in this forum, in the scenery design forum here, and at the "other terrain" forum at fsdeveloper.com.basically we are trying to see if lopping off any and all rendering behavior in BGL, so that it just contains data - is that going to be ok.

[MillKa 0]

Hi Phil,i am working on a map / flight planner application, so i need all navigation data and whatever else makes sense on a map.This is the bgl data that i need and that i am able to read:- waypoints / intersections, V/J routes, approaches, transitions- radio nav aids: ndb, vor, dme, loc, gs, im/mm/om, com- airports, runways, taxiways, names- airspace structure, geopolitical boundariesThis is the data i am not yet able to read:- raster data: dem, landclass, ...- vector data: roads, railways, ...It would be great if future versions of the FS/ESP SDK would document the binary formats.Martin

[Guest christian]

Hi PhilThanks for your message, much appreciated asking us developers!I think it's a good move to make the scenery file a container and move away from the scripting (this is in line with what you've done over the last versions anyway).On the spot, the only restriction I can think of is exposure of conditions. What I really miss is being able to query sim vars and make container parts conditional. I think this could work via xml similar to the aircraft models. Exposing sim vars (like it's done in the old bgls) to scenery would really help us out (time (hour, month, year) of course being high up the list, but radio controlled lighting could also be possible this way, or conditional actions (proximity of aircraft, etc)!If you do this quite generically (ie external xml control), this could be used for great scenery design, such as varying the landclass over time, simulating tides, having golden age airports, etc.Anyway, a 'condition system' I think is something most developers would want, otherwise a container system should be ok.Best wishes,Christian

[Guest]

As long as the data remains accessible, why not.I've always found the mixing of data with application code in one file to be a bit of an abomination (not just in FS), as well as the use of a single extension for different data formats.That said, things like AFD and traffic flightplans are of course data, though a strong argument could be made that they deserve their own file formats, formats that might be better off as text data so they're easier to maintain and read (handy for for example flight planners) with tools available to the average user.Same with the waypoint and navaid databases.Or if they are compiled for performance reasons (which I can fully understand) shipping the file formats with the SDK and possibly an API to read the data from FS itself using for example SimConnect would be a very viable alternative.

[DadJokeCinema 145]

>it is posted here in this forum, in the scenery design forum>here, and at the "other terrain" forum at fsdeveloper.com.>>basically we are trying to see if lopping off any and all>rendering behavior in BGL, so that it just contains data - is>that going to be ok.I think this is a fabulous idea. I can't really add any reasons to not do it because my work with BGLs has been from a "Figuring them out" point of view so far, but I'm happy because I feel this will assist back-compat and contain the rendering code to the core engine.