Page 2 of 6

Posted: Thu Oct 30, 2008 8:09 pm
by Griff
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.

Posted: Thu Oct 30, 2008 10:24 pm
by Simon B
Sanity check:

Code: Select all

"arachnid-katipo" =
{
	"model" = "katipo.dat";
	"smooth" = "true"
	density = 0.7;
	"name" = "Arachnid - Katipo ";
	"roles" = "arachnid";
	materials = 
	{
		"katipo.png" = 
		{ 
		illumination_map = "katipo.png";
		specular = "redcolor";
                shininess = 128;
		 };
	 };
	shaders =

	{

		"katipo.png" =

		{

			textures =

			(

				"katipo.png",

				"katipo-effect.png"

			);

			uniforms =

			{

				"uTime" = "timeElapsedSinceSpawn";

				"uEngineLevel" = "speedFactor";

				"uLaserHeatLevel" = "laserHeatLevel";

				"uHullHeatLevel" = "hullHeatLevel";

			};

		};

	};
}
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?)

Posted: Thu Oct 30, 2008 10:47 pm
by Simon B
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.

Posted: Thu Oct 30, 2008 10:48 pm
by Eric Walch
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.

Posted: Fri Oct 31, 2008 12:07 am
by Simon B
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

Code: Select all

<key>ship_desc</key>
  <string>katipo-player</string>
I've given katipo-player and it's subentities the following:

Code: Select all

		<key>materials</key>
		<dict>
			<key>katipo.png</key>
			<dict>
				<key>illumination_map</key>
				<string>katipo.png</string>
				<key>specular</key>
				<string>redcolor</string>
				<key>shininess</key>
				<integer>128</integer>
			</dict>
		</dict>
		<key>shaders</key>
		<dict>
			<key>fragment_shader</key>
			<string>ahruman_sv_ship_vector</string>
	 		<key>vertex_shader</key>
			<string>ahruman_sv_ship_vector</string>

			<key>katipo.png</key>
			<dict>
				<key>textures</key>
				<array>
					<string>katipo.png</string>
					<string>arachnid-effects.png</string>
				</array>
			</dict>
			<key>uniforms</key>
			<dict>
				<key>uTime</key>
				<string>timeElapsedSinceSpawn</string>
				<key>uEngineLevel</key>
				<string>speedFactor</string>
				<key>uLaserHeatLevel</key>
				<string>laserHeatLevel</string>
				<key>uHullHeatLevel</key>
				<string>hullHeatLevel</string>
			</dict>
		</dict>
The fragment and vertex shaders were added jic.
Here's whats in the oxp:

Code: Select all

simon@indigo-prime:arachnid.oxp$ ls
AIs  Config  Images  Models  Shaders  Sources  Textures
simon@indigo-prime:arachnid.oxp$ ls Textures
arachnid-effects.png  avondale-nacelle.png  avondale.png  katipo.png  wolf.png
simon@indigo-prime:arachnid.oxp$ ls Config
avondale-hud.plist  shipdata.plist  wolf-hud.plist  katipo-hud.plist
simon@indigo-prime:arachnid.oxp$ ls Shaders
ahruman_sv_ship_vector.fragment  ahruman_sv_ship_vector.vertex
simon@indigo-prime:arachnid.oxp$ 
All done attempting to understand the vector :)

Posted: Fri Oct 31, 2008 1:02 am
by JensAyton
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. :-)

Posted: Fri Oct 31, 2008 1:16 am
by Simon B
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?

Posted: Fri Oct 31, 2008 9:31 am
by Commander McLane
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.

Posted: Fri Oct 31, 2008 10:45 am
by Simon B
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?

Back to shaders...

Posted: Fri Oct 31, 2008 10:49 am
by Simon B
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?

Re: Back to shaders...

Posted: Fri Oct 31, 2008 10:59 am
by Commander McLane
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 :wink: )

Posted: Fri Oct 31, 2008 12:16 pm
by Simon B
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.

Posted: Fri Oct 31, 2008 1:51 pm
by JensAyton
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. ;-)

Posted: Sat Nov 01, 2008 12:41 am
by Simon B
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.

Posted: Sat Nov 01, 2008 12:57 am
by Simon B
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.