Oolite Bulletins

Reposted by request from https://bb.oolite.space/viewtopic.php?p=88105#88105

Lestradae wrote:

The obsolete warning, yes. But for the RS/OSE packages, there is information included there that says which oxps they intend to be replacement alternatives to. That is not the responsibility of the original oxp's makers or the wiki admins, that is my responsibility as the RS/OSE provider.

Consider the person who is introducing themselves for the first time to OXPs.
They will download many OXPs that seem to be of interest, only to find after downloading them that many of them are advised, by other OXPs that have also been obtained, to not be used.

The alternative here is to have a note on the duplicate OXPs that they are also included in other named OXPs. That way a person can decide if they want to try just the individual ones. If they want to try out one of the multi-packs then they will know beforehand - which is an important aspect here - that they need not perform duplicate/obselete downloads.

Myself, I personally wasted about 3 times the time it would have taken, not knowing that. All of the OXPs were downloaded, stored away, unpacked, and shuffled over to the AddOns folder. Then when things failed to work I read the readme files, and ended up trimming away 1/3 of the OXPs.

Then, when documenting some of this, due to the wiki not having all of the info, the experience of digging in to the OXP code-base was very useful for me.

Had I known though about the duplicate content issues up front, a lot less time would have been wasted on the managing and organising side of things. That upsets me, because I want to use that time to play the game instead.

Specify up front, on the wiki's OXP page where they are already used, and we'll stop wasting a lot of peoples time. After the fact it's clear which ones are incompatible with other ones, but this information needs to be readily available before the fact.

Boy Racers (also found in Realistic Shipyards)

and a piece somewhere about clashing OXPs if it's not there already.

Enable yesterdays request for an account on the wiki and I'll be more than happy to lend a hand.

Off-hand I think RS/OSE are the only "meta" OXPs to which this would apply? The only other slightly relevant case is Eric and my bigShips OXP, and that isn't really applicable as it's distributed as a separate zip file within certain OXPs that use it.

Oh, and...

pmw57 wrote:

Then when things failed to work I read the readme files, and ended up trimming away 1/3 of the OXPs.

Methinks that's part of the problem. We don't put readme's in OXPs just to make them bigger

Thargoid wrote:

Off-hand I think RS/OSE are the only "meta" OXPs to which this would apply? The only other slightly relevant case is Eric and my bigShips OXP, and that isn't really applicable as it's distributed as a separate zip file within certain OXPs that use it.

Oh, and...

This is the problem, because memory is a fickle creature.

With the Assassins Guild OXP, the Orbits OXP changes things that cause problems with the Assassins missions.

Then there is RingPod / Ring Racer - of which you really only want one installed at a time, not both together.

This sort of information is not currently on the wiki and really is needed. It's not in any of the readme files either.

pmw57 wrote:

Then when things failed to work I read the readme files, and ended up trimming away 1/3 of the OXPs.

Methinks that's part of the problem. We don't put readme's in OXPs just to make them bigger [/quote]

Understood, yet how many readme files are required reading before one jumps in to give things a go.

If there is mandetory information that needs to be known as a part of the installation process, this is where you get peoples attention with an install.txt file instead.

I am fortunate enough to have read the readme files, but bear in mind that many other people won't. Place the required info in something like install.txt and you will then have the upper hand when people question why things break.

pmw57 wrote:

With the Assassins Guild OXP, the Orbits OXP changes things that cause problems with the Assassins missions.

That sort of incompatability I agree should be in the readme, but also as its known it should be one that is worked around by one or both of the OXPs in question if possible.

pmw57 wrote:

Then there is RingPod / Ring Racer - of which you really only want one installed at a time, not both together.

Those two can quite happily sit side by side, and are entirely seperate. That said RingPods doesn't do much, which is actually why I wrote RingRacer as the next step on from it.

pmw57 wrote:

This sort of information is not currently on the wiki and really is needed. It's not in any of the readme files either.

Firstly not all OXPs were written at the same time, and it would be rather difficult to put something in a readme about incompatibility with an OXP that wasn't written yet Secondly it would be a semi-impossible task to do, as then every OXP made would need to be tested against every other one at every point in their usage, which due to number and certain OXPs complexity is a daydream. Also whenever a new OXP came out the whole thing would have to be repeated, and then the readme for every OXP (and therefore every uploaded OXP) would need to be updated. Ain't gonna happen, although wiki updates with that kind of notes are possibly an idea. That said not everyone looks there either.

pmw57 wrote:

Understood, yet how many readme files are required reading before one jumps in to give things a go.

However many OXPs you install.

pmw57 wrote:

If there is mandetory information that needs to be known as a part of the installation process, this is where you get peoples attention with an install.txt file instead.

If they don't read readme.txt, why are they going to read install.txt?

pmw57 wrote:

I am fortunate enough to have read the readme files, but bear in mind that many other people won't. Place the required info in something like install.txt and you will then have the upper hand when people question why things break.

And we don't currently by telling them politely to RTFM, in this case FTM being the readme file?

Thargoid wrote:

That sort of incompatability I agree should be in the readme, but also as its known it should be one that is worked around by one or both of the OXPs in question if possible.

In the mean time, the wiki should be updated to help advise people about this. All it would take is to add a Compatibility section at the end of the Assassins page.

I have approached the wiki owner about gaining an account but to no avail. Does anyone know how I may gain a wiki account?

pmw57 wrote:

Then there is RingPod / Ring Racer - of which you really only want one installed at a time, not both together.

Those two can quite happily sit side by side, and are entirely seperate. That said RingPods doesn't do much, which is actually why I wrote RingRacer as the next step on from it.

So Ring Racer can be considered an upgrade of sorts, from RingPods.

Also whenever a new OXP came out the whole thing would have to be repeated, and then the readme for every OXP (and therefore every uploaded OXP) would need to be updated. Ain't gonna happen, although wiki updates with that kind of notes are possibly an idea. That said not everyone looks there either.

I agree, the wiki is the very best place record this sort of information. I would love to be able to assist here, given the availability of a wiki account.

I think winston is the one to contact about a wiki log in, pmw57.

T, is that correct as far as you know?

If someone took the task unto themselves to add a compatibility page with info like the one debated above, or even an extended installation guide, this would be a good idea for "first glance" beginners.

At least these are my 0.2 Cr or, as we know in the meantime, 200 $ or 150 € ...



L

Lestradae wrote:

I think winston is the one to contact about a wiki log in, pmw57.

T, is that correct as far as you know?

Aha, we now have someone in the firing line.

I'll let him know that you lads have pushed him to the head of the queue, and see where we can go from there.

pmw57 wrote:

With the Assassins Guild OXP, the Orbits OXP changes things that cause problems with the Assassins missions.

I never had installed Orbits, but when reading the readMe it is immediately clear it is changing planet positions. So it is likely incompatible with any oxp that requires certain planet positions for its secondary planets. e.g. Tionisla pulsar will also not work with it.

Even the current trunk version is incompatible with it. I just launched: kaboom.... After trying different saved games I noticed I immediately was in the planet atmosphere after launch. Somehow the main planet was moved towards the station (Or vise versa). No problem with 1.73.x

Really? I didn't think there were any changes to that part of the code inside trunk. Hmm, time to have a look in there - again!

Kaks wrote:

Really? I didn't think there were any changes to that part of the code inside trunk. Hmm, time to have a look in there - again!

I could be because stuff like setPosition stop being working for Orbits with 1.74. ?

EDIT: looking better in the code I see that the default addition position for the extra planets is the mainPlanet position. From there they are relocated. With setPosition not working anymore, they stay at that location. And at Lave we just have one that is bigger than the original planet. That planet is now completely covered with bits of me.

So Orbits need definitely new code.

Also the [] with quaternion definition are missing. After fixing that, I finally could launch. But there are plenty of warnings in the log about entity.ID deprecation. Looking if it could be used differently I wonder if it ever has worked. He uses the ID to make sure every planet is placed at a reproducible spot. To do this he sorts the planets on ID number. I wonder however if these ID number order was always the same? Anyhow, there is no way to sort them in a reproducible way.

We definitely need a way to unique recognise a planet. The planet key would be best as this is unique by definition.

Good to know it's in the OXP / js changes, rather than inside the main oolite code!

Well, we now have the new read/write .texture property, that could be used to identify the different planets! Besides that, planets are entities, so the name they're given inside the .plist should be already accessible via .name!

Kaks wrote:

Besides that, planets are entities, so the name they're given inside the .plist should be already accessible via .name!

That is only for shipEntities. Entities in general have no name nor a PersonalityNumber.

I see... just a question though... no matter if they've been moved about, system.planets[1] will always refer to the same planet as long as you're still in that system. So why would orbits need .ID on top of that?

Kaks wrote:

system.planets[1] will always refer to the same planet as long as you're still in that system. So why would orbits need .ID on top of that?

According to the comment Erbi noticed the order in the array was different on different ways of system entry. e.g. launch from a saved game or with a hyperspace jump. I haven't looked but I think that list is player distance sorted and than he is right. And the whole purpose of the oxp is to rotate the planets in time. They don't move during the stay in the system, but on every entry they have moved a bit according to the system clock.
(But I am pretty sure that using ID for that worsens things as ID was more or less randomly attached.)