[Turner]

"Here's a test version of OverlayEditor that displays the preview screenshots:"

Woo!

That's sure a step in a good direction... now, if we could only get previews for all the existing objects

Thanks again for the great tool-

Andrew

[aussi]

...the front page should contain installation instructions for dummies. Also, perhaps rename the front page from index.html to ReadMe.html?

Yes, good point.

Here's a test version of OverlayEditor that displays the preview screenshots:

I'm sure this has been said a few times before, but you rock!

It assumes that the preview screenshot is called screenshot.jpg and lives in the same folder as the object (which implies one object per folder). Is this likely to change?

Heh, that question is tied to the texture problem mentioned above - where to store textures shared by multiple objects. I think we should stick to a one-object-per-folder scheme. So, because two objects will never be in the same folder, if a shared texture is used then it should be referenced by going up a folder level and then down into the folder containing the shared texture.

One-object-per-folder simplifies all other aspects, including paths, screenshots and info files.

So in summary: YES.

A.

[Marginal]

if we could only get previews for all the existing objects

That version includes previews for most "airport", "misc v800" and, if you're using v8.50, "cars", "dynamic", "legacy" and "ships" objects. But not "global8" objects yet (frankly, producing the screenshots is a pretty tedious business).

One-object-per-folder simplifies all other aspects, including paths, screenshots and info files.

Sounds good to me. If it ever gets too unwieldy you can always reorganise at a later date while preserving the exported names.

[bsupnik]

Hi Guys,

A few comments - hopefully I didn't miss any posts in my reading of the thread...

1. To me it seems that some of this discussion of licensing may be moot; the act of _using_ an X-Plane library object in scenery does not involve making a derivative work, copy, or even aggregation.

So copyright law doesn't allow you guys to say what AUTHORS get to REFERENCE these library objects in their packages.

It does let you say what USERS get to INSTALL the library itself on their end machine.

The only way you could stop payware authors from leveraging the library (e.g. making a package that uses the library objects by reference) would be to have a VERY restrictive license on end users about when they're allowd to INSTALL the library. This would mean the license could not be GPL, and frankly it would be a real uninforcable mess.

So IMO I think you all need to accept that payware scenery will be able to reference the library, because there isn't a good clean simple way to stop this.

2. What copyright law does let you do is address the issue of duplication of the library. Since duplication of the library is needed by end users to see it, but not by authors to leverage it, you could possibly use a very restrictive end user license without losing any of the advantage of the library. I'm not coming out and saying "restrictive EULAs are great" (I think the opposite), but I am saying that if you guys can't find a consensus on what rights authors should have to give up to participate, maybe the simplest thing is to say "give us your object, it will be used only for the library with no further duplication made except to install it". That's very restrictive...but gets the job done. If authors want to further give away objects, they can do so anyway. :-)

3. I think the GPL is not compatible with X-Plane's old EULA (no commercial, no MSFS) or new EULA (ask before you copy). Of course, x-plane artwork can be used as-is without even being in the library - all of our scenery already comes in library form!!

4. It is intentional that textures cannot be libraried, only objects. The reason is that if an object author "repacks" the texture to save or optimize space, all derived objects' ST coordinates will be wrong. So it simply isn't safe to utilize other objects textures if it's not your own package.

5. It is possible to reference files by using ../ to go up a directory...but do NOT count on the ability to go up into other packages - the ability to reference other packages directly is an "open back door" in the scenery system that I will be closing soon! Please only reference files using the library system.

With all that in mind, it's great to see people hashing this stuff out...hopefully with overlays and libraries the technology exists to allow you all to make this happen. :-)

*Cheers*
Ben

[aussi]

Hi Ben,

Very good point about the licence and copying vs. referencing. Can we all be happy with the non-commercial licence and wrap that one up?

A.

[Cormac]

Ok, ok, who told Ben about the object library being set up?


The point about the feasibility of licencing referencing of the library objects is a good one. It again begs the question, why bother trying to restrict the usage?


I do wonder if a one object per folder scheme is necessary, or even desirable. In my scheme, there can be multiple objects and, if required, multiple textures per folder. In this way related objects are grouped, the object's texture is always in the same folder. A group of objects can be retextured by copying a single folder and then editing the texture(s) in it. In a collaborative effort, it may desirable to have a rule of that any one folder has only one author. Screenshots could share the same name as the object but with a .jpg suffix, allowing multiple instances per folder. From a user's point of view, it may be moot as the library file can rearrange the exported objects as seen fit but I just think it would be easie from the admin viewpoint.

Example - the contents of ./airside_vehicles/services/aerlingus/ in the library I was already putting together are something like:

apt_vehicles_01.png
airstairs_truck.obj
airstairs_truck_a32x.obj
airstairs_truck_b737.obj
airstairs_truck_covered_a32x.obj
airstairs_truck_covered_b737.obj
bus.obj
catervan_big_up_a32x.obj
catervan_big_down.obj
fordtransit_van.obj
etc.

Now i could create a folder called "textures" at the same level and then one folder for each object, but why go to the bother? Have I missed something?

[aussi]

Hi Andrew,

Sorry, I somehow managed to completely miss your post earlier.

an alternative would be for the payware author to be able to use the freeware in their project for accurate placement, then replace each instance with a "placeholder" to allow them to distribute the package with some generic object which would then in turn be replaced automatically, by the end user, with the intended structures, provided they have the freeware versions of the objects.

Ben mentioned the same thing in an email conversation - Actually X-Plane will give a nasty error message if a package references library objects that don't exist (i.e. if the scenery library is missing). He suggested exactly the same thing - The library should include a 'stub' library.txt file pointing to an invisible object for every path in the library. Every author that uses the library should include this stub in their project so that everything behaves nicely if the library isn't there. I'll add this to the build script.

I'm also a Photoshop expert; perhaps a list of contributors can be kept with the particular areas of interest for each?

Good idea - I think the wiki will be the best place for this, but I'll also make sure the documentation includes a list of contributors in a list for reference.

Also, to make this easier for the less experienced of us who wish to be involved, I also ask that a reasonably good set of faqs/tutorials be maintained. This stuff is second nature to a lot of folks, but, unfortunately, I'm not one of those people yet!

Heh, well there are quite a few tutorials here at the org, I'm not sure the scenery library is the place for them but if anyone wants to contribute a tutorial we will put that on the wiki too.

If anyone is willing to test out some of my files, email me at
andrew at turnerdesign dot com

I've dropped you a PM.


BTW everyone, any objections to calling the library OpenScenery? It's a working title that seems to be becoming less 'working' and more 'hanging around and moving in'.

A.

This post has been edited by aussi: 20 November 2006 - 01:52 PM

[Cormac]

BTW everyone, any objections to calling the library OpenScenery? It's a working title that seems to be becoming less 'working' and more 'hanging around and moving in'.

Yep, seems a good title to me. Just googled it to see if it was used elsewhere and got just one result returned - isn't there a name for that?

[DanCnKC]

Yep, seems a good title to me. Just googled it to see if it was used elsewhere and got just one result returned - isn't there a name for that?

Whatever the name is.... it's a unique/virgin keyword ( or metatag search phrase) that would allow the library to index very well in a search browser... at least in terms of list placement.... first page/top of the list....

Using the search phrase "Open Scenery" nets a dozen pages of results.... but fusing the title together "openscenery" grants unique placement

Just make sure whoever indexes the home page uses keywords for those who will type "open scenery" into the search engine, so we have our bases covered. not everyone is used to a "no space" search title.

Aussie, when you were counting contributers, did you put my name in the hat? I have to think we have more than 2... you and me alone make 2. Jochen has been releasing his "heavy metal" packages in the same spirit, so unless I'm mistaken, I think he would be keen to the idea.....

I'll relent on use restrictions.... I'd like to have them... but no matter what we say or do.... people who want to chance using our objects in a retail scenery are going to take the chance regardless of what we say...

We absolutely have a right to add a Terms of Use to the download page....Intellectual property is still property... But when it's offered as freeware on the public square.... a dozen loopholes make it hard to create a policy that has true teeth..after all...lawsuites are centered on what "damaged" is caused over and above what a persons right to property is...... that which is given freely makes it difficult to claim damages... and we all can probably agree that retail sceneries for $10 each don't generate wild profits.... 2% royalties on $10 isn't worth the time it's taking me to type this post.

I say we should be resolute with a Terms of Use statement, and then let the issue go on that....

So Aussie.... you asked if we can wrap up this issue on the stated consensus... and as for me, I consider it a wrap...

This project holds too much promise for the community to let red tape bring it down...

.

This post has been edited by DDeGroff: 20 November 2006 - 03:13 PM

[Mr 3D]

Hi All


I'm pretty new to x-plane but 3d animation has been my love for many a year, too many to worry about...Id love to contribute in any way I can the only problem I have is BLENDER.. I don’t want to sound snobbish but it is a little EEEERRRRRR..

There has been lots of talk on Freeware/Playwear well its my experience that once its out there you don’t stand a chance (you can get anything you like on the net - so I would prefer to keep it freeware after all isn't that what this community is all about)

Maybe we could get it up and running and see what we can do together..

Maybe a wish list would give us all the inspiration we need to get it up and running. Also Id love to see some animated object if its at all possible...

Cormacshaw did a fantastic job with Dublin and Aussi has inspired me too..