00:06:40 Bananafish1988 (L27 DsHs) Crash caused by signal #6: Aborted (Pan) 00:34:41 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1280-g2aef843f5c (34) 00:55:43 Monster database of master branch on crawl.develz.org updated to: 0.34-a0-1280-g2aef843f5c 01:59:17 -!- indigaz22 is now known as indigaz2 02:21:45 PriceMaster (L2 SpAl) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:1) 04:32:53 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:35:32 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-1280-g2aef843 (34) 08:08:05 Aidan (L1 HuNe) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:1) 08:08:42 Aidan (L1 HuNe) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:1) 08:10:19 Aidan (L1 HuNe) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:1) 08:56:05 Aidan (L1 HuNe) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:1) 10:30:44 Pokonic1 (L3 DrSh) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:2) 10:32:23 <04dracoomega> I do wonder what to do about this. Like, this assert is demonstrating a real actual bug, but I have no idea how easy it will be to fix such a thing (that apparently was mostly invisible before this, instead of causing certain people to repeatedly crash >.>) 10:41:29 <03implojin> Looking at this, I think the issue is that TilesFramework::_handle_control_message really shouldn't be doing any immediate processing of game commands on its own and should instead be passing through virtual CMDs to be handled later? Otherwise it's always going to have race conditions where websocket control message events can happen (and be processed) with timing outside of the normal CMD input loop. I can sorta see how the current 10:41:29 situation might've come about wrt it being difficult to pass through mouse positions for later processing with the way the code is setup, but, like, the timing of this stuff in _handle_cell_click is just clearly wrong: (and is why it's asserting, the movement.cc assert here is good imo and has at least brought this to our attention even if it's probably nontrivial to fix) // click travel if (mouse_control::current_mode() == MOUSE_MODE_COMMAND 10:41:30 && button == 1) { command_type c = click_travel(gc, force, false); if (c != CMD_NO_CMD) { clear_messages(); process_command(c); } return CK_MOUSE_CMD; } 10:41:50 <02Monkooky> this crash is from an assert stopping you from basically taking multiple turns at once, right? 10:42:01 <03implojin> the assert is doing that, yes 10:44:04 <04dracoomega> (I'd been unable to reproduce the issue locally, even hammering on the mouse and keyboard like a madwoman. Presumably you might actually need network lag ^^; ) 10:44:25 <04dracoomega> But it seems we know the root of the problem regardless 10:45:42 <11Odds> If it’s hard to fix, would it be better to return it to the previous state where this bug exists but doesn’t crash games? 10:45:44 <03implojin> i also tried a game on CDI mashing mouseclicks and keyboard input and couldn't get it to trigger, presumably it needs network latency 10:47:42 <03implojin> the refactoring of movement.cc was good and long-needed, restoring that code isn't something i'd want to see happen 10:48:17 <03implojin> this has just revealed another underlying mouse event bug 10:48:43 <02Monkooky> I somewhat suspect you need to set up a macro to intentionally do this 10:49:20 <02Monkooky> and that it's nigh impossible to trigger without doing so 10:49:51 <11Odds> Ah yes I was assuming that removing this assert left things as broken as before. Not suggesting reverting more than that 10:57:26 <04dracoomega> Yeah, like... I guess it depends on plausible timeframe to fix this. Allowing theoretical race conditions to exist isn't great, but given that the effects of this were nearly invisible to players before but now are causing crashes, I'm a little uncomfortable with just letting people with bad internet connections crash for the indefinite future. 10:58:40 <03implojin> am greatly amused by the possibility that clicking faster to do more damage has apparently always been a thing 11:00:05 <04dracoomega> At least it does seem impractical for most people 11:00:27 <03implojin> i don't think i can physically move my fingers fast enough to trigger this 11:00:32 <11Odds> rushes off to write a game-breaking macro 11:01:01 <11Odds> Oh wait that’s just a game-crashing macro now 11:01:03 <02Monkooky> I'm really not sure this is bad internet connections 11:02:39 <11Odds> Might be worth checking out the rc file of a serial crasher? 11:04:24 <03implojin> djonin has an empty rcfile and empty macros 11:07:30 <02Monkooky> For one thing, I think bad internet connections should not be making packets arrive in chunks; though I can't really be confident at all about that since I'm hardly an expert and I don't know if crawl has special handling for networking shittiness besides for another, if it was bad internet I think we'd be seeing a lot more players crashing 11:08:23 <11Odds> Bad internet plus an unusual use of controls could be quite rare though? 11:14:44 <03implojin> hmm 11:16:04 <03implojin> do we need this ASSERT(!you.turn_is_over); in move_player_action? what if we just returned early there 11:19:42 <03implojin> (recognizing that it would be preferable to fix the underlying mouse event issues but that doing so might take some time) 11:20:22 <08o____0> managed to trigger it with an autoclicker at 20ms delay, connecting a server far away (cnc) and just sort of waving the mouse around while autoclicking 11:21:07 <08o____0> I don't think an in-game macro would work 😅 11:26:47 <04dracoomega> Yeah, I realized I initially added it when refactoring in response to comments saying "What are we setting you.turn_is_over to false here? Shouldn't it always already be false?" and being like "Well, if I'm taking out this stuff, let's just make sure it is actually correct." And it turns out it sometimes wasn't, though for reasons very unlike any of the code that talked about this. 11:27:34 <04dracoomega> But just returning early seems like a harmless way of handling it for now (probably with a comment saying why this can happen) 11:27:44 <04dracoomega> Like, this is presumably not the only command that can be triggered incorrectly by mouse >.> 11:28:15 <04dracoomega> Even if it's the single most common command in the game, I assume 11:30:18 <03implojin> We've had issues before where failing to set turn_is_over in that function would allow for infinite move/attack chains (ec2d92a32 at least) so refusing to process the move if the turn is over seems correct to me 11:30:26 <04dracoomega> Yeah 11:30:49 <03implojin> also yes there are other issues with mouse commands from looking at that, i think 11:31:12 <03implojin> greatly alarmed by this comment 11:31:16 <03implojin> // TODO: add a control message type that can send arbitrary commands // (possibly just as a string, like the lua API for this) 11:31:19 <03implojin> (please no) 11:37:29 03DracoOmega02 07* 0.34-a0-1281-g028126efb3: Temporarily change an assert to a no-op (various) 10(71 seconds ago, 1 file, 7+ 1-) 13https://github.com/crawl/crawl/commit/028126efb311 11:37:29 03DracoOmega02 07* 0.34-a0-1282-gfdd75ac4f6: Fix inverted logic 10(34 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/fdd75ac4f655 11:38:05 <04dracoomega> The problem of making changes so trivial that you don't bother to test them >.> 11:38:05 <04dracoomega> <.< 11:38:35 <08o____0> (oh actually don't even need to connect to a server far away to trigger it with 20ms autoclicker. It works on my machine just fine) 11:38:53 <04dracoomega> (Imagining nightmare scenarios of some slow-build server getting the first commit and players being literally unable to move for a day) 11:42:28 <04dracoomega> Now: back to coding new ways for players to have mushrooms on their head 11:42:29 <08nicolae> that will teach them respect. the devs giveth and the devs taketh away 11:42:36 <08nicolae> siiiiiiiiiiiiiiiick 12:08:40 One master branch commit to Stoat Soup had an uninitialised value bug such that _in Webtiles_ you'd starve to death after taking the first move. In console (presumably uninitialised memory tended to turn out zero because it's doing less?), never saw it. So it was like that for three days and we didn't know. :-/ 12:08:51 ... after that I started testing in Webtiles too 12:09:49 <04dracoomega> Ouch 12:11:25 Eh, after that debacle I wrote https://crawl.montres.org.uk/wsl-webtiles.txt 12:11:47 which I gather has been some help to vanilla too so as ever we progress by shooting ourselves in the foot 12:11:59 Pokonic1 (L4 TrSh) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:3) 12:17:16 <09hellmonk> finally, a good food clock 12:17:18 <03implojin> i think i've triggered a rebuild on cbr2 12:17:39 <03implojin> (is it normal for this page to look like it's loading indefinitely? -.-) 12:18:13 <04dracoomega> Yes 12:18:13 <04dracoomega> Alas 12:18:37 <04dracoomega> In fact, sometimes it needs nudging again to actually finish, I think 12:18:48 <04dracoomega> (Eventually) 12:19:02 Pokonic1 (L8 TrSh) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:5) 12:20:05 Pokonic1 (L8 TrSh) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:6) 12:39:37 ComradeHaspi (L3 ReMo) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:1) 12:45:04 it's waiting for the server to respond that it finished; sometimes that times out and you need to hit it again (which will see the first one still running and wait for that) 12:45:15 silly 1990s era web services 12:48:55 <09gammafunk> it worked at least a little better when we doing things via reverse proxies all the time 12:49:24 <09gammafunk> telling a CGI script to just have unbuffered output so the client won't timeout seems to work not so great when a proxy is in between 12:49:40 <09gammafunk> sorry, when we weren't doing things via reverse proxies 13:05:54 starib (L8 MDMo) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (D:6) 13:34:08 Pokonic1 (L8 TrSh) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (Bailey) 13:34:57 Pokonic1 (L9 TrSh) ASSERT(!you.turn_is_over) in 'movement.cc' at line 937 failed. (Bailey) 13:36:27 hellmonk: oof! 13:48:00 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1282-gfdd75ac4f6 (34) 13:49:27 New branch created: pull/4914 (1 commit) 13https://github.com/crawl/crawl/pull/4914 13:49:27 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4914 * 0.34-a0-1266-ge1c2e0cd13: Change solo tentacles only to attack targets in our LoS 10(7 minutes ago, 1 file, 8+ 0-) 13https://github.com/crawl/crawl/commit/e1c2e0cd1325 14:16:54 <11Odds> ^ Here be tentacles. 14:28:49 <09hellmonk> is there a deep technical reason we compile check for NUM_FEATURES <= 256 and is this likely to be a problem in the future? 14:28:54 <09hellmonk> asking 4 myself 14:33:02 my butt says it's save compat (that is, tags.cc seems to marshal/unmarshal as a byte) 14:34:25 <04dracoomega> I presume this is something that can be changed without too much trouble, though 14:34:41 if you can figure out a way to maintain save compat, sure 14:34:44 <04dracoomega> (Just need to look over the data structures involved) 14:35:07 <09hellmonk> alright, that's what I thought 14:35:21 <04dracoomega> I actually have no idea how close we are to the limit right now 14:35:27 <04dracoomega> Probably close-ish? 14:35:32 it's less the data strutures than how tags.cc saves stuff to/loads stuff from the file; it doesn't just blat structs to it afaict 14:35:48 <09hellmonk> yeah, I wasn't going to count because the file is full of tag majors and double definitions 14:36:23 <04dracoomega> geekosaur: It's more that I meant I'd want to double-check that no other places also rely on this assumption in some way. 14:37:15 I did a quick grep, everything else seems to use the #define. there are places that do assume a special meaning for NUM_FEATURES itself, but they all seem to use the #define so they should be okay 14:37:32 probably a fuller check would be needed though 14:37:37 crawlcode being what it is 14:37:53 <04dracoomega> Yeah, I suspect it's fine, but one never knows 14:37:55 but I think it's mostly just how it's marshaled 14:38:18 meatstix (L16 FoHu) ASSERT(in_bounds(newpos)) in 'player.cc' at line 584 failed. (newpos = (79,53)) (Spider:1) 14:38:36 <04dracoomega> Incidentally, it looks like we currently have 219 features actually defined 14:38:50 meatstix (L16 FoHu) ASSERT(in_bounds(newpos)) in 'player.cc' at line 584 failed. (newpos = (70,69)) (Spider:1) 14:39:35 <04dracoomega> Oh boy 14:39:45 <09hellmonk> ruh roh 14:40:06 but watch out for non-fixed things (the tags.cc code tracks transporters as part of marshaling, for example) 14:40:13 <04dracoomega> Well, at least that's an easy bug to fix 14:40:15 <11Odds> Digging shenanigans? 14:40:27 <04dracoomega> (Formicid digging isn't checking for the level border) 14:40:46 <04dracoomega> So as long as there's seemingly-diggable rock there, they can move into it (and crash) 14:41:02 <09hellmonk> luckily I am not worried about savecompat yet 14:41:41 <04dracoomega> But one of the nice things about freshly-refactored functions is that even if there are bugs, it's usually much easier to figure out where a fix is supposed to go ^^; 14:45:25 03DracoOmega02 07* 0.34-a0-1283-gfb7a264d33: Fix formicids being able to dig into the level border (and then crash) 10(13 seconds ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/fb7a264d3319 14:49:25 <09hellmonk> yet another formicid nerf 14:49:57 <03implojin> every day we stray further from dwants 14:50:48 dwon'ts? 14:59:39 <06dolorous_84348> Some people prefer to focus on dneeds. 🙂 15:09:41 <09hellmonk> dwuncles coming soon 16:06:07 Hey, not a dcss dev, but wanted to start contributing, so I'm here to look at some PRs and generally idle. Hope that's ok etc. 16:14:10 -!- russ0r is now known as russ0r|BNC 16:14:37 -!- russ0r|BNC is now known as russ0r 16:14:58 -!- russ0r is now known as russ0r|BNC 16:15:06 -!- russ0r|BNC is now known as REISUB 16:15:12 -!- REISUB is now known as REISUB|BNC 16:15:20 -!- REISUB|BNC is now known as russ0r 16:38:14 -!- REISUB is now known as russ0r 16:38:25 Unstable branch on underhound.eu updated to: 0.34-a0-1283-gfb7a264d33 (34) 16:42:40 fwiw hanging out here isn't problem, arguing with the devs can be especially if you have no experience with the dcss codebase (and/or you haven't read https://crawl.develz.org/wiki/doku.php?id=dcss:planning:wont_do) 16:44:29 the dokuwiki's also a good starting place in general, even if it's a bit sparse 16:45:47 <06dolorous_84348> Although that document's a bit out of date (there is dual-wielding now, but it's limited to exactly one species and won't be expanded beyond that). 16:47:38 gyre and gimble… 16:48:25 were sequell online, there's entries for implemented and unimplemented "bad ideas" 16:49:20 <09hellmonk> tbh I would not even worry about arguing with devs too much, it isn't like we all agree with each other on every point. I would frame it more as, if you are intending to do a big gameplay change pr then ask first to see if it's something that is likely to be accepted. 16:49:56 (or that someone else is already working on looks at dracoomega) 16:50:24 <09hellmonk> and if you want to contribute without having to care about game balance or mechanics or whatever, then consider trying some bugfixes while you familiarize yourself with the code base. 16:50:36 <09hellmonk> as there is usually a long list of minor bugs nobody's gotten to yet 16:52:03 fwiw, while I'm not a dev (mostly I triage server game crashes when nobody else is around; I have enough on my plate already) I taught myself how to add a monster some versions back by implementing one. not that I expected it to be accepted or even made the code available anywhere but my dropbox for a while 16:52:34 (it's gone now; things have changed a lot since then, including that much of the manual fiddling is now data-ified) 16:54:09 <09hellmonk> yeah, just trying out implementing things is also good learning experience and there's nothing wrong with coding for yourself. I think we have some guides for implementing various game features like species and backgrounds, though they might be out of date. 16:54:48 <08o____0> ( https://github.com/crawl/crawl/wiki/Won't-Do-(2024) <- a more modern won't do btw) 16:54:59 <09hellmonk> looking up commits on github for the most recently implemented (whatever feature type you're working on) can also be a good way to figure out what that would entail 17:13:48 Don't worry, I've had to review enough massive PRs out of nowhere at work so I know what it's like. I'm mostly here because I've loved the game for years and I want to scrub up on my C++. Thanks for the pointers, will read the docs. 17:14:08 Where's the Discord channel? I can't see it in the roguelikes server 17:15:12 <03implojin> the dev discord is private because nobody wants to deal with the moderation issues that opening it would bring, community members who contribute tend to get invited eventually 17:29:36 GeeHouse (L12 TrWn) Crash caused by signal #6: Aborted (Gauntlet) 17:29:59 Presten (L19 HuWz) Crash caused by signal #6: Aborted (Orc:2) 18:27:23 fair enough 18:39:51 sasquatch (L17 FoBr) ASSERT(in_bounds(newpos)) in 'player.cc' at line 584 failed. (newpos = (32,69)) (Snake:4) 20:49:32 <07wizardike> You need a slow server so that pending mouse commands build up while waiting for the previous command to complete. I faked this by adding a sleep(1000) call to process_command 20:59:08 <07wizardike> We are attempting to store features in 8 bits in map_cell with the following line dungeon_feature_type _feat:8; (this doesn't actually work because bitfield packing is silly) and of cause the stuff in tags.cc that other people have already pointed out. 21:07:43 good evening. is there anyone i can speak to about getting a password reset sent to my accounts email? i couldnt find a link on https://crawl.dcss.io/ to reset my password. thank you 21:16:05 @gammafunk ^^ 21:23:59 <09gammafunk> code13: If you send me (see the email address listed on the crawl.dcss.io lobby) an email from the email account on file with your username, I can reset it 21:27:20 nice, sent 21:31:16 much appreciated! cheers 21:35:07 <09gammafunk> no problem 22:56:41 -!- daethoven137180 is now known as daethoven13718 23:35:45 Unstable branch on crawl.develz.org updated to: 0.34-a0-1283-gfb7a264d33 (34) 23:59:07 Windows builds of master branch on crawl.develz.org updated to: 0.34-a0-1283-gfb7a264d33