OXZ and balance

[Smivs]

True. It's far easier to make everybody unhappy

[Cody]

... some members complained about .txt readmes...

I was one of them, I expect. I see both sides, but if you want to encourage people to read readmes, .rtf seems more readable.

[spara]

I have to agree with Dizzy - I'd prefer to be able to open the file in any text editor myself.

As for the format actually used, if it was made an official part of the OXZ registration process then having a copy of the readme in .txt format could be made a requirement if the OXP author wants to have it readable in game.

- Neelix

Readmes tend to go unread, so this feels a bit silly requirement. Wiki's the best solution here, it just needs a clean up for 1.80. And that's not a small task, I'm afraid .

[Diziet Sma]

... some members complained about .txt readmes...

I was one of them, I expect.

Actually, it looks like you were pretty much the only one..
https://bb.oolite.space/viewtopic.php?p=172049#p172049

[Diziet Sma]

I have to agree with Dizzy - I'd prefer to be able to open the file in any text editor myself.

As for the format actually used, if it was made an official part of the OXZ registration process then having a copy of the readme in .txt format could be made a requirement if the OXP author wants to have it readable in game.

- Neelix

Readmes tend to go unread, so this feels a bit silly requirement. Wiki's the best solution here, it just needs a clean up for 1.80. And that's not a small task, I'm afraid .

The thing is, the only way to get from a reference given in the OXZ manager, to the wiki (or the BB) is by manually writing down the URL displayed on-screen, and then looking it up later in a browser. If there are several to check, it gets even worse. In other words, NOT GONNA HAPPEN. Hence the suggestion to make it possible to read the readme files, from within the OXZ manager.

[Neelix]

... some members complained about .txt readmes...

I was one of them, I expect. I see both sides, but if you want to encourage people to read readmes, .rtf seems more readable.

I'm much less likely to bother to read a .rtf than I am a text file. As Dizzy mentioned, reading a .rtf means loading up a full word processor, which tends to take time to load, especially on low end machines like my netbook or Pandora.

Readmes tend to go unread, so this feels a bit silly requirement. Wiki's the best solution here, it just needs a clean up for 1.80. And that's not a small task, I'm afraid .

They are much more likely to be read if there's a facility to do so in the same place that the OXZs are accessed from. - ie In the game itself.

In any case, (having looked at one of the "library book" OXZs) it looks the in game library book code requires the text to be embedded in a plist, and It would make sense to re-use the same code for this.

On the bright side doing this would also mean that if the readme.plist file was included inside the OXZ the user should theoretically be able to refer to it via the in game library while playing, not just prior to installation.

@cim: Do you have any tools which will automatically break down a text file into a readable plist for the library?


That being said, I agree that the information should also be kept in the Wiki.

- Neelix

[Smivs]

Should this thread be split? The 'balance' bit has got a bit derailed

[mossfoot]

Just a thought, what about categorizing based on effects that can't really be argued over? Affect: Cosmetic (ie looks only), Affect: Everyone (ie weapons that players can get but enemies can also have mounted), Affect: Player Only (ie new stations, because those don't really affect the NPC abilities, though they might add NPCs that affect the player) Affect: Enemy Only (ie better A.I. which has no effect on player ability)

[Zireael]

Just a thought, what about categorizing based on effects that can't really be argued over? Affect: Cosmetic (ie looks only), Affect: Everyone (ie weapons that players can get but enemies can also have mounted), Affect: Player Only (ie new stations, because those don't really affect the NPC abilities, though they might add NPCs that affect the player) Affect: Enemy Only (ie better A.I. which has no effect on player ability)

I like this idea.

[maik]

I have to agree with Dizzy - I'd prefer to be able to open the file in any text editor myself.

As for the format actually used, if it was made an official part of the OXZ registration process then having a copy of the readme in .txt format could be made a requirement if the OXP author wants to have it readable in game.

- Neelix

Readmes tend to go unread, so this feels a bit silly requirement. Wiki's the best solution here, it just needs a clean up for 1.80. And that's not a small task, I'm afraid .

The thing is, the only way to get from a reference given in the OXZ manager, to the wiki (or the BB) is by manually writing down the URL displayed on-screen, and then looking it up later in a browser. If there are several to check, it gets even worse. In other words, NOT GONNA HAPPEN. Hence the suggestion to make it possible to read the readme files, from within the OXZ manager.

I agree with Dizzy

[maik]

Should this thread be split? The 'balance' bit has got a bit derailed

Probably ues. Use the exclamation mark on the post where to split and request it. The admins react quite quickly

[Norby]

How about a new field in manifest where the author can select the state of his work from some predefined case? What I missing is a WIP state (for example my Carriers) which suggest that this can contain bugs so save often.

Additional "safe" and "extra" states in the same field mean this is not wip and can give a chance to the author to make a recommendation which is especially useful for new pilots. For example I can split my Telescope into safe and extra parts if I transfer the over-scanner detections into the second part and leave the lightballs in "safe". So I think there is no problem if the author can set it and tell his reason in the forum if needed.

We can live without centalized quality control, I think a few false setting is much better than the current nothing and maybe the author will reconsider his selection if players write "press space" stories about a hard production which set to "safe", or an admiral say this is very far from the core game.

I think the default of this field (if missing) should be "extra" and the author can change to "wip" or "safe" with reason - the "extra" is equally good state as "safe", except for newbies and very strict players.

I know this will not be in 1.80 but the manifest database should contain the field in the admin page from now to set the states of updated oxzs meantime.

[spara]

The thing is, the only way to get from a reference given in the OXZ manager, to the wiki (or the BB) is by manually writing down the URL displayed on-screen, and then looking it up later in a browser. If there are several to check, it gets even worse. In other words, NOT GONNA HAPPEN.

I have to agree here. This new in-built manager has turned things upside down. Before 1.79/1.80 I used to browse wiki and look for interesting oxps.

Am I right or is the problem here the too short description in the oxz manifest? How about adding a long description field to the manifest that would allow enough text to fill one screen? That would be enough for most cases and short enough to be readable. And maybe that description could be used as a short wiki text, if there ever will be some automatic wiki page creation type of thing.

How about a new field in manifest where the author can select the state of his work from some predefined case? What I missing is a WIP state (for example my Carriers) which suggest that this can contain bugs so save often.

I've been missing wip flag too. It would not need to be a new field though, it could just be another choice in the status field.

Additional "safe" and "extra" states in the same field mean this is not wip and can give a chance to the author to make a recommendation which is especially useful for new pilots...

Not sure about this. These are really so subjective matters as debates earlier have shown. What's uber to someone is basic to someone else.

[Norby]

How about adding a long description field to the manifest that would allow enough text to fill one screen?

I like the idea, much better than the current short info.

I've been missing wip flag too. It would not need to be a new field though, it could just be another choice in the status field.

There is no status field in [wiki]Manifest.plist[/wiki] but in admin page to publish the manifest. I think better if not mixed into.

These are really so subjective matters as debates earlier have shown. What's uber to someone is basic to someone else.

Show the subjective viewpoint of the author what everybody can handle as a personal sight. In extreme case anybody can recommend to reconsider, the author can refuse to change and players can neglect the setting (install an "extra" or skip a "safe" oxz), so nobody should be unhappy and newcomers can get help in decision.

We can define one more level: "normal" between "safe" and "extra", so the last is set only if the author is accepted that this is over the normal rules (uber/cheat). This leave more room to decide and put less oxzs into "safe" (harmless).

[spara]

I've been missing wip flag too. It would not need to be a new field though, it could just be another choice in the status field.

There is no status field in [wiki]Manifest.plist[/wiki] but in admin page to publish the manifest. I think better if not mixed into.

It could be in the master manifest. Manifest.plist in the oxz does not need download_url, but it has to be in the master manifest. The same could be with the status field.

These are really so subjective matters as debates earlier have shown. What's uber to someone is basic to someone else.

Show the subjective viewpoint of the author what everybody can handle as a personal sight. In extreme case anybody can recommend to reconsider, the author can refuse to change and players can neglect the setting (install an "extra" or skip a "safe" oxz), so nobody should be unhappy and newcomers can get help in decision.

I can feel the slippery slope here . Soon the argument starts about the guidelines for safe, extra etc. definitions. If I recall it right, the previous debate ended with the outcome that there are no "safe" oxps.