Oolite Bulletins

hmm, not sure what's happening there, maybe box.net want you to see their logo so are forcing you to only download from the link on the page that they set up for you when you share a file.

is it the arcelite shader ships you're after? the download seems to work ok for me if i first go to
http://www.box.net/shared/gej970qtqj
then click on the download link that is on that page.

the 'user' they're refering to is me i suspect, i've only signed up for a free account. You shouldn't have to sign up with them just to download my files.

Sanity check:
Qs.

Does this mean I no longer need seperate dat files for different skins? (i.e. I can use the same model with different illumination maps?)

Griff wrote:

hmm, not sure what's happening there, maybe box.net want you to see their logo so are forcing you to only download from the link on the page that they set up for you when you share a file.

is it the arcelite shader ships you're after? the download seems to work ok for me if i first go to
http://www.box.net/shared/gej970qtqj
then click on the download link that is on that page.

the 'user' they're refering to is me i suspect, i've only signed up for a free account. You shouldn't have to sign up with them just to download my files.

That link won't work for me using:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3

Non W3C compliant pages sometimes fail, as well as those which are designed around non-existant web security.... like allowing scripts globally. Lets see what I can find out:

... OK I need to allow box-cdn and box and cetrk to run javascript in my browser, as well as allow box to send me six cookies. What is all this for?

(this board, for eg, only wants 2 cookies - tracking logins or they have to time me out - and javascript is used in the online editor.)

cetrk.com is some sort of domain registration company... so it's probably some sort of traffic monitoring. box/box-cdn are using javascript for buttons, and as the user interface for their database - I'm guessing.

The error message implies some sort of user administration.
I've sent a complaint to the box admins.
As you can gather, I'm a bit fussy about what software I run on my computer. At the very least, box need to put needed browser settings (cookies and java and who for) on the failure page.

Hello Simon,
I was probably not clear. The easiest to implement NPC ships is to give them generic roles like you do. But that way Oolite itself will give them AI files belonging to it. (And it will give a bounty when it adds them as pirate). Best is to give them a pirate AI and no bounty like the internal ships. (And remove the specific AI )

To make testing easier I would also give each ship an additional unique role. That way you can add a specific ship from your oxp by script. (or with the console)

I noticed that I could not open the shipYard file. It contains a syntax error: missing </plist> at the last line.

And as McLane wrote: "wolf" is a bit common name. And it is this ship key that should be unique. Equal ship keys overwrite each other. And as the player never will see this key name, you should add characters to make it unique. Even if it is unique now, you run the risk someone else will use this name.
The ship display name does not need to be unique. At least not for game-play to work.

Hmmm... still don't seem to be doing this right... just getting a big question mark. [edit]Got rid of the big ? by switching back to XML - now just not seeing the effects - so I've missed something out or made a bad syntax.... maybe more experienced eyes can spot it?[/edit]

- here's what I've done:

In ~/Oolite-saves/Eionick.save I've given katipo-player and it's subentities the following:
The fragment and vertex shaders were added jic.
Here's whats in the oxp:
All done attempting to understand the vector :)

Svengali wrote:

Sounds nice, Griff - 'excellent OXP' - but the truth is that I've stol.., err misus.., eeh used Ahrumans code from the ShadyCobra.oxp.

The shaders in the Shady Cobra OXP were of course intended to be used as an example, and taken into chop shops to be stripped down for spare parts… but I didn’t include a license statement to that effect. So much for following my own good advice. :-)

Ahruman wrote:

Svengali wrote:

Sounds nice, Griff - 'excellent OXP' - but the truth is that I've stol.., err misus.., eeh used Ahrumans code from the ShadyCobra.oxp.

The shaders in the Shady Cobra OXP were of course intended to be used as an example, and taken into chop shops to be stripped down for spare parts… but I didn’t include a license statement to that effect. So much for following my own good advice. :-)

Ain't everything supposed to be GPL v2 unless otherwise specified?

Simon B wrote:

Ain't everything supposed to be GPL v2 unless otherwise specified?

No, as Ahruman patiently explained (again) in this thread.

If I understand correctly, only everything that is a derivative work of Oolite is supposed to be GPL v2. Now the astonishing and (at least for me) a little mystifying thing is that not every OXP as such seems to qualify as derivative work of Oolite (which is a little counter-intuitive, at least for me). It seems that, in order to be counted as 'derivative', an OXP has to borrow (read: copy) more or less heavily from code inside Oolite. Which (as far as I understand) translates into: using either script-parts, models, or textures which can be found inside the Oolite-application. Scripting something that only gets executed through the Oolite-application (which would be true for every OXP, because an OXP makes no sense and doesn't do anything without Oolite itself) does not seem to qualify.

Therefore, if you have come up with solutions of your own, without using script tid-bits from Oolite's Contents/Resources/Config folder, you are free to release under whatever license you want.

Yes - I understand - I've just spent a fortnight in the company of Richard Stallman trust me on this: I know ;) (I'm also something of an FSF rep to NZ.)

I just remember seeing something about submitted OXPs needing to be GPLv2 ... oh well. A quick hunt didn't turn up the reference so I'll let it go.

It's probably worth repeating at interval that, in most jurisdictions (including EU, NZ and USA), if you don't put a license to the contrary, all rights are reserved to the author.

So if you want contributions - better put a license line in the plists, also in the metadata of the images. It's a pain - yes. Fortunately, folk here are pretty informal about licensing...

The above suggests that the shady-cobra oxp is in the public domain?

Still no luck with those shaders - I know I missed something simple.

It's reminding me of the hours trying to figure out why the arachnid-wolf didn't come with legs - only to find I'd misspelled the name.

Had a go subverting the shady cobra too ... now did I convert the open format to XML correctly?

Simon B wrote:

now did I convert the open format to XML correctly?

PListEdit Pro does it with a mouseclick. Back and forth. And back. And forth. And back. And forth. And... (if you're into those small little tiny wee detractions from work, of course )

http://www.fatcatsoftware.com/plisteditpro/
... sadly it is not Free Software. No use to me.

I'll have to crank up the old mark 1 eyeball (trouble is, it's coupled to a v0.9.1 brain).

I have seen a bunch of utilities for gnu/linux which edit plists, but they all convert binary to XML.

O course, another approach is to cenvert the XML to open and add the shaders verbatim. However, I'd rather just know what I'm doing...

Aside: introducing test captains John Doric, Jerry Corinthian and Cerise Eionick - capital people, pillars of the community.

Simon B wrote:

The above suggests that the shady-cobra oxp is in the public domain?

That’s another tricky one. It’s not at all clear that placing something in the public domain is legally valid anywhere, and it certainly isn’t everywhere. However, I’ve added the following statement to the Shady Cobra OXP wiki page:

The shaders in this OXP may be used and modified freely without attribution.

In effect, they may be treated as public domain. (The model and textures, except the effect map, aren’t mine to give away.)

Commander McLane wrote:

Now the astonishing and (at least for me) a little mystifying thing is that not every OXP as such seems to qualify as derivative work of Oolite

The derivative work thing is a matter of interpretation, and of course varies by jurisdiction, so it’s hard to make a general statement. There have been rulings such as Micro Star v. FormGen Inc (United States Court of Appeals for the Ninth Circuit) which found that expansions (maps) for Duke Nukem were inherently derivative works because they’re intended for use with Duke Nukem; I alluded to this ruling using naughty words in that other thread because it’s basically equivalent to saying that Microsoft holds the right to all Excel documents. As you may have deduced, I favour a tighter concept of “derivative work”, so I consider OXPs that don’t contain elements directly from Oolite non-derivative, meaning that as far as I’m concerned you can license them as you please.

I should note that someone brought up the idea of copying the idea of Ionics and recreating it with the names changed and new ship designs. That kind of thing is precisely what the concept of “derivative work” was created for: specifically, the business model of rewriting someone’s book in your own words with the name changed and selling it as a new work. At the same time, copyright is intended to cover implementation, but not idea, so the storyline of a book is not itself covered by copyright. The tension between these ideas should be obvious.

I’d sum up by pointing out that copyright was rather more sane when it was applied to the actions of commercial publishers rather than individuals, but I’m trying not to get political here (!), so I won’t. ;-)

Considering the interest, a (sticky) copyright thread may be useful.

Your ideas about derived works are similar to FSF ones. If you don't use any of the source code, then it ain't a derived work. Note - in software, rewriting a program using our own code is allowed (or whither GNU). The DN case would not be considered deriverative under GPLv2 ... though there is concern about creeping propriataryness... the point of free software is defeated if the addons needed to run it are non-free. So I think v3 tightens this up.

If you use only Free Software compatible licenses, you don't need to know.

The plists are tricky - you cannot help using a substantial amount of the core plists in your own, that's just the definition. So many lines are just the same as the core ones but with a number a bit different - however, it's the numbers that make it unique.

Note. GPLv2 really expects the full text of the license to be distributed with the work. GPLv3 does not. Using GPL for non-software needs care - what counts as the source code for an oxp?

* the plists? check
* the png files for textures - or the gimp/photoshop/whatever native format that you actually worked on? The latter is technically correct, but proprietary, so it's self defeating. The texture created by exporting from wings would be ideal.
* the .wings models? (Unless one can import .dat files to something, they are not source code.) But what if you didn't use wings - you don't have to? This suggests that the obj/mtl files are the source for models.

This is why I have put a Sources directory in each plist containing the base png texture and the obj/mtl files. However - under v3 I can put these in a different file OK - since not everyone wants to modify things.

In the end we just need to relax ad realize we are sharing code here. That,s the whole point. The only forseeabe problem here is in the event someone dies or otherwise ends up with some commercial entity in control of their "IP"... which may decide to enforce their "rights". Including an explicit license statement protects the future ooniverse.

In the long term, OOlite benifits from being free software. (Disagree? We need another thread?) So it is advisable to release oxps under a free license anyway.

Oh - and - when distributing png files which are not intended to be transparent in any way, please flatten them. You get better compression that way.

Still no luck figuring the syntax... maybe
<key>katipo.png</key>

should be
<string>katipo.png</string>

as that is the texture being replaced by the shaders?

Nah - has no effect - there's obviously a key concept I'm missing.