Hey! It looks like you're new here. You might want to check out the introduction.
>>Bad Horse
Replied to your Fimfiction DM.
Only if they say something.
Replied to your Fimfiction DM.
Is there any way of finding out who's participating?
Only if they say something.
Had some server problems, so the site was down for about the last 6 hours. All should be good now. Sorry for the inconvenience.
>>Super_Trampoline
>>Super_Trampoline
As Light_Striker noted, what you've done is against the rules.
Given you submitted a lot of entries this round, I suspect you may have broken this rule even more than you cared to admit.
Since it's difficult to disqualify entries after the event is over, I probably won't bother to do it this time. But I'm issuing you a warning not to do it again.
>>Super_Trampoline
As Light_Striker noted, what you've done is against the rules.
Participants—may not start creating their work(s) until the prompt has been selected
Given you submitted a lot of entries this round, I suspect you may have broken this rule even more than you cared to admit.
Since it's difficult to disqualify entries after the event is over, I probably won't bother to do it this time. But I'm issuing you a warning not to do it again.
I've uploaded the picture for the artist.
Their issue was trying to upload an image with dimensions 6912x5184. To get an idea of how big this is, you'd need 20 1080p monitors in a 5x4 grid to display every pixel in it.
This is too big for the server's memory limit to hold in memory when trying to process it, and unnecessary since it'll be resized down to a maximum of 1800x1800 anyway. The fix is simple: resize before uploading.
But yeah, the error message when running into this is rather cryptic. This artist isn't the first person to be confused by it.
Their issue was trying to upload an image with dimensions 6912x5184. To get an idea of how big this is, you'd need 20 1080p monitors in a 5x4 grid to display every pixel in it.
This is too big for the server's memory limit to hold in memory when trying to process it, and unnecessary since it'll be resized down to a maximum of 1800x1800 anyway. The fix is simple: resize before uploading.
But yeah, the error message when running into this is rather cryptic. This artist isn't the first person to be confused by it.
>>Pascoite
>>CoffeeMinion
>>Bachiavellian
It's not great if there's too much discussion being held on Discord, since it's harder to find there. When possible people should try to leave comments here rather than there, or to copy the thoughts they wrote there over here.
Of course, the assumption that that discussion would appear on the site in the absence of Discord is probably not right. A lot of these discussions are spontaneous or off-the-cuff, which on a forum probably wouldn't happen at all. So I think the real issue is a search problem.
To that, there's an easy solution: if you happen to be involved in a Discord chat about a particular story, just put the story title in the chat—an entire discussion can easily go by where the title isn't actually written out once, started off by some comment like "hey so what about that story where the thing happened?" Then the author can search and find all discussion for their fic easily using Discord's built-in search.
Main issue I see with this is adding friction to the commenting process. If we've already got an issue where there's too much posting on the lower-effort Discord, then adding an extra step to commenting here only makes that problem worse. We'd have to decide where the line between "review" and "comment" is, and we'd have to decide which category every post we make goes into; and if people disagree on how to do the categorisation, or they forget to do it, then the data is worse than useless.
That's not to say that the idea can't work, just that it's more complicated than it seems. The data needs to be accurate and comprehensive, and it needs to be gathered in a way that isn't a burden. The procedure I'm thinking of is something like:
- Anyone, including the commenter, can mark a comment as being a review. Appears in the tally immediately.
- Anyone can dispute that a comment is a review. The dispute is resolved by ??? (this is the really annoying part)
- A comment with a resolved dispute cannot be disputed again.
The other issue is that there won't be any historical data, so the data still won't be that comprehensive if we wanted to, say, display the number of reviews someone's done on their profile.
I recognise that using "number of comments" as a proxy for "number of reviews" dissuades people from making short, mildly helpful or kind posts, since that would be taking from the entry's "review quota" and maybe get it less attention than it otherwise would have. It's just that it's a good enough solution and the proper one of getting comprehensive data on what is and isn't a review takes a lot of work. I'll try and look into sorting it out once I've finished with other priorities. (But you know how that usually ends up...)
>>CoffeeMinion
>>Bachiavellian
It's not great if there's too much discussion being held on Discord, since it's harder to find there. When possible people should try to leave comments here rather than there, or to copy the thoughts they wrote there over here.
Of course, the assumption that that discussion would appear on the site in the absence of Discord is probably not right. A lot of these discussions are spontaneous or off-the-cuff, which on a forum probably wouldn't happen at all. So I think the real issue is a search problem.
To that, there's an easy solution: if you happen to be involved in a Discord chat about a particular story, just put the story title in the chat—an entire discussion can easily go by where the title isn't actually written out once, started off by some comment like "hey so what about that story where the thing happened?" Then the author can search and find all discussion for their fic easily using Discord's built-in search.
My proposal to fix this was for story comments to have a little checkbox for "Is this comment a Review?" and have the gallery page track marked reviews in addition to total comments.
Main issue I see with this is adding friction to the commenting process. If we've already got an issue where there's too much posting on the lower-effort Discord, then adding an extra step to commenting here only makes that problem worse. We'd have to decide where the line between "review" and "comment" is, and we'd have to decide which category every post we make goes into; and if people disagree on how to do the categorisation, or they forget to do it, then the data is worse than useless.
That's not to say that the idea can't work, just that it's more complicated than it seems. The data needs to be accurate and comprehensive, and it needs to be gathered in a way that isn't a burden. The procedure I'm thinking of is something like:
- Anyone, including the commenter, can mark a comment as being a review. Appears in the tally immediately.
- Anyone can dispute that a comment is a review. The dispute is resolved by ??? (this is the really annoying part)
- A comment with a resolved dispute cannot be disputed again.
The other issue is that there won't be any historical data, so the data still won't be that comprehensive if we wanted to, say, display the number of reviews someone's done on their profile.
I recognise that using "number of comments" as a proxy for "number of reviews" dissuades people from making short, mildly helpful or kind posts, since that would be taking from the entry's "review quota" and maybe get it less attention than it otherwise would have. It's just that it's a good enough solution and the proper one of getting comprehensive data on what is and isn't a review takes a lot of work. I'll try and look into sorting it out once I've finished with other priorities. (But you know how that usually ends up...)
Because of this entry, I have decided to add a new rule: stories must not be mostly nonsense.
Author informed me “, or even half of it” was supposed to be a related pic, and not “Whose Who?”. I've updated it accordingly.
Author of “The Mære” informed me this was supposed to be a related pic. I've updated it accordingly.
>>Xepher
Basically what Quill said. Just convince me that at least 3-4 people will enter.
Basically what Quill said. Just convince me that at least 3-4 people will enter.
Title changed from "Pumpkin Spike Season" to "Pumpkin Spice Season" at author's request.
I would've liked the chat messages to have timestamps, to see if response times could be used as clues (or red herrings).
>>No_Raisin
This isn't really the right question to ask. Rather: Is IRC the most appropriate communications platform to hold this contest on? The answer, even in 2038, is almost certainly yes.
The reason IRC isn't a popular platform in 2018 is that people want more out of a communications platform than just text messages. People want server-side logging, hypertext, media embeds, file uploads, finer permissions levels, phone-number-as-id, an identity extending beyond a single server's fiefdom, etc.
For the purposes of this competition, though, IRC is sufficient, because the competition only needs text chat. To the human users, the platform is irrelevant. They just need a text box they can type into.
The choice for IRC would be made for two reasons:
- Every programming language has a library for writing a bot
- It's stable: you can be sure it's both not going anywhere and not changing anytime soon
However, this explanation still leaves a plot hole: The limited history of the human's clients makes no sense, not just for technical reasons (they could connect with whatever IRC client they please), but that the organiser wouldn't want to leave such trivial gotchas into the contest environment. This isn't their first rodeo.
This is a totally compelling story throughout, but as >>Pascoite says there's a lot of fridge logic.
Why do human clients have a history limit? It's IRC.
Why is swearing not allowed? It may be a "globally broadcast" competition, but even in 2038, the only people who would actually watch this are nerds. There'd be no need to make it family friendly. Even then, enforcement is either strict (in which case <fern> would have been kicked immediately) or lax (in which case swearing shouldn't be considered definitive evidence of humanness).
<xcomwell> fabricating a memory is if anything more likely to occur with a human than a bot. A human could skim read "small chalk ... fell out of my hands" and assume a memory of that occurring to them.
What's the penalty for kicking a human? You get increasingly more points just for staying in the round as late as possible. So unless the penalty for kicking humans is super high, you should just always vote to kick.
What are the points for? Does the contest have an entrance fee and prizes? In that case, <fern>'s strategy of acting like someone who just opened the game up for a lark isn't that convincing.
I think that a lot of these pegs can be squared with 2 changes:
First, that the voting is done by the audience, not the participants. This way the strategy is simple: If people think you're a bot, you lose. You get more points the longer in the round you last. Humans try to act human to humans. Bots try to act human to humans. Otherwise, there's metagaming where you're trying to act human as other bots think humans act, because the bots typically outnumber the humans, and you have to evaluate kick decisions not just based on whether you think the subject is a bot or not, but based on your expected points gained by being wrong versus progressing to later stages of the round. Similarly, it would make the decisive elimination of bots like <cccccc> and <Lizzie> more sensible. It would also make the contest more attractive as a spectator sport, since it'd involve the audience. And it'd have the result less subject to the quirks of a particular group and closer to the intent of a Turing test: winning would mean you appeared human to a wide array of humans, rather than just to a small group of mostly bots.
Second, that there actually are humans in the game. For example, make <xcomwell> and <Shiva> humans. As >>alarajrogers says, the type of speech that <Shiva> exhibits could be autism just as well as it could be a bot tell, and as I say above, <xcomwell> could just as well be a human fabricating a memory from a skimmed read of the text. You could have <Shiva> say he's using software assistance to make estimates of whether other participants are bots and find their most damning tells, like a centaur in Advanced_Chess. I think players metagaming and explicitly appealing to the audience about these strategies and pontificating about what is and isn't a bot tell would make the game more interesting, but is also probably difficult to actually make into a satisfying narrative, given that the main problem with there being any humans at all is that who actually is human and who is a bot is ultimately authorial fiat and probably unsatisfying in one way or another. At least everyone being a bot is a closed circle. The main purpose here is for the story to actually have something to say (c.f. >>Pascoite "it's kind of thin and doesn't make a point"), since if you can make this work you'd be saying something about what it is exactly that makes humans human.
>>No_Raisin
So author, I don't know who you are, but do you really think IRC is still going to be a thing in 2038?
This isn't really the right question to ask. Rather: Is IRC the most appropriate communications platform to hold this contest on? The answer, even in 2038, is almost certainly yes.
The reason IRC isn't a popular platform in 2018 is that people want more out of a communications platform than just text messages. People want server-side logging, hypertext, media embeds, file uploads, finer permissions levels, phone-number-as-id, an identity extending beyond a single server's fiefdom, etc.
For the purposes of this competition, though, IRC is sufficient, because the competition only needs text chat. To the human users, the platform is irrelevant. They just need a text box they can type into.
The choice for IRC would be made for two reasons:
- Every programming language has a library for writing a bot
- It's stable: you can be sure it's both not going anywhere and not changing anytime soon
However, this explanation still leaves a plot hole: The limited history of the human's clients makes no sense, not just for technical reasons (they could connect with whatever IRC client they please), but that the organiser wouldn't want to leave such trivial gotchas into the contest environment. This isn't their first rodeo.
This is a totally compelling story throughout, but as >>Pascoite says there's a lot of fridge logic.
Why do human clients have a history limit? It's IRC.
Why is swearing not allowed? It may be a "globally broadcast" competition, but even in 2038, the only people who would actually watch this are nerds. There'd be no need to make it family friendly. Even then, enforcement is either strict (in which case <fern> would have been kicked immediately) or lax (in which case swearing shouldn't be considered definitive evidence of humanness).
<xcomwell> fabricating a memory is if anything more likely to occur with a human than a bot. A human could skim read "small chalk ... fell out of my hands" and assume a memory of that occurring to them.
What's the penalty for kicking a human? You get increasingly more points just for staying in the round as late as possible. So unless the penalty for kicking humans is super high, you should just always vote to kick.
What are the points for? Does the contest have an entrance fee and prizes? In that case, <fern>'s strategy of acting like someone who just opened the game up for a lark isn't that convincing.
I think that a lot of these pegs can be squared with 2 changes:
First, that the voting is done by the audience, not the participants. This way the strategy is simple: If people think you're a bot, you lose. You get more points the longer in the round you last. Humans try to act human to humans. Bots try to act human to humans. Otherwise, there's metagaming where you're trying to act human as other bots think humans act, because the bots typically outnumber the humans, and you have to evaluate kick decisions not just based on whether you think the subject is a bot or not, but based on your expected points gained by being wrong versus progressing to later stages of the round. Similarly, it would make the decisive elimination of bots like <cccccc> and <Lizzie> more sensible. It would also make the contest more attractive as a spectator sport, since it'd involve the audience. And it'd have the result less subject to the quirks of a particular group and closer to the intent of a Turing test: winning would mean you appeared human to a wide array of humans, rather than just to a small group of mostly bots.
Second, that there actually are humans in the game. For example, make <xcomwell> and <Shiva> humans. As >>alarajrogers says, the type of speech that <Shiva> exhibits could be autism just as well as it could be a bot tell, and as I say above, <xcomwell> could just as well be a human fabricating a memory from a skimmed read of the text. You could have <Shiva> say he's using software assistance to make estimates of whether other participants are bots and find their most damning tells, like a centaur in Advanced_Chess. I think players metagaming and explicitly appealing to the audience about these strategies and pontificating about what is and isn't a bot tell would make the game more interesting, but is also probably difficult to actually make into a satisfying narrative, given that the main problem with there being any humans at all is that who actually is human and who is a bot is ultimately authorial fiat and probably unsatisfying in one way or another. At least everyone being a bot is a closed circle. The main purpose here is for the story to actually have something to say (c.f. >>Pascoite "it's kind of thin and doesn't make a point"), since if you can make this work you'd be saying something about what it is exactly that makes humans human.
The scoreboard has been updated with a fresh, mobile-friendly design, with fancy new vector award icons courtesy of GGA.
(Go look at it it's very pretty.)
(Go look at it it's very pretty.)
>>Trick_Question
A while back I spent a while thinking about the guessing system and how to make the awards meaningful.
Most of the relevant ideas I posted in this GitHub issue. Admittedly, most of the thinking was about the avoided detection award. The most relevant part:
Maybe there's actually a solution after all: punish wrong guesses slightly (maybe 1/5th of a point), enough to discourage uninformed guesses, but not enough to discourage mising a guess. Then, with uninformed guesses not diluting the data, an "avoided detection" award might have some meaning.
A while back I spent a while thinking about the guessing system and how to make the awards meaningful.
Most of the relevant ideas I posted in this GitHub issue. Admittedly, most of the thinking was about the avoided detection award. The most relevant part:
Another thing I try to keep in mind is that wrong guesses are basically meaningless, at least as far as the observed data is concerned. Most people make about 6-8 informed guesses, and then either don't bother with the rest or just throw in a mostly random one.
Maybe there's actually a solution after all: punish wrong guesses slightly (maybe 1/5th of a point), enough to discourage uninformed guesses, but not enough to discourage mising a guess. Then, with uninformed guesses not diluting the data, an "avoided detection" award might have some meaning.
>>Trick_Question
Short answer: I'm messing with the session code, and hopefully it's fixed now.
Long answer: The reason that the server would crash and have to be reset every ~45 days is that new sessions being built up by non-persisting clients would eventually fill up the server's storage. These sessions were all useless, but distinguishing them from actually useful sessions to clear space is expensive.
Instead of doing that, I decided to change the session storage from being in files on the server in /tmp to being in the cookie itself. The upside of this is that errant sessions don't endlessly fill up space on the server, and session data survives a server reset. This is a relatively old idea that's regained popularity since ways of doing it securely have been made robust. The downside is that the cookie data is sent on each request, increasing bandwidth, and that cookies have a size limit of 4KB. However, since the session only contains the user id, this isn't really an issue.
The Perl module that implements this cookie store, though, has a few kludges to it that prevents me from doing a few things I want the session to do: (1) setting the sameSite, httponly, and secure flags on the cookie; (2) only resetting the cookie when necessary; and (3) resetting the cookie if its more than a day old, to prevent expiry.
Coming to your specific question: With this module, the cookie that stores the data is actually different from the one that stores the session id, and the config setting I set to make the cookie expire in 1 year instead of the default 1 day only applied to the latter, so while the session itself persisted longer than a day, the data did not.
So to get the session behaviour I wanted, I wrote my own session handler, which should behave nicely and not cause any problems from now on.
Short answer: I'm messing with the session code, and hopefully it's fixed now.
Long answer: The reason that the server would crash and have to be reset every ~45 days is that new sessions being built up by non-persisting clients would eventually fill up the server's storage. These sessions were all useless, but distinguishing them from actually useful sessions to clear space is expensive.
Instead of doing that, I decided to change the session storage from being in files on the server in /tmp to being in the cookie itself. The upside of this is that errant sessions don't endlessly fill up space on the server, and session data survives a server reset. This is a relatively old idea that's regained popularity since ways of doing it securely have been made robust. The downside is that the cookie data is sent on each request, increasing bandwidth, and that cookies have a size limit of 4KB. However, since the session only contains the user id, this isn't really an issue.
The Perl module that implements this cookie store, though, has a few kludges to it that prevents me from doing a few things I want the session to do: (1) setting the sameSite, httponly, and secure flags on the cookie; (2) only resetting the cookie when necessary; and (3) resetting the cookie if its more than a day old, to prevent expiry.
Coming to your specific question: With this module, the cookie that stores the data is actually different from the one that stores the session id, and the config setting I set to make the cookie expire in 1 year instead of the default 1 day only applied to the latter, so while the session itself persisted longer than a day, the data did not.
So to get the session behaviour I wanted, I wrote my own session handler, which should behave nicely and not cause any problems from now on.
>>aconcernedparent
>>aconcernedparent
These comments were reported as an anonymity violation because they are obviously by the author.
While usually I would've DQ'd this entry, it was submitted under Anonymous. Anonymity violations when the fic is by Anonymous don't have any precedent, and I think the rules in this case were sufficiently ambiguous that a disqualification was not justified.
The intent of the rules however are very distinctly against this behaviour. Any future cases of people giving an authorial perspective will be ruled as an anonymity violation, regardless of who the entry was submitted under.
(Also, as a general rule, please don't use the alias feature to make inflammatory comments.)
>>aconcernedparent
These comments were reported as an anonymity violation because they are obviously by the author.
While usually I would've DQ'd this entry, it was submitted under Anonymous. Anonymity violations when the fic is by Anonymous don't have any precedent, and I think the rules in this case were sufficiently ambiguous that a disqualification was not justified.
The intent of the rules however are very distinctly against this behaviour. Any future cases of people giving an authorial perspective will be ruled as an anonymity violation, regardless of who the entry was submitted under.
(Also, as a general rule, please don't use the alias feature to make inflammatory comments.)
Sorry about the technical difficulties. I was away this weekend and wasn't able to do anything short of hitting the reboot button. The rounds have been extended so there's still 1 day to finish prelim voting and art submissions.
I haven't figured out what the problem is but have setup a debug system up so I'll know what it is when it happens next. It's probably something to do with art submissions.
I haven't figured out what the problem is but have setup a debug system up so I'll know what it is when it happens next. It's probably something to do with art submissions.
Reminder to everyone that there will be a meeting tomorrow to discuss changes to the schedule (among other things). See >>RogerDodger for details.
If you're unable to make the meeting time but want a particular issue discussed, say so in the #meta Discord channel beforehand.
If you're unable to make the meeting time but want a particular issue discussed, say so in the #meta Discord channel beforehand.
Experimenting with a word limit of 500–900 for this event.
I need a way to more decisively make changes or do experiments with the formats, rules, etc. I have previously taken discussions of this nature with a bent towards conservatism out of concern for people who missed the discussions or are simply happy with the way things are. However, I think this has lead to it being hard to get any changes made at all.
To that end, I'm going to periodically hold meetings in the #meta discord channel where things can not just be discussed but also decided on. This means decisions will mostly be made with consideration for people who show up. (However, this is still not necessarily a democratic process, since I've got the final say on everything.)
These meetings will be held on the Sunday following the conclusion of a scheduled event at 00:30 UTC. The first will be 24 Jun 00:30.
I need a way to more decisively make changes or do experiments with the formats, rules, etc. I have previously taken discussions of this nature with a bent towards conservatism out of concern for people who missed the discussions or are simply happy with the way things are. However, I think this has lead to it being hard to get any changes made at all.
To that end, I'm going to periodically hold meetings in the #meta discord channel where things can not just be discussed but also decided on. This means decisions will mostly be made with consideration for people who show up. (However, this is still not necessarily a democratic process, since I've got the final say on everything.)
These meetings will be held on the Sunday following the conclusion of a scheduled event at 00:30 UTC. The first will be 24 Jun 00:30.
2nd and 3rd look to be tied (to 5 decimal places), so them not being so in the ranking is probably a floating point error.
Will check it out further soon.
Will check it out further soon.
Paging WIP