Oolite Bulletins

Thargoid wrote:

And as we're at the early stage, would there be any benefit from a "Size" column? As not everyone has fast download links or extensive hard disk space, some of the larger OXPs might be a no-no simply due to size.

Good point, till one year ago I only had an isdn connection. And any oxp > 4 MB I downloaded only when I was sure I really wanted it. At that time it would have found it useful. A problem are of course the pages that also contain a slimmed down version. Which size should be presented. Probably the lowest as this number is mainly interesting for those with a slow connection.

The min and max version do need some attention. I would prefer a "unknown" for max version instead of 1.74. That way you can better distinguish with oxp that really have a max version of 1.74 as most will just work perfect with future Oolites.

And min version is probably not the min version of the latest work but the min Oolite version for which still an oxp can be downloaded, because some pages contain several oxp version.

mcarans wrote:

maik wrote:

One option to not loose this information is to include it in the Wiki OXP template.

You learn something new every day. What does the Wiki OXP template do?

It's similar to what the ship template does for ships, it adds an info box to OXPs if you include it in your page. Look at the source of any ship page (most use the template) to see how it's done. To find templates use the special pages link on the left hand side of the wiki and then look at the list of uncategorized templates. Maybe we can/should use those and enhance them with new attributes if needed.

Eric Walch wrote:

Good point, till one year ago I only had an isdn connection. And any oxp > 4 MB I downloaded only when I was sure I really wanted it. At that time it would have found it useful. A problem are of course the pages that also contain a slimmed down version. Which size should be presented. Probably the lowest as this number is mainly interesting for those with a slow connection.

Firstly, thanks for your wiki updates last evening.

Few OXPs are direct file downloads. Box.Net tells you the size if you host there. Size can put on the OXP's main site. Ok maybe it's a bit annoying if you've got your hopes up about an OXP from the description, only to find it's a huge download that won't work for your connection - if this is really necessary in the table, maybe we could colour code the OXP name according to download size or something like that. [EDIT: maik's solution sounds better] The thing is I reckon then the question will be - why not put the system requirements of the OXP in there somehow.

Eric Walch wrote:

The min and max version do need some attention. I would prefer a "unknown" for max version instead of 1.74. That way you can better distinguish with oxp that really have a max version of 1.74 as most will just work perfect with future Oolites.

Can you be 100% sure that an OXP will work with Oolite 1.75.x or 2.0.x, that something won't come along that deprecates it somehow?

When we reach Oolite 1.76, my intention is to try to see how many OXPs' Max Version still say 1.74.x, contact those authors and if I can't get hold of them, mark the OXP deprecated.

Eric Walch wrote:

And min version is probably not the min version of the latest work but the min Oolite version for which still an oxp can be downloaded, because some pages contain several oxp version.

I would keep it to min version of latest work for simplicity. The table is just supposed to be a taster for a more detailed description elsewhere.

mcarans wrote:

Eric Walch wrote:

And min version is probably not the min version of the latest work but the min Oolite version for which still an oxp can be downloaded, because some pages contain several oxp version.

I would keep it to min version of latest work for simplicity. The table is just supposed to be a taster for a more detailed description elsewhere.

On the other hand it might deter someone who, for whatever reason, still uses an older version then the min version of the latest release, from digging deeper. If the OXP page offers an older version for download which has a lower min version than the latest release then I would go for the lowest min version.

In order to really only make the table a taster I would actually remove everything but category and description.

I think there is merit in the idea of keeping stats that are in the table with the broadest reasonable values. So if there is no explicit max version then "unknown" seems reasonable, and if there are multiple versions readily available for download then I would repeat the lowest min version in the table.

maik wrote:

On the other hand it might deter someone who, for whatever reason, still uses an older version then the min version of the latest release, from digging deeper. If the OXP page offers an older version for download which has a lower min version than the latest release then I would go for the lowest min version.

Ok lowest min version sounds good.

maik wrote:

In order to really only make the table a taster I would actually remove everything but category and description.

There is method in my madness. When we reach Oolite 1.76, my intention is to try to see how many OXPs' Max Version still say 1.74.x, contact those authors and if I can't get hold of them to confirm they work with 1.76, mark their OXPs deprecated. That's why I believe strongly that this column should be there - I see no other way in the long term to determine if an OXP is deprecated unless someone can come up with a better idea.

mcarans wrote:

There is method in my madness. When we reach Oolite 1.76, my intention is to try to see how many OXPs' Max Version still say 1.74.x, contact those authors and if I can't get hold of them to confirm they work with 1.76, mark their OXPs deprecated. That's why I believe strongly that this column should be there - I see no other way in the long term to determine if an OXP is deprecated unless someone can come up with a better idea.

The goal is noble but I think we might need more options than only author contact. When 1.74 was released there was a lot of discussion on the BB about which OXPs work and which don't. These discussion are also a source of information that I would consider even if an author doesn't reply. Or just plain old testing...

maik wrote:

The goal is noble but I think we might need more options than only author contact. When 1.74 was released there was a lot of discussion on the BB about which OXPs work and which don't. These discussion are also a source of information that I would consider even if an author doesn't reply. Or just plain old testing...

Quite right. We can try several methods including forums and testing ourselves if necessary - but at least we'll be able to identify those that could be deprecated.

mcarans wrote:

There is method in my madness. When we reach Oolite 1.76, my intention is to try to see how many OXPs' Max Version still say 1.74.x, contact those authors and if I can't get hold of them to confirm they work with 1.76, mark their OXPs deprecated.

That sounds rather control-freakish to me. Who are you to deprecate OXPs?

If a OXP doesn't specify a max version, please accept that and don't give it a max version of your liking. Frankly, you don't know enough about Oolite and any specific OXP to be competent for that.

And if a new Oolite version comes out, you only have to run it and examine the resulting log-file. If there is any problem with the OXP, the log will tell you. If there isn't, there is no reason to do anything about it.

By the way: "deprecated" in computer slang means the same as "is currently working perfectly, but will stop working at some point in the future". Therefore it doesn't even make sense to mark something as "deprecated" which has stopped working.

Strictly speaking the current version of oolite is 1.65 so nothing should be deprecated unless it doesnt work on 1.65

I guess what Im saying, is dont deprecate anything, just state version compatibility.

Commander McLane wrote:

By the way: "deprecated" in computer slang means the same as "is currently working perfectly, but will stop working at some point in the future". Therefore it doesn't even make sense to mark something as "deprecated" which has stopped working.

Yes true, deprecated is not the right word. We would not mark something as not working without trying to contact the author and posting on the forums. If anyone came back and said it works, then clearly we're not going to mark it as not working, but if noone comes back, I had in mind simply to grey the line or something like that. If eventually, someone came back, we could of course immediately ungrey it.

You are thinking quite reasonably from the author's point of view. "Why should this guy come along and mark my OXPs as not working?" Think about if you, for whatever reason, stopped working on your OXPs and they stopped working with Oolite 2.1x. Assuming someone contacted you and you did not want to update your OXPs, wouldn't you want people to be able to see that they do not work with Oolite 2.1x? Would you want every newbie to come along, install it and then curse because they do not work or the game crashes? (I'm exaggerating but I hope you see my point.)

I do not plan to make the decision alone on whether an OXP is working. I will consult on the forums and try as best I can to get hold of the author.

Regarding size of download:
One problem is there may not be one size. System Redux 2 has low res textures and high res textures. BackgroundSet consists of various parts and you don't have to download them all. The constore has various ad packs.

I think what low bandwidth users want is for large downloads to be broken into chunks or for the download site to support resuming. Does anyone know if Box.Net supports resuming? Could not find anything on their website. Maybe we could have a list of storage sites that support resuming?

Things is, that it seems you're targetting only a single aspect. Make the table usable for all of us and then it will be great. If you don't want it, then a simple list or a category would match your needs better than such a table and it would be a lot better to roll back the OXP page to the thing before your changes.

My suggestion for it is on the Sandbox page as I really think such a table could be useful not only for newbees...

<wandering off />

Svengali, nice.

Cmdr James wrote:

Svengali, nice.

Seconded.

Svengali, are you happy for me to hand over the task of finding and filling in all of that information for authors who don't have wiki accounts? The more columns you have in the table the more maintenance it requires.

I've already had it suggested to me that I could make a wiki page for every OXP for which the author does not have a wiki account to enable auto-generation, but I don't fancy maintaining 100s of OXP pages and I can't imagine anyone wanting that job.

As people seem dead against the Max Version thing, I'm tempted to adopt maik's idea and just reduce the tables to the incredibly simple Category, OXP Name and Brief Description, Author. Any comments?