Oolite Wiki

[maik]

Good stuff! Thanks a bunch, Cholmondely!

[Cody]

Aye... good work, amigo!

[Cholmondely]

Updating the wiki

Hiran, since the wiki is itself unavailable at the moment, this seems like the best place for discussing how to do it.

I would suggest dividing up the OXZs by category into more manageable chunks:

Activities
Ambience
Dockables
Equipment
HUDs
Mechanics
Miscellaneous
Missions
Retextures
Ships
Systems
Weapons

From http://www.oolite.org/oxps/?sort=c

As well as the blurb, there are
(i) the tags/categories
(ii) the assessments (how the OXZ affects gameplay makes it easier or tougher - or how good one needs to be to cope with the mission or what it does to the game)
(iii) computer assessments in terms of drain on CPU & graphics creation unit
(iv) links to the BB discussion threads and the author's User page (if there is one!)

One approach might be to select a category - something short maybe like Dockables, or something that really appeals to you - and then either we each attack it from different ends (A/Z) or we split each entry between us - you bung in the blurb and I take care of the trimmings.

What do you think?

[maik]

Updating the wiki

Do I understand your intention correctly, you want to copy the extension manager descriptions to the wiki?

[Cholmondely]

Updating the wiki

Do I understand your intention correctly, you want to copy the extension manager descriptions to the wiki?

Hiran has suggested that (in collaboration with myself and anybody else who wishes to join in) we create new wiki pages for the OXZs on the Expansions Manager which have no such page.

So far I've not had to refer to the 'i' descriptions on the Expansions Manager, but it is a source of information where all else fails.

Unlike me, he is a practitioner of the Dark Arts.

[maik]

Updating the wiki

Do I understand your intention correctly, you want to copy the extension manager descriptions to the wiki?

Hiran has suggested that (in collaboration with myself and anybody else who wishes to join in) we create new wiki pages for the OXZs on the Expansions Manager which have no such page.

So far I've not had to refer to the 'i' descriptions on the Expansions Manager, but it is a source of information where all else fails.

Unlike me, he is a practitioner of the Dark Arts.

I wonder how we could automate this. Long-term it is a pain to maintain things twice, and thus will not happen consistently (e.g. if an OXZ author updates the description for the extension manager the copy on the wiki would need an update, too). Couldn't we have one source for this data only, and have both generated from this?

[montana05]

Hiran has suggested that (in collaboration with myself and anybody else who wishes to join in) we create new wiki pages for the OXZs on the Expansions Manager which have no such page.

So far I've not had to refer to the 'i' descriptions on the Expansions Manager, but it is a source of information where all else fails.

Unlike me, he is a practitioner of the Dark Arts.

I will be happy to assist, but I do agree with Malik, creating new pages for OXZ's missing them is great, as soon as you create new categories it would be advisable to add scripts for automation. Unfortunately now we already have a lot of pages from the past hardy to get updated.

[hiran]

I wonder how we could automate this. Long-term it is a pain to maintain things twice, and thus will not happen consistently (e.g. if an OXZ author updates the description for the extension manager the copy on the wiki would need an update, too). Couldn't we have one source for this data only, and have both generated from this?

I thought of something like automatically generating wiki pages from expansions. This could be a small batch job that runs at regular intervals or maybe as part of the CI/CD pipeline.

• it starts off with a list of expansions - this could be the same source that the expansion manager[ uses. (see http://wiki.alioth.net/index.php/Expansions_Manager)

• From that list it uses the download links, then downloads and scans the OXPs, OXzs and whatever it can get hold of. Not sure here, currently I think reading the manifest could be sufficient, future versions could access more information.

• From this information we could then generate wiki pages, one or several if need be. Or filterable/sortable ones if that is possible.

• Finally these pages get uploaded into the oolite wiki.

Not that hard to code. It would more require some knowledge about the expansions and the source to read and the destination to write.

[hiran]

Thinking about this, it could be a very similar process to document ships.
And enemies.
And planets.
And...

The real benefit comes where the data is available in the wiki plus in the in-game information. Alternatively the game could just open a browser window for further reference - I find it a bit annoying to read long text in the limited text rendering capabilities of oolite.

Understand me right: I do not expect the text rendering of oolite to be improved. But let's use the wiki where it is strong and oolite for the game itself.

[Cholmondely]

Does Extension = Expansion = (OXZs & OXPs) ?

[Cody]

<nods sagely>

[hiran]

Does Extension = Expansion = (OXZs & OXPs) ?

I may be using the wrong words. Please forgive me...
Some domains call it extension, some expansion, some plugins, some addons, some ....
I was talking about the OXZs and OXPs.

[maik]

I wonder how we could automate this. Long-term it is a pain to maintain things twice, and thus will not happen consistently (e.g. if an OXZ author updates the description for the extension manager the copy on the wiki would need an update, too). Couldn't we have one source for this data only, and have both generated from this?

I thought of something like automatically generating wiki pages from expansions. This could be a small batch job that runs at regular intervals or maybe as part of the CI/CD pipeline.

• it starts off with a list of expansions - this could be the same source that the expansion manager[ uses. (see http://wiki.alioth.net/index.php/Expansions_Manager)

• From that list it uses the download links, then downloads and scans the OXPs, OXzs and whatever it can get hold of. Not sure here, currently I think reading the manifest could be sufficient, future versions could access more information.

• From this information we could then generate wiki pages, one or several if need be. Or filterable/sortable ones if that is possible.

• Finally these pages get uploaded into the oolite wiki.

Not that hard to code. It would more require some knowledge about the expansions and the source to read and the destination to write.

I agree the initial creation of wiki pages from manifests is not that hard to code, you just need a unique identifier across manifests and the wiki to not start creating duplicates.

The more difficult bit comes when there are updates. One author might leave the manifest as is and just update the wiki page, another might update the manifest but does not like editing the wiki, and the third one is happy to keep both in sync

I believe we should have a complete strategy before we implement such automation. The risk to mess up the wiki is quite real

I can see if I can create a wiki playground again for testing when we get somewhat further.

[hiran]

I agree the initial creation of wiki pages from manifests is not that hard to code, you just need a unique identifier across manifests and the wiki to not start creating duplicates.

The more difficult bit comes when there are updates. One author might leave the manifest as is and just update the wiki page, another might update the manifest but does not like editing the wiki, and the third one is happy to keep both in sync

I believe we should have a complete strategy before we implement such automation. The risk to mess up the wiki is quite real

For updates you mention different cases:

• Automatically generated pages: This is trivial as for updates we can simply overwrite the page.

• Some authors just update the wiki page: We could track for manual changes and no longer auto-update the page - but this behaviour would mean once touched it is back in manual mode, and the quality would deteriorate. Therefore I propose to discourage manually updating pages that were generated or even protect them from interactive users.

• Those that update the manifest only are the good boys, and the first rule applies.

• A bit stranger is if users keep both manifest and wiki page up to date. This is the only case where I see a strategy is necessary. But once we have the automation ready a goal should be set to synchronize the data on the manually maintained wiki pages into the OXPs so we have one source of truth. OXP maintainers should actually agree as from then on they only would have to care about their OXP and the inclusion in the OXP list but nothing else. it eases their life.

I can see if I can create a wiki playground again for testing when we get somewhat further.

This is actually the best approach to move on.

[hiran]

In the meantime I could give that batch job a try.
Who knows which download URL is used by the Expansion Manager to get the most up to date list of plugins?

I found this line so far:
https://github.com/OoliteProject/oolite ... ager.m#L48

which indicates to me this would be the URL used by oolite to find expansions:
http://addons.oolite.org/api/1.0/overview

Next is to figure out syntax and grammar of the data. Or the best parser to choose, as I'd prefer to not implement that myself.
However I am not familiar with Objective C, yet it seems the data format is whatever is generated using the NSCoding protocol.