Oolite Wiki

[Cody]

Ramen? Is that his name?

And some fell on stony ground!

[Cholmondely]

Ramen? Is that his name?

And some fell on stony ground!

Aha!

So the Great and Glorious God, Ramen, the Witchspace Lobster, fell from his celestial throne plummeting down from the heavenly heights onto stony ground!

And what happened next, after the Divine Defenestration?

And how on earth does it tie up with his worshippers flying out through pirate-infested reaches to the witchspace beacon before they blast off to another system?

[hiran]

I saw it and decided that is 'an issue but not for the report'. I guess we need to improve quality in the OXP registration process, then such descrepancies should go away on it's own.

After reading the values from the manifest files, doing a Trim() (or whatever the function is in the language you're using) to remove leading and trailing spaces might be easier...

I do agree a trim() to remove leading and trailing whitespace before comparison would fix this issue. I also strongly believe it is a step in the wrong direction. I have seen projects going towards wobbly behaviour just because input files were treated too generously.

So what stops us from either updating the OXP or the Expansion Manager's list?

Yes, I know. Sometimes I can be pedantic.

[hiran]

So the Great and Glorious God, Ramen, the Witchspace Lobster, fell from his celestial throne plummeting down from the heavenly heights onto stony ground!

And what happened next, after the Divine Defenestration?

And how on earth does it tie up with his worshippers flying out through pirate-infested reaches to the witchspace beacon before they blast off to another system?

While falling, it tried to grab whatever/whomever to prevent or at least soften the sudden impact at the end. So he stretched all his noodly appendages, but noone held on. They all felt blessed by having been touched by a god or something...

[Cody]

Pastafarians rule, okay!

[hiran]

I updated the index of artefacts again. Warnings went up when I discovered...
* items in the Oolite vanilla game should also be part of the Oolite documentation project (ODP), so now the ships and equipment are also listed
* quite many OXPs define ships or equipment that already exist but get overridden and thus kind of invalidate the index

I have not yet started to remove items that should not be visible to the user.

[hiran]

Is there a way to identify those that should stay "invisible"?

Equipment items have the "visible" property, which is probably the best thing to use for those. This property, if false, will hide the item on the F3 Outfitting page, as well as on the F5 screen if the item is actually equipped.

Implemented.

To keep the index as accurate as possible those items are still listed, but the Wiki check is skipped and the index is marked up accordingly. I will try to do a similar behaviour for ships.

For ships, that's trickier. First, if anything has "is_template = yes", if can't be created directly anyway, so can be left off.

Agree. Abstract ships do not have to have user documentation. For programmers it might be worth having something, but this is out of scope for now.

Next, if a ship identifier is used anywhere in the shipdata.plist file in a "subentity_key" (see the "Broadcast Array Arm", key "broadcast_array_arm", from the "Tionisla Chronicle Array" OXP), then that's probably only part of a larger ship and can be left off as well.

'probably part of a larger ship' means to me the ship was reused as part of a larger ship. It does not mean it is no ship per se.

After that it's much harder to define. For instance, in the "Breakable WItch Drive" OXP, it has one ship entity, named "Malfunction...Malfunction", id "btd_dummy_entity". This entity is used to pull the player ship out of torus when it's malfunctioning. It's not a ship that you will ever see in the game, but there's no way, other than by looking through the code and working out how it keeps the ship from appearing on the scanner when it's spawned (FWIW, it changes the scanner color to "clear", essentially making it invisible).

This is a really strange case, but yes it seems not to be a ship in the common sense.

I think your best bet is to look at the "roles" property of the ship, and seeing it if includes any of the standard spawning roles ("pirate-*", "assassin-*", "trader*", etc). Also check the "scan_class" for "CLASS_STATION", as that might be a way of picking up what could spawn (the Broadcast Array from the Tionisla Chronicle Array is an example of where the "roles" property probably won't help, but the scan_class might. The scan_class might also help if it says "CLASS_NO_DRAW", as that item won't be seen in the game. scan_class = "CLASS_POLICE" should only be used for police vessels, and could pick up a bit more.

I think this is going to take a bit of refinement before we've got something robust and accurate. Sorry I can't give you a more definitive list.

Hmmm, maybe we still need a good definition what we want to achieve.

From my POV, I am still searching for a good documentation where I can lookup stuff when playing the game. So my goal would be to go for a complete documentation set. However that is a lot of work, now that I see the amount of artefacts myself.

How about taking it in phases? (which would not mean we must not work on stuff of the other phases, but we could focus our attention to fewer issues):
Phase 1: All expansions
Phase 2: All player playable ships
Phase 3: All visible equipment
Phase 4: Complete the missing parts

[hiran]

For ships, that's trickier. First, if anything has "is_template = yes", if can't be created directly anyway, so can be left off.

Agree. Abstract ships do not have to have user documentation. For programmers it might be worth having something, but this is out of scope for now.

Very nice. You tell me to check whether is_template contains yes, which is in sync with http://wiki.alioth.net/index.php/Shipda ... s_template. At the same time I am checking for values yes, no, true, false. Not a big deal. But then I stumble over the oolite core game, which marks templates with is_template=1.

This really makes me think of what is going on internally in Oolite. Why/how does it actually work?

[phkb]

Why/how does it actually work?

1 is the integer representation of the boolean true (in most languages at least). And Oolite is trying to handle the widest range of possible user inputs. So, 1, true, yes all do the same thing for a boolean value. There are exceptions to this rule in Oolite (of course) - consider the "has_escape_pod" property, which can be 1, yes, true, or 0.5, 0.1 (decimals being the likelihood of the escape pod being awarded) etc.

Yep, it's complicated.

'probably part of a larger ship' means to me the ship was reused as part of a larger ship. It does not mean it is no ship per se.

The cases where a smaller ship that can be spawned on it's own as well as part of a larger ship are so few as to be edge cases, rather than something you need to cater for up front.

How about taking it in phases? (which would not mean we must not work on stuff of the other phases, but we could focus our attention to fewer issues):
Phase 1: All expansions
Phase 2: All player playable ships
Phase 3: All visible equipment
Phase 4: Complete the missing parts

That seems reasonable.
For Phase 2, you can use the debug command Ship.keysForRole("player") to get a list of player-flyable ship data keys. (Of course, you'd have to have every player ship installed in your game for that to work, but still. Possibly useful.

[hiran]

Why/how does it actually work?

1 is the integer representation of the boolean true (in most languages at least). And Oolite is trying to handle the widest range of possible user inputs. So, 1, true, yes all do the same thing for a boolean value. There are exceptions to this rule in Oolite (of course) - consider the "has_escape_pod" property, which can be 1, yes, true, or 0.5, 0.1 (decimals being the likelihood of the escape pod being awarded) etc.

Yep, it's complicated.

I grew up with a programming language that used -1 for true so it was safer to go with the definition:

Code: Select all

false = 0; true = not false; 

But as you mention, Oolite has even more...

'probably part of a larger ship' means to me the ship was reused as part of a larger ship. It does not mean it is no ship per se.

The cases where a smaller ship that can be spawned on it's own as well as part of a larger ship are so few as to be edge cases, rather than something you need to cater for up front.

At least for the time being it makes sense. Ok.

How about taking it in phases? (which would not mean we must not work on stuff of the other phases, but we could focus our attention to fewer issues):

That seems reasonable.
For Phase 2, you can use the debug command Ship.keysForRole("player") to get a list of player-flyable ship data keys. (Of course, you'd have to have every player ship installed in your game for that to work, but still. Possibly useful.

I thought player playable ships should be listed in the shipyard.plist files. But yes we can consider that.

Now as this documentation project is bigger than one thread I think of placing such information into the wiki. So far I just do not see a suitable location. @Cholmondeley or others: Any idea?

[hiran]

I am becoming increasingly concerned about the number of redirect pages on the wiki (all my own fault. I know, I know...). People use it to find things and I would suspect most of us type in the words, which allows the wiki search engine come up with a list of choices, from which the correct item can be chosen. If there are too many choices, this does not work as well. Of course if people cut and paste, then it is a very different matter - but you can't cut and paste from the F3 ship outfitting screen in the game (even Version 1.90). So you will be typing, as above...

I see the important thing as that everything is on our wiki. our new Hiranistificalite Index is an absolutely spiffing tool for managing that. But it is merely a tool. Turning the index page blue is not the same as having everything listed (and findable) on the wiki. Of course, if Phkb waves his glass of cognac and the items on the F3 shipyard suddenly link to the wiki, then we will indeed need to turn the index page blue. But we are not there quite yet!

I understand this is becoming an issue. We may need a better solution for that.
While I want everything to have a page, you want the search function to behave wisely. Which means not everything that might exist in the wiki should directly show up when a human being initiates a search.

Now I am wondering whether namespaces could be a solution for that (https://www.mediawiki.org/wiki/Help:Namespaces)...

Oh, look what I found':
https://www.mediawiki.org/wiki/Help:Redirects
Redirects are used to forward users from one page name to another. They can be useful if a particular article is referred to by multiple names, or has alternative punctuation, capitalization or spellings.

No surprise here: redirects are intended to bridge different spellings or different names - just the discrepancy we have between artefact names and page names. Let's go and make use of them.

https://www.mediawiki.org/wiki/Manual:U ... _namespace
A custom namespace can be used to hold content that should not be shown on the search results page

...and this is to save the wiki index from exploding. We could introduce a namespace for Oolite artefact names consisting mainly of redirects to the existing pages. Given that these redirect pages are hosted in a separate namespace will not clog up the search function.

[Cholmondely]

I am becoming increasingly concerned about the number of redirect pages on the wiki (all my own fault. I know, I know...). People use it to find things and I would suspect most of us type in the words, which allows the wiki search engine come up with a list of choices, from which the correct item can be chosen. If there are too many choices, this does not work as well. Of course if people cut and paste, then it is a very different matter - but you can't cut and paste from the F3 ship outfitting screen in the game (even Version 1.90). So you will be typing, as above...

I see the important thing as that everything is on our wiki. our new Hiranistificalite Index is an absolutely spiffing tool for managing that. But it is merely a tool. Turning the index page blue is not the same as having everything listed (and findable) on the wiki. Of course, if Phkb waves his glass of cognac and the items on the F3 shipyard suddenly link to the wiki, then we will indeed need to turn the index page blue. But we are not there quite yet!

I understand this is becoming an issue. We may need a better solution for that.
While I want everything to have a page, you want the search function to behave wisely. Which means not everything that might exist in the wiki should directly show up when a human being initiates a search.

Now I am wondering whether namespaces could be a solution for that (https://www.mediawiki.org/wiki/Help:Namespaces)...

Oh, look what I found':
https://www.mediawiki.org/wiki/Help:Redirects
Redirects are used to forward users from one page name to another. They can be useful if a particular article is referred to by multiple names, or has alternative punctuation, capitalization or spellings.

No surprise here: redirects are intended to bridge different spellings or different names - just the discrepancy we have between artefact names and page names. Let's go and make use of them.

https://www.mediawiki.org/wiki/Manual:U ... _namespace
A custom namespace can be used to hold content that should not be shown on the search results page

...and this is to save the wiki index from exploding. We could introduce a namespace for Oolite artefact names consisting mainly of redirects to the existing pages. Given that these redirect pages are hosted in a separate namespace will not clog up the search function.

An interesting find! Well done, sir!

To be honest, I'm less worried about the proliferation of new equipment (showing the diversity of Oolite - ... and I love some of the names that, for example, Redspear has concatenated). I am more concerned with that of such as the "Market Observer/MarketObserver/MarketObserver OXP" .mixes.

Heavens... what a confusing array of pronouns, prepositions and what not. Tell me, Hiran, is it the same in German?

[Cholmondely]

Just thought that I should mention: some of the equipment artefacts have spelling mistakes in their names. Probably best to get them fixed before creating redirects...

[Cholmondely]

I've started with the lasers. I've created a new category (Lasers) which is now a subcategory of Weapons OXPs, and tagged all the redirect pages to that we have a list of all this stuff somewhere!

http://wiki.alioth.net/index.php/Category:Lasers

[hiran]

An interesting find! Well done, sir!

To be honest, I'm less worried about the proliferation of new equipment (showing the diversity of Oolite - ... and I love some of the names that, for example, Redspear has concatenated). I am more concerned with that of such as the "Market Observer/MarketObserver/MarketObserver OXP" .mixes.

Heavens... what a confusing array of pronouns, prepositions and what not. Tell me, Hiran, is it the same in German?

In German it is actually slightly easier. Well, you can still combine all such words to make up one big one. But in such cases they are written as one word - no whitespace between. Ugly for first class students trying to decipher the word and running out of breath. But compared to English...

When I joined university, I also read the Intel documentation for the 80286 processor not only because I needed it or was interested - I also wanted to improve my english. So I was reading it aloud to myself. And I was wondering how to get the pronounciation right, the speed and melody of the sentence did also matter for me. How do you do that if you cannot tell upfront how many words are the subject of the sentence?

Specialized bus interface components connect the 80286 local bus to both the buffered local bus and the system bus. These interface components process the signals that come from the 80286 local bus and generate appropriate signals for use on the buffered local bus or the public system bus.

In this example I started reading "specialized bus", that must be the subject. The verb then is "interface". D'oh!
Finally I learned to go by the maximum munch principle and read as many words for the noun until the next one would no longer make sense. Which means "Specialized bus interface components" is the subject, because adding "connect" would make sense and thus must be the verb. And note that your eyes have to be one word ahead from your readout. For those of you who grew up with such a language this is so deep in your DNA you do not even think about it.

--- maximum message size limit reached ---