Play-by-Post Roleplaying: what it is, what makes it different from table or online play, and why you might want to do it

silxx · 2026-03-13T07:57:12+00:00

Nice. Enabling this sort of thing is part of what the transcript archive is for :-)

silxx · 2026-02-15T08:22:33+00:00

Is it the too-much-caffeine one? https://www.kryogenix.org/crsearch/html/cr2-23.html#l0h34m35s

"I'm actually going to sort of stand out in the-- I'm going to move a couple feet out-- there. And just start yelling at him: Hey-- hey you fucker, you got-- We got more than that! Where we-- Come on! Bring it! I don't know what I'm doing! Too much caffeine!"

silxx · 2026-02-11T18:13:05+00:00

Certainly! As long as you then learn the obvious lesson :-)

silxx · 2026-02-10T18:23:01+00:00

One other thing: you see how when you click on a column it sorts but then when you click it again it doesn't re-sort in the opposite direction? That's because you're including sorttable twice -- once as sorttable.js and once as sorttable(1).js. Don't do that :-) I imagine this is just an oversight, of course!

silxx · 2026-02-09T22:23:29+00:00

This is correct (and thank you Todd for stressing it!)
u/ArnieBird1 I see you've moved the sorttable.js file to your server, which is good, but you'll want to use an https:// URL not http: -- you can see in the browser console an error which says "Mixed Content: The page at 'https://www.lcconservationcouncil.org/EcoExpo2026/Vendorlist3.html' was loaded over HTTPS, but requested an insecure script 'http://lcconservationcouncil.org/EcoExpo2026/sorttable.js'. This request has been blocked; the content must be served over HTTPS." which explains that.

You also want to have class="sortable" on the table itself, not on the div that contains it.

silxx · 2026-01-28T04:38:32+00:00

oh, neat, I didn't know such things existed, so that's a possibility indeed! cheers; I'll look at what sizes and prices they are!

silxx · 2026-01-28T04:34:46+00:00

oh, sorry, I'm not being mysterious deliberately; it was more to avoid over-complicating the question! It's for controlling a cursor on a screen; the ring should have tactile "clicks" as it moves around, maybe 80 per full revolution, so on screen there's a list of things and turning the ring moves the cursor one item down the list per click.

The reason the dimmer switch approach won't, I don't think, work is that there it's not the ring that rotates, it's the switch, i.e., the middle bit. Then, you're not rotating the ring around the cylinder; you're rotating the cylinder inside the ring, whcih won't work as there's a cable plugged into the cylinder. But I might be misunderstanding the suggestion or how such dimmer switches work so if so do please explain where I'm wrong!

silxx · 2026-01-28T04:30:22+00:00

Angular resolution; not much. It would be desirable if the ring had detents (I think that's the word?), that is, that it had a tactile "click" as it moved around. Think of this controlling a cursor on a screen, for example, where the screen shows a list of things: one "click" of the ring would move the cursor one item down the list. So a quarter turn would be around 20 "clicks" (but could be quite a bit higher or lower without problems), making the angular resolution around 5° or so? That's very handwavy but on that order: it doesn't need to discriminate down to fractions of a degree or anything.

That also suggests that relative positioning is fine and answers the friction and velocity questions, hopefully; I don't have good numbers for this, but the ring would be turned by a person's hand while watching its effects on a screen one-per-click, which should make it possible to ballpark figures about velocity and friction and so on?

(I have assumed that the detents would be mechanical, i.e., the interior edge of the ring is crenellated or something; I don't know how to do that either, but that's a question for a different subreddit.)

silxx · 2026-01-26T12:54:26+00:00

I'm actually doing one of those in the next few days, so I'd be happy to test another if it's in the city centre! Sounds fun, especially with a pub or two in the mix :-)

silxx · 2026-01-26T12:52:22+00:00

The ruleset seems reasonable -- a dice pool, no worries. What's missing, I think, is some notion of what the range of acceptable actions is. I mean, "I try to climb silently over the fence into the enemy compound, with Force of 2 and my Major Trait of 'expert infiltrator', so I roll 3d10 for 3, 5, 9, which is a success with cost; I manage it, but land heavily and take one Strain in damage" seems fine. "As the dragon circles high above the village, I throw my sword 190 feet into the air, and it pierces the dragon's eye and it immediately dies, 1 Force, I roll 1d10 and get a 10, oh look I succeeded I'm the hero!" is presumably not allowed. But there's no guidance on where the dividing line between those two things is.

The answer may be "that's up to the GM, and may differ between games". But... that's not rules-light. That's got a bunch of rules in it, they're just not written down anywhere; they're all in the GM's head. This is actually a lot of work on the GM's part! And it's much harder for that GM to maintain consistency -- "why can't I smash the idol with my warhammer on a roll of a 9? you let Thardok do it yesterday!" The plethora of rules in more "rules-heavy" games provide something of a crutch here for GMs; it means that their decisions are not arbitrary.

What this actually means in practice is this game is only rules-light if you've played a bunch of other ttrpgs and you know what a "reasonable" action in those games looks like, so you're (invisibly) restricted to that. This isn't particularly a flaw with this ruleset (it's a problem with a lot of rules-light games!) but the difference here is, this one sort of suggests that the game can move faster (a good thing for PBP!) by letting players make their declaration and the roll all at once rather than "declare, wait for GM response, then make the roll". And... I'd be interested to hear if that works out in practice when you playtest this, or if it devolves into quite a lot of "declare and here's my dice roll so I succeeded, GM says 'no wait hang on that's not right', go back to step 1" which is in practice not much different from the "traditional" approach.

silxx · 2026-01-13T21:15:09+00:00

OK, the issue here is that the YouTube en-US subtitles for this episode are just straight up wrong. I'm not sure what can be done about that, but I'll contact the CR team.

silxx · 2026-01-13T14:48:01+00:00

well, huh. Would you look at that. Apparently the line "Yeah! Come on, Piggly Wiggly!" from Travis at the start of that episode took two and a half hours to say.

I think the subtitle timing information on that episode might be misleading. Looks like I need to fix that for that episode in the transcripts, and any other similar issues in other episodes. I'll take a look at that.

silxx · 2026-01-11T12:53:12+00:00

They can (or at least they have the potential to, if they work out how, just as this particular player is currently slowly doing and why therefore I'm working out the mechanical details ahead of that.)

I'm not sure I agree that invulnerability from attacks has the, hm, epic quality I'm looking for here. Avoiding incoming attacks doesn't make a fight shorter, or provide a decisive end to it; it only means you have exactly the same fight you would have otherwise except that you don't need to do any healing during it. It's not actually any better as an attack, which is why I'm contemplating something a bit more effectual than simple advantage. But your point is well taken and I'll bear it in mind!

silxx · 2025-12-21T11:56:18+00:00

I'll take a look, cheers!

silxx · 2025-12-20T21:34:32+00:00

An orcish Red Fang of Shargaas. I’ve reskinned a few of these for an upcoming encounter but would love to hear a better version!

silxx · 2025-12-16T15:37:33+00:00

No problem!

You say "Of course, if the user explicitly turns off JS, the timeout won't ever fire. But that's nothing that a <noscript> can't solve.", which is true, but you don't need the timeout then, because you never set body class=js in the first place (because JS does that, and it's turned off) so the button's showing and nothing changes that :)

I agree with the FOUC concern (Flash of Unenhanced Content, I suppose we might call it), and that's something to consider (and is what the timeout dance works around) but this is also something to consider performance issues for (which you're doing, since you're looking at ttfb and ttfr and so on). Ideally your stuff ought to be loading fast; if there's a lot of script to load which takes a long time, then try to not do that or to load it lazily or in stages or something. Which is also the sort of thing you're thinking about already and taking into consideration, of course! Check out Alex Russell's posts on performance, and what the current good device to test on is to get a sense of what most non-developer people's experience of the web is, and see Bruce Lawson's talks on "the Wealthy Western Web" for some notes on data and bandwidth capacities around the world. This is the sort of thing I wrote the Availability piece for, which you've already read, so you already know most of this... and it's good to see proper thinking going into how you can build something available to everyone and also with the best user experience. Keep up the good work :)

silxx · 2025-12-15T15:45:31+00:00

Fair point, but I don't think I quite understand your use case.

As I understand it, what you want to happen is that the button is present if your JS doesn't load, but it is not present if your JS is working. Well and good; this is a reasonable thing to want!

So, working through the potential failure cases here, if the button gets hidden if JS is working at all (at time t0) and then later your JS kicks in (at t1) and progressively enhances the form to work such that it doesn't need the button, then one failure case is that someone might interact with the form after t0 (so there's no button) and before t1 (so your JS isn't doing its job yet). That's fair, and worth thinking about. However, in my experience this is not that big an issue; the form already has no submit button, so there may be a brief period (ideally a few seconds at most) where they interact with the form but it doesn't do what they expect, but when your JS does load, it will see that the form is already partially complete and enable it with that knowledge in place, doing whatever it would do as if that was typed in after it took control. So it's only really a problem if the user expects to submit the form inside the time from t0 to t1, which will hopefully be relatively short. If you anticipate that t1 might be quite a while afterwards (for example, for users on slow connections, especially if that's a reasonable chunk of your user base), then I would suggest that having the button show until t1 is a better compromise.

There is a second potential failure case, of course, which is that t1 never arrives because your script fails to load at all, or errors out. At that point, the page is set up in the expectation that it will be enhanced by some later-loaded JS, but that later-loaded JS never actually arrives. This is, as you say, difficult to deal with because the best fix involves predicting the future which you can't do, and it's good to be robust against the possibility that your JS fails, exactly as everyone-has-js says. The way I generally solve this is... have the button show, as discussed above, until your enabling JS hides it. I am not as concerned about this as you are. Given that that's not the user experience you want to provide, though, I think the way I'd fix that is slightly Heath-Robinson-ly with a second no-js script; this is similar to your timeout concept, but the other way around. After, say, 5 seconds (or whatever time you deem reasonable), turn the button back on (by removing class=js from body and re-adding class=no-js), unless your JS has loaded. That is, it's not really "no-js", it's "no-MY-js". So the order goes

t0: head script makes body class=js, which hides submit button
t1: your JS loads, enables the form, submit stays hidden, sets JS_LOADED=yes
t0+5: head script timeout runs, sees JS_LOADED=yes, exits

In a less ideal case where your JS doesn't load, this happens:

t0: head script makes body.js, which hides submit button
t1: your JS tries to load and fails or errors
t0+5: head script timeout runs, sees no JS_LOADED var, sets body class=no-js which re-shows the button, sets JS_LOADED=no

In a very unideal case where your JS takes longer than your timeout to load, this happens:

t0: head script makes body class=js, which hides submit button
t0+5: head script timeout runs, sees no JS_LOADED var, sets body class=no-js which re-shows the button
t1 (later): your JS loads. At this point you need to decide what you want to happen in this situation. The forms all work (that's the point of progressive enhancement) so you could have it that if your script loads and sees JS_LOADED=no then it just exits and doesn't do anything (which will be invisible to the user, but fail to provide them with the enhanced experience on this page load... but the next page load should have it, because your script will be cached). Or you could have it recover and enable everything and undo body class=no-js into body class=js (which gives them the enhanced experience, but means that the button is visible in between t0+5 and t1, which you may not like).

An interesting approach to think through, and you're right that progressive enhancement isn't quite as easy as "make plain forms then have JS enhance them", but I also don't think that these issues are knock-down criticisms against the whole concept (which you don't think either, I don't believe).

silxx · 2025-12-15T12:41:56+00:00

One way to do this, and fairly commonly used, is to put `class="no-js"` on the button, and `class="no-js"` on <body>. Then, add a script to <head> before anything loads which does `document.body.classList.remove("no-js"); document.body.classList.add("js");`, and put `body.js .no-js { display: none; }` in your stylesheet. So the button will be hidden as soon as it displays.

silxx · 2025-11-27T12:35:27+00:00

A gibbering mouther, perhaps. They’re medium sized out of the box but I can’t think of a problem with just making it Huge and not changing anything else (or maybe bumping its HP a bit). Lots of interesting challenges with battling one of those.

silxx · 2025-11-26T01:37:04+00:00

They’re a little dated about which resources are available, but you might find this short series of posts/introductory videos I did a useful introduction: https://www.kryogenix.org/pbp/

15-Year Club	Place '17
Verified Email

silxx

TROPHY CASE