Deep Horizon Industries Meta-OXP

[Cmd. Cheyd]

Ahh... Gotcha. You want to change your end, or want me to change mine?

[Cody]

Just docked at Estiri… the main planet looks like a gas giant though:



I really like the ‘Lights Down’ feature… fits my Ooniverse nicely.

[Thargoid]

Ahh... Gotcha. You want to change your end, or want me to change mine?

See the PM I just sent you - there are a few other comments on some of the scripts. If you're going to update them then you may as well roll this into it as well. If not then I'm happy to update Planetfall, but it will mean everyone with it will need to update to be compatible with SR2.

Not fussed either way, but no point in both OXPs updating.

[JazHaz]

Have added this Meta-OXP to the OXP table on the wiki. Have just put it as a link to the deephorizons.com website for now. Maybe we should have a full page on it at a later date, what do you think?

[Cmd. Cheyd]

Sounds great... Could you also add Lights Down, Pirate Ambushes, and Gas Giant Skimming?

[Commander McLane]

Hopefully Commander Mcclane will include SR2 compatibility in his next assassins update.

<hears his name being uttered>

Ummh? Moi? Oh thank you sir, and %R bless you, but this is too much honour you're doing to this humble script monkey. Assassins is the creation of nobody else than the truly great LittleBear, the giant on whose shoulders we mere mortals of OXPing are standing.

I wouldn't dare to update his magnum opus of OXPing which I haven't even finished playing yet.

But, as you're making the point here: Assassins changes and adds planets by script (as opposed to: by planetinfo). Thereby it will always override all changes made in planetinfo. Practically this means that in those systems affected by Assassins you will always see the textures coming with Assassins, not those of SR2 (or SR1, for that matter). You will also—in some cases—have the ambient light level cranked up to 11, disregarding the default level, or any change made by Lights Down.oxp.

Thus, in case of conflict, Assassins simply wins. Which means that its missions are always playable and will not become impossible by accidentally altering the setup of the system. I guess that is the concern behind the original question. So, rest assured.

</returns to dozing in the dazing heat>

[Kaks]

But can it be improved?

No. It would require a mechanism by Oolite to ask every oxp if it wants to present a special planet for that system. Such a mechanism would be quite different than how an oxp currently works.
Possible but not with current Oolite.

Well, there are ways of permanently change all planets' textures: the first one 'just' needs you to add texture='newplanettexture.png' as an override inside planetinfo.plist:

http://wiki.alioth.net/index.php/Planet ... st#Texture

This would need to be done for each system in each galaxy, meaning that 'just' actually means having to copy and paste the blasted thing 2048 (256*8) times...

However, if we get more than one oxp using the same method, the last oxp loaded 'wins' and their texture override will override all other oxps.



With javascript, there are actually 2 ways of overriding planet textures: a temporary one - the one used by just about everybody so far:

Code: Select all

System.mainPlanet.texture = 'tmpTexture.png';

(The changed texture will only stay on until we leave the system. Can also be used on secondary planets & moons)

and a permanent one:

Code: Select all

System.info.texture = 'permTexture.png';

The permanent js method can be used at a distance too:

Code: Select all

System.infoForSystem(0, 55).texture = "whateverpermtexture.png";

The permanent js override has higher status than a .plist override (the latter always permanent), but increases the size of the save game file, like mission variables do.

In theory, System Redux 1.x could already be given a planetinfo.plist with all the relevant information, and then happily skip the retexturing for the main planet via javascript...

[JazHaz]

Have added this Meta-OXP to the OXP table on the wiki. Have just put it as a link to the deephorizons.com website for now. Maybe we should have a full page on it at a later date, what do you think?

Sounds great... Could you also add Lights Down, Pirate Ambushes, and Gas Giant Skimming?

Yeah probably could do that. For now I have mentioned them in the text of the OXP table.

[tonyhippy]

The gas giant textures seem to be mapping strangely onto the planets with the bands of clouds forming hexagons intead of rings.

[Cmd. Cheyd]

But, as you're making the point here: Assassins changes and adds planets by script (as opposed to: by planetinfo). Thereby it will always override all changes made in planetinfo. Practically this means that in those systems affected by Assassins you will always see the textures coming with Assassins, not those of SR2 (or SR1, for that matter). You will also—in some cases—have the ambient light level cranked up to 11, disregarding the default level, or any change made by Lights Down.oxp.

Thus, in case of conflict, Assassins simply wins. Which means that its missions are always playable and will not become impossible by accidentally altering the setup of the system. I guess that is the concern behind the original question. So, rest assured.

</returns to dozing in the dazing heat>

Actually sir, SR2 adds planets, moons, and textures them all by script as well. So unless I am misinterpreting how Assassins does it (I'll go check it's script here in a sec), it is in danger of being rendered impossible. I built the API so someone else's OXP could tell SR2 to texture or not, add planets or not, add moons or not, or control any of it's other functions. Without that API, the changes made by Assassins may be overwritten depending on the event they occur on and the order Oolite executes the function of each script. If it falls alphabetically, Assassins would lose to SR2.

Oh, and tonyhippy - that's part of the core Oolite code. It's a feature that I hope is fixed in a future version.

Hmm... Wonder if it does it with cube maps... I'll have to play...

[Eric Walch]

... the changes made by Assassins may be overwritten depending on the event they occur on and the order Oolite executes the function of each script. If it falls alphabetically, Assassins would lose to SR2.

The only thing that is alphabetical for oxp names is loading the plist on start-up. Script execution order is random, there is no guaranteed execution order. With one exception: On witchspace jumping, the legacy scripts execute before the JS script. So Assassins will loose on this.

But it should not be a major problem for the missions. It is only the texture of the main planet that is affected, it will be able to add its secondary planets. The only problem is not texturing, but some of the SR moons might be added in a location were the action is planned. But that problem qualifies for a lot of other oxp's like lave academy, feudal states etc.

[pagroove]

Glad to see that you launched this oxp. It comes as a nice surprise because I havent visited the boards for 3 days due to the heatwave here in The Netherlands. I spent most of the time on playing Fuel on Ps3.

Now I see that even Within such a short time a lot can happen.

[Commander McLane]

Assassins does win over SR1, as far as planet texturing is concerned. I am too lazy right now to compare the SR1-texture-application-mechanism with the SR2-texture-application-mechanism, but if it is basically the same, there should be no difference.

EDIT: Hmmm, no I'm getting curious. It appears that Assassins doesn't change main planet textures at all, only adds additional (and textured) moons and planets. So I am asking myself: Why does no SR1-texture appear in my current, Assassins-affected system. The answer must be that, as I seem to remember now, all systems affected by Assassins are explicitly excuded from any changes in the SR1-script. Yes, I think that's how it was working.

[JazHaz]

I've installed the Gas Giant Skimming OXP, and it seems to be replacing the main planet in a system with a gas giant.

When I first loaded today after installation I launched and flew to land at what I thought was the planet (using Planetfall v1.30), only to crash at low altitude. Thought my planetary equipment might have been damaged, so I tried again, however, just in time, I noticed the warning about it being a gas giant before I crashed again!

Re this, I've done a few experiments and have found that the problem is not with the GGS OXP but with the main SR2 OXP. I removed the GGS but still got the main planet replaced by a gas giant *every* time.

Hmm... Looks like Thargoid and I have a few more things to talk about.

Having seen your script, I can see what's happening.

Having read the above, is there any chance of an update to fix this issue? I've had to remove the DH OXP set for now as these gas giants were proving to be a real nuisance!

[Cmd. Cheyd]

Jaz-
Tharg and I worked it out early this weekend. We had agreed to a common property, but we were using it in different ways. He was setting isGasGiant only on planets that were, I was establishing the property for everything and then storing a True/False value I would check.

I was just waiting for any more possible bugs / conflicts to appear before issuing an update. There's that one, and a few minor ones that were PM'd to me over the weekend. Seems it's slowing down now. I'll post an update later today probably.