00:14:11 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1134-ge1e2a20661 (34) 00:55:41 Monster database of master branch on crawl.develz.org updated to: 0.34-a0-1134-ge1e2a20661 01:35:45 03Zhang Haocheng02 07https://github.com/crawl/crawl/pull/4891 * 0.34-a0-1087-g8894bff4d3: Consider corrosion in some descriptions 10(18 hours ago, 8 files, 44+ 43-) 13https://github.com/crawl/crawl/commit/8894bff4d39a 01:35:45 03Zhang Haocheng02 07https://github.com/crawl/crawl/pull/4891 * 0.34-a0-1088-g3122c47c73: Fix spacing 10(3 minutes ago, 1 file, 4+ 4-) 13https://github.com/crawl/crawl/commit/3122c47c73ee 01:58:56 -!- indigaz22 is now known as indigaz2 04:18:08 <06mumra> I have been digging into some of this last week in fact, in particular the duplicated code. There is a lot of unused code as well. Basically there was a "new improved" version of the layout system and the intent was for V to use the new functions instead, with a whole bunch of other new layouts as well, but much of this was never finished. At the time, my life changed significantly when I moved to London and started full time paid dev 04:18:09 work, and this fell to the wayside. Certainly there's a chunk of stuff here that should probably have never have been pushed to master 🙂 04:29:57 <06mumra> I think for this particular error under the assumption was that the array length is based on the index of the last element (so removing earlier indexes won't actually shorten the array), it should work fine, as it's just remembering the index from the table to avoid having to loop through the table to find what we want. Obviously there's some unexpected interaction going on somewhere. I'll have a closer look. It might be that just 04:29:58 checking if it's present before trying to remove it would fix the error, but probably there's some underlying reason why that's happening if it's trying to remove them twice, which it doesn't seem like it should. 04:31:31 <06mumra> Hmm yeah in v_rooms the way the eligibles array is being accessed also assumes it's a continuous array of elements, which is odd. 04:32:32 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:09:14 03dolorous02 07* 0.34-a0-1135-g7d0d760c15: Fix comment typo. 10(21 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/7d0d760c1583 05:09:14 03dolorous02 07* 0.34-a0-1136-gbbcba9398f: Mark transformed protean talismans as seen. 10(11 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/bbcba9398f99 05:10:23 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-1134-ge1e2a20 (34) 05:29:39 03dolorous02 07https://github.com/crawl/crawl/pull/4884 * 0.34-a0-1137-g43b256d874: Adjust description of the book of Transmutation. 10(2 days ago, 1 file, 5+ 3-) 13https://github.com/crawl/crawl/commit/43b256d87429 05:47:55 03dolorous02 07https://github.com/crawl/crawl/pull/4884 * 0.34-a0-1137-gf5cb05fa33: Adjust description of the book of Transmutation. 10(2 days ago, 1 file, 5+ 3-) 13https://github.com/crawl/crawl/commit/f5cb05fa3308 06:46:28 <09gammafunk> But table.remove() does shorten the array, both in 5.1 and 5.4. Here's the 5.1 doc: > table.remove (table [, pos]) > Removes from table the element at position pos, shifting down other elements to close the space, if necessary. Returns the value of the removed element. The default value for pos is n, where n is the length of the table, so that a call table.remove(t) removes the last element of table t. 06:48:18 <09gammafunk> and this is what I see in a 5.1 interpreter 07:55:14 Lemonice (L14 FeFw) ASSERT(!invalid_monster(mon_act)) in 'state.cc' at line 450 failed. (Orc:2) 08:05:08 03dolorous02 07* 0.34-a0-1137-gea88c4b8bb: Adjust description of the book of Transmutation. 10(2 days ago, 1 file, 5+ 3-) 13https://github.com/crawl/crawl/commit/ea88c4b8bb2d 08:32:23 <06mumra> Yeah so that seems to be the cause of the bug, as once an element has been removed the stored indices for other elements will now be wrong 08:33:42 <06mumra> I don't know if a key based on x,y coord works as you can have more than eligibility per cell 08:35:25 <06mumra> we could remove the element by looping through the table to find its position and don't even try to store the index, it's a bit slow but probably not that bad 08:36:52 <06mumra> and otherwise (if we used say a stable key as you suggest) we'd have to looping through the whole table every time we wanted to pick a random element as we wouldn't know its length 09:16:59 <09gammafunk> I think you may be misunderstanding lua tables a bit? They are inherently associative arrays that utilizes arbitrary keys as indexes. Integer indexing is just a special mode a table can use. So if you use e.g. an Integer hash value as a key in a table, you add elements by assignment and remove them by assigning a value of nil for that key value in that table. The actual values in the table can of course be tables themselves, just as 09:16:59 you're doing. You just don't use table.remove and use nil assignment instead 09:59:43 <06mumra> No I think you misunderstand what I'm saying. The way that eligibles is used is we want to pick a single eligible spot at random 09:59:59 <06mumra> For this we need to pick a random element from the table 10:00:24 <06mumra> The way the Lua # function works to calculate the length of a table only works with integer-indexed tables 10:00:57 <06mumra> https://www.tutorialspoint.com/lua/lua_table_length.htm 10:58:30 <09gammafunk> Yeah, that's fine. So you want to randomly compose as coordinate (within bounds) and use that to index your table. You shouldn't need to reference the number of keys in the table at all to do this 10:59:21 <09gammafunk> Basically don't use the table size operator because you're not using the table as an array here 11:02:11 <09gammafunk> If you like, store in a separate array table a list of all keys of eligible cells etc. Then you could randomly index and iterate and delete from that. And the elements encode an index into your associative table of position keys 11:03:14 <09gammafunk> The keys are just hashes of coordinates here. Sounds like we're probably on the same page, but let me know if you have any remaining issues 11:03:33 <06mumra> No you're still not understanding 🙂 11:03:50 <06mumra> We have a list of eligible coordinates. We're picking from that list. We're not picking just a random x,y coordinate 11:04:17 <06mumra> It's a big vector of coordinates which are potentially eligible to have a vault connected adjacent 11:04:42 <06mumra> Ok right i see 11:05:17 <06mumra> But i still need to pick a random element from that table by knowing its length 11:05:26 <06mumra> And remove the element once it's been picked 11:05:38 <09gammafunk> Yeah thats fine 11:05:49 <09gammafunk> You don't use its indices 11:05:55 <09gammafunk> Just its values 11:07:30 <06mumra> It still requires iterating a table tho so it doesn't seem any better than maintaining the existing table structure, and just iterating through to delete the target element when needed, so I'm just not using the index at all 11:07:55 <06mumra> Which is what I was attempting to describe 11:09:21 <06mumra> Iterating once for a deletion is probably better than iterating potentially multiple times for random picking (as the selected point might not be a suitable place for the specific vault we're trying to place, so we have to pick multiple times until we find a coord that works) 13:04:21 03RypoFalem02 {Implojin} 07* 0.34-a0-1138-gb9efe5695e: art: Make exclusions more readable 10(4 days ago, 2 files, 0+ 0-) 13https://github.com/crawl/crawl/commit/b9efe5695e7c 13:09:47 <09gammafunk> I don't understand why your needing to randomly choose an element from this separate array of position hashes means that you need to iterate a table at all. You have two tables, one indexed by a hash of coordinates pairs (i.e. every distinct pair of x,y values is turned into a distinct integer used as a key). This table has your per-cell data table as values with the coordinate hash of the cell as a key. It can't be accessed as an 13:09:48 array. But the second table is simply an array of these coodinate hashes that you add to as you add entries into the first table. Then, when you need to test a random candidate, you select a random index in the second table (using its table size operator; it's just an array). The value at this index is a coordinate pair hash that you use to index the first table to get its cell data. If this candidate cell passes and you want to delete it to prevent 13:09:48 future selection, you table.remove() that index in the second array you just randomly selected. Possibly also delete cell table at the coordinate hash in the first table if that's relevant. 13:10:14 <09gammafunk> But at some point rather than trying to describe this, it might be better to just see your proposed change 14:52:54 03dolorous02 07* 0.34-a0-1139-g0f358fb7c0: Fix a Crazy Yiuf quote. 10(3 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/0f358fb7c04b 15:58:57 -!- meatpath1 is now known as meatpath 16:40:14 Unstable branch on underhound.eu updated to: 0.34-a0-1139-g0f358fb7c0 (34) 19:57:36 New branch created: pull/4894 (1 commit) 13https://github.com/crawl/crawl/pull/4894 19:57:37 03WizardIke02 07https://github.com/crawl/crawl/pull/4894 * 0.34-a0-1133-g57eb02cec6: Show actual feature tile flavour in more menus 10(15 minutes ago, 9 files, 316+ 320-) 13https://github.com/crawl/crawl/commit/57eb02cec660 20:00:52 03WizardIke02 07https://github.com/crawl/crawl/pull/4894 * 0.34-a0-1133-g05ef6ec6b5: Show actual feature tile flavour in more menus 10(18 minutes ago, 9 files, 316+ 320-) 13https://github.com/crawl/crawl/commit/05ef6ec6b5a3 20:01:58 03WizardIke02 07* 0.34-a0-1140-g72e09e7ad3: Fix felids receiving attacks while dead 10(3 days ago, 17 files, 47+ 33-) 13https://github.com/crawl/crawl/commit/72e09e7ad306 23:35:34 Unstable branch on crawl.develz.org updated to: 0.34-a0-1140-g72e09e7ad3 (34) 23:58:52 Windows builds of master branch on crawl.develz.org updated to: 0.34-a0-1140-g72e09e7ad3