Oolite Wiki

[Cody]

Feel free to do what needs to be done to improve it.

As regards almost all Oolite Wiki stuff, I'd agree. But a user's personal legend should be sacrosanct. Having had some discourteous person tinker with mine, and attempt a synopsis of one of my tales (and getting it wrong), I feel very strongly about this.



<wanders away, grumbling>

[maik]

It looks good to me, but the final decision will be with a_c and Malik.

Guys, the wiki content has never been controlled in any way by the developers (excluding minor changes here and there when inaccuracies or factual errors are noted). Feel free to do what needs to be done to improve it.

Bust what a_c said. There is no ownership on the wiki...

[maik]

Feel free to do what needs to be done to improve it.

As regards almost all Oolite Wiki stuff, I'd agree. But a user's personal legend should be sacrosanct. Having had some discourteous person tinker with mine, and attempt a synopsis of one of my tales (and getting it wrong), I feel very strongly about this.



<wanders away, grumbling>

Hah! That might be an exception

[hiran]

You may want to have a look at these links for a general description of the GNUstep property list grammar:
http://www.gnustep.it/nicola/Tutorials/ ... ode29.html
http://wiki.gnustep.org/index.php/Property_Lists

Good catch! I was searching for something like that.
But there remain questions.

As can be seen, each key-value pair is separated by a semi-colon. Within the pair, the key is seperated from the value with an "equals" (=) sign. The key name is arbitrary, and not put in inverted commas (""). Shown above are: an unknown type (could be some sort of string - TODO), a string, an array, a number and another dictionary (respectively).

The example they show has more semi-colons than the amount required for separation.
Plus if this were authorative, quite a chunk of OXPs the Expansion Manager works with would be syntactically wrong - even the Oolite documentation shows wrong examples at http://wiki.alioth.net/index.php/Manife ... uired_keys. The keys are all quoted.

While creating a parser with all such exceptions is not impossible (actually I just did it) I am still wondering how all these nice OXPs actually work in Oolite. It must have a very forgiving parser, and I hope to meet the same kind of forgiveness...

Now I found some information that soothes my mind. Here is a why for the format and the target format description, even better formulated than on the GNUstep page:
https://bb.oolite.space/viewtopic.php?f=2&t=10039
https://en.wikipedia.org/wiki/Property_list

[Cholmondely]

There can be different approaches how to present the nice documentation on the wiki to users.
So the difference between simulator and the simulated universe is only one, and is topic oriented.

Another one could be use-case/experience level oriented:
Go for basic functionality (like in a getting started szenario), where the first installation and then the first steps in the universe are clubbed together.
There could be an advanced section as well that covers hints for missions, customization of Oolite and the such.
Wizard level could be to tweak the Ooniverse via expansions, while god level would then dive under the hood of the simulator and modify that mechanics.

Which would be preferable? I would not know myself and leave it up to the user. Which means we'd have to maintain multiple entry pages showing the same information just differently aggregated. Which indicates all content could be marked up with categories, and these categories are then used to create automatic index pages...

Thinking about this.

The main issue is time and effort. Ours, on the one hand, to do it all. Apart from people adding new OXZs to it, there seems to me to have been little concerted work on the wiki for a decade or so. Several people tweaked at the edges, categorising and that sort of thing, but no real analysis of what was missing or deficient. Again, time & effort. It takes time to read through all those pages and see what is missing.

But much more importantly, the real issue - it seems to me - is that while Oolite is supremely modifiable so that you can virtually create the game you want - it will take considerable time & effort to go through all the 682 OXZs on the Expansions Manager - and even longer for the other 200-300 functioning OXPs.

I suspect that this was the root issue behind the advocates of Oolite II in the Oolite II vs 2.0 debate. To attract new players without a background playing (and loving) Classic Elite is not so easy if it is the Vanilla Game which is on offer.

The modern deficiencies have been addressed by the oxp's: piracy, mass-locking, some aspects of scale ratios, economics, etc. But the time & effort to go through all the OXZs and pick out what is relevant is non-trivial.

If we could modify the way the Expansions are stored (or maybe just use Cim's architecture for SOTL and have 2 new scenarios on offer with added OXPs) , we could port a game which had
* the Vanilla version
* a starter's version with Paddling Pool etc for the combat shy
* something else for the combat-proficient
- all with the relevant oxp's preloaded.

But of course, all this is guesswork. We don't know how many people download Oolite and then give up! We only know how many people - like you and I - join the BB. And how many download the game.

[Cody]

Song of the Labyrinth has so much going for it. It's a pity that no-one with the skills, and perhaps more crucially, the time, took it on.
The Scenario thing has great possibilites, but again, it would require skill and oodles of spare time, to make something worthwhile.

[hiran]

The main issue is time and effort. Ours, on the one hand, to do it all. Apart from people adding new OXZs to it, there seems to me to have been little concerted work on the wiki for a decade or so. Several people tweaked at the edges, categorising and that sort of thing, but no real analysis of what was missing or deficient. Again, time & effort. It takes time to read through all those pages and see what is missing.

Good point. Time&effort are the problem as everything is done in the little bits of leisure time contributors can invest. The little bits of time are not the issue I think. It is more the fact that there is no master mind to coordinate little bits of effort&time to contribute to a master plan.

But much more importantly, the real issue - it seems to me - is that while Oolite is supremely modifiable so that you can virtually create the game you want - it will take considerable time & effort to go through all the 682 OXZs on the Expansions Manager - and even longer for the other 200-300 functioning OXPs.

I am impressed anyway of what has been created and maintained over the years. Maybe today there is still a lot of distance covered by foot. If we could add some automation, part of the time&effort could be invested on higher levels of thinking. So instead of going through all the expansions to check if they are still compatible some automated testing could be introduced. Which would then free up humans to think about the wiki?

If we could modify the way the Expansions are stored (or maybe just use Cim's architecture for SOTL and have 2 new scenarios on offer with added OXPs) , we could port a game which had
* the Vanilla version
* a starter's version with Paddling Pool etc for the combat shy
* something else for the combat-proficient
- all with the relevant oxp's preloaded.

I believe it partly exists. There is the vanilla game anyway, and someone (Norby?) created a collection of OXPs recommended for newbies. So the features exist, someone with experience would simply have to fill in the data.

But of course, all this is guesswork. We don't know how many people download Oolite and then give up!

Maybe it would be time to collect data. So many applications access the network to check for updates. What if the server accumulates that into metrics? You could see when/from where people start the game, which OXZs they install (discourage the use of OXPs unless for development), or how far (in simulation time) they dive into Ooniverse. With that, some decisions could be taken based on facts.

[Cody]

It is more the fact that there is no master mind to coordinate little bits of effort&time to contribute to a master plan.

No Project Lead - yep, that's the problem.

[hiran]

It is more the fact that there is no master mind to coordinate little bits of effort&time to contribute to a master plan.

No Project Lead - yep, that's the problem.

How is that done between the developers? I doubt Oolite got that far with many little contributions without a project lead...

[Cody]

Giles handed the job to Jens, and Jens handed it on to cim (although Jens retained the title, 'til he removed it from his profile).
Some of that was before my time here - another_commander would probably know whether that was the way of it.

[another_commander]

When the main part of today's core was created there were project leads involved, of course. It's more or less as Cody said. The only detail I believe was slightly different is that I do not recall an official handover between Jens and cim. cim happened to be the guy with the right skills, ideas and will to add to the game at about the same time Jens had started withdrawing from the project, so the transition came naturally. The members of the dev team used to communicate while development was ongoing via an internal mailing list - still valid today as far as I am aware, only unused for a while now.

[Cody]

I do not recall an official handover between Jens and cim.

<nods> I seem to recall Jens becoming what he called the 'back-seat driver', and cim was never 'officially' Project Lead.

[Cody]

I do not recall an official handover between Jens and cim.

<nods> I seem to recall Jens becoming what he called the 'back-seat driver', and cim was never 'officially' Project Lead.

Took a while to find the quote, as it was buried in the ED thread...

I think of cim as the current lead “feature developer”. I’m in charge of back-seat driving and, to a large extent, technical improvements and housekeeping.

[hiran]

So what might help here could be a leadership team (don't know how many members it should have) that could setup strategies/policies/... and nudge other contributors to actually follow those strategies. With that every snippet of time and effort could help achieve the big picture.

If there were a todo-list with well-defined tasks, maybe even newcomers like me could pick something and create meaningful output.

[another_commander]

For future reference, my todo list would be this:

• Environment mapping. We already have a class in the source related to this (OOEnvironmentCubeMap.h/m) but it is not currently used and I am not entirely sure what more is needed to make it work. It would enable various degrees of reflections of the environment on objects and would exponentially increase the quality of our rendering.
• Shadows, for more realistic lighting effects.
• Render to texture, for potential post-processing capabilities in the future (examples: bloom, infra-red vision and more).

All the above imply digging deeply in the current rendering setup and most likely require someone with solid experience in gfx programming.