Oolite Bulletins

I was getting my machine ready for the next run of Oolite and when I fired is up, I found that a lot of my OXPs were outdated. Ok, I guess it is not a big deal to go and download the latest, greatest, but I would be slick if I could just have it automatically check for any updated OXPs based on the running version of the game.

Just a thoguht!

While not quite reaching the level of comfort that an auto-update would bring, in the Wiki Sandbox you can find draft OXP lists with revision dates which you can sort by. That way you can see all the OXPs that have been updated since a certain date. Note that the tables are a work in progress...

for the request : if ever, please optional only.

I do not want any software auto-this or that over the network.

And how would you let your OXPs decide if there is an update ?
The wiki ?
Then any !§%"==/%(5 malicious folks who sneaked an access to the wiki could post their %$$& as an OXP update available there and whoomps! your PC downloading it.

No thanks. I'm malware-free for years now, and there's reasons to that.

snork wrote:

for the request : if ever, please optional only.

I do not want any software auto-this or that over the network.

And how would you let your OXPs decide if there is an update ?
The wiki ?
Then any !§%"==/%(5 malicious folks who sneaked an access to the wiki could post their %$$& as an OXP update available there and whoomps! your PC downloading it.

No thanks. I'm malware-free for years now, and there's reasons to that.

*scratches head* Certainly not via the Wiki.

There have been numerous threads discussing the mechanics of this topic, search e.g. for OXPCentral, or for a more recent post from someone volunteering to develop a mechanism along the lines of apt (Debian's packaging system).

Could you not run it like a journal update? a la podcasting. OK it would be a lot of work keeping track of the merhoosive xml document. Its another one of thos "upkeep" things that can so easily go by the by.

The first thing that needs to happen is a consistent approach to version naming, so there is a reliable way of working out what version is what. It could be MyOxp1.5.oxp or it could be a file called version.txt in the root, or something else, but I think some systematic version identifier is a prerequisite for meaningful autoupdate.

Right now the most reliable thing I can see is file timestamps, but they are not quite as helpful as you might imagine.

Cmdr James wrote:

Right now the most reliable thing I can see is file timestamps, but they are not quite as helpful as you might imagine.

Yeah, time stamps. Depend on how the computer is set up you last saved it from. Bit depth? That said if you make your oxp MORE efficient then that's a no no. I would say a file in the oxp specifically with a date stamp and nothing else in it. But then some numb nuts will copy someones oxp do some tweeks and forget to change the time file or fill it in wrong etc etc etc.

It is a tricky one.

Maybe a bottom up solution is better than a top down one. Adding a field in the wiki table specifically for date of publication? Ok so the players might have to remember the last time they pillaged the oxp list but it does mean ANYONE can fill in the blanks if a maker can't be assed.

Why not just standardise on having version number as part of the OXP name?

Yeah, that would do it too.

ClymAngus wrote:

Maybe a bottom up solution is better than a top down one. Adding a field in the wiki table specifically for date of publication? Ok so the players might have to remember the last time they pillaged the oxp list but it does mean ANYONE can fill in the blanks if a maker can't be assed.

Shameless plug: take a look at the Sandbox on the Wiki. It's not finished yet but we're getting the pieces together.

maik wrote:

ClymAngus wrote:

Maybe a bottom up solution is better than a top down one. Adding a field in the wiki table specifically for date of publication? Ok so the players might have to remember the last time they pillaged the oxp list but it does mean ANYONE can fill in the blanks if a maker can't be assed.

Shameless plug: take a look at the Sandbox on the Wiki. It's not finished yet but we're getting the pieces together.

You can find it here

Finally, someone instead of asking permission or putting it to a committee just going ahead and doing something. Publish and be damned.

Good call on the metres, feet issue Mr Maik!

ClymAngus wrote:

Finally, someone instead of asking permission or putting it to a committee just going ahead and doing something. Publish and be damned.

Good call on the metres, feet issue Mr Maik!

Meters, feet? Hmmm, you must be talking about ACDK's table on the Wiki... I was actually referring to the three OXP tables further down on the page. No mention of feet nor meters there

My thought is that any site with OXPs could simply have an RSS feed that lists all OXPs available from there, providing a version number, direct URL and OXP title.

This would allow anyone wanting to simply browse available OXPs to do so, and those wanting to automagically obtain the current version to do so.

In order for this list to be guaranteed not tampered with, my suggestion is that it is NOT maintained via a wiki, but by replication. Originating sites publish the official OXP, their RSS gets updated accordingly (automatically or otherwise).

Archive sites that have permission to copy from a given site (and they would need a list of official providing sites) would get the list, check the versions against what they have, and wget those that are newer, updating their own RSS feeds accordingly.

End-users could use any RSS client to monitor the updates when they come out and could use a suitable updater client to grab updates in the same way the archives would except without needing to update any RSS feeds of their own.

This is not the fastest replication scheme in the world, it does require some standards to be adopted, but it is simple, it does defeat malicious users and it would be usable (albeit at a primitive level) with only existing software - nothing new would actually be required to be written. New software would merely make such a scheme easier and friendlier.

Does that deal with the objections raised so far?