00:13:27 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1804-g99c0725460 (34) 04:33:12 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:10:06 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-1804-g99c0725 (34) 13:20:13 bronco (L17 MiBe) ASSERT(!monster_at(newpos) || (flags & MV_ALLOW_OVERLAP) || fedhas_passthrough(monster_at(newpos)) || mons_is_wrath_avatar(*monster_at(newpos))) in 'player.cc' at line 655 failed. (Snake:3) 13:21:34 <09g​ammafunk> interesting crash 13:41:09 <04d​racoomega> Oh, shit, I forgot to fix that after seeing it the other day 13:41:49 <04d​racoomega> (When the player is trampling, it isn't aborting if a monster has been created on their destination by the time it tries to move them. A very simple fix, and it just slipped my mind) 17:42:24 <06m​umra> I had a fairly deep look into all that triggerable stuff when there was that Lua error with that bat vault a few weeks back if you recall. There definitely seemed to be a number of strange things with how these markers behaved. It feels like the new behaviour you describe is actually what I was expecting looking at the way things were written, and I was confused that they didn't. Is sounds like maybe now for each application of the 17:42:24 marker there is a new closure being generated, not that each execution of the closure is getting a fresh scope. 17:43:18 <06m​umra> Which is now consistent with what would happen if you exited and re-entered the level causing all markers to be serialized and deserialized, at which point you'd have a new instance of each rather than a magically shared instance 18:28:27 <09g​ammafunk> hrm, then it sounds like having a marker value be a closure is just a bad idea? 18:33:09 <09g​ammafunk> I guess now that I think of it, I'm not actually 100% clear what happens to these markers when unserialized on an already generated level. For the vault placements on an unserialized level, when it's loaded does the map's main lua chunk from cache get run...but then I guess the marker values can only be what was unserialized from save, which isn't going to be able to connect from some lua value in the main chunk 18:34:37 <09g​ammafunk> but one thing to note is that upvalue for the closure did have a correct initial value (which was true) 18:36:19 <09g​ammafunk> hrm, but that's also talking about level placement, not unserializing from save 18:37:49 <09g​ammafunk> right, that sychronized_marker() code is clearly just not being run at all when unserializing a placed level from a save. It's all the finalized marker results at that point, and it's unserializing however that particular does that 18:38:00 <09g​ammafunk> sorry, I'm sort of rambling, but I think I understand a bit better 19:03:20 <09g​ammafunk> @mumra follow up, is your theory that the following line in hellmonk_volcano_collapse is being run for each instance of M (e.g. making a new closure each time)? lua lua_marker("M", Triggerable.synchronized_markers(collapse_marker)) If so, that's not what's happening. If I use the following diff: diff diff --git a/crawl-ref/source/dat/dlua/lm_trig.lua b/crawl-ref/source/dat/dlua/lm_trig.lua index 17461163cb..19253da30d 100644 --- 19:03:20 a/crawl-ref/source/dat/dlua/lm_trig.lua +++ b/crawl-ref/source/dat/dlua/lm_trig.lua @@ -395,11 +395,15 @@ end Triggerable.primary_initialized = {} function Triggerable.synchronized_markers(primary) local replica_id = lmark.next_replica_id() + crawl.mpr("Triggerable.synchronized_markers; replica id: " .. replica_id) Triggerable.primary_initialized[replica_id] = false return function () + crawl.mpr("closure; replica id: " .. 19:03:21 replica_id) if Triggerable.primary_initialized[replica_id] then + crawl.mpr("Making replica") return Triggerable.make_replica(replica_id) else + crawl.mpr("Making primary") Triggerable.primary_initialized[replica_id] = true return Triggerable.make_primary(primary, replica_id) end I get the following when placing the map in the volcano: 19:03:21 Triggerable.synchronized_markers; replica id: marker_replica0 Closure; replica id: marker_replica0; Making primary Closure; replica id: marker_replica0; Making replica Closure; replica id: marker_replica0; Making replica Closure; replica id: marker_replica0; Making replica Closure; replica id: marker_replica0; Making replica Closure; replica id: marker_replica0; Making replica Closure; replica id: marker_replica0; Making replica Closure; replica 19:03:22 id: marker_replica0; Making replica 19:04:00 <09g​ammafunk> if a new closure were being made each time, that replica id would not be shared among the markers (since that ID is created each time when creating the closure 19:06:14 <06m​umra> hmm 19:06:33 <06m​umra> sure, you'd also expect to see "Triggerable.synchronized_markers; replica id: marker_replica0" repeated multiple times if my theory were true 19:06:45 <09g​ammafunk> I'm not sure if you're aware how the function lua_marker(m, k, v) takes the value vand stores it in a lua_datum() if it's a function or a table. That datum turns into a lua ligh userdata where the lua_datum pointer is the (unique) key that is used to save the value v in the lua registry 19:06:56 <09g​ammafunk> which can then be pulled when actually creating a map placement on the actual level 19:07:27 <09g​ammafunk> hence it can pull some arbitrary thing from lua since, on the lua side, it's saved in the special lua registry (not the stack, a different special thing in lua for C functions) 19:07:51 <09g​ammafunk> and it's all keyed in the registry that lua_datum instance so it can repeatedly pull this lua value lua-side from the registry 19:08:11 <06m​umra> that definitely seems to confirm there was a scope issue with that local (altho it looks like you potentially fixed that by moving it to the primary_initialized table?) 19:08:31 <09g​ammafunk> yeah I just moved it to a global :yogidaFeels: 19:08:45 <09g​ammafunk> because I could not understand the behaviour of modifying that first upvalue 19:09:10 <06m​umra> it seems potentially problematic and could come up again in some other context 19:09:12 <09g​ammafunk> for the replic id thing, that doesn't need modification in the closure 19:09:25 <09g​ammafunk> right, I am planning to do some debugging with lua itself to try to figure out what's happening 19:09:49 <09g​ammafunk> 5.2 changed things so that C functions and lua userdata (i.e. full userdata, not light) don't have environments of their own 19:09:53 <09g​ammafunk> like lua functions do 19:10:19 <09g​ammafunk> and I'm wondering if this is related to that change somehow, since the marker class itself is indeed a lua userdata 19:11:24 <09g​ammafunk> for now I'm just diagnosing actual bugs related to 5.4 that I know of, and the only other thing I actually no of is the crash upon re-entry to the main menu bug 19:11:50 <09g​ammafunk> and I think that's because we're really not re-initializing dlua like we should be, and it's probably easy to fix, but I want to understand specifically what's happening before I make some fix 19:12:36 <09g​ammafunk> so I'm becoming cautiously optimistic about the move to lua 5.4, but there's still a bit of concerning behavior