00:00:47 Unstable branch on CRAWL.XTAHUA.COM updated to: 0.22-a0-392-g5dc3fd9 (34) 03:12:16 Unstable branch on crawl.beRotato.org updated to: 0.22-a0-392-g5dc3fd9 (34) 10:11:55 ??won . hu-- 10:11:55 I don't have a page labeled won_._hu-- in my learndb. 10:11:59 er 10:12:04 !won . hu-- 10:12:05 Lightli (hu--) has won 3 times in 81 games (3.70%): 1xHuBe 1xHuFi 1xHuIE 12:24:34 You guys said yesterday that it would be useful to know specifically what dump_options and dump_macros are required to do for speedrunning purposes. I asked the other speedrunners for their opinions and we have agreed on the following: https://pastebin.com/raw/kVSscaLC . I hope this answers your questions. 12:28:19 I have linked that in the PR as well 13:04:54 Unstable branch on crawl.akrasiac.org updated to: 0.22-a0-392-g5dc3fd9 (34) 13:13:11 -!- amalloy_ is now known as amalloy 13:25:18 that general approach might work if hashing the RC file and saving the hash in the save is implemented so that it can be detected when a game resumes 13:25:37 I don't know if resuming a game from a save generates a note unconditionally, but that would probably need to be a thing as well 13:26:55 but binding lua console would need to be forbidden by anyone making some ruleset forbidding these kinds of changes, probably 13:27:53 also none of this addresses someone simply making a macro like this directly on their PC 13:28:09 <|amethyst> gammafunk: well, someone entering something in the lua console will show up in the ttyrec, right? 13:28:24 well yes, but don't tell anyone about that because so far that hasn't happened and we don't want it to happen 13:28:26 |amethyst: they're trying to avoid watching the ttyrec 13:28:31 <|amethyst> ah 13:28:36 NormalPerson7: that's a terrible attitude 13:28:37 |amethyst: well, people are trying to get these options in to avoid that kind of verification, but yes 13:28:56 basically there's not going to be a way to avoid verification via video/ttyrec if you want to be more sure 13:28:58 i mean it's a terrible attitude sure, but it's what the realtime community has operated on in the past 13:29:03 it doesn't have to i agree 13:29:08 so was not using multi-turn macros 13:30:40 this thing of making option to avoid having to do video/ttyrec verification does kind of feel like a fool's errand, and I'm not sure how motivated the various people asking for them actually are in vetting runs 13:30:43 i mean, i guess it's not our problem, as long as you don't come back later when some speedrunner uses the lua console askign for another feature to disable it. but it seems like it would be pretty easy for your community to also say "in addition to [whatever other rules], you can't use the lua console" 13:31:38 yeah, if you're going to use these heuristic verifications, disabling lua console sounds like a good idea, but I suppose if you just show macro changes that's a heuristic for covering that 13:33:30 i wonder what will be done about OS-level macros 13:34:02 yeah, that's what I meant about by "macro like this directly on their PC" 13:34:14 someone could very trivially just macro tab on their OS 13:34:32 record the minimum delta between keypresses? 13:37:43 obviously we need to ship an anti-cheating daemon users have to run on their computer 13:38:34 who would have guessed that VAC would be what finally propels us to a steam release 13:38:47 could throw in a bonus hardware dongle too 13:41:44 yes, well the lua console should be disabled for sure (but tbh i didn't know this was even accessible online) - what i should say regarding the pc macro idea is as far as i'm aware there is no way to block such macros through crawl, but if there is then sure that could be done 13:42:20 that's 1) not possible, and 2) way outside of scope for crawl 13:43:09 yep, as i thought 13:43:50 which means there is no point worrying about something we can't control, is kind of the idea i'm getting at, but you're right this thing will eventually die a horrible death to it 13:43:54 s/this thing/realtime speedrunning 13:44:11 s/it/pc macros 13:44:32 well it's not a problem if you have people asking for videos and verifying those videos 13:44:39 right i guess 13:44:41 that's how most speedrun communities work 13:45:30 i think the reason the realtime community didn't want to have to do this is because we didn't think it was necessary, but you have now provided a concrete reason why that would be necessary 13:45:38 *i think*, i don't know 13:46:25 you might be interested in recording all key input events with timestamps 13:46:52 you were discussing that or something similar yesterday no? 13:47:16 because that could be useful, sure 13:47:32 would be useful in fact 13:47:49 because that would make it pretty clear when macros are being used 13:48:23 <|amethyst> unless you hook up an arduino or what have you as a USB input device 13:48:29 <|amethyst> and have it play back the macros :) 13:48:46 <|amethyst> (similar to console joysticks with rapid fire) 13:49:10 right, but if crawl is receiving key events faster than fingers can physically move.. 13:49:22 ye that's what i mean 13:49:27 I'm not sure if storage of that would be trivial 13:49:28 wait, are speedrunners playing locally? I was under the impression it's webtiles only 13:49:36 ye it's webtiles only 13:49:46 storage and analysis 13:49:49 because morgue files are trivial to modify offline 13:49:56 right, exactly 13:50:09 well it's not even morgue files, you can just modify the game 13:50:14 that too 13:51:12 aidanh: I'm not sure if you can store keypresses/timestamps in a way that wouldn't be intrusive, and how would you actually analyze these? 13:51:16 |amethyst: reminds me of an SGDQ event i saw where they plugged an arduino or something into an SNES to act as a controller and replay inputs as fast as the console would take them 13:52:13 not really all that different from a normal TAS i guess, but using an actual physical input device was cool 13:52:49 intrusive in what sense? basically, you'd be looking for key events with low deltas between them 13:53:49 aidanh: well, you're talking about storing these, no? 13:54:30 are you talking about having crawl make some kind of warning note if events have a low delta? 13:58:45 depends how people want to analyze the data, I suppose; events are going to have a low delta for macros anyway 14:04:01 -!- Nomi__ is now known as Nomi 14:04:38 i mean internal macros are handled by crawl so we should be able to except them from the delta calculations no? 14:06:07 <|amethyst> BTW, re: multi-action macros, it might be necessary to be a little more specific 14:06:13 <|amethyst> two examples: 14:06:27 <|amethyst> 1. Someone macros F1 to > 14:06:34 <|amethyst> going down stairs takes multiple player turns 14:07:25 <|amethyst> 2. someone macros F2 to G< 14:07:59 <|amethyst> or to o for that matter 14:08:14 depends if you want to see what the player presses, or what crawl sees; both are potentially useful 14:08:20 <|amethyst> which not only takes several turns, but in-game is the same as executing single actions in a row 14:08:27 <|amethyst> s/single/several single/ 14:08:51 <|amethyst> oh, I see, you do mention G> 14:09:06 if you can detect the use of a macro (and its actions), then you can decide on a case-by-case basis what's acceptable 14:09:10 <|amethyst> so o would be banned? even without being macroed to a different key? 14:09:43 <|amethyst> not that someone would use o in a speedrun, but let's say G< 14:09:52 |amethyst: these are realtime speedruns 14:09:53 <|amethyst> or GD0 14:09:56 all i want for christmas is to see demise's face when he hears that o is disallowed 14:10:30 i mentioned travel in that document |amethyst 14:10:32 where G> (and G<) are accentable 14:10:32 <|amethyst> yeah, but it mentions macros 14:10:45 *acceptable, all other G and o macros are banned 14:10:56 <|amethyst> I mean, is GD0 banned by itself, or only when it's in a macro? 14:11:02 <|amethyst> likewise o 14:11:16 only in a macro (which is a bit weird, i know, but that's the current consensus) 14:11:20 <|amethyst> hm 14:11:55 <|amethyst> I suppose keybindings are fine, though? 14:12:05 <|amethyst> I have a keybinding from keypad- to o 14:12:18 i've never actually used them, so idk what they are - they bind one key to another right? that would be fine yes 14:13:08 effectively single-key macros 14:13:19 i macro the - key to be an alias for 5, so i don't have to reach for the middle of the keyboard. but it's a "multi-turn macro" 14:13:46 <|amethyst> One possible change, if people agree to that: Multi-action macros are disallowed. A multi-action macro is one where ready() would be called in the middle of the macro 14:14:01 <|amethyst> of course, you'd want to phrase it in a less lua-botter-centric way 14:14:25 ready() would ban G> too no? 14:14:38 but banning G> is consistent 14:14:48 <|amethyst> hm 14:15:04 just because people were using it before, people are using it now, so that's why it has been explicitly permitted 14:15:07 <|amethyst> I guess ready() isn't quite right because I think it's not called in the middle of a macro 14:15:23 (i don't actually know what ready() does) 14:15:50 i'll look it up 14:15:53 <|amethyst> ready (if it exists as a lua function) is called every time the game is ready for the user to enter a new command 14:16:10 oh it's a user-defined lua func, right 14:16:22 perhaps require that _input() isn't called multiple times for a macro? 14:16:30 <|amethyst> hm 14:16:58 <|amethyst> that could be something we count in-game too 14:17:54 <|amethyst> but my main point is that "multi-action" and "multi-turn" aren't quite the same thing. Even if you don't want travel to be allowed in macros, there are also things like W (wear armour) or > (take stairs) that take multiple turns even though they're really one action 14:18:28 <|amethyst> (not just >1 aut, but actually multiple turns) 14:18:31 yes they aren't, i admit that, i just didn't quite know how to express it 14:18:40 yep 14:19:08 W and > and casting passwall are indeed what i would consider single-actions 14:21:43 so |amethyst how should i express it? 14:23:42 <|amethyst> I'm not quite sure, maybe something like what aidanh suggested about the _input function only being called once while processing the macro 14:24:01 <|amethyst> that's kind of internals-ish, but it is something we could track 14:24:21 I'm not too sure about that either 14:24:24 <|amethyst> OTOH, I think that would exclude G> 14:24:36 that would, but we can deal with that 14:24:43 <|amethyst> at the very least it would count GD0 and G> the same 14:24:50 <|amethyst> which sounds like not exactly what you want 14:24:50 does it not exclude any multi-key action tho 14:25:11 <|amethyst> _input is used to get a command, not for things like the "which spell" prompt 14:25:16 ok thx 14:25:34 basically apart from G> that is exactly the definition we want 14:25:39 <|amethyst> oh, 14:25:43 <|amethyst> what about shift-direction 14:25:50 <|amethyst> do folks consider that a travel command? 14:25:57 no idea, nobody has asked that ever 14:26:01 :D 14:26:31 i mean shift-dir isn't something people use, cos people use o, but it's a valid question nonetheless 14:28:19 it would be banned under the _input definition, and for consistency i would say yes we would consider that a banned travel command, but i would have to discuss it to be sure (nobody will ever macro it because it's slow to use) 15:09:14 -!- electrons is now known as quarks 15:25:20 I wouldn't want to promise that macros, even multi-turn macros, aren't used internally for things 15:25:25 they *definitely* are for offline tiles 15:53:25 ^status 15:53:26 46 Crawlers. CBRO disk usage=96% (135GB) | RAM usage=48% (4GB)| uptime/CPU= 15:53:25 up 114 days, 19:29, 2 users, load average: 0.65, 0.78, 0.85 (4 Cores) http://status.berotato.org 19:43:04 -!- amalloy is now known as amalloy_ 21:13:06 https://twitter.com/the_T_bot/status/989546278156685313 21:15:42 One weird trick to improve DCSS. Developers hate him!