I fear one of the main points of my last post was perhaps lost in the excited discussion of how to cope with conflicting crowd-sourced airport submissions. The engineering principle is:
Fix real bugs, not hypothetical bugs. Solve real problems, not hypothetical problems.
By this I mean: it’s invaluable to wait until you actually have evidence of a problem before you design the solution. Without a real data point showing what the bug is, the solution might not actually fit the problem as it actually happens. In a program as complex as X-Plane, particularly when third party content is thrown in, it’s hard to predict in advance what is going to go wrong.
In the previous case (coping with conflicts) the key here is that I want to see a few conflicts before I choose a plan. I see proposals for a revision system, public logs, a registery, a voting system…any one of these ideas might be the right solution, but we don’t know yet because we don’t have two people submitting buildings.
The same principle applies to another issue that was brought up a while ago:
Won’t all of the default airports look the same since they all use the same library?
First, to be clear: we’re not trying to make the default library airports look like the real world airports, we’re not trying to duplicate custom scenery, and if people submit buildings for all 20,000 airports in X-Plane there’s no way we’re going to have 20,000 control tower libraries in the library.
But there is a valid issue: what if people heavily use the assets? Won’t we start to get a “sameness” either between two airports or within an airport as we use the library more and more?
This brings up the second half of “fix real bugs”:
Identify possible solutions, but don’t use them until necessary.
I am not worried about collisions of airport because there are a huge number of possible solutions, many of which are easy to implement and have been proven to work well in the real world in other problems. In other words, the problem of merging crowd-sourced data is a solved problem, and we can use the right existing solution when we have enough data to pick that solution.
The same thing applies to repetition in the library: we have ways of fixing repetition. I want to develop a few airports and see what looks repetitive before asking our artists to spend their time making more stuff* but we at least know how we can fix the problem when the time comes.
Options to Deal With Repetition
So what are the safety valves here? How can we deal with repetition in the library? There are a few ways:
- Every object in the library can have multiple real OBJ models for each “virtual” object. X-Plane picks randomly among the choices, so we can always add more real objects. We already do this for cars. (There are something like a dozen cars and trucks backing up one or two library entities.)
- Some of the library elements are .agp (autogen-point) files – these files are mini-scenes made up of other objects, and the objects referred to within the scene are also subject to library variation. So we can have a mini-scene where some of the decorations are constantly changing.
- The facade engine contains some fairly flexible rules for picking which segments of walls go where, so there’s a lot of potential to break up the order of facade walls.
- We can add more types of facade walls to a given facade without hurting X-Plane’s performance.
All of these changes can be put into an X-Plane update.
In summary, there are a lot of ways we can make the library more diverse and less repetitive, and as we see the library get used (and certain elements become over-used) we can add more variation to keep things looking fresh.
* For example, it wouldn’t make sense for me to ask Tom to make 50 variants of the administration building if almost no one places it in any airport. We need to see what kinds of assets get used the most and then make decisions.
How are the new airports being distributed? I may have missed that, but will they all be in the apt.dat and nav.dat files? And will we be downloading a new one each time it changes, or more weekly/monthly pushes like that way Robin does it now?
Also, and I know this is off topic, but you guys have got to talk to Austin about the UI. It needs work. I want to love X-plane so much, and it’s so close…but flipping back to FSX still reminds how much easier it is to plan a flight, check weather/see and edit the route etc….
The airports will be distributed in X-Plane updates.
Is it smart enough to know what scenery I have installed, and what I don’t?
Yes!
I can only sign your comment regarding th UI. It really needs some work!
Quote
“In a program as complex as X-Plane, particularly when third party content is thrown in, it’s hard to predict in advance what is going to go wrong.”
End Quote
Collobration can be a good thing if it is done correctly i.e the Linux Kernel
My suggestion is to develop better tools for creative third party use and if collobration is a huge invest, learn from Apple and collect, review and approve if the quality is good enough for X-plane.
> I want to see a few conflicts before I choose a plan. I see proposals for a revision system, public logs, a registery, a voting system…any one of these ideas might be the right solution, but we don’t know yet because we don’t have two people submitting buildings.
I don’t see why adding buildings into the mix is going to change the nature of conflicts, but that doesn’t matter. My only point yesterday was: you already have a case for study with long history, that is the airport layout database. Collisions have been happening there for quite some time, so you already have a a lot of useful data to draw at least some conclusions.
If it’s difficult to identify “destructive collisions” (conflicts where valuable work is lost) just by inspecting the apt.dat change history, I’m sure many followers can point you to particular cases.
I think you lead this towards the wrong direction.
First of all the two problems (duplicate data and similar airports) are not similar.
Duplicate data WILL happen. It’s like driving to a wall and waiting to hit first and then see what kind of safety measures you should have used. Well I am exaggerating here, because with the duplicate data issue you can actually “pause” duplicate submissions (all or all par one for each multiple submission), until you decide how to handle this. My point is that since you know it WILL happen (not that it MIGHT) happen sooner or later (esp. for highly popular airports), how you present this as a hypothetical issue. Except if you don’t know the meaning of the word (it is Greek after all).
The other issue, repetition, is completely different. Users just don’t get the quality they could, scenery developers don’t get the library they would like. Game still works, no conflicts, no need to “pause” something to make a decision. Again deciding the proper solution to this problem that WILL occur (and IS happening in existing stock airports) is not something to decide afterwards. This is one of the decisions that someone takes when jumping major versions not afterwards. Let see the possible “ready made” solutions you give for this problem:
– Random selection for a virtual object. So airports will look “a bit different” each time you visit them. Erm… how is this good?
– Mini-scenes. Again this looks to me like randomization. Maybe I didn’t understand it well.
– Facade. How will someone build something if they don’t get the full “palette” from the beggining? You are saying, they should make buildings etc. with the limitations that are there AND THEN those limitations with lessen and they should update their creations to use the new data? Again maybe I didn’t get you. This indeed happens with all good software (some new things are not released in their full potential and updates expand them). On the other hand, it shouldn’t be the rule.
Anyway the serious point of my comment is the starting point. Those problems are not hypothetical, they are bound to happen and the issues already known. I don’t get the point of waiting for two LAX to see how to handle two LAX.
My problem also comes from that I haven’t seen ANY good solution with this problem with ANY simulator (inc. X-Plane previous versions) – so I don’t see it happening now.
I agree. Without some kind of online collaboration/project status page, it seems like a disaster waiting to happen. It takes HOURS of work to build a whole airport, I’m not going to do it if someone else is going to do the same thing a week later.
But having empty airports all over sucks too.
Using a system like CVS or GIT might help you with the dilemma of multiple submissions. The WED designer would have to know what version of the airport is being edited. When you go to edit it, it checks for an update to the airport right then or maybe just a warning if you’re not using the up-to-date data, your work may conflict. When you go to upload, it will not allow you to create a duplicate.
If there is already an airport, it would create essentially a change-log where the new version is 1.1 instead of 1.0 and it would be modification of an existing item. All airports in the database are currently at 1.0 except for the Seattle and other Aerosoft airports.
Jim edits KJFK to add terminals and anything else he does. Bill sees this new KJFK, but says he can edit a few things Jim did to make it better. Bill goes in and edits the current airport (Jim’s) to move a building, add a fence and a few signs around the airport. Bill then uploads the changes. In this instance, WED would have to upload the new file, but it would be changes based on the previous version.
I don’t think object or facade randomization is a good idea in general. Of course, there are very valid exceptions – cars, for example, make a lot of sense indeed to randomize. But in the general case, if I spend the time to select a specific object/facade/mini-scene for a given location (instead of just randomly plopping down the first item I come across), in order to make the result look reasonably similar to the original, or even just plausible, I’d hate to find my carefully crafted composition tampered with at the next update. There’s nothing like finding the standard 40ft corrugated steel control tower (which doesn’t exist in the library yet, by the way) I selected because it looks plausible for a small GA airport randomly replaced by a futuristic 200ft international hub version, just to break repetition. And if I deliberately place 50 blue porta-potties (as opposed to 50 general ones), I don’t want 20 of them replaced by green ones the next morning. Maybe repetition of architectural style is characteristic for that airport (or the whole area even), after all.
I think the library should export both all the specific objects etc. available (including objects designed to make up .apg mini-scenes), which are guaranteed not to change, as well as aliases to general categories, where a specific example is selected at random. That way, each author can decide if an individual item represents a deliberate choice of architectural style, of if it merely indicates a function.
Judith
I totally agree.
I proposed the creation of a centralized site for airport maintenance a few years ago in the .org. I actually created a proof of concept site, so discussions could be held on something tangible. I got banned from the org in return o_O.
The original idea for the site was to contain educational content in wiki format (doc, tutorials, guidelines, etc), an airport repository under revision control, and organizational tools to facilitate team collaboration (issue tracker, discussion forum, etc). Pretty standard for mature open source projects.
That idea was killed upon inception due to the frontal opposition found in the org administration, and because I had no intention to disturb the community.
Infrastructure is necessary and nice to have, but in the end, it is the people who make it happen. So if the community don’t buy it, it’s not going to work.
But it is remarkable that the same ideas are being raised years after…
If that’s how things went then that is truly disgusting behaviour and longer-term will seriously be damaging the sim’s traction with new adopters. I wonder why they saw your initiative as damaging to their information fiefdom when there are other similar collab projects (e.g OpenSceneryX) that get breathing room there?
That is something I can’t answer. My impression is that it was perceived as a self promotion campaign by the admins as I was new to the org at that time (2008).
Regardless, what made me step back immediately was that the discussion thread was obliterated from the forum. Opposing an initiative is one thing, censuring an open discussion in educated terms is a very different one.
What is a bit sad is that none of the ideas crystallized in 4 years, when there where people willing to push them forward. Maybe it is just a matter of time. Maybe it is not the right community for this kind of organization.
Seems most people agree here…