Add-on server improvements

[SkeletonCrew]

I really doubt we can find a small group of devs who will want to constantly test everything. A small groups could be responsible to take recommendations from other devs and trusted regulars. In most cases i doubt there would be a disagreement, except with UMC creators. And of course, there's no guarantee that a campaign will keep a star.

The problem with allowing everybody to vote is that people will try to abuse it. So what would slow down the implementation. It'll be possible to allow voters by invitation, that way we could allow more people we trust to vote.
But one of the important things for the ranking was the mark broken code.

[SkeletonCrew]

I had a discussion with esr this morning about using macroscope in combination with the new campaign server. Below a copy from the irc logs.

Code: Select all

[08:52]	<esr>	BTW, somebody said I should prod you about integrating a macroscope check into the campaign server.
[08:53]	<Mordante>	hmm I didn't see that in the logs, but that might be possible to do
[08:54]	<Mordante>	only not sure what's the best way, haven't looked much in campaign server yet
[08:55]	<esr>	Are you the person who maintains it?
[08:56]	<Mordante>	no, but I'm about to enhance the campaign server
[08:57]	<Mordante>	we want some new features and specifically allow the translation to be splitted
[08:57]	<Mordante>	that way the campaign author just has to upload his stuff and it gets pushed to wescamp
[08:57]	<Mordante>	and when new translations are loaded to wescamp these are pushed to the campaign server
[08:58]	<esr>	Well, rthe way to use macoscupe would be to attacj it to your compaihm-upload CGI so that it bogon-checks incoming UMC and bounces back an error message if it finds unresolved references.
[08:58]	<esr>	s./compaihm/campaign/
[08:59]	<Mordante>	there's a thread about it here http://www.wesnoth.org/forum/viewtopic.php?t=15664 but I think you can't post there unless Ivanovic made you a developer on the forum
[09:00]	<Mordante>	the only problem with doing it on upload is that the campaign server doesn't have the mainline contents loaded so it will show a lot of unresolved references
[09:01]	<Mordante>	that could be solved by uploading the latest data files after a release, or have a command that it copies it from svn
[09:02]	<esr>	That's easy to fix. You wouldn't even need all if mailinle, just data/utils
[09:02]	<Mordante>	you can't do it against trunk since trunk might be incompatible for unstable and will be incompatible for stable
[09:02]	<Mordante>	images also can be used items/portraits come in mind
[09:03]	<esr>	Which is why explicitly uploading the current set of "blessed" macro files for the macroscope check to use should be something a responsible human dev has to do.
[09:05]	<Mordante>	I'd rather have things semi-automatic if it has to be copied manually things get forgotten and might cost quite some time
[09:06]	<Mordante>	since the campaign server will get svn capabilities I'd rather make it automatic on release once change the svn path and the server will pull the info required
[09:07]	<Mordante>	If people use a deprecated macro it will be shown in game and we also might let the server after a data update validate all stuff and automatically mark it as broken
[09:08]	<esr>	Reasonable.
[09:08]	<Mordante>	in that case it is broken, but who would download stuff marked as broken?
[09:09]	<Mordante>	might even be possible to mail the author, since an email address will be required

[Boucman]

would including Macroscope imply that the campaign server would only work with the current of the game ?

would it be reasonable to check that in the same way we check it when entering MP server ?

[Sapient]

also: there are some add-ons that require other add-ons

[SkeletonCrew]

Noyga brought that point up on irc and that can be fixed by having the dependency checked as well. Esr is working on changing macroscope to support this.

[SkeletonCrew]

I made a first proposal for the new addon server posted here http://www.wesnoth.org/wiki/User:Skelet ... don_server

[Mist]

icon like current icon
name like current name
title like current title
description like current description (but hopefully shown in the client)

No doubts here, just one remark. If you manage to show description in the client it might render few things below redundant.

image larger image to show (as shown in the addon menu when you select
an addon)

Don't realy see the point of having another image, icon should do well enough.

type* type of the content see below (the client might want to split this
displayed info per type)
author name of the author
version version number of the addon (as set by the author)
date timestamp of last upload, this way 2 updates on one day can be seen
as different. (ideally the client should notice a newer version by
this value and give a visible clue)
size download size of the addon excluding languages. Languages show
this value separately.

Comment regarding types further on, besides that agreed here

length number of scenarios, mainly for campaigns

This is at best unnecessary (even useless when applied to most MP content). If campaign description shows in the client lenght can be booted there, if not I think we can safely scrap it.

difficulty difficulties available as comma separated list

Don't see how this is supposed to work. Despite best wishes there is no chance of unifying difficulty levels across the campaign. TB hard is still easier than TRoW one, HttT medium is as hard as EI easy. There is no way to keep this value from misinforming people and any custom values will cause only confusion. And besides, how do you define difficulty of MP map?

version string with versions it works with eg
- 1.2.* all 1.2 versions
- 1.2.3+ versions equal or newer as 1.2.3
- 1.2.0 - 1.2.2 versions greater or equal to 1.2.0 and smaller
or equal to 1.2.2
dependency other content this addon depends on, comma separated list of names
(This might allow the client to allow automatic downloads of
dependencies)

No comments here

status The status is split in 3 parts
- author status, the development status of the addon**
- dev status, the status the devs give to the addon***
- macroscope status, the status macroscope gives****

I don't think macroscope status sould be shown as separate entry, results of macroscope check should be shown to author on upload and if the content fails the test dev status should be downgraded.

* type is one of the following
SP campaign
MP campaign
MP map(s)
era
faction
mod
other

Maybe incorporate 'mod' into 'other', but nothing else here.

** author status is one of the following
under construction addon is still in its early stages and is incomplete
alpha addon is pretty much complete
beta addon is complete but needs more polishing/debugging
complete addon is complete and hopes to get a star soon

Alpha status should be asigned to everything below beta, under construction category is not realy needed. Work advancement is clearly shown by version number, and if needed we can relase some guidelines on versioning.

*** dev status is one of the following
Unknow default status
broken the addon doesn't work as expected
buggy the addon works almost as expected but has some bugs
works the addon works as expected but uses deprecated WML
certified the addon works and triggers no deprecated WML messages
(I don't like the word certified, so a better name is welcomed)
star same as certified but the devs enjoy to playing with this addon

For simplicity everything that works but uses deprecated WML should be called legacy, and everything that works without warnig should be called just that - 'works'. The other four statuses are ok.

[SkeletonCrew]

icon like current icon
name like current name
title like current title
description like current description (but hopefully shown in the client)

No doubts here, just one remark. If you manage to show description in the client it might render few things below redundant.

True also note I mostly want to look at the server side.

image larger image to show (as shown in the addon menu when you select
an addon)

Don't realy see the point of having another image, icon should do well enough.

A feature request earlier in this thread by JW, for a detail page it might be nice.

length number of scenarios, mainly for campaigns

This is at best unnecessary (even useless when applied to most MP content). If campaign description shows in the client lenght can be booted there, if not I think we can safely scrap it.

difficulty difficulties available as comma separated list

Don't see how this is supposed to work. Despite best wishes there is no chance of unifying difficulty levels across the campaign. TB hard is still easier than TRoW one, HttT medium is as hard as EI easy. There is no way to keep this value from misinforming people and any custom values will cause only confusion. And besides, how do you define difficulty of MP map?

Both ideas are from the mockup screenshots but I also see little use in them, so if nobody really wants them I can leave them.

status The status is split in 3 parts
- author status, the development status of the addon**
- dev status, the status the devs give to the addon***
- macroscope status, the status macroscope gives****

I don't think macroscope status sould be shown as separate entry, results of macroscope check should be shown to author on upload and if the content fails the test dev status should be downgraded.

If a tool can do the basic test I don't see a reason not to use it, the tool will run whenever an addon can become broken a dev only tests every now and then.

* type is one of the following
SP campaign
MP campaign
MP map(s)
era
faction
mod
other

Maybe incorporate 'mod' into 'other', but nothing else here.

I was also thinking about that, but also thought about spitting them since mods might need special handling (including inside wesnoth.)

** author status is one of the following
under construction addon is still in its early stages and is incomplete
alpha addon is pretty much complete
beta addon is complete but needs more polishing/debugging
complete addon is complete and hopes to get a star soon

Alpha status should be asigned to everything below beta, under construction category is not realy needed. Work advancement is clearly shown by version number, and if needed we can relase some guidelines on versioning.

Ok I just pulled up some names, and I do like it better to have a sane version number scheme.

*** dev status is one of the following
Unknow default status
broken the addon doesn't work as expected
buggy the addon works almost as expected but has some bugs
works the addon works as expected but uses deprecated WML
certified the addon works and triggers no deprecated WML messages
(I don't like the word certified, so a better name is welcomed)
star same as certified but the devs enjoy to playing with this addon

For simplicity everything that works but uses deprecated WML should be called legacy, and everything that works without warnig should be called just that - 'works'. The other four statuses are ok.

Could you write out your proposal?

[Mist]

My proposal (complex solution)
1) .pbl file :

name - string
title - string
description -string
image - local path (.png, .jpg only, we don't want animated content)
type - a set of (sp_campaign, sp_map (scenario) , mp_campaign, mp_map (map, mappack, scenario) , mod (faction, era, other mod) , other)
author - string
version - number in x.x.x format
compatibility - a set of (legacy, stable, dev) *
dependencies - a comma separated list of strings
status - a set of (alpha, beta, complete)

*This is valid under two assumptions. Firstly we will support only one stable and development branch and encourage use of latest relases (thus last stable relase gets stable status, last dev gets dev, everything else gets legacy). Secondly one can provide detailed list of version range supported in description visible by client. If any of those assumptions is incorrect compability should be resolved as Mordante suggests.

2)Server
In addition to above and changing when needed

dev_status - a set of (-1, 0, 1, 2, 3, 4) **
high_score - a set of (-1, 0, 1, 2, 3, 4) and a number in x.x.x format ***
icon - image shrunk to icon size

**dev_status is set automaticaly on upload to -1 if content fails macroscope check or 0 if the check is passed. At any moment afterwards person maintaning the campaign server can add no more than to 4 to the status.
-1, 0 - unknown (not assesed by at least three devs | tastes differ, grading on one opinion might be unfair)
1 - broken (not working as supposed)
2 - buggy (containing known bugs, using deprecated WML)
3 - works (works, nothing special)
4 - star (at least two of three devs grading enjoyed plaing it)

***dev_status should be reseted after each new upload (things might get broken in development), again not to be unfair on good content this will show that eg. few revisions ago this was considered a star type campaign. This key should hold highest rating achieved with revision number it happened on.

Alpha and beta type content should not be dev_status graded.

3) Client

Should show all above (excluding description and image) , dev_status and high_score in text format, with icon on simple list and on demand acces to description and image (via a 'details' button perhaps). dev_status and high_score should not be presented next to alpha and beta status contetnt.