SIRF - update Released

[tinker]

Seeing as there seems to be nothing interesting to do for a few days I decided to work on the SIRF shipyard, with several aims in mind.

The textures were not well done in places and needed to be redone.

Parts of the scripts seem to be incompatible with current game version.

Some people seem to think it is a frame rate killer, though I have never seen this.

I started simple by redoing the textures, which ended up not so simple as I have 'lost' the original model and texture files. I did find some untextured sub-entities and as I cannot remember where they were supposed to be and nobody has seen them they might as well get deleted. I am considering removing the derelicts from the far end of the yard and may replace them with standard model wrecks, not spinning, perhaps this will help with framerates.

I am now onto updating the scripts. I am looking at the shipdata.plist wich is currently XML, the beginning I have converted OK but when I get to this

Code: Select all

<key>subentities</key>
                <array>
                  <string>dock-flat 0.0 0.0 -600.0 1 0 0 0</string>
                  <string>civ-supports 0.0 0.0 -400.0 1 0 0 0</string>
                  <string>civ_docks_main 0.0 0.0 -609.0 1 0 0 0</string>
                  <string>civ_docks_main 0.0 0.0 -609.0 0 0 0 1</string>
                  <string>sirf 0.0 0.0 -400.0 1 0 0 0</string>
                  <string>sirfplanet 0.0 0.0 -400.0 1 0 0 0</string>

I am not sure how to proceed.

I have this template from a working station

Code: Select all

subentities =
		(
			{
				subentity_key = "dock-flat";
				orientation = ( 1, 0, 0, 1);	// rotated 90 degrees
				position = ( 0, 0, 500 );
				is_dock = true;
			},
			{
				subentity_key = "arc-detail";
			},
			{
				subentity_key = "arc-detail";
				orientation = ( 1, 0, 0, 1 );
			},

Are the first three numbers in the XML version the position, the next four then the orientation? As there are currently about 60 sub-entities I would rather get it right the first time.

The next problem is with flashers, the XML contains dozens like this

Code: Select all

<string>*FLASHER* 96.01342 -0.150384 -50 60.0 1 -0.50 12</string>

and the template gives them like this

Code: Select all

{
				type = flasher;
				size = 12;
				color = { hue = 120; };
				frequency = 1;
				phase = -1.8;
				position = ( 0, -92, 275 );
			},

or

Code: Select all

			{
				type = flasher;
				size = 12;
				color = "orangeColor";
				frequency = 1;
				phase = 0.5;
				position = ( 0, -16, 252 );
			}, 

I have not found any reference to what the meaning of the XML number list is to convert it.

Could someone also point to something to help me convert the script.plist to script.js.

[Thargoid]

Look in the wiki old chap, for answers to most of your questions.

Specifically for the modelled sub-ents:

<string>dock-flat 0.0 0.0 -600.0 1 0 0 0</string>

The first item is obviously the shipdata key for the sub-entity. The next three figures are its position, equivalent to the figures in the position key in the new methodology. The final four figures are the orientation quaternion, again equivalent to the orientation key in the new method.

The new one has some additional keys like the is_dock one, see the wiki link above for more details.

Similarly for the flashers:

<string>*FLASHER* 96.01342 -0.150384 -50 60.0 1 -0.50 12</string>

is defined as *FLASHER* x y z hue frequency phase size where hue is the "angle" on a standard colo(u)r wheel (here wikipedia reveals all - see figure 9).

As above the new method is more powerful, flexible and simpler, and gives some new options and things that can be done (for example multi-colour flashers). See the first link above again for more details.

For the script.plist to script.js, that's somewhat more complex, as it's a totally different scripting language. There you'd be best to work out what the script.plist is trying to do, and then basically re-write it from scratch in js.

[tinker]

I've going around in circles on the wiki most of the day. I realise now that I had been at the link you pointed to about three hours ago. Thanks for kicking me back there.

As for the scriptplist to script.js, I thought it might be more complex, even more so as I know next to nothing about js. Ahh Well, something new to learn, it might take me some time.

[Thargoid]

It's quite a simple spawning script. So you can concentrate on the other bits, I've put together a js equivalent for you that you can use instead of the plist one.

Just copy the code below into a file called script.js, and save it in the config folder of the OXP (same place as the script.plist file). Then delete the script.plist file itself, as it's now redundant.

Code: Select all

this.name					= "SIRF_populator.js";
this.author					= "Thargoid, for Tinker";
this.copyright				= "Creative Commons: attribution, non-commercial, sharealike";
this.description			= "Script to add SIRF stations to certain systems";
this.version				= "1.00";
"use strict";

this.shipWillLaunchFromStation = function()
	{
	this.shipWillExitWitchspace();
	delete this.shipLaunchedFromStation;
	}

this.shipWillExitWitchspace = function()
	{
	if(system.isInterstellarSpace || system.sun.isGoingNova || system.sun.hasGoneNova || system.government < 3 || system.techLevel < 9 || system.countShipsWithRole("SIRF-YARD") > 0)
		{ return; }
		
    system.legacy_addShipsAt("SIRF-YARD", 1, "pwu", [1.2, 1.2, 1.5]);
	system.legacy_addShipsAt("trader", 3, "pwu", [1.2, 1.2, 1.3]);
	}

The functionality is exactly the same as the plist version. It could be improved to make the appearance pseudo-random rather than at every system of tech level 9+ and suitable government type if you want. I also took the liberty of excluding nova systems (going and gone) in addition to blocking off witchspace spawning.

A little late gift - Merry Christmas [/color]

[tinker]

Many thanks, now that there is a start I'll see what I can learn from it then start a bit more tweaking, I was thinking a bit more randomness would be better but I'll get to that later.

Once again thanks for the assistance.

[Thargoid]

If you want to see how to do the spawning pseudo-randomly, have a look at the populator script in WildShips (on which your other one is based, as it does roughly the same job).

Also look in the wiki about the system functionality in javascript (search for "javascript system" and take the first page). And if you need any guidance, just let me know.

[Hotblack's-stuntship]

It would be nice to have a random roll for equipment pricing like in planetfall selecting maybe 0.8X to 1.0X. Right now I cheated and set it to 0.9X (or am I really cheating?? repair is in the name). Needless to say I go to SIRF for all my repair needs. I like that it's off the spacelane.

[tinker]

Currently the prices are rather high as the station does emulate tech level 14 in lower tech systems, and while they use slaves as labour which should make it cheap the slaves do suffer a lot of damage meaning there is always a shortage and the station has to pay over the odds for replacement workers (slaves). Repairs is in the name but cheap repairs is not. I'll look at more variability in the prices though, that sounds nice, especially if the stations become even more rare as Thargoid has suggested.

More people using the station will of course lead to increased pirate activity in the area.

Currently version 2.1 (not available for download) is working well as fully js, some aspects of the model are being tweaked for version 2.2 expected soon. Planning for a mission based on SIRF stations has started but will not appear until version 2.3 at least.

[Thargoid]

One thing I do notice in trunk (and perhaps 1.76.1, but not tried that) is docking is a bit strange. You fly through part of the station and then enter a second dock, which is where you actually dock-proper. It looks very strange, especially as when you go through the first part most of the main model disappears and you see the second dock in free space with the spinning wrecks near it.

Probably some of the positioning needs adjusting (maybe you already did in your ongoing work), but the original version is definitely wrong at the moment.

[Eric Walch]

...You fly through part of the station and then enter a second dock, which is where you actually dock-proper. It looks very strange,....

I think that will be because of the old definition:

Code: Select all

                  <string>dock-flat 0.0 0.0 -600.0 1 0 0 0</string>
                  <string>civ-supports 0.0 0.0 -400.0 1 0 0 0</string>
                  <string>civ_docks_main 0.0 0.0 -609.0 1 0 0 0</string>
                  <string>civ_docks_main 0.0 0.0 -609.0 0 0 0 1</string>

Anything containing "dock" will be considered as dock. But because there are 3 subents containing this string, Oolite probably takes an other subent as dock than intended. This will fix itself when converting to the new structure.

And for the very lazy people on a mac: The converted version is already present in the cache. Just open it with a proper plist editor (it is not readable by a text editor), find the proper subentitie section, copy it to a new plist file and save that in text format.

[tinker]

Yes docking confused me at first when I saw the oxp some years ago, I fly around the first bay for several minutes before I acidentally passed through the wall and found the real docking bay.. The model is not mine, it and the oxp were abandoned by milinks shortly after release.

Part of the current reworking is to drop the second docking bay altogether, though it does still work as I think he intended in 1.76.1. civ_docks_main is actually some walkways around the shipyard, as far from the docks as you can get, there is also a civ_docks_walk2 in the shipyard. These have all been renamed, dock-flat does not exist.

Even the wiki entry for the station is wrong, milinks placed it next to the main station as stated in the wiki, they moved a long way away 2 years ago, the back story is in the readme, but I do not have wiki edit permission to correct it. How do I get wiki edit permission?

[Cody]

How do I get wiki edit permission?

PM the Wiki Wizard.

[Eric Walch]

Part of the current reworking is to drop the second docking bay altogether,

Maybe you should rethink that, because starting with Oolite 1.77, the code will support multiple docks. Nice to have an oxp that already has such a model.

The JS side is described here and the dock properties in shipdata can be found here in the subentities definitions.

Essentially, you can set a main dock for docking, and an other for launching.

[tinker]

Yes it might be nice but this one you have to enter through one that looks like it should be the dock, then fly through the wall into the real one, this would not work even if you are allowed multiple docks, as both would try to use the same entrance.

I'll look at the code though and see about adding one elsewhere, later.

[maik]

How do I get wiki edit permission?

PM the Wiki Wizard.

Just saw this post. PM with credentials is on the way