00:13:40 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1656-g07c986e9b8 (34) 04:31:49 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:10:55 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-1656-g07c986e (34) 08:02:10 <09g​ammafunk> I've seen that random empty save crash as well and will add it to my list 08:02:23 <09g​ammafunk> but if anyone else wants to look into it first, please feel free 08:04:02 <09g​ammafunk> I think your crash is the same as this issue so probably no need to create a new one 08:25:51 <06d​olorous_84348> Thanks for the info. 16:40:57 Unstable branch on underhound.eu updated to: 0.34-a0-1656-g07c986e9b8 (34) 19:37:52 <09g​ammafunk> ugggggaaa 19:38:13 <09g​ammafunk> guess what's the cause of this crypt (and possibly also the volcano) lua errorrrrrrs 19:39:14 <09g​ammafunk> finding a "trap_sarcophagus" map marker with its corresponding special value of 1 19:40:04 <09g​ammafunk> from dlua in wizmode: > y = dgn.find_marker_positions_by_prop("trap_sarcophagus", 1) > crawl.mpr(#y) 0 no matches 19:40:11 <09g​ammafunk> I check the marker directly by position 19:41:01 <09g​ammafunk> and get 19:43:09 <09g​ammafunk> > m = dgn.marker_at_pos(37, 50) > crawl.mpr(m:property("trap_sarcophagus")) 1.0 19:43:50 <09g​ammafunk> sure enough, when I do: > y = dgn.find_marker_positions_by_prop("trap_sarcophagus", 1.0) > crawl.mpr(#y) 10 ...it finds all 10 of them... 19:44:28 <09h​ellmonk> uh oh 19:45:31 <09g​ammafunk> it raises an interesting question of where the designation of int vs number should be happening 19:45:42 <09g​ammafunk> it's simply specified as 1 in the vault's lua 19:45:59 <09g​ammafunk> and interestingly it seems somehow seed specific, this error; in my local testing, the vault always worked 19:46:31 <09g​ammafunk> but it fails in this seed because the 1 is becoming a number (despite lua normally making the conversion internally) 19:46:48 <04d​racoomega> Seed-specific, whether a number gets cast or not?? 19:46:52 <09g​ammafunk> so maybe we have a forced conversion happening somewhere in the api or even maybe in the marker lua 19:47:04 <09g​ammafunk> yeah, can you test this on your machine DO? I can't replicate with a random seed 19:47:24 <04d​racoomega> Sure, I can. What do you need me to do? 19:47:26 <09g​ammafunk> the vault is grunt_crypt_arrival_guarded_gate 19:47:37 <09g​ammafunk> if I manually place on crypt:1 it works with no lua error 19:47:54 <04d​racoomega> Okay, gimme a sec to compile an up to date master 19:48:03 <09g​ammafunk> and then you can try (HEAD of trunk) with seed 12013585808020364378 and you should see the error 19:48:28 <04d​racoomega> Okay, well, my first problem is that master doesn't compile 19:48:29 <09g​ammafunk> placing the vault in wizmode &P is obv different from generating naturally in a game, but unclear how that could affect conversion 19:48:34 <09g​ammafunk> rip 19:48:50 <04d​racoomega> error: ‘luaL_setfuncs’ was not declared in this scope; did you mean ‘lua_setfenv’? and so forth 19:49:44 <09g​ammafunk> weird, it's compiling for me 19:49:48 <09g​ammafunk> oh 19:49:50 <09g​ammafunk> your submodule 19:49:56 <09g​ammafunk> is probably in need of git submodule update 19:50:08 <09g​ammafunk> like if you have a local branch that's on lua 5.1? 19:50:24 <09g​ammafunk> not sure if you're working off something pre lua 5.4 and you switched off that, for example 19:50:57 <09g​ammafunk> but yeah try git submodule update from the crawl repo (not the contrib repo) and see if it checks out a different submodule commit 19:51:41 <04d​racoomega> Updating submodules was the first thing I did (it did not help) 19:52:26 <09g​ammafunk> luaL_setfuncs is a liblua function that's new in 5.4 iirc 19:52:37 <04d​racoomega> Oh, make clean might be doing it? 19:53:32 <04d​racoomega> Ah, this creates a number of INSTALL directives that seem lua-related. Maybe it just didn't get the memo anything there needed updating 19:54:45 <09g​ammafunk> our make file is so weird; when you run make clean....it builds the tilegen tool 19:55:09 <04d​racoomega> Haha, what? 19:55:16 <09g​ammafunk> yeah, read the top of the output of make clean 19:55:22 <04d​racoomega> (Anyway, it builds fine now) 19:55:26 <04d​racoomega> Thankfully 19:55:36 if you're on ubuntu and have liblua5.1-dev installed, try installing liblua5.4-dev 19:56:20 <09g​ammafunk> right, I'm building off said lua5.4-dev package, and you're probably building off contrib 19:56:41 <09g​ammafunk> (top of make clean's output) $ make clean make -C rltiles all ARCH=x86_64-linux-gnu NO_PKGCONFIG= TILES= make[1]: Entering directory '/home/gammafunk/Games/dcss/crawl-dev/crawl-ref/source/rltiles' * rebuilding tilegen: new build flags or prefix HOSTCXX tool/tile_colour.o HOSTCXX tool/tile.o HOSTCXX tool/tile_page.o HOSTCXX tool/tile_list_processor.o HOSTCXX tool/main.o HOSTLINK tool/tilegen.elf GEN 19:56:41 tiledef-main.h GEN tiledef-dngn.h GEN tiledef-floor.h GEN tiledef-wall.h GEN tiledef-feat.h GEN tiledef-player.h GEN tiledef-gui.h GEN tiledef-icons.h make[1]: Leaving directory '/home/gammafunk/Games/dcss/crawl-dev/crawl-ref/source/rltiles' ... 19:56:49 <04d​racoomega> Huh. grunt_crypt_arrival_guarded_gate placed without error once, then I exited and reentered the floor a couple times to see if it had to do with marshalling/unmarshalling. It also seemed fine. Then I placed it again and it crashed. 19:57:16 <04d​racoomega> ERROR in 'files.cc' at line 2211: Builder failure while generating 'Crypt:1'! Last builder error: 'Crypt:1: Vault placement failure for 'grunt_crypt_arrival_guarded_gate'. attempt to index a nil value' 19:58:10 <04d​racoomega> (When I reload that save, I am on Crypt:1 and an entire different layout is there, with no obvious vault) 19:58:20 <09g​ammafunk> I have noticed, even before lua 5.4, that maps with marker/triggers sometime crash with repeated wizmode placement, although I think that happens not as much with some fixes advil made a few years back 19:58:32 re `make clean`, yeh, it's done that for years. I think all top level make rules just build rltiles first 19:58:49 probably because pretty much every other top level target requires it 19:58:55 <09g​ammafunk> but yeah that seed I pasted above, that probably does error for you? 19:59:02 <09g​ammafunk> 12013585808020364378 19:59:09 <09g​ammafunk> if you generate that seed and warp to crypt:1 19:59:12 <09g​ammafunk> I'll bet you see the lua errors 19:59:23 <04d​racoomega> Okay, I placed it a whole lot more times and it worked fine and then it crashed with ASSERT(layout) in 'dungeon.cc' at line 4707 failed. >.> 19:59:30 <04d​racoomega> Er, not on that seed yet. One sec. 20:00:12 <09g​ammafunk> maybe I should mess with repeat placement then to see if that's related to 5.4 (although I suspect it's something deeper, as I've said &P is crash-prone on complicated marker maps IME) 20:00:31 <04d​racoomega> Using that seed, immediately going to Crypt:1, and placing the vault, also works fine 20:00:41 <09g​ammafunk> wait, placing the vault? 20:00:47 <09g​ammafunk> it should be part of the seed, no need to place it 20:01:04 <04d​racoomega> Oh, huh. Let me try again 20:01:20 <09g​ammafunk> you'll see a bunch of sarcophagi 20:01:27 <09g​ammafunk> you have to walk through the door and trigger it 20:01:41 <09g​ammafunk> actually I think the error happens without walking through the door to trigger 20:02:02 <09g​ammafunk> it just errors as its a per-turn trigger? I need to refresh my memory there 20:02:10 <04d​racoomega> Trying the seed again, that vault is not on my Crypt:1 20:03:13 <09g​ammafunk> hrm, just generated it again and it is for me 20:04:23 <04d​racoomega> Hrmm 20:04:29 <09g​ammafunk> original morgue: https://crawl.dcss.io/crawl/morgue/tswn/morgue-tswn-20251208-042605.txt 20:05:07 <09g​ammafunk> well, that's another mystery I guess, but now I need to see what exactly is causing this conversion, I guess 20:05:33 <09g​ammafunk> or I suppose what in our code is unable to see that 1.0 is equal to 1, for that matter 20:06:12 <09g​ammafunk> because lua thinks 1.0 == 1 so this technically shouldn't matter 20:06:46 <09g​ammafunk> ...ug 20:06:59 <09g​ammafunk> cpp vector find_marker_positions_by_prop(const string &prop, const string &expected, unsigned maxresults) { vector marker_positions; for (rectangle_iterator i(0, 0); i; ++i) { const string value = env.markers.property_at(*i, MAT_ANY, prop); if (!value.empty() && (expected.empty() || value == 20:06:59 expected)) 20:07:01 <09g​ammafunk> lovely 20:07:01 <04d​racoomega> Huh. Got a ERROR in 'ng-setup.cc' at line 669: Builder failure while trying to generate temple! when trying to make that seeded run again. Upon restart, the game said there was an empty save file under that character's name 20:07:13 <09g​ammafunk> yes, this is another 5.4 related bug 20:07:34 <09g​ammafunk> starting a new game in a current session will sometimes crash and generate an empty save 20:07:48 <09g​ammafunk> seems to only be happening offline unless DGL is smark about this 20:08:28 <09g​ammafunk> (but yeah the reason why the number conversion is breaking is because our marker property value code wants everything to be a string) 20:08:46 <09g​ammafunk> which of course people are using dummy values like 1 because the value doesn't really matter 20:09:01 <04d​racoomega> Huh 20:09:19 <04d​racoomega> (I'm going to take a look at the vault list in that morgue and my own game, to see if there's some obvious point they diverge) 20:09:41 <09g​ammafunk> yes, it is concerning if there's seed instability (for some platforms/systems) 20:10:17 <09g​ammafunk> the fact that this value was stored as...oh this is probably just our marker marshalling code, isn't it 20:10:37 <09g​ammafunk> it's probably unconditionally unmarshalling as a lua number 20:12:14 <09g​ammafunk> which seems fixable, although I don't know why it would ever work, based on my understanding. will need to investigate more tomorrow and push a fix, but this is a strong enough lead on the problem for now. hopefully the volcano crash is related to this 20:15:33 <04d​racoomega> Okay, so they seem to diverge on Vault:4. Interestingly, the vaults on those floors are heavily overlapping, but non-identical. (Then everything after that is understandably quite divergent. This list for the morgue you linked is: nicolae_vaults_apartment_1, nicolae_vaults_big_angled_halls, v_misc_18, v_pattern_4, nicolae_vaults_tetromino_T_1, nicolae_vaults_variations_on_themes, nicolae_vaults_bisected_inception, 20:15:34 hangedman_vaults_impose, v_misc_22, hangedman_vaults_stagger, nicolae_vaults_three_branches, nicolae_vaults_frosty_reception, nicolae_vaults_house_3, nicolae_vaults_little_squares_5, layout_vaults_omnibox and my V:4 instead has nicolae_vaults_apartment_1, nicolae_vaults_big_angled_halls, v_misc_18, v_pattern_4, nicolae_vaults_tetromino_T_1, nicolae_vaults_variations_on_themes, nicolae_vaults_bisected_inception, hangedman_vaults_impose, v_misc_22, 20:15:34 hangedman_vaults_stagger, nicolae_vaults_diamond_1, nicolae_vaults_oval_intersection, v_misc_15, hangedman_vaults_maws, nicolae_vaults_rhombus_6, layout_vaults_omnibox, serial_shops, nicolae_diamond_shop, parchment_shop 20:16:08 <09g​ammafunk> so, one thing we do have to check is that the original game didn't upgrade 20:16:37 <09g​ammafunk> or rather we should probably compare to my local game...I guess since I did see the crypt:1 vault we can assume that V:4 is the divergence point 20:16:42 <04d​racoomega> Oh, right, it did 20:17:00 <09g​ammafunk> my local game never upgraded, of course 20:17:08 <04d​racoomega> Though, in Depths:3, so that should be irrelevant 20:17:15 <04d​racoomega> That's after those levels are generated 20:17:20 <09g​ammafunk> well twice in lair, too 20:17:25 <04d​racoomega> Oh, missed that 20:17:47 <09g​ammafunk> I can pastebin my morgue for comparison, but I think you're right about the divergence point 20:18:15 <09g​ammafunk> [+gen,-vis] Vaults:4: nicolae_vaults_apartment_1, nicolae_vaults_big_angled_halls, v_misc_18, v_pattern_4, nicolae_vaults_tetromino_T_1, nicolae_vaults_variations_on_themes, nicolae_vaults_bisected_inception, hangedman_vaults_impose, v_misc_22, hangedman_vaults_stagger, nicolae_vaults_diamond_1, 20:18:16 nicolae_vaults_oval_intersection, v_misc_15, hangedman_vaults_maws, layout_vaults_omnibox, serial_shops, nicolae_shop_peninsula, parchment_shop, uniq_nameless_revenant 20:18:50 <09g​ammafunk> I guess I have a few extra vaults? 20:20:11 <09g​ammafunk> actually I see there's divergence in my set vs his set 20:21:02 <04d​racoomega> Yeah, all 3 of these are like... at least 50% the same, and then the rest are all different 20:21:15 <04d​racoomega> Which is really quite odd behavior 20:21:45 <04d​racoomega> Some specific thing partway through the generation process must not be seed stable, and then all bets are off whenever that is hit 20:21:50 <09g​ammafunk> https://pastebin.com/Pdij4gFd 20:21:58 <09g​ammafunk> is my vault list for that local game 20:25:03 <04d​racoomega> Interesting that your Crypt:1 and tswn's are almost the same and mine isn't. (Though yours is still not 100% identical to their) (Mine was [+gen,+vis] Crypt:1: layout_gridlike, nicolae_crypt_gravecubes, roderic_lattice_octagonal_star, uniq_josephina 20:25:13 <04d​racoomega> Everything before V:4 was identical between us, though 20:27:52 <09g​ammafunk> I'll be not shocked if I learn that compilation differences between my liblua5.4-dev package and the lua contrib are the cause 20:28:33 <09g​ammafunk> which might mean we need to tweak build arguments, or it could again be related to some incautious marshalling of numbers 20:28:35 <04d​racoomega> Which would the servers be likely to be using, though? 20:28:47 <09g​ammafunk> contrib, yeah, good point 20:28:50 <09g​ammafunk> cdi is contrib for sure 20:29:08 <09g​ammafunk> we have divergence between you, me, and cdi I guess 20:29:10 <04d​racoomega> So then if my game disagrees with CDI, it's probably not that 20:29:42 <04d​racoomega> (This is all very frown-inducing) 20:29:55 <09g​ammafunk> what can happen of course is that improper handling of lua numbers leads to a veto because some layout's math doesn't work 20:30:00 <09g​ammafunk> that earlier bug we saw 20:31:10 <09g​ammafunk> and vaults layouts are certainly very elaborate in some unique ways. in any case, I'll have to investigate that some more, but my first priority is to fix the marker marshalling the right way 20:31:17 <04d​racoomega> Yes, perhaps we can keep our fingers crossed that solving the 'known' issues will incidentally fix the more mysterious ones as a side-effect. 20:32:30 <09g​ammafunk> in the worst case we certainly CAN revert back to lua 5.1; we can't do it in the simplest "squashed revert commit" way in that we will need to introduce a new minor version to invalidate des cache 20:33:08 <09g​ammafunk> but I don't think we're really there yet and I'd prefer to spend some more time fixing the issues. But if it gets totally overwhelming, well then there's no choice I guess 20:33:26 <09g​ammafunk> if advil had more time to assist, that'd be great, but he's [retired] 😫 20:34:43 <04d​racoomega> Yeah, so long as there are known angles of attack for dealing with some of these issues, it seems premature to assume the undertaking should be rolled back 20:52:03 <04d​racoomega> Meanwhile, I am trying to squash and clean up the new brands branch, which has quite a messy history by this point. A couple brands were added before a meaningful refactor, but had some mechanical changes after the refactor, and it's a bit fiddly getting that all straightened out.