02:06:02 -!- illusion is now known as Guest92349 03:00:38 -!- Kramin42 is now known as Kramin 03:41:25 -!- amalloy is now known as amalloy_ 12:26:58 SpartanLlama (L16 TrNe) ERROR in 'mon-movetarget.cc' at line 115: ZotDef: monster oklob plant failed to pathfind to (39,43) (the Orb) (Zot (ZotDef)) 12:27:17 SpartanLlama (L16 TrNe) ERROR in 'mon-movetarget.cc' at line 115: ZotDef: monster oklob plant failed to pathfind to (39,43) (the Orb) (Zot (ZotDef)) 12:31:59 wooeeeh, instead of spending the morning powering over webtiles code, i was fixing a broken grub entry 12:32:15 ...and it's still broken, but that's my issue 12:32:31 gammafunk: anywhere in particular in the webtiles code i should be looking to finalize that drac hat issue? 12:52:30 <|amethyst> espais: on the client side it is webserver/game_data/static/cell_renderer.js, but 12:52:30 |amethyst: You have 1 message. Use !messages to read it. 12:52:38 <|amethyst> espais: I think the relevant logic is actually in the C++ side 12:53:02 oh 12:53:04 I had a fix! 12:53:09 and I forgot to finish testing 12:53:19 <|amethyst> espais: if you look in tileweb.cc, you will find that _send_doll looks very very familiar :) 12:53:22 it's just a simple ordering 12:53:31 now I may lost commit credit! 12:53:40 yeah it's just that ordering of the array 12:53:43 it needs to match 12:53:50 espais: I'll fix that in your PR 12:54:24 and no one let neil fix it, someone tie him down with dimension anchor! 12:54:27 or a web trap, or shaft him to beam.cc! 12:54:52 <|amethyst> gammafunk: fine, I'm making you responsible for eliminating the code duplication between pack_doll_buf and _send_doll 12:55:02 uh oh 12:55:24 he's attacked me with his af_do_actual_work attack 12:55:27 I may be doomed 12:55:44 hm 12:56:37 this does look rather duplicated 12:57:17 <|amethyst> I think probably you could just make it take a function/lambda that does the part that is different 12:57:18 wow it's completely duplicated isn't it 12:58:33 <|amethyst> everything up to tiles.json_open_array("doll"); is the same, or should be 12:58:45 <|amethyst> hm 12:58:53 <|amethyst> maybe it makes more sense to pull that part into a new function 12:59:13 <|amethyst> that fills in or returns the flags array 12:59:38 Scarf in shop does not become auto-identified when previous scarf found of same type. 13https://crawl.develz.org/mantis/view.php?id=11230 by stoneychips 12:59:40 <|amethyst> tilep_calc_doll_flags or such 13:01:23 |amethyst: that seems similar to the naming of tilep_calc_flags(), which is also focused on filling in flags for dolls, no? 13:01:47 <|amethyst> oh, that one is entirely about dolls, isn't it? 13:02:07 yeah, it takes a doll argument and a flags array 13:02:12 <|amethyst> ah 13:02:21 <|amethyst> but doesn't do anything with the order 13:02:23 right 13:02:35 tilep_calc_doll_order ? 13:02:39 <|amethyst> oh hey 13:02:41 <|amethyst> guess hat 13:02:42 <|amethyst> what 13:02:47 <|amethyst> PlayerMenuEntry::get_tiles 13:02:54 <|amethyst> look at that code 13:03:07 <|amethyst> and SaveMenuItem::_pack_doll 13:03:25 hah 13:03:30 ho boy 13:03:35 <|amethyst> honestly I think the code can just be folded into tilep_calc_flags 13:03:45 <|amethyst> give it one extra argument for p_order 13:03:57 // FIXME: A lot of code duplication from DungeonRegion::pack_doll(). 13:04:22 <|amethyst> that function isn't named that anymore of course :) 13:04:27 nice 13:04:51 <|amethyst> I think that is pack_doll_buf 13:05:17 well, that's going to take more work to clean up all of that 13:05:39 <|amethyst> for the time being, probably apply the same fix to those other two copies 13:05:50 yeah, maybe that's the easy way for now 13:06:03 <|amethyst> tick... tick... tick... 13:06:14 <|amethyst> (that's the code base about to explode) 13:06:32 tease. it's been doing that for how long now? 13:06:54 <|amethyst> 11 or 20 years, depending on what you count as "the code base" 13:07:53 it will happen during the conversion to C++30 13:08:14 I am assuming 4.1's demise is related >.> 13:08:26 (crawl: wolf-rayet software?) 13:11:15 |amethyst: any reason why SaveMenuItem should have this totally different ordering that it does? 13:11:18 for the doll order 13:11:33 not talking about the drac head, but like hands have a different order 13:11:38 maybe it just wasn't kept up to date? 13:11:44 I assume that's just the doll for the save browser 13:11:49 <|amethyst> that would be my guess 13:11:58 ok 13:16:01 Praised be Sif, derpy dracs have come to webtiles https://cdn.discordapp.com/attachments/205316046230388737/359749362731057152/unknown.png 13:16:54 <|amethyst> FR: Scumbag Steve doll hat tile 13:32:14 fr: paper bag tile 13:33:08 today's actually the 11th birthday of stone soup, isn't it 13:33:15 counting from its first announcement 13:38:21 <|amethyst> oh, hey, that is today! 13:42:52 03gammafunk02 07* 0.21-a0-275-g1afbe6a: Fix player doll order in menus and better document code duplication 10(22 minutes ago, 2 files, 7+ 6-) 13https://github.com/crawl/crawl/commit/1afbe6ae7ad7 13:42:52 03efredericks02 {gammafunk} 07* 0.21-a0-276-gff8b496: Fixed issue where draconian hat was not shown when equipped 10(23 hours ago, 2 files, 3+ 3-) 13https://github.com/crawl/crawl/commit/ff8b496fd2a2 13:42:52 03gammafunk02 07* 0.21-a0-277-geaec956: Fix Draconian hat tiles to display properly in WebTiles and in menus 10(21 minutes ago, 2 files, 3+ 3-) 13https://github.com/crawl/crawl/commit/eaec95604f6f 13:43:13 🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂🎂 13:43:51 the hats are retroactively party hats 13:44:05 !tell espais That should hopefully do it for fixing drac hat tiles everywhere, thanks! 13:44:06 gammafunk: OK, I'll let espais know. 13:52:14 retroactive party hats put on a hell of a show in '02 at the bronco bowl in ft worth 14:09:15 Unstable branch on crawl.jorgrun.rocks updated to: 0.21-a0-277-geaec956 (34) 15:12:21 Medar: Do you have the 0.20 default RC set to disable the vault listing in the dump_order ? 15:12:33 !log monsterracer 15:12:34 1157. Monsterracer, XL4 FeCj, T:4189: http://crawl.xtahua.com/crawl/morgue/Monsterracer/morgue-Monsterracer-20170919-184652.txt 15:12:42 doesn't seem to have it, it's 0.20.1 15:12:48 and their RC doesn't change dump_order 15:13:14 don't think there should be any special default rc 15:13:57 yeah, seems that cxc games are not seeing the vault table 15:14:31 aha 15:14:33 I see 15:14:38 we only have that enabled in alpha, sorry 15:14:41 not a cxc thing 15:14:52 hooray 16:06:26 -!- amalloy_ is now known as amalloy 17:06:32 -!- erkin is now known as MiGR0S1911 17:15:33 -!- MiGR0S1911 is now known as erkin 17:18:51 -!- amalloy is now known as amalloy_ 18:02:05 Unstable branch on underhound.eu updated to: 0.21-a0-277-geaec956 (34) 19:46:04 -!- amalloy_ is now known as amalloy 20:50:47 so here's an obscure question 20:50:58 does anyone know why formatted_string::parse_string_to_multiple doesn't trim the strings it produces? 20:52:06 parse_string_to_multiple has literally never been discussed in irc before now 20:56:02 this is one of those 10yo questions, so there may be no answer 21:09:48 oh, nevermind, that doesn't even matter 21:10:06 i guess the obvious answer is a question: why should it trim them? 21:13:16 it seems like trimming would help a tiny bit in the most common use case, but it doesn't seem so fundamental to the operation that it should be built-in; you might want to do the line-splitting without the trimming for some reason, and it's easy to trim the result of the function 21:14:01 why would you want to do line splitting without trimming? 21:14:19 but in any case, that wasn't the problem I'm trying to find (it just has exactly the same behavior as the problem) 21:22:47 -!- amalloy is now known as amalloy_ 22:11:14 -!- amalloy_ is now known as amalloy 22:15:38 03advil02 07* 0.21-a0-278-ga722497: Don't use the entire string when iterating over the result of a split 10(7 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/a722497ad32a 23:09:15 Unstable branch on crawl.jorgrun.rocks updated to: 0.21-a0-278-ga722497 (34) 23:59:39 Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-278-ga722497 (34)