[NEW-RELEASE] - ZGrOovy Griff System Stations AMENDED -

[Commander McLane]

And just in case anybody has a misunderstanding about that: nobody is providing jellybabies to Lave Academy graduates!

Not even Purple ones?

Nope. As far as I hear their diet consists mostly of pumpkin souffle.

[Smivs]

And just in case anybody has a misunderstanding about that: nobody is providing jellybabies to Lave Academy graduates!

Not even Purple ones?

Nope. As far as I hear their diet consists mostly of pumpkin souffle.

[Cody]

What! No ice-cream?

[Gimi]

And just in case anybody has a misunderstanding about that: nobody is providing jellybabies to Lave Academy graduates!

I smell a trading opportunity here. Main station to lave academy with jellybabies (Royal Blue Jellybabies).

[Commander McLane]

<fighting off the jellybaby-and-icecream spammers to the left and the right, in a futile attempt to make a meaningful post; the katana is coated in jelly and cream, in the most perverse colours of the rainbow>

For example, I changed the code for the Octa with a condition so it would show up in anarchy and in feudal worlds. The result was that the dodo didn't show the proper model nor the proper skin anymore.

All I did was thus change the condition on the octo from governmentnumber equal 0 to lessthan 2 and the condition of the coriolis from goverment greater than 0 to greater than 2. Bang there went the dodo and its nice model and texture.

Just to be clear: Are you saying that only the texture disappeared? So the station was still there, but 'naked'? This would be a bug. No condition in shipdata should be able to strip a model of its texture.

Or are you saying that the distribution of stations over the systems changed? Where there was a (correctly textured) Dodo before, there would now be a (correctly textured) Coriolis? This would be normal behaviour and is to be expected.

You see, Oolite distributes stations pseudo-randomly in the Ooniverse according to its present station mix. Pseudo-randomly (instead of purely randomly), because when you quit the game and then start a new session, the distribution will be exactly the same as in your last session. In a real random system the distribution would be different each time you start Oolite.

But first Oolite has to rely on a mix of stations. If you change the mix (for instance by adding a new station, or changing the conditions under which certain stations appear), the overall distribution of stations will change as well as a result. It's only logical: if you add a completely new station to the mix, it wants to take its place in the Ooniverse. But that place was already taken before. For every specimen of the new station type appearing in a system, whatever station was in that system before has to go. This changes also the overall balance of stations. Dodos and Icos are always rarer than Coriolis. So, if due to a new station the total number of Coriolis is reduced, the number of Dodos and Icos must also be reduced. Therefore some of the systems which had a Dodo before will now get a Coriolis. If you only change the conditions it's basically the same: the whole distribution of stations is re-calculated from scratch, therefore there may be any kind of change. From then on it's going to be stable, until you make another change to the general mix.

[dertien]

Ok I've tested another condition again:

Code: Select all

// Z_Groovy_Griff_System_Stations
{
"dodecahedron-station" = {
	like_ship = "griff_normalmapped_coriolis";
	auto_ai = yes;
	model = "dodecahedron.dat";
	name = "Dodecahedron Station"; 
	roles = "dodo dodec dodecahedron station";
	rotating = "true";	
	scanClass = "CLASS_STATION";
	subentities = (
					"griff_coriolis_dockingbay  0 0 284 1 0 0 0",
					"griff_coriolis_flashers    0 0 -120 1 0 0 0"
				   );
};
"icosahedron-station" = {
	like_ship = "griff_normalmapped_coriolis";
	auto_ai = yes;
	model = "icosahedron.dat";
	name = "Icosahedron Station"; 
	roles = "ico icosa icosahedron station";
	rotating = "true";	
	scanClass = "CLASS_STATION";
	subentities = (
					"griff_coriolis_dockingbay  0 0 501 1 0 0 0",
					"griff_coriolis_flashers    0 0 40  1 0 0 0",
				   );
};
"griff_normalmapped_coriolis_2" = 
	{
	"conditions" = (
                "systemGovernment_number greaterthan 3"
               );
	frangible = "false";
	like_ship = "griff_normalmapped_coriolis";
	name = "Coriolis Station";			 
	roles = "coriolis station";	
	rotating = "true";
	scanClass = "CLASS_STATION";
	subentities = (
					"griff_coriolis_dockingbay  0 0 501 1 0 0 0",
					"griff_coriolis_flashers    0 0 120 1 0 0 0",
					"*FLASHER* -250 0 750 120 1 0 30", 
					"*FLASHER* -250 0 1000 120 1 0 30",
					"*FLASHER* -250 0 2000 120 1 0 30",
					"*FLASHER* 250 0 750 120 1 0 30", 
					"*FLASHER* 250 0 1000 120 1 0 30",
					"*FLASHER* 250 0 2000 120 1 0 30"
				   );	 
	};
"octahedron-outpost" = 
	{
	frangible = "false";
	like_ship = "griff_normalmapped_coriolis";
	name = "Octahedron outpost";
	"conditions" = (
                "systemGovernment_number lessthan 3"
               );			
	model = "octahedron.dat"; 
	roles = "coriolis station";	
	rotating = "true";
	scanClass = "CLASS_STATION";
	subentities = (
					"griff_coriolis_dockingbay  3.75 0 281.075 1 0 0 0",
					"griff_coriolis_flashers    0 0 -100 1 0 0 0"
				   );
	shaders = 
			{ 
				"griff_station_coriolis_diffuse.png" = 
				{ 
					vertex_shader = "griff_normalmap_ships.vertex"; 
					fragment_shader = "griff_station_coriolis.fragment"; 
					textures = 
							(
								"griff_station_coriolis_diffuse.png", 
								"griff_station_coriolis_normalmap.png",
							);
					uniforms =
							{
							uColorMap = { type = texture; value = 0; };
							uNormalMap = { type = texture; value = 1; };
							uTime = "universalTime";
							hull_heat_level = "hullHeatLevel";
							};				
					}; 
			};
	};
}

This code should make the octo outpost show up in anarchy and feudal systems right ? Well it doesnt. if I fly from quator (anarchy) to begeabi (feudal) in G1 just north norht west of Reorte. I get the Octo Outpost in the anarchy yes, but I get a coriolis in the feudal world. How do you explain that, or am I missing something here ? AND I have a coriolis station at Vebege also which should be an Octahedron station since vebege is an Anarchy.

I don't get this, and so I stuck with something that was sensible and worked.

[dertien]

If I for example remove the "shader" part of the Octo in the shipdata plist file completely, the anarchysystems will show up Corioleses again ... Now that is another thing I dont understand. I keep the model in there, with the Like ship behaviour and it shows me a coriolis. doesnt make any sense to me either. It should still show the octahedron.dat but without the correct texture or am I wrong.

And yes it occured to me that one some occasions I would lose the model and texture ingame, but the station would be correct, but just the vanilla version that comes with standard oolite.

Also I had an Icosahedron station showing up perfectly in usrarema (south of biarge) but it would be naked and again the vanilla model in Reorte. Beleive me I've gone through some uncomprehenisble things here making this oxp.

[Commander McLane]

The like_ship = "griff_normalmapped_coriolis"; indicates that there exists another Coriolis station, namely the griff_normalmapped_coriolis, either inside or outside your OXP. As it's not in your shipdata, it must be outside. And where it lives, there may be other Coriolis types as well.

If this griff_normalmapped_coriolis doesn't have the same condition in its shipdata, there is nothing to prevent it from being created in Feudal or Anarchy systems.

BTW: the greaterthan 3 also excludes Multi-Governments and Dictatorships, because it allows only values of 4 or more. On the other hand, lessthan 3 only allows Anarchies, Feudals, and Multi-Governments. Poor Dictatorships, they're in both cases excluded.

(Numbering begins with 0, not 1.)

[dertien]

The like_ship = "griff_normalmapped_coriolis"; indicates that there exists another Coriolis station, namely the griff_normalmapped_coriolis, either inside or outside your OXP. As it's not in your shipdata, it must be outside. And where it lives, there may be other Coriolis types as well.

If this griff_normalmapped_coriolis doesn't have the same condition in its shipdata, there is nothing to prevent it from being created in Feudal or Anarchy systems.

BTW: the greaterthan 3 also excludes Multi-Governments and Dictatorships, because it allows only values of 4 or more. On the other hand, lessthan 3 only allows Anarchies, Feudals, and Multi-Governments. Poor Dictatorships, they're in both cases excluded.

(Numbering begins with 0, not 1.)

Okay makes sense, but how do you explain this;

I removed the shader part from the shipdata.plist and now ico and dodos are again naked and the original Oolite model. Since they have the like ship = griff coriolis line and a different model souldn't they get their texture in the griff's coriolis oxp and their texture from the dat file in my oxp ? why would they load the vanilla Oolite model and texuture. That is beyond me.

Hm Okay my mistake so far, I took out a }; too much

\that probably caused that.

[Commander McLane]

Another point: I assume your plist is a shipdata-overrides.plist (not shipdata.plist)?

You are using entry-names which are already used by the game: dodecahedron-station and icosahedron-station. These already exist in Oolite's own shipdata.plist, and if your plist uses the same names it will overwrite and therefore erase the stations in Oolite's own shipdata.plist. (EDITed, because what I originally wrote was rubbish. Apologies, it's late at light here.)

shipdata-overrides.plist is different, because it takes an existing entry and allows you to change it. If your file is called that way, there is another problem: you are changing and thereby overwriting the default dodecahedron-station and icosahedron-station entries, but not the default coriolis-station entry. Which means that original 'flat' Coriolis stations exist happily ever after. As this type of station is in vanilla Oolite by far the most abundant in the Ooniverse, I would expect to see a fair number of them even if your new stations have been added to the mix.

[dertien]

Another point: I assume your plist is a shipdata-overrides.plist (not shipdata.plist)?

It has to be, because you are using entry-names which are already used by the game: dodecahedron-station and icosahedron-station. These already exist in Oolite's own shipdata.plist, and it is illegal to create another shipdata.plist-entry under the same name. I don't know how Oolite would react in that case, but it could cause strange and unexpected behaviour.

shipdata-overrides.plist is different, because it takes an existing entry and allows you to change it. If your file is called that way, there is another problem: you are changing and thereby overwriting the default dodecahedron-station and icosahedron-station entries, but not the default coriolis-station entry. Which means that original 'flat' Coriolis stations exist happily ever after. As this type of station is in vanilla Oolite by far the most abundant in the Ooniverse, I would expect to see a fair number of them even if your new stations have been added to the mix.

Nope it is a shipdata.plist file but it shows griff's coriolises fine since they depend on the one in griff's all in one shippack. But its no biggie to change the name. I didn't realise it made a difference, so I just took the same name I used for the two ships I created.

Will change that now.

The reason I used the original Oolite names was that with a name like "my_griffified_dodo_station" the station would simply not replace the model nor the texture, this way it worked all the way.

[dertien]

Well changing the shipdata.plist to the overrides version didnt help a bit. It made it worse. The octahedron was nowhere to be seen anymore, so I changed it back to shipdata.plist and that seems to put everything back in place.

[Commander McLane]

Wait! It's late at night here, and I'm probably not entirely clear anymore. Forget what I said about strange and unexpected behaviour. Having a shipdata.plist with same entry names means that your stations will replace the original stations. If that's what you want, that's what you should do.

Having a shipdata-overrides.plist with same entry names means that your stations will modify the original stations. That's probably not what you want.

Having said that, I am not clear what your problem is. Everything you're telling me is consistent.

(1) You created an icosahedron entry which replaced Oolite's own icosahedron, and you saw your ico in game.

(2) You created a dodec entry which replaced Oolite's own dodec, and you saw it in game.

(3) You created an octo entry, and you saw it in game. The octo is bound to low politics.

(4) You created an independent coriolis entry, which replaced neither Oolite's own coriolis, nor the Griff coriolis, therefore you saw all three types of coriolis in game. Your coriolis is bound to high politics, the other (at least) two coriolis types are not bound to any politics. Therefore you saw your own coriolis in high politics systems, and the original coriolis and the griff coriolis in any system.

This is what you have done, and what you described as what you saw. There is absolutely no bug, problem, mystery or inconsistency. The game is doing exactly what you're ordering it to do.

a) If you don't want to see the original coriolis (note: it isn't 'naked'; it looks differently because it has a different (much simpler) texture; that's what everything looks like without OXPs), you have to remove it from the game. One simple way of removing it is to overwrite its shipdata.plist entry, as you have done with the dodec and the ico.

b) If you don't want to see the griff coriolis which obviously serves as a template for your own stations, you have to remove it from the game as well. As long as you need it as a template, you cannot physically remove it by deleting its entry or removing the OXP. You could set its role-probability to 0, then it won't be chosen by the system populator again. Or you could raise the role-probabilities of your own stations, which makes the appearing of other stations at least much more unlikely and rare.

There are a couple of things you still have to learn, but you're on a good way. Keep it up!

[Eric Walch]

The others are possibly not documented yet. I can't check, because the Wiki is down.

Its up again and they can be found in [wiki]Methods[/wiki], the page with all the legacy stuff. (somewhere near the bottom of the page under 'System States'.) Most of it is useless when using JS but sometimes you still need them. e.g. when putting those values as variable in messages.

[Commander McLane]

Suggestion: they could get a footnote (or a linked sub-page) on their respective JS-pages. For instance http://wiki.alioth.net/index.php/Oolite ... ce:_System could link to a page containing only the legacy system querying variables.

And they also could be linked from the scripts-in-plists page(s), because that's the only instance when you actually need to know them nowadays.