I tend to agree that -1 is a bad choice for "does not apply".

I also don't recall anyone ever agreeing that "Adventure" is a bogus genre because IMO it seems perfectly valid to me. But it's your website, you can display whatever you want there and ignore data from whomever you choose to. *shrug*

I do see a point in a token that is explicit about non-applicability. This avoids
problems with crawlers that assume NULL == 0, and lets you correct old
listings on crawlers with persistent individual fields (as apparently is/was
part of the proposal).

I think N/A is better than -1, and I don't see that it's a difference that rises to
the level of it being "garbage". As to the Adventure thing, that's just really
weird of Scandum to assert.




Ewps. My mud's info wound up going into the distlib template. I'll blank that out in the
next release. Hardly "garbage" though, that merits such harsh, categorical grumpiness.

You'd think I wasn't adding MSSP plaintext+telopt support to a popular codebase or something,
the way yer acting.

-Crat
http://lpmuds.net

All this because I asked a question about why the icons were supposed to be 32x32 and not png…. So the Icon field is now a square image of no larger than 32Kb?

I thought that got tossed a while ago, because of how unworkable it is.

If people are making the assumption that lack of value means something other than lack of value (like, lack of value –> use previous value) then I agree that an explicit N/A is better. (I just think that's an assumption of very dubious intelligence.)

Well maybe I think you're of "dubious intelligence"

I dunno, you could probably fit a lot of intelligence in there. Or at least a lot of something. :tongue:

It seems to me that MSSP doesn't follow the rule of simplicity. Either you should use fixed tokens for all values that have a limited set of choices, OR you should be more relaxed in what values you accept. This is supposed to make it EASIER for people to get their games listed on crawler sites, no?

N/A, NULL, -1… all seem reasonable "no value" tokens unless -1 is a valid integer value for some field. You're already reading everything as text anyways, so why not let the poor admins use whatever values they want as long as it makes sense.

"Adventure." vs. "ADVENTURE" vs. "Adventure"…. case sensitivity is dumb. Again, make life easier… strip punctuation and force everything to uppercase when evaluating it.

The alternative is to make a cryptic protocol that only allows perfectly valid choices, and then you may as well use one byte values for all this and make the admins look up that "Adventure" => 'A', and "Hack and Slash" => 'X', or whatever.

It's almost like disturbing an ant nest.



I changed the spec to the following for now:

"ICON"               URL to a square image in bmp, png, jpg, or gif format.
                     The icon should be equal or larger than 32x32 pixels with
                     a filesize no larger than 32KB.

Ah, well, at least it's clear now what Scandum thinks about the community, if it wasn't before. :lol:

I agree with one of the earlier posters about the idea of leaving the icon attribute as-is and adding png support and either leaving at 32x32 or bumping to 64x64 or a higher square icon. Then a separate entry for like a banner or larger image.

On the subject of null values, another opinion that I had mused on either in the PennMUSH patch thread of mine or somewhere else is following a similar idea to mudconnector's submission page: Can leave the options blank if it has absolutely no relevance on your theme or game whatsoever (in the case of MSSP, the variable does not get reported to the crawler at all), or if it does bear relevance you can set yes, no, or whatever option is available (MSSP: gets reported to the crawler even if it is -1, N/A, yes, no, whathaveyou).

Omitting the variable is acceptable, though the behavior is not defined in the specification. I'd suggest mud crawlers use the previously set value however, which might be the default value set when the listing was created.

Reporting an empty value is only acceptable for a few variables, like the INTERMUD variable.

Maybe the standard should define what happens when a value is omitted, and maybe it should have the more intelligent behavior that several people have argued for. (Hint: that means more than just you, who are the only person who has argued for this nothing-means-default stuff.)