03:33:02 <Lantell> Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5208-geafff8c3b6
04:39:15 <Discord|> <02t​zer0> Hey, getting some crashes on a character here, can someone take a look? https://underhound.eu/crawl/morgue/NikiYani/crash-NikiYani-20240819-113635.txt
04:54:40 <Discord|> <06m​umra> > ERROR in 'tags.cc' at line 3823: Timer 0 next trigger in the past [1067200 < 1067210]  Hmm that really probably shouldn't happen
05:11:53 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.32-a0-2155-g8ac6e39 (34)
09:37:01 <NotCheibriados> New branch created: pull/3986 (1 commit) 13https://github.com/crawl/crawl/pull/3986
09:37:02 <NotCheibriados> 03Sean Dewar02 07https://github.com/crawl/crawl/pull/3986 * 0.32-a0-2156-g3b00e038ab: Fix stash search prefixes for golden dragon scales 10(33 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/3b00e038ab55
09:53:06 <NotCheibriados> 03Sean Dewar02 {PleasingFungus} 07* 0.32-a0-2156-ge547df2160: Fix stash search prefixes for golden dragon scales 10(49 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/e547df21609a
09:54:42 <Discord|> <04d​racoomega> That timer crash is really weird. I've never seen anything like it before, and as near as I can tell, all the code that sets timers has been unchanged in over a decade.
09:55:16 <Discord|> <04d​racoomega> Timer 0 is the corpse rot timer, and unlike most of those, isn't even randomized. It should be scheduled each time for 20 turns into the future.
09:55:25 <Discord|> <06p​leasingfungus> hypothesis: god of time travel (added in 0.35) has time traveled back into 0.32
09:55:50 <Discord|> <04d​racoomega> I mean, the crashlog is from 0.31, but again, nothing here seems to have changed in over a decade
09:56:41 <Discord|> <06p​leasingfungus> that's exactly why the problem must come from the future
09:57:08 <Discord|> <06p​leasingfungus> sorry, i can stop posting nonsense until/unless i actually have time to look into the problem
09:57:59 <Discord|> <04d​racoomega> ...wait, wait, wait
09:59:57 <Discord|> <04d​racoomega> Oh, nevermind. It looked for a moment like the timers weren't ever being unmarshalled, but only recreated on load, but actually it's just that the code to load timers and the code to fill in timers beyond the number of ones loaded, are about 500 lines apart in the same function
10:00:19 <Discord|> <06p​leasingfungus> well, tags.cc is very small and easy to read
10:00:23 <Discord|> <04d​racoomega> Hahahaha
10:00:26 <Discord|> <04d​racoomega> T.T
10:10:34 <Discord|> <04d​racoomega> The character's god is Chei, and I am wondering if there's some slim possibility that Step From Time may have been involved (but the crash happens on load, so we don't even get the recent log)
10:12:02 <Discord|> <04d​racoomega> But I will investigate to see if it seems possible somehow to skip applying timers on any turn where total aut increases, since I'm not sure I see another way to 'pass' a timer's time without triggering it
10:13:04 <Discord|> <04d​racoomega> No, that seems to be working normally
10:15:11 <Discord|> <04d​racoomega> Funnily enough, while this mismatch is preventing the save from loading, I don't believe it would actually cause a visible problem in-game.
10:16:08 <Discord|> <04d​racoomega> The timer would just be processed the next time that timers are processed, since it always expects you.elapsed_time to be greater or equal to the timer at that time
10:17:15 <Discord|> <04d​racoomega> (In fact, the corpse rot timer is the only one that even cares about the delta, and it only rots corpses, so even if somehow the timer was 100,000 turns in the past, it woud still trigger just once and move on)
10:18:00 <Discord|> <04d​racoomega> Oh, wait, that's not 100% true, I suppose. Since the next timer is scheduled based on the last timer, not the current time
10:19:01 <Discord|> <04d​racoomega> Anyway, this timer is so close to correct-seeming that I doubt it was buggily loaded. It feels more like somehow the save happened before the handle_time() call that would have dealt with the just-reached timer.
10:22:11 <Discord|> <04d​racoomega> I am not sure I can do much with this without the save file. (I am not sure I can do much even with it). Rendering the save unloadable under these circumstances feels very unfortunate, though =/
10:24:59 <Discord|> <04d​racoomega> I realize some of the point of these 'crash on load' checks is to make the existence of ways to create buggy data more obvious to devs, but I have very mixed feelings about bugs that could be readily fixable in the load code causing save files to become unopperable. The load code already fills in arbitrary values for missing timers. It could easily nudge a timer from the past to a near-future time and just print a warning. (I
10:25:00 <Discord|> realize devs get notified of warnings less often than outright crashes, but this causes a very bad situation for players when we can't find a fix in a timely manner)
10:25:40 <Discord|> <06p​leasingfungus> pretty classic dynamic
10:25:46 <Discord|> <06p​leasingfungus> better for devs, worse for players
10:25:58 <Discord|> <06p​leasingfungus> wrt stricter error handling
10:26:20 <Discord|> <04d​racoomega> Yeah. Like, some load errors leave things in too garbled a state to recover from, but this would be easy.
10:29:15 <Discord|> <04d​racoomega> (And this is a game that's 106k turns in)
10:52:40 <Discord|> <07z​ureal> Today I learned you can die this way:  Jigsaw the Conjurer (L6 GnCj), killed by miscasting Iskenderun's Mystic Blast on D:4, with 360 points after 3408 turns and 0:05:47. [cbr2+]
10:53:07 <NotCheibriados> 03DracoOmega02 07* 0.32-a0-2157-gcf733dc7dc: Fix swoop/flank attacks missing some of the proper checks (Ogregutan) 10(2 minutes ago, 1 file, 6+ 1-) 13https://github.com/crawl/crawl/commit/cf733dc7dc13
10:58:19 <Discord|> <04d​racoomega> Is it possible to get a copy of this save file? I'm not sure I will be able to make any further progress on deducing the cause of this bug without it.
11:09:19 <Discord|> <06m​umra> Doesn't get_foe() already imply that the defender is not aligned?
11:12:34 <Discord|> <04d​racoomega> It... might? But similar actions checked that, and I mostly copied what checks were missing from flanking that were present for, say, reaching
11:13:34 <Discord|> <04d​racoomega> (get_foe() will return nullptr instead of the player for MHITYOU, avoiding by far the most common case of a 'foe' that is not a foe, but it doesn't otherwise check that a monster's foe is not an allied monster)
11:14:19 <Discord|> <04d​racoomega> Thus it may be possible in some situations (charming a monster that was its foe?) to have a non-aligne monster foe?
11:15:25 <Discord|> <04d​racoomega> (I do think this check is rarely relevant, and I'm not completely sure it ever matters, but since I'm not completely confident it couldn't matter, and it was present elsewhere, I decided to include it)
11:17:01 <Discord|> <06m​umra> I think if it is relevant, there are dozens of places in the code that should also implement the same check
11:17:37 <Discord|> <06m​umra> So maybe that check should be in get_foe and return nullptr in that case
11:18:35 <Discord|> <04d​racoomega> That might make sense. I'd have to check that there aren't places that sometimes rely on the fact that it maybe can return a friendly monster
11:18:52 <Discord|> <06m​umra> In fact, we sort of want something to check for this and reassign the foe
11:18:58 <Discord|> <04d​racoomega> (As I said, there already are checks for this in multiple other places)
11:19:05 <Discord|> <06m​umra> In cases where a foe has changed alignment and is no longer valid
11:19:19 <Discord|> <04d​racoomega> Such a check may exist, for all I know. Monster behavior code is really complicated.
11:19:33 <Discord|> <04d​racoomega> And I was just cautiously emulated a related function's formatting
11:19:55 <Discord|> <04d​racoomega> Since it couldn't hurt to be a little paranoid
11:20:59 <Discord|> <04d​racoomega> (I do agree in general that it's nicer not to have to be paranoid. After a certain point, it becomes hard to know what function calls were necessary an which weren't. But while I'm willing to put a review of all this on a list for the future, I wouldn't want to do that kind of general refactoring post-feature-freeze, since it seems quite possible to cause subtle bugs by it)
11:24:24 <Discord|> <06m​umra> Yeah it potentially has a lot of ramifications
11:25:00 <Discord|> <06m​umra> But certainly searching for get_foe in the codebase, most places it's used there is then an assumption it is a valid target
15:14:21 <NotCheibriados> New branch created: pull/3987 (1 commit) 13https://github.com/crawl/crawl/pull/3987
15:14:21 <NotCheibriados> 03Medrano8302 07https://github.com/crawl/crawl/pull/3987 * 0.32-a0-2158-g0d815068ca: Fix Android build on armeabi-v7a 10(24 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/0d815068caa0
15:19:44 <NotCheibriados> 03Medrano8302 07* 0.32-a0-2158-g751def610d: Fix Android build on armeabi-v7a 10(29 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/751def610d97
15:39:09 <Lantell> Unstable branch on underhound.eu updated to: 0.32-a0-2157-gcf733dc7dc (34)
15:40:01 <NotCheibriados> New branch created: pull/3988 (1 commit) 13https://github.com/crawl/crawl/pull/3988
15:40:01 <NotCheibriados> 03Medrano8302 07https://github.com/crawl/crawl/pull/3988 * 0.32-a0-2159-ge22c7f6d4e: Android: Add an option to the launcher to hide the status bar 10(2 hours ago, 5 files, 76+ 1-) 13https://github.com/crawl/crawl/commit/e22c7f6d4e8d
15:41:09 <NotCheibriados> 03DracoOmega02 07* 0.32-a0-2159-g3d2af943be: Update removed_spells list 10(15 minutes ago, 2 files, 26+ 22-) 13https://github.com/crawl/crawl/commit/3d2af943be02
15:41:09 <NotCheibriados> 03DracoOmega02 07* 0.32-a0-2160-g1eb867fef6: Hopefully finally make player ghosts stop trying to cast Gell's Gravitas 10(13 minutes ago, 1 file, 3+ 1-) 13https://github.com/crawl/crawl/commit/1eb867fef6d3
15:41:09 <NotCheibriados> 03DracoOmega02 07* 0.32-a0-2161-g8f3c08acc0: Show some fprops in the local tiles tile tooltip 10(11 minutes ago, 1 file, 30+ 0-) 13https://github.com/crawl/crawl/commit/8f3c08acc094
15:41:09 <NotCheibriados> 03DracoOmega02 07* 0.32-a0-2162-gfda3adbe32: Allow no_tele_into tags (and some others) to actually work for subvaults 10(2 minutes ago, 1 file, 10+ 0-) 13https://github.com/crawl/crawl/commit/fda3adbe3254
15:43:43 <Discord|> <02t​zer0> https://underhound.eu/crawl/meta/NikiYani.cs
15:44:26 <Discord|> <04d​racoomega> Thanks!
16:13:26 <Discord|> <06m​umra> It occurs to me the cleanest way to handle gravitas would be to actually remove the spell and add a new SPELL_GRAVITAMBOURINE for the evoker
16:14:32 <Discord|> <06m​umra> Then the special case doesn't have to exist basically forever
16:16:45 <Discord|> <04d​racoomega> Yeah, that occurred to me when I was writing that, but that would mean even more save compat code elsewhere to- wait, actually it specifically wouldn't in this case, would it? Since it's not a memorizable player spell.
16:17:11 <Discord|> <04d​racoomega> (Which would involve save compat code, just elsewhere)
16:17:34 <Discord|> <04d​racoomega> (Alternately, we actually regenerate the bone store >.>; )
16:17:36 <Discord|> <06m​umra> Exactly i had the same train of thought
16:18:02 <Discord|> <06m​umra> The evoker will just trigger whatever spell it's coded to
16:31:00 <Henzell> angelslayer (L25 CoCK) Crash caused by signal #11: Segmentation fault (Zot:4)
16:31:43 <Discord|> <04d​racoomega> Looking at that save file with the timer bug, I am somewhat more baffled. They've missed triggering multiple times somehow (and some by as many as 147 aut), but there's no indication in the log or anywhere else that anything unusual happened.
16:31:52 <geekosaur> !crashlog angelslayer
16:31:53 <Sequell> 2. angelslayer, XL25 CoCK, T:44160 (milestone): http://crawl.akrasiac.org/rawdata/angelslayer/crash-angelslayer-20240819-233059.txt
16:36:42 <geekosaur> place_monster_corpse has a 50% chance of returning NULL
16:37:19 <geekosaur> which _xom_wave_of_despair doesn't check for
16:38:51 <geekosaur> oh wait, it forces it
16:39:00 <Discord|> <06r​egret-⸸nde※> It's passing a true value for the force argument, which should avoid that coinflip?
16:41:24 <geekosaur> right, now I'm trying to figure out why it's returning nullptr anyway
16:49:34 <Discord|> <04d​racoomega> Yeah, I really have no idea. The timers all look like they have sensible values for their previous and next scheduled trigger time, and they're all in the broad vacinity of the current time. It doesn't look like garbage data or anything. But this would also require somehow at least 147 aut passing without world_reacts() being called, which sounds impossible in a general sense and I can see nothing out of the ordinary that might
16:49:34 <Discord|> explain it
17:08:00 <Discord|> <04d​racoomega> I don't like shrugging at an unloadable save file, but I'm not sure how to investigate further. (And even if I did replace the 'crash on load' with 'print an error, but then fix up timers on load', that is a non-trunk save file, so they wouldn't even be able to upgrade it)
17:11:28 <Discord|> <02M​onkooky> Which one are we lookin at right now?
17:11:45 <Discord|> <02M​onkooky> I've not been keeping up with the conversation but I've got some time to take a look
17:11:53 <Discord|> <02M​onkooky> maybe I get lucky and stumble on a solution
17:25:10 <Discord|> <04d​racoomega> Crashlog here: https://discord.com/channels/735056636644687913/747522859361894521/1275056483284811796 Save file here: https://discord.com/channels/735056636644687913/747522859361894521/1275223704111939685  The immediate cause of the crash is obvious, but it's extremely non-obvious how the data got that way in the first place, and I don't have any theories after spending quite a while looking at related code and examining other things
17:25:11 <Discord|> from the save file itself.
17:25:23 <Discord|> <04d​racoomega> And by 'we', I'm pretty sure it's just me
17:25:38 <Discord|> <04d​racoomega> Though the corpse one might be easier ^^;
17:25:55 <Discord|> <04d​racoomega> (I hadn't looked at that yet, and am pretty spent after all the hours it took to fix other things today)
17:33:08 <Discord|> <02M​onkooky> oh wow this could be comin from anywhere
17:34:11 <Discord|> <02M​onkooky> hm actually there's not a ton of places that set timer-effects
17:34:23 <Discord|> <04d​racoomega> There is basically exactly one place, during the game itself
17:34:42 <Discord|> <04d​racoomega> And the place that sets timers is also the one that processes them, and is called after basically any amount of time passes for any reason
17:35:38 <Discord|> <04d​racoomega> Since the timers all look like they have sensible values, it doesn't seem like it was obviously garbage data that got in them somehow, which suggests that somehow a whole lot of turns passed without world_reacts() being called and I don't see how that is possible
17:39:09 <Discord|> <02M​onkooky> What do you use to inspect the save file
17:40:28 <Discord|> <04d​racoomega> I mean, I just turned the actual assert into a warning, so the file would load, and added some diagnostic output for the timers. Otherwise, it was just looking at the long and the character's stuff in-game. There isn't like a tool to examine a save file directly
17:41:13 <Discord|> <02M​onkooky> gotcha
17:41:47 <geekosaur> well, you can extract chunks and iirc gammafunk has some stuff to examine certain specific chunks (like the one containing "you")
17:42:58 <Discord|> <04d​racoomega> Either way, this save file isn't actually fucked up in a way that would prevent loading
17:43:08 <Discord|> <04d​racoomega> Aside from the game specifically electing to stop when it sees the timer is off
17:43:36 <Discord|> <04d​racoomega> (Which, as I said earlier, I'm not convinced should be a fatal load error, since it's extremely recoverable from)
17:44:49 <Discord|> <04d​racoomega> It may be indicative of a bug somewhere, but on principle I don't really like ruining a player's game when we could just... not >.>;
17:49:25 <Discord|> <02M​onkooky> what actually is next_timer_effect tracking
17:50:08 <Discord|> <04d​racoomega> A variety of things. See timed_effects[] in tmed-effects.cc
17:50:30 <Discord|> <04d​racoomega> Corpse decay, god actions (wrath and other things), abyss stuff, evolution mutation
17:50:44 <Discord|> <04d​racoomega> Used to be more (a bunch of them have been removed), but still many common things
17:50:46 <Discord|> <02M​onkooky> sure, sorry, what is the role of next_timer_effect in this
17:51:03 <Discord|> <04d​racoomega> That is the timestamp for when that type of timer should fire again
17:51:09 <Discord|> <04d​racoomega> Since they're randomized a bit
17:51:14 <Discord|> <02M​onkooky> ok gotcha
17:51:19 <Discord|> <04d​racoomega> Timer fires, then a new time is set for the next time it should fire
17:51:30 <Discord|> <04d​racoomega> And somehow this save file skipped like 147 aut past one without actually firing it
17:52:39 <Discord|> <02M​onkooky> so ARRAYSZ(timed_effects) should be the same as ARRAYSZ(next_timed_effect)
17:53:10 <geekosaur> hm, it occurs to me that some past timer issues have involved a user's ready() lua?
17:53:34 <Discord|> <04d​racoomega> Oh boy
17:53:48 <Discord|> <04d​racoomega> Maybe we need to see the user's .rc too? >.>
17:55:39 <geekosaur> (this "time passes without anything firing" is tickling a vague memory)
17:59:57 <Discord|> <04d​racoomega> https://underhound.eu/crawl/rcfiles/crawl-0.31/NikiYani.rc  Seems vanilla to me.
18:00:36 <geekosaur> yeh, that can't be involved, nothing but comments
18:02:28 <NotCheibriados> 03Lexi Hattaway02 07https://github.com/crawl/crawl/pull/3984 * 0.32-a0-2135-g9b1b3561c7: fixed whitespace issues 10(38 seconds ago, 3 files, 33+ 35-) 13https://github.com/crawl/crawl/commit/9b1b3561c77f
18:05:14 <Discord|> <02M​onkooky> what's gonna be the first thing that runs
18:37:04 <Discord|> <02M​onkooky> is this, for some reason, arena?
18:37:09 <Discord|> <02M​onkooky> that can't be right
18:38:55 <NotCheibriados> 03dolorous02 07* 0.32-a0-2163-ga8b5e4c4fa: Move Beogh resurrection invo icon to UNUSED. 10(5 minutes ago, 1 file, 0+ 0-) 13https://github.com/crawl/crawl/commit/a8b5e4c4fa3d
19:18:10 <Discord|> <02M​onkooky> So my current theory for how this came about is somehow saving between time progressing and handle_time getting called
19:22:19 <Discord|> <02M​onkooky> hm wait no if you're telling me we're 147 auts past the next_timer_effect then that's out
19:32:21 <Discord|> <02M​onkooky> Also, the only things that occur between elapsed time incrementing and timed effects being handled are random spawns, abyss map rot, and contam over time- none of which seem likely to be triggering a save here
19:44:46 <Discord|> <04d​racoomega> Yeah, if it was a tiny gap, I could imagine somehow a crash or similar happening right before timers were about to be dealt with, but that doesn't seem possible for so large a one
19:45:06 <Discord|> <04d​racoomega> Different timers were overdue for different lengths of time, but one of them was a whole 147 aut, yes
20:13:39 <Henzell> lockbuilder (L9 FeSh) Crash caused by signal #11: Segmentation fault (D:8)
20:18:24 <geekosaur> !crashlog lockbuilder
20:18:25 <Sequell> 1. lockbuilder, XL9 FeSh, T:4956 (milestone): http://crawl.akrasiac.org/rawdata/lockbuilder/crash-lockbuilder-20240820-031338.txt
20:19:53 <geekosaur> MutationMenu::update_muts??
21:00:20 <Discord|> <02M​onkooky> a segfault could theoretically be completely unrelated to the code it crashed at
21:06:21 <Discord|> <04d​racoomega> No, I actually know what the issue there is, I think
21:07:22 <Discord|> <04d​racoomega> A situation I didn't think to account for with the future mutation list. Felid that hasn't gotten their second fur upgrade yet, but has mutated the same mutation randomly
21:07:41 <Discord|> <04d​racoomega> So the game sees that they're due to get another level of fur and thinks that must mean it's fur 4
21:07:49 <Discord|> <04d​racoomega> (Which doesn't exist)
21:08:10 <geekosaur> fur shame!
21:09:36 <Discord|> <04d​racoomega> I'm not going to get to it tonight, but I've put it on the list
21:09:48 * geekosaur knows that one
22:35:34 <Gretell> Unstable branch on crawl.develz.org updated to: 0.32-a0-2163-ga8b5e4c4fa (34)
22:57:38 <NotCheibriados> 03dolorous02 07* 0.32-a0-2164-gdab2e85f15: Fix Xom ring msgs for macabre finger necklace. 10(25 minutes ago, 1 file, 26+ 2-) 13https://github.com/crawl/crawl/commit/dab2e85f15b9
22:58:51 <Gretell> Windows builds of master branch on crawl.develz.org updated to: 0.32-a0-2163-ga8b5e4c4fa
23:34:02 <Cbrotell> Unstable branch on cbro.berotato.org updated to: 0.32-a0-2164-gdab2e85f15 (34)
23:55:32 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.32-a0-2164-gdab2e85f15