Are OXZ's an improvement ...

[Neelix]

In principle I very much agree with you, Smivs. But it would require the devs to start making rules about OXP/Zs (and be willing to enforce them), something they've never shown any inclination to do. Relying on people's goodwill won't do - you've already seen the petulant response to the simple thought experiment of asking people to think about which of their creations are most worthy of inclusion. So, it seems inevitable that soon the OXZ manager will look like the OXP list page on the wiki. (This is getting a bit depressing.)

What I was objecting to was not the idea of regulating OXP quality but the specific methodology you suggested. You can't regulate quality by limiting quantity.

Both of my OXPs still carry the WIP tag... both need further work. If as per my last suggestion WIP tagged OXPs were filtered out by default, this would suppress both of them. Quality control I have no issue with, but quantity limits are not good way to approach the issue, even on a hypothetical basis.

- Neelix

[Switeck]

But this is getting away from the discussion on 'dodgy' OXZs. having been part of this debate, and having thought about this a bit more I feel that an expansion should simply NOT be released as an OXZ until it is fully finished and polished, is completely up to date and is tested as working. WIPs, old OXPs and newcomers' work should only be released as an OXP until such time as it can be considered fit to become an OXZ (part of the game, if you like).

In principle I very much agree with you, Smivs. But it would require the devs to start making rules about OXP/Zs (and be willing to enforce them), something they've never shown any inclination to do. Relying on people's goodwill won't do - you've already seen the petulant response to the simple thought experiment of asking people to think about which of their creations are most worthy of inclusion. So, it seems inevitable that soon the OXZ manager will look like the OXP list page on the wiki. (This is getting a bit depressing.)

The problem with self-limiting OXZ release by authors to their "very best" 5 or 10 OXZs is because a LOT of the developers fall into 2 categories:
1.Those that have only a couple OXZs.
2.Those that have and produce many OXZs.

A poor coder is not measured by how many or few programs she or he makes!

I'm not going to tell Thargoid to quit making OXZs because he has "too many". It's not my place to do so...and I borrow too much stuff from him to do that non-hypocritically.
I'm not going to tell mandoman to quit making ships for Oolite because he has "too many" either. It's not my place to do so...I don't know how to make ship models myself and don't even have a modeling program installed to begin to learn more.
Nor am I going to claim that Thargoid or mandoman are poor coders, (I don't feel they are) seeing as how I have my own problems coding anything in Oolite.

All the OXP/OXZ developers need LOTS of help polishing their ideas but harsh criticism (which I'm guilty of myself...) and censorship does nearly nothing.

Quit talking, start doing!

Make the tutorials, if not in whole, at least in tiny parts. Release early, change a few times...let others help out.

Code examples of each scripting command on the Wiki is my biggest hang-up. The way the syntax is listed in the wiki, I almost have to find a OXP which uses that command to give me any clue how to use it, and I've caught hell for following "bad examples". "Learned wrong" is a very hard thing to unlearn.

We definitely need to separate OXZs into finished and WIP/unfinished/untested pools, defaulting of course to only finished OXZ -- but giving users the option in advanced settings to choose to add from both/either -- with the understanding that WIP involves definite risks. (Insert Warning messages here!)

The game needs a couple more links in it to point people TO the forum and wiki, such as on the starting splash screen.

Sponsor a developer! -- Got OXPs/OXZs you like? Give a little feedback on their appropriate message thread, whether it be code cleanup, testing for potential other OXP/OXZ conflicts, add ideas, or just to say thanks.

[Neelix]

Code examples of each scripting command on the Wiki is my biggest hang-up. The way the syntax is listed in the wiki, I almost have to find a OXP which uses that command to give me any clue how to use it, and I've caught hell for following "bad examples". "Learned wrong" is a very hard thing to unlearn.

Seconded! Real code examples are invaluable, because they show the context in which you would use the command and how it actually looks in real code. To my mind this is vital to understanding how to use it.


- Neelix

[Smivs]

A few points and a few thoughts.
OXPs are not obsolete and are not 'the past' in any sense. They are as valid now as they have ever been, perhaps even more so, as they will be the expansion format used when it is not appropriate to issue an OXZ.

So when is it appropriate to issue an OXZ? The whole point of OXZs is to give end users easy access to expansions within the game framework. This is a totally novel concept to Oolite, and has certain ramifications. As has been mentioned, many players who do not frequent this board have probably not dabbled with OXPs before. Now they find that there are expansions and they will probably be keen to try them. After all, they can be installed easily by the game, and as 'part of the game' (that is how they will see them) they will add to the game, they will work, and they will be to the same standard as the core game. Won't they? Well, not necessarily, and that is the problem. The whole Oolite 'thing' will be damaged and discredited if players find that something they got 'from the game expansions handler' doesn't work, or breaks things, or is just too far removed from the core game that it doesn't make sense.

This is why I think we need to be really careful about which expansions we make available as OXZs. OXPs on the other hand are very different. They are clearly expansions made by fans and made available to the community, warts and all.
And with the manager now handling the 'safe, appropriate' expansions, the OXPs role has also polarised. They are no longer the sole medium for all expansions, rather they should become the 'bleeding edge' of expansions. Away from the 'safety' of the Expansions Manager, players can seek out and try new expansions still under development. They could test the work of newcomers who may still get things wrong from time to time. They can grab expansions designed for tinkerers, where the user is encouraged to open them up and poke around inside. They can try things like silly uber-ships too far out to be truly relevant to the core game.

These are all things that make the game great for so many of us, but regular players who just want to play and don't visit the forum etc don't want this. They want ease of use. They want reliability. They want confidence that what they are using isn't going to break their game somehow. They want OXZs!

And I think this distinction really needs to be made. OXZs and OXPs are different things now. They are not necessarily alternatives to each other. They are not quite the same thing.
OXZs, which will be seen by many as part of the game, must maintain the very high standards of the core game. That is what the casual user will expect of them, and if we fail them in this respect the game itself loses credibility.
OXPs should now be the parallel Ooniverse of cutting-edge, of new ideas, of fun stuff you can open up and play around with, and of things in development which need work/testing/feedback to complete them. If more needs to be done to alert casual players to the exciting world of OXPs, then let's do it!
OXPs are not a poor relation to OXZs, not second best or inferior in any way. Although some people around here seem to be viewing them as inferior in some way, they are not. They are just as important and should have parity of esteem in the way we perceive them. They are just different, and to the keen user they should have more appeal as well.

[Lone_Wolf]

Smivs, i like it.

You've convinced me to do the following with shieldcycler :

release 0.31 as oxp
once it's been tested by other people, release it as oxz

Work on next version (which will add shieldequalizer & capacitors functionality, so will be a rather big change)
release them as oxp test versions
once stable, release as oxz.

rinse and repeat.

[spara]

Just to clarify a couple concepts here now that this has become an OXZ vs OXP discussion. I'm assuming that OXZ means an expansion available from the game itself and OXP means an expansion not available from the game. So...OXP in this context also means OXZ-files, not available from the game? Personally I like to make solely OXZ files because I find them easier to manage.

So the talk here really is about expansions available from the game manager vs expansions not available from the game manager.

It's in no way mandatory to put oxz-files into the manager, you can share them in the wiki and forum too.

[Smivs]

So the talk here really is about expansions available from the game manager vs expansions not available from the game manager.

Not exactly. My point is more to do with which is the best medium for individual expansions. It's not versus as in a battle, it is more which is the more appropriate format.

[spara]

I still don't really get it, sorry for being slow . It's currently recommended that all expansions include a manifest file. With that in, OXZ is just a zipped OXP renamed to OXZ. The only difference is that in the old style zip files there as an OXP-folder inside the zip. With OXZs, if you want to open it, you need to create the forlder yourself.

I really don't see how this has anything to do with what should be the preferred format when developing or something.

* Make an oxz and the user can just drop it in. If you want to tinker, create an oxp folder and unzip it there.
* Make a zip and the user needs to unzip it first.

[cim]

1. disregard any files, OXPs, OXZs that aren't explicitly stated as dependencies.

This is the tricky bit, I think. Everything else should be fairly straightforward to add to the OXP verifier mode. (And all worth doing)

I think I know how to do it, though - and there are a few other nice features it could bring in - so it's certainly going on my list for 1.82 to at least improve the OXP verifier's features.


Another option - and this is something I've thought of just now, so it may be a terrible idea - for improving quality of OXZs without affecting ordinary users is to make the "OXP Developer" builds considerably harsher about what they'll accept than the deployment builds - we could easily make the OXP Developer builds do things like:
- refuse to load OXPs which don't have a manifest (or even refuse to load OXPs at all, since the OXZ format is inherently stricter)
- refuse to load JS files which don't have "use strict"
- exit on errors which would normally only get a log warning (e.g. missing files)
- log things which the normal build doesn't
It would mean that you wouldn't want to use them for day-to-day play, necessarily, since some of the older OXPs would just refuse to load in a developer build, but it would make it easier for OXP debugging. (Note: the nightlies are built in OXP Developer mode)
What do people think - good idea, or more likely to cause problems than solve them?

The whole Oolite 'thing' will be damaged and discredited if players find that something they got 'from the game expansions handler' doesn't work, or breaks things, or is just too far removed from the core game that it doesn't make sense.

I'm not sure that's really the case. At least, this doesn't seem to be a concern for the other open source games I have which have expansion managers. As a quick summary of those (none of which, from checking their forums, appear to be concerned about reputational problems from low-quality expansions, though most of them have had their expansion managers for several years and maybe had this discussion then too).

• Battle For Wesnoth: lots of expansions, expansion manager about feature-level with ours, no quality control of expansions, no quality indicator except the fairly useless download count
• Freespace Open: lots of expansions, expansion manager is very limited (and doesn't include a downloader), no quality control or indicator
• OpenTTD: lots of expansions, expansion manager has several nice features ours doesn't (yet...), no quality control or indicator
• Supertux: a few expansions, expansion manager just gives the name of the pack and that's it
• Supertuxkart: many expansions, expansion manager about feature-level with ours, though it looks shinier. Quality indicator provided by a 1-3 community star rating and a "featured" mark which is presumably at least a bit more official since they don't always match up

Now - we do have challenges they don't, in that an Oolite OXP has considerably more freedom to make changes and to interact with other expansions - and it's certainly sometimes difficult to tell whether something which just happened was core or OXP if you have lots installed or aren't familiar with that aspect of core gameplay ... but I don't think we need to be much more concerned about bad OXZs than we were about bad OXPs, and many of the issues we're seeing at the moment will probably sort themselves out a bit in the next three months or so as people get more used to the format.

The whole point of OXZs is to give end users easy access to expansions within the game framework.

Well... not the whole point, though that was the main motivation. It was necessary to develop that format to get the in-game manager to work, but I think it's also a better format than OXP even without that (and it was a definite option for 1.80 that it would be released with OXZ support but not with the in-game manager, though as it happens the manager was easier to write than I expected it would be). I have some fairly experimental expansions I want to put together at some point, and they will be released in OXZ format. They just won't be on the OXZ manager list. I think it's worth distinguishing between the format and the delivery method a bit more.

Quit talking, start doing!

Yes. The documentation is about as good as I have time to make it - which means a mostly-accurate but short API reference, and a few pages here and there summarising major new features. If people aren't confident about adding examples, extra notes, etc. to the documentation, put it on the talk page first, and/or have a thread on the forum to discuss them - I'll try to make time to check things over.

(The Wiki as a whole is in need of updates in several places - installing, playing, OXP writing, pictures, etc. I don't have time to take on that project as well, but if the community takes it on then I'm certainly happy to answer questions or check pages here and there for technical accuracy)

[Smivs]

I really don't see how this has anything to do with what should be the preferred format when developing or something.

It doesn't.
In my opinion OXZs (perceived by many casual users I suspect as 'part of the game') should be finished, professional products that enhance the game in a safe, hassle-free way. They are easy to install and need no input from the user.
OXPs on the other hand I see nowadays as the development medium, and maybe the medium for those expansions which are a bit 'far away' from the core game. They might be WIPs, or just untested, or maybe aimed at the tinkering audience who like to open things up and play around.
A car analogy is often useful, so think about a new car, but one that you'd like to go a bit faster. You have a choice. For the same price you can order an official factory turbo kit that gives you 33% more power and is fully tested and guaranteed etc, or you can take it to your local tuning shop where they will fit a turbo system that will give you a 50% power hike but might break your engine.
The factory order safe bet is the OXZ, the OMGWTF uber-turbo that is a bit risky is the OXP. So is the turbo kit you fit yourself

[Cody]

It would mean that you wouldn't want to use them for day-to-day play, necessarily, since some of the older OXPs would just refuse to load in a developer build, but it would make it easier for OXP debugging. (Note: the nightlies are built in OXP Developer mode)

This could affect me, I think, as I'd probably then have to use a Deployment build for playing - which may or may not be a good thing - hmm.

[Zireael]

In my opinion OXZs (perceived by many casual users I suspect as 'part of the game')

They are Oolite EXpansions still, therefore not 'part of the game'.

[Smivs]

In my opinion OXZs (perceived by many casual users I suspect as 'part of the game')

They are Oolite EXpansions still, therefore not 'part of the game'.

Well, think of them as being like Apps then, for your smartphone or whatever..
You download an app from the Apple app store and you expect it to work properly and not break anything. Because it comes from an officially sanctioned source, you take it on faith that it is reliable.
You download an app from a website you know nothing about. Would you be confident enough to consider that to be as safe and reliable?

[spara]

In my opinion OXZs (perceived by many casual users I suspect as 'part of the game')

They are Oolite EXpansions still, therefore not 'part of the game'.

Well, think of them as being like Apps then, for your smartphone or whatever..
You download an app from the Apple app store and you expect it to work properly and not break anything. Because it comes from an officially sanctioned source, you take it on faith that it is reliable.
You download an app from a website you know nothing about. Would you be confident enough to consider that to be as safe and reliable?

I think we still don't understand each other. I agree 100% that expansions available from the Oolite website/manager should be as well behaving as possible. But if you download an OXZ-file from the forum or wiki, then it's totally possible that it might not work properly or at all. My point is that the format is not the key here, the distribution channel matters. And because of that, I see no point of using more than one format: OXZ.

[Smivs]

I do see what you are saying, and yes, the distribution method is the main issue I am discussing. You might even be right in saying that we only therefore need OXZs, but then what happens to the OXP format itself, and all the OXPs that will never be converted? I also still personally prefer to develop in OXP format, then convert to OXZ for addition to the manager.
I will be keeping some of my old OXPs alive, as OXPs not OXZs, and may even release new ones in the future if I don't view them as OXZ material. You see I don't see any point in producing an OXZ that won't be added to the manager, and it might well be that some of my future work (like some of my old work) is not considered by me to be suitable for the manager.