New EliteWiki OXP table layout brainstorm spot

Wiki pages · Post by **Thargoid** » Tue Sep 22, 2009 9:42 am

Two points come to mind. Firstly the table page is linked directly from the main Oolite page of the wiki (this one), whereas the auto-generated index page isn't. And secondly, due to the naming of the pages, if you type "OXP" into the search box, you get taken to the table page (as it's page name is OXP).

Both of those would for me be reasons why one is more used than the other. Personally I do use the index tags after Ahruman showed me them, and they are quite useful, if a bit limited in that you can only search for one of them at a time, and there is no way to control versioning with them.

But then I guess this sort of thing isn't really what the wiki is designed for. It's for information-hosting, not really file-hosting.

lfnfan · Post by **lfnfan** » Tue Sep 22, 2009 10:26 am

So even when you are aware of both ways of getting to OXPs, the table is preferable.

Still, the value of a 'one click' complete OXP index page would increase if the structure of the main OXP page changed from 'one large table' to: 'main OXP page > OXP by type (table pages) > individual OXP page'. With the current 'one large table', it's probably as fast as the index page is to Ctrl+F the OXP you are after, but if that 'one large table' gets broken up in to 8 or 9 smaller ones each on a different page, that Ctrl+F option is not available.

another point is that - given a bit of attention in the tagging of individual OXP pages - the index page auto-generates 'for free', so where's the harm in that?

Wiki pages · Post by **Thargoid** » Tue Sep 22, 2009 10:39 am

For me the problem isn't using the big table's usage (there it's fine), it's maintaining and upkeeping it. I personally have rarely had a problem in getting an OXP via it, but to add a new one into it is a real PITA if you do it properly, maintaining the alternate background colour bandings etc and making sure it's in the correct place alphabetically.

That's where the indexes win, in that they're automagically created. If the table could do that (and possibly include a version number column, and/or a last-updated date one) then things would be fine I'd say. But it can't, hence the discussion here.

lfnfan · Post by **lfnfan** » Tue Sep 22, 2009 11:10 am

ah, well if it's practical maintenance, upkeep, and automagical generation, i don't have anything to bring to the table, being clueless about all things wiki-code.

from a theoretical layout and organisation point of view, I think the universe of oxps could be better set out for the general user, per my previous (long) post.

zevans · Post by **zevans** » Thu Oct 01, 2009 12:38 am

So to summarise:

* Keep a master page where every OXP is mentioned and categorised. This will still be http://wiki.alioth.net/index.php/OXP. Caveat it with a warning that it is manual and may therefore be slightly out of date, and point to the wiki category pages as the automated-but-harder-to-get-info-from alternative.
* NO download links on the master page, rather, the link should point to the OXP's page. (If the OXP doesn't have a page, I'll create one; really stale OXPs I might cheat and pile a few into a larger page.)

* I'm hoping this will flush out any OXP pages where we forgot to add the {{xxx-OXP}} tags, again will fix-on-fail.

* The other thing we need to do is standardise the sections in invidual OXP pages a bit... luckily most people have been quite good about copying what's already there but sometimes the link is at the top, sometimes at the bottom... etc.

...all of which is more or less what lfnfan said.

On top of that I'm still convinced there should be ways to automate some of this stuff but no-one I know seems to know anything about wikis beyond the basic markup. I was expecting to find an ex-colleague somewhere along the line who was a guru, but nope!

pmw57 · Post by **pmw57** » Thu Oct 01, 2009 2:03 am

zevans wrote:
On top of that I'm still convinced there should be ways to automate some of this stuff but no-one I know seems to know anything about wikis beyond the basic markup. I was expecting to find an ex-colleague somewhere along the line who was a guru, but nope!

If we use a template for OXP information then information like version number and supported game version (minimum, recomended, etc) can be easily accommodated.

Once there is a template in place, we can script the retrieval of information, so that tables of OXPs for certain version numbers can be automagically created.

The trick is to first provide the information in a reliable and consistant manner, and this is where templates come in to play.

lfnfan · Post by **lfnfan** » Thu Oct 01, 2009 10:51 am

pmw57 wrote:
Once there is a template in place, we can script the retrieval of information, so that tables of OXPs for certain version numbers can be automagically created.

that sounds very promising.

would it be possible to use scripts to automagically create a replica of the 'one large OXP table', pulling info from the underlying wiki page templates? Would it be possible to automagically sort that table by OXP category, date last updated, etc? [/vistas opening up]

I did ask a similar question on a wikimedia forum, but got no response - i think that forum is on the less-friendly side over from Riedquat (or perhaps they are all just busy dealing with trumbles).

pmw57 · Post by **pmw57** » Thu Oct 01, 2009 11:29 am

lfnfan wrote:
pmw57 wrote:
would it be possible to use scripts to automagically create a replica of the 'one large OXP table', pulling info from the underlying wiki page templates? Would it be possible to automagically sort that table by OXP category, date last updated, etc? [/vistas opening up]

I did ask a similar question on a wikimedia forum, but got no response - i think that forum is on the less-friendly side over from Riedquat (or perhaps they are all just busy dealing with trumbles).

I would suggest using a partial transclusion.
http://en.wikipedia.org/wiki/Wikipedia: ... ansclusion

That way a bot can regularly edit the OXP page with transclusions for each page in the Oolite_expansion_packs category.
http://en.wikipedia.org/wiki/Wikipedia:Creating_a_bot
http://wiki.alioth.net/index.php/Catego ... sion_packs

When the appropriate section on the individual OXP page is updated, the main OXP page content will then automatically update itself.

When the Oolite_expansion_packs category changes, the bot can recreate the OXP page with partial transclusions from all pages in the Oolite_expansion_packs category. This can also be performed manually, but scripting the update relieves the tedium.

Edit: It may sound like I know what I'm talking about, but really I just make it up as I go.

lfnfan · Post by **lfnfan** » Thu Oct 01, 2009 12:41 pm

pmw57 wrote:
It may sound like I know what I'm talking about, but really I just making it up as I go.

what do the Commanders think about bot-based partial transclusion?

It seems, to coin a phrase, wikimedia has the technology....

pmw57 · Post by **pmw57** » Thu Oct 01, 2009 1:02 pm

lfnfan wrote:
what do the Commanders think about bot-based partial transclusion?

It seems, to coin a phrase, wikimedia has the technology....

This may be of assistance too:
http://www.mediawiki.org/wiki/Extension ... ansclusion

While normal transclusion is primarily intended to transclude large portions of small templates, labeled section transclusion is intended for small portions of large pages.

CheeseRedux · Post by **CheeseRedux** » Fri Oct 02, 2009 9:50 pm

I accidentally stumbled across the wonder that is Oolite a few days ago.
Since then I have spent a considerable time reading the Wiki, sifting through Forum posts, downloading, installing, testing, uninstalling, reading, sifting etc, etc.
Like so many before me, I was looking for some guidance as to which of the OXPs were must-have, but with the realization that the consensus is that there is no consensus, I went for broke and got almost all of them.
All in all I've probably spent more than 10x the time setting up and preparing than actually flying around.

Being new to Oolite [but not Elite - Commander Cheese was the name used for the joint commander two of my friends and I used to take turns flying on the good old C64; we even devised a system where one of us would be flying while another manned the weapons systems - but I digress] the sheer number of OXPs can be daunting, and any upgrades to the Wiki helping the newbie navigate would be good.

Since work sometimes keeps me offline for weeks at a time, I can already foresee that I'll be doing quite a bit of the catching up from time to time. (Even in the few days I've been around, PlanetFall went from 1.21 to 1.23)
What I would very much like to see is a basic list of "what's new".
From the discussion on this thread it is clear that automatic sorting under Wiki is far from trivial.

I suggest a very simple, no-frills solution: A page containing Last Version Date and Name/Link.
Whenever a new version is done, the author simply puts the OXP on top of the list.
Thus, whenever someone returns after being away (or for that matter, someone who doesn't read the Forum closely enough to catch all release/update announcements) all that is needed is to check this page to find any updates since last time.

Beyond the few moments it would take to put the new release on top of the list, this format requires absolutely NO maintenance. (The virtue of removing the previous version from the list can be argued, but it is not a necessity for the list to work.)

This may be a matter of taste, but since I have already downloaded all the OXPs that I want from the already existing lists, there is no reason for me to ever look at those lists again - provided there's a way for me to find what's new/changed.

As an afterthought: I see no good reason to limit such a list to just OXPs; new game versions could also find their natural place here.

CheeseRedux · Post by **CheeseRedux** » Fri Oct 02, 2009 10:19 pm

After my ramblings in my previous post, I'll try to keep this one short.

Having downloaded and installed every single Mission OXP I could find, I now intend to completely ignore them.
That is, I'm going to happily flutter around in the Galaxies until I stumble upon the missions, not seeking them out.
So, if some mission requires me to fly a specific ship to a specific planet carrying a specific cargo in order for it to be triggered, chances are I'll miss it.

So for those who would like to be kept in the dark, a no-spoiler mission page could be an idea, containing only the the bare minimum of information on all the mission OXPs; ie a download link, any dependencies, plus whatever information the author deems absolutely essential.

On the opposite end of the scale, for those who want to make sure they haven't left anything out:
A list of all the trigger conditions for any specific mission; Rank, Galaxy, Legal Status, you name it.
(A list I can certainly see myself checking sometime down the road, once I've reached the been everywhere, seen everything stage...)

pmw57 · Post by **pmw57** » Fri Oct 02, 2009 10:26 pm

CheeseRedux wrote:
Like so many before me, I was looking for some guidance as to which of the OXPs were must-have, but with the realization that the consensus is that there is no consensus, I went for broke and got almost all of them.
All in all I've probably spent more than 10x the time setting up and preparing than actually flying around.

Beware downloading OXPs if you intend to use megapacks such as Realistic Shipyards or Oolite Shipyard Extension, because most of the OXPs you download won't be able to be used at the same time as the mega packs.

CheeseRedux wrote:
I suggest a very simple, no-frills solution: A page containing Last Version Date and Name/Link.
...
Beyond the few moments it would take to put the new release on top of the list, this format requires absolutely NO maintenance. (The virtue of removing the previous version from the list can be argued, but it is not a necessity for the list to work.)

What would take even less maintenance is for a template on the individual OXP page to contain the release date. That release date would be the category itself, with the date being the sort order. No maintenance required at all then.

Perhaps the information about sorting categories, and listing dates in a sortable manner, can be somehow combined?

[[Category:OXP Release Date|{{DTS|2009|10|04}}]]
http://en.wikipedia.org/wiki/Wikipedia: ... Sort_order
http://en.wikipedia.org/wiki/Template:Dts

The only problem with doing this though is that I suspect that a wiki may have other ways of finding out that information.

Website · Post by **Cody** » Sat Oct 03, 2009 12:50 am

CheeseRedux wrote:
once I've reached the been everywhere, seen everything stage...)

I like your plan, CR.
Welcome to the "friendliest boards this side of Riedquat".

CheeseRedux · Post by **CheeseRedux** » Sat Oct 03, 2009 1:15 am

pmw57 wrote:
Beware downloading OXPs if you intend to use megapacks such as Realistic Shipyards or Oolite Shipyard Extension, because most of the OXPs you download won't be able to be used at the same time as the mega packs.

Fortunately, through the wonders of OCD, all Wiki entries and readme files have been thoroughly perused, so unless there's some undocumented pitfalls, I should be good.
I do appreciate the concern, though.

pmw57 wrote:
CheeseRedux wrote:
I suggest a very simple, no-frills solution: A page containing Last Version Date and Name/Link.
...
Beyond the few moments it would take to put the new release on top of the list, this format requires absolutely NO maintenance. (The virtue of removing the previous version from the list can be argued, but it is not a necessity for the list to work.)
What would take even less maintenance is for a template on the individual OXP page to contain the release date. That release date would be the category itself, with the date being the sort order. No maintenance required at all then.

I must admit that all the technical lingo is far above me - I can barely manage to read a Wiki on a good day.

I just got the impression that list sorting was a difficult subject.

Anyway, my main - oh, okay, only - point here is that a location where anyone can find out at-a-glance what has been updated/added since whenever they last checked would be highly beneficial to virtually everybody.
Your template solution looks to be exactly what the doctor ordered, if I understand it correctly.