Hi Isaak
Isaak wrote in Thu Jul 11, 2019 6: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 6: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 6: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 6: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
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 6: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