Board index FlightGear Development Scenery

Belgian scenery

Questions and discussion about enhancing and populating the FlightGear world.

Belgian scenery

Postby dvanmosselbeen » Wed Jul 10, 2019 10:08 pm

Hi FG users,
Just to announce that the Belgian scenery development is back on track :-) An entry has been created on the FlightGear Newsletter of June 2019.

The Belgian scenery development started around 2011 in solo by David Van Mosselbeen and stalled around 2013. Some parts of the scenery has been pushed to TerraSync around 2015. Since then, not much has been pushed to the TerraSync server.

The old external Belgian scenery that was hosted on gitorious host (which is read only now) has been imported to a new github host account in 2018. Since then, many updates have been pushed to the new repository.

I need help to get a good promotional screenshot for the Newsletter to represent the scenery of Belgium. (Sorry, my ufo skills are limited for the moment).

Image
Screenshot of EBSW, a heliport very close to Brussels.

Even if it's a bit against the spirit of the (TerraSync) scenery development (mind the pain and the limitation of the TerraSync web interface), i recommend to use the WIP scenery that is available on the github repository if you want to make use of the latest Belgian scenery features. Please test and reports issues on the issue system of the repo or contact me (preferences for an email). That way we can ensure that most of the bugs are gone before the scenery get pushed to TerraSync.

Here you can find the full list of developed airfields.

To give a quick overview, here's a list of airports / airfields that are concerned in the Belgian Scenery:

EBAL - Aalst Hospital helistrip. (Comming soon) (Blender draft model only)
EBAV - Avernas (100% done)
EBAW - Antwerp Deurne (60% done - Basic textures)
EBBE - Bauchevain (40% done - Only placed my generic hangar bunker but that fill up a lot of blanc spaces on this airbase).
EBBL - Kleine-Brogel (98% done)
EBBR - Brussels Airport (75% done - Bloatware region - Also look to all these buildings in Brussels and landmark).
EBBY - Baisy-Thy (100% done)
EBBZ - Buzet (100% done)
EBCF - Cerfontaine (100% done)
EBCI - Brussels South (Charleroi) (40% done - very basic texturing)
EBFN - Koksijde (25% done - Base blocs only)
EBFS - Florennes (25% done - Base blocs only)
EBGB - Grimbergen (100% done)
EBGG - Geraarsbergen Overboelare (Airport layout only - TaxiDraw)
EBLE - Sanicole (Airport layout only - TaxiDraw)
EBLN - Liernu (Airport layout only - TaxiDraw)
EBOS - Oostende (80% done)
EBSG - St. Ghislain (100% done)
EBSL - Zutendaal (Airport layout only - TaxiDraw)
EBSP - Spa (Airport layout only - TaxiDraw)
EBSW - Sint-Pieters-Leeuw (Heliport) (100% done)
EBTY - Tournai Maubray (100% done)
EBZH - Kiewit (base blocs only) (NEW WIP)
EBZW - Zwartberg (Airport layout only - TaxiDraw)

A dedicated Belgium page has been created on the FlightGear wiki to give an overview of the status.

There are also wiki pages stored on the github account with more information about the airports and with screenshots. In the meantime this will be also pushed to the FlightGear Wiki. But like everything is in development, stuff change a lot there. (Mind to avoid overloading with many wiki revisions on the FG wiki)

Of course, this scenery is licenced as GPL v2 and my long term goal is to get everything pushed to the TerraSync server. Bur for now, most things is only available as external scenery. Understand that it's way to difficult to push a daily update to TerraSync. And like the scenery is all about Work In Progress...

I'm very open to work on new (Belgian only) airfields at request. I'm proud that an ULM pilot student (Aaron L.) asked me to collaborate to work on his home airfield EBZH. Of course, as this is the first request, i will give my priority for this new airfield. But feel free to request me to work on (Belgian only) airfields.

P.S. To avoid the same issue that i have now, i would like to ask you to not push stuff to the TerraSync server without my approval. Some stuff has been pushed to TerraSync server in the past and now it's a huge pain to maintain. To be clear, i don't want "parts" to be pushed to the TerraSync server. I prefer that a whole airport / airfield to be pushed to TerraSync. Or at least, that we discuss beforehand what will be pushed. That way i can look if the concerned objects are ready to be pushed to TerraSync (mind optimized).

Disclaimer: I don't want that ownership of my scenery get stolen again like Martin Herweg has done by publishing parts of my scenery to the TerraSync database and auto proclaim to be the author of objects I have made. He have pushed my stuff to the TerraSync server, alright, but don't claim to be the owner of the huge amount of objects I made . This is my stuff I made from scratch! A minimum of respect has to be applied! Please fix your error and give back my ownership on the scenery database!


EDITED: Fixed up some bad language and some url's and tried to cleanup things and be more clear.

Enjoy your flight and see you in air !
Kind regards,
David Van Mosselbeen
http://www.davidvanmosselbeen.be
david.van.mosselbeen@gmail.com
mobile phone: +32 496 28 38 96
Last edited by dvanmosselbeen on Fri Jul 12, 2019 12:04 pm, edited 1 time in total.
Proud to work on Belgian sceneries: https://github.com/dvanmosselbeen and the Rans S-6S aircraft: https://github.com/dvanmosselbeen/Rans-S-6S
dvanmosselbeen
 
Posts: 68
Joined: Sat Feb 26, 2011 2:54 pm
Location: Brussel
Callsign: B-ITCH
IRC name: dvanmosselbeen
Version: git
OS: Debian / Windwoss

Re: Belgian scenery

Postby Isaak » Thu Jul 11, 2019 5:20 am

Hi David,

As PM'ed before: glad you are back, looking forward to see some work done to my home country again!

Regarding the scenery uploaded to Terrasync without your consent: I didn't immediately find a license on your github. Was your work unlicensed before? If it had a copyright/-left license that is incompatible with the GPL v2 we use, this is quite a big issue, as this could easily corrupt objects in our scenery database. I think Torsten should step in to see if we can fix this, eventually by removing your work until you decide it's time to (re)upload it.

Don't understand me wrong: I 'm a big pro for centralising our scenery on Terrasync. Everyone has the same, good looking, scenery and we don't get issues in an MP environment, but I totally understand that you prefer to finish your work on a certain airport before committing it in one time.

Now on topic: the current EBBR scenery on Terrasync: the two terminals aren't aligned very good to the groundnet at the moment and the groundnet will need an update since the Connector has been built. I don't know if that 's also the case on your github, but it's an issue I thought was worth mentioning.

My modelling skills are still very basic, almost non existent, but I am willing to learn and contribute, so if you have some work that you'd like to get done, please ask me and I 'll see if I can be of any help.

And a last comment regarding static aircraft/ground equipment: there's recently been some talk on static aircraft on parking stands etc. In an ATC enviroment (e.g. on VATSIM, which is already possible but will become increasingly popular as FG will be capable of connecting to their network almost out of the box starting with FG 2019.2.x) people like to have all stands available for parking, as they might get a gate assignment that is already taken by a static aircraft or by some ground equipment blocking the stand (or even a taxiway, I remember crashing my 777 once at LFPG because someone put a cone in the middle of the taxiway). Next to the forum topic, there's also been some talk on the dev list to implement a system where the user can decide whether (s)he wants to see static aircraft etc. based on their own preferences/computer power. I myself experience a lot of issues at e.g. KBOS at the moment because it is so detailed that my pc has troubles visualising it (I have a 5 GHz CPU and 2 GTX 1080 cards, but I do render on 4 screens) I think since your work is so detailed it would be good to use these new stg verbs as soon as the code is ready. It will stay compatible with older FG versions, as they will just ignore the unknown stg verbs, but on current FG versions users will be able to decide for themselves how much detail they want.

Thanks again for your work!
Isaak
 
Posts: 469
Joined: Sat Jun 04, 2011 2:52 pm
Location: Leuven, Belgium
Callsign: OO-ISA
Version: 2019.1.1
OS: Windows 10

Re: Belgian scenery

Postby fmg » Thu Jul 11, 2019 8:19 am

Great work and project!
And a sad story on the other hand. Have had exactly the same unpleasant experience with some of my Terrasync stuff.
Keep up your good work!
User avatar
fmg
 
Posts: 541
Joined: Tue Jun 29, 2010 5:13 pm
Location: EDDI
Callsign: fotomas
Version: 2
OS: Mac OS X 10.6.8

Re: Belgian scenery

Postby dvanmosselbeen » Thu Jul 11, 2019 8:11 pm

Hi Isaak :)

Isaak wrote in Thu Jul 11, 2019 5:20 am:Regarding the scenery uploaded to Terrasync without your consent: I didn't immediately find a license on your github. Was your work unlicensed before? If it had a copyright/-left license that is incompatible with the GPL v2 we use, this is quite a big issue, as this could easily corrupt objects in our scenery database. I think Torsten should step in to see if we can fix this, eventually by removing your work until you decide it's time to (re)upload it.


The Belgian scenery has always been GPL v2, so at this point we shouldn't worry at all. There's mention of the license somewhere but not sure where like i lost many repo's and data when Gitorious claimed the game over. I have had to play the MacGyver to rescue back some data. Unlike MacGuver, sadly enough, i don't have everything at my disposal. So still lot's of things are lost and broken. (If anyone has a trick to get back hidden repo's on Gitorious, give a sign. The git log isn't important to me, if that matters). My Trac account has also passed away, so bug reports and features request, wiki, todo's etc are lost.

To clear things up i have added a GPLv2 LICENSE file in the root tree on my github repo's. Not sure if it's the right way so, but i will fix it if needed. Of course, i'm open to change the license as needed to comply with the FG scenery database. After all, my goal has always been to create "Free" scenery for all.

My main concern is that back in time, someone had mailed me and asked to put the scenery on the scenery database. Which i had found awesome as at that period i was lacking time (family, kids and their health problems...). However, my point goes to the fact of the ownership take over which i discovered a few days ago and which is very disappointing. Let the thing like it is, i dislike médailles anyway. I just want to avoid that same glitch again.

To easy things up, i also have created a repo with the source files of the Belgian scenery. Step by step i move my (upgraded) source files to that repo. (So far all airport source files are in, landmarks and the Brussels building, and OBJECT_SHARED not yet). Hopefully it would help if there's some volunteers in the future. (Side note, uploading the source files to source scenery repo will take time. As in 2011 i made these objects with older software, like Blender 2.49 and some things are incompatible with current Blender 2.79b, (I cross my fingers for the next stable Blender which is again a major change). To keep the story short: it's an pain to migrate these files. Hitting various bugs etc as the older files aren't 100% compatible with newer Blender version). The blender ac export script also work differently now and have other requirements as back in time. So this is a double migration.

Isaak wrote in Thu Jul 11, 2019 5:20 am:Don't understand me wrong: I 'm a big pro for centralising our scenery on Terrasync. Everyone has the same, good looking, scenery and we don't get issues in an MP environment, but I totally understand that you prefer to finish your work on a certain airport before committing it in one time.


I follow your point at 100%. The big issue is that the scenery db web interface is lacking a few features. I don't blame the web interface at all as it's a complex infrastructure and this all is about a huge amount of data. That interface needs to be userfriendly, and compromises had need to be done. It just miss some handy features for scenery developers who are very active and don't want to overload the scenery db maintainer, nor loose hours with uploading stuff one by one and by hand. (Linus, a dbgit please !). I will come back on this point. (Did web development in the past, and i know that it's pita to build up such a huge project like this with resources that are compatible with our License. I wouldn't have be able to build what there is).

My big fault back in 2011 is that i was also busy working on airport layouts which implied to regenerate the scenery. Which made in sort that most of the scenery i made was somehow incompatible with the scenery db (mind objects obstructing because of airport layout mismatch). Yeah, back then, very few airport layouts where available for Belgium, and if available, many of them where to basic or completely wrong. So i had no choice to first fix these airport layouts. I don't want to make that same mistake again so don't count on me to work on airport layouts and terrain regeneration.

Isaak wrote in Thu Jul 11, 2019 5:20 am:Now on topic: the current EBBR scenery on Terrasync: the two terminals aren't aligned very good to the groundnet at the moment and the groundnet will need an update since the Connector has been built. I don't know if that 's also the case on your github, but it's an issue I thought was worth mentioning.


Indeed, these huge terminals lacks a pitch and roll information in the stg file on the scenery db. I could quick fix it in my repo but still not 100% perfect. It's not only about T1 and T2, many objects have that issue now. Our country is not that flat anymore. Seems like the terrain has been regenerated by FG and elevation data is more detailed now. Which brings that issue more evident. My first thoughts is that big objects, or objects at problematic location should need to have a foundation (workaround) in it's object. Like it's done for these buildings that are randomly placed and at some other airports and landmarks.

If i look to Terminal 2 object in the scenery db. There's no way to add pitch and roll information to already uploaded objects. Thus i can't upload a fix right now.

It should be updated with this info:

#desc: Terminal 1
OBJECT_STATIC ebbr_terminal_1.xml 4.483730 50.899085 38.1806 205 0.10 0.025
#desc: Terminal 2
OBJECT_STATIC ebbr_terminal_2.xml 4.481877 50.902323 35.5132 204 0.18 0.15


UPDATE: Checked the upload process for new objects to the scenery DB and its been noted that pitch and roll information is ignored. That sounds so strange no ?

Beside this glitch, some scripts that are at disposal for the scenery devs have also issues to manage pitch and roll information. For example this nasal script to get a number of elevation offset for a number of objects just fails if pitch and roll data is in the stg file. I have no Nasal knowledge, so it will take a time to get that script fixed. That script should also output the real elevation instead of telling my the different of height, forcing my to do math by hand for each object. Futhermore, the FllightGear python library found in the / scripts / python / FlightGear.py doesn't work anymore too, so i can't get elevation data from there either. (as well as my old Python 2.6 scripts). There's an need to updated this all to the current tools.

The ground network has never been worked correctly at EBBR. The aircraft's there like to do a bit off road. I remember that i tried to fix this in the past without any success. The ground net is part of the FG core iirc, anyway, not included in my scenery. The current ground net also conflict with a new walktrouhg building i have (temporary) placed between Terminal 1 and 2 like it is in real life. The AI is awesome as they jump over that building that is on their path.

Isaak wrote in Thu Jul 11, 2019 5:20 am:My modelling skills are still very basic, almost non existent, but I am willing to learn and contribute, so if you have some work that you'd like to get done, please ask me and I 'll see if I can be of any help.


Don't worry, i need to get a massive update as well. Many things have changed over the years. So we are close to be in the same aircraft :-D It's not only 3D, GFX that needs an update at my side, but a serious FG pull too.

Isaak wrote in Thu Jul 11, 2019 5:20 am:And a last comment regarding static aircraft/ground equipment: there's recently been some talk on static aircraft on parking stands etc. In an ATC enviroment (e.g. on VATSIM, which is already possible but will become increasingly popular as FG will be capable of connecting to their network almost out of the box starting with FG 2019.2.x) people like to have all stands available for parking, as they might get a gate assignment that is already taken by a static aircraft or by some ground equipment blocking the stand (or even a taxiway, I remember crashing my 777 once at LFPG because someone put a cone in the middle of the taxiway). Next to the forum topic, there's also been some talk on the dev list to implement a system where the user can decide whether (s)he wants to see static aircraft etc. based on their own preferences/computer power. I myself experience a lot of issues at e.g. KBOS at the moment because it is so detailed that my pc has troubles visualising it (I have a 5 GHz CPU and 2 GTX 1080 cards, but I do render on 4 screens) I think since your work is so detailed it would be good to use these new stg verbs as soon as the code is ready. It will stay compatible with older FG versions, as they will just ignore the unknown stg verbs, but on current FG versions users will be able to decide for themselves how much detail they want.

Thanks again for your work!


KBOS seems awesome (except some serious object collisions here and there). I can't imagine the amount of resources to build a detailed airport and region like this. But here the same case (ahum, on my gamer laptop), this region is not usable at all, even with the ufo. (GTX 1060, the 6GB version, I7 with 4GHz turboost).

I agree completely, static aircraft give a good scenery enhancement offline and as long as they aren't in the way. But some use case, especially to little airfields would be completely different.
Somehow the static aircraft that i have set at EBBR doesn't always shows up. I think this is related with the AI option. IF AI is disabled, static aircraft's looks like to disappear. I need to investigate. Anyway, EBBR has a lot of AI traffic (and with Brussels Airliners now :), so even without static aircraft it doesn't feel empty anymore. So that's a very positive point. At my little airfield, i make in sort that the static aircraft's and their props aren't in the way.

I have read your links, sounds like Chinese for the moment. But i will try again. Some points i was able to understand are brilliant. I'm looking forward for these great changes. Of course, i will collaborate to get the best out of everything and adjust what is needed. I think we need to take into consideration that little airfields haven't the same problematic issue as international massive crowed airports.

To finish this long reply, sorry, but so there's a log of historical decisions i took in the past. I think some things needs to be changed. A first thought is a user registration and some sort of approval system on the scenery db. On many location there's are some serious issue with scenery from TerraSync. for example huge 300m chimneys flying at 500m height in the air... That feels like a strange user error. (For my part, this feels like a trick to put high visible landmarks to find your way, nice hack as this is practical).

Furthermore, i didn't realize that a have a huge amount of work with updating the scenery, updating my knowledge, as well a learning back basic aviation terms. So my future contribs will take time. But don't worry, i have a few bongo's and i will fly again really soon :)

For the moment, i will try to fix major issue on ma scenery, to match current requirement. I plan also to make a list of notes of what's a bottleneck for scenery devs. Guidelines (speaking for my self too) would be good. I remember that i tried all different ways of modeling techniques, different texture backing techniques. So i guess i will be slow the coming weeks due the fact i need to read docs :)

Kind regards
Last edited by dvanmosselbeen on Thu Jul 11, 2019 8:43 pm, edited 1 time in total.
Proud to work on Belgian sceneries: https://github.com/dvanmosselbeen and the Rans S-6S aircraft: https://github.com/dvanmosselbeen/Rans-S-6S
dvanmosselbeen
 
Posts: 68
Joined: Sat Feb 26, 2011 2:54 pm
Location: Brussel
Callsign: B-ITCH
IRC name: dvanmosselbeen
Version: git
OS: Debian / Windwoss

Re: Belgian scenery

Postby dvanmosselbeen » Thu Jul 11, 2019 8:41 pm

fmg wrote in Thu Jul 11, 2019 8:19 am:Great work and project!
And a sad story on the other hand. Have had exactly the same unpleasant experience with some of my Terrasync stuff.
Keep up your good work!


Thanks :)
Proud to work on Belgian sceneries: https://github.com/dvanmosselbeen and the Rans S-6S aircraft: https://github.com/dvanmosselbeen/Rans-S-6S
dvanmosselbeen
 
Posts: 68
Joined: Sat Feb 26, 2011 2:54 pm
Location: Brussel
Callsign: B-ITCH
IRC name: dvanmosselbeen
Version: git
OS: Debian / Windwoss

Re: Belgian scenery

Postby dvanmosselbeen » Thu Jul 11, 2019 9:58 pm

To justify why there should be an approval system (or a control check) on the scenery database. See here:

https://github.com/dvanmosselbeen/fligh ... /issues/36

Mind the - (minus) and _ (underscore) change in file naming.

EDIT:
Another good example might be this: https://github.com/dvanmosselbeen/fligh ... /issues/37

EDIT: I don't blame the scenery db admin at all. I think i must have go nuts much faster :D
I just to want to point out that it's almost impossible (these days anyway) that only one person manage this HUGE work.
Proud to work on Belgian sceneries: https://github.com/dvanmosselbeen and the Rans S-6S aircraft: https://github.com/dvanmosselbeen/Rans-S-6S
dvanmosselbeen
 
Posts: 68
Joined: Sat Feb 26, 2011 2:54 pm
Location: Brussel
Callsign: B-ITCH
IRC name: dvanmosselbeen
Version: git
OS: Debian / Windwoss

Re: Belgian scenery

Postby VicMar » Fri Jul 12, 2019 6:36 am

Hi David,

1. I don't have the knowledge to answer all of the problems you've pointed to.
2. There are at least 2 of us working on the scenery db.
3. Unless a way can be found to reduce the data for each model without destroying the object and the look-up system, it will remain policy for the validator (usually me) to reject multiple buildings on a new model input.

I know it's frustrating and we'd all like to complete our project and submit it as one file, but that just isn't possible at the moment.

If you want to avoid spending a day or two uploading the models, submit them as you finish each one.

I'm sure Torsten would welcome any ideas you have regarding the db, but be prepared - the input system is being made more user friendly wherever it can be done without destroying what we already have.

Cheers,

Vic
Time flies like an arrow
Fruit flies like a banana
User avatar
VicMar
 
Posts: 2059
Joined: Sun Apr 06, 2008 5:53 pm
Location: Lancing. UK (EGKA)
Callsign: VicMar
Version: 2018.3.1
OS: OS X 10.12.6

Re: Belgian scenery

Postby bugman » Fri Jul 12, 2019 9:05 am

dvanmosselbeen wrote in Thu Jul 11, 2019 8:11 pm:The Belgian scenery has always been GPL v2, so at this point we shouldn't worry at all. There's mention of the license somewhere but not sure where like i lost many repo's and data when Gitorious claimed the game over. I have had to play the MacGyver to rescue back some data. Unlike MacGuver, sadly enough, i don't have everything at my disposal. So still lot's of things are lost and broken. (If anyone has a trick to get back hidden repo's on Gitorious, give a sign. The git log isn't important to me, if that matters). My Trac account has also passed away, so bug reports and features request, wiki, todo's etc are lost.


Firstly, please clean up the language in your first post (forum rule 1). With the GPL, the author still owns the copyright and the author name absolutely cannot be changed. This is very important for the enforceability of the GPL licence - if someone violates the licence, they loose the licence to use the work and then it falls back to using the strongly copyrighted protected material of the original author without a licence.

As for gitorious links, since the shutdown and archiving process, the URLs have changed. I have worked out almost all of these changes for incorporating it into the wiki {{repo link}} template. You can see plenty of examples of the new gitorious link formats in the example section of the gitorious url subtemplate. You could even use that template on your user page to input the project name, repository name, and any other key info and have the template create the new URL for you.

Regards,
Edward
bugman
Moderator
 
Posts: 1718
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Belgian scenery

Postby legoboyvdlp » Fri Jul 12, 2019 10:03 am

Does that mean that by taking ownership for himself said person that uploaded the work actually voided the license (i.e. David's work is under full copyright and can't be on TerraSync unless he re-releases it under GPL?)
User avatar
legoboyvdlp
 
Posts: 7164
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Belgian scenery

Postby bugman » Fri Jul 12, 2019 12:14 pm

Leaving aside if it is deliberate or, more likely, not, I don't think it's a GPL licence violation to change the author. However it is clearly a copyright violation. I guess the GPL does not need to address this point as copyright law covers the issue.

Regards,
Edward
bugman
Moderator
 
Posts: 1718
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Belgian scenery

Postby dvanmosselbeen » Fri Jul 12, 2019 12:37 pm

bugman wrote in Fri Jul 12, 2019 9:05 am:Firstly, please clean up the language in your first post (forum rule 1).


Sorry, writing with emotions on fire is a very bad idea. I have freed my heart with my words, so now i can turn that page. I have fixed this in the first post as well as some cleanups.

bugman wrote in Fri Jul 12, 2019 9:05 am:With the GPL, the author still owns the copyright and the author name absolutely cannot be changed. This is very important for the enforceability of the GPL licence - if someone violates the licence, they loose the licence to use the work and then it falls back to using the strongly copyrighted protected material of the original author without a licence.


Removing my work of TerraSync will break other mans work too as some objects where pushed as OBJECT_SHARED and used in other sceneries on TerraSync. A good example could be this army shelter object. I absolutely don't want to break other man's efforts. After all, we all want to contribute and work in the GPL spirit.

bugman wrote in Fri Jul 12, 2019 9:05 am:As for gitorious links, since the shutdown and archiving process, the URLs have changed. I have worked out almost all of these changes for incorporating it into the wiki {{repo link}} template. You can see plenty of examples of the new gitorious link formats in the example section of the gitorious url subtemplate. You could even use that template on your user page to input the project name, repository name, and any other key info and have the template create the new URL for you.


I have take a quick look, seems a tad to complex to quick fix it as i have to leave now. I will try to look again to this and fix it this evening or this weekend. Thanks for the info ! If there's any other remarks about stuff i'm doing wrong, don't hesitate to point it out. To be honest, i'm a bit lost with all this stuff that i should learn back and with all these amazing changes FlightGear got.

If you need a list of concerned object id's with ownership take over. Here's what i discovered so far:

4464
4465
4469
4470
4471
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4514
4515
4516
4517
4518
4519
4520
4525
4526
4528
4531
4532
4533
4534
4535
4536
4458
4459
Proud to work on Belgian sceneries: https://github.com/dvanmosselbeen and the Rans S-6S aircraft: https://github.com/dvanmosselbeen/Rans-S-6S
dvanmosselbeen
 
Posts: 68
Joined: Sat Feb 26, 2011 2:54 pm
Location: Brussel
Callsign: B-ITCH
IRC name: dvanmosselbeen
Version: git
OS: Debian / Windwoss

Re: Belgian scenery

Postby dvanmosselbeen » Sat Aug 31, 2019 8:20 pm

Hi there,
Just to give a quick feedback about the progress of the Belgian sceneries.
There's still tons of work to do and it's still not ready at all to be pushed to TerraSync.

I just started to create a Youtube playlist with a few flights on the airports i modeled.
I'm planning to create a few more video's. I'm also busy creating screenshots and
starting to document the whole project. Very soon i would like to release some sort of
RC and do a call for testing before the final v2 release get out and will be pushed to
TerraSync. Actually peoples can already do that by reporting bugs on the github issue system:
https://github.com/dvanmosselbeen/fligh ... om-scenery


But for now, you can take a look to a few videos:
https://www.youtube.com/playlist?list=P ... kvo50T3WH2

Enjoy :)
Kind regards,
Proud to work on Belgian sceneries: https://github.com/dvanmosselbeen and the Rans S-6S aircraft: https://github.com/dvanmosselbeen/Rans-S-6S
dvanmosselbeen
 
Posts: 68
Joined: Sat Feb 26, 2011 2:54 pm
Location: Brussel
Callsign: B-ITCH
IRC name: dvanmosselbeen
Version: git
OS: Debian / Windwoss


Return to Scenery

Who is online

Users browsing this forum: No registered users and 1 guest