00:22:49 <Cbrotell> Unstable branch on cbro.berotato.org updated to: 0.33-a0-541-g8bf3021b3d (34)
00:55:21 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.33-a0-541-g8bf3021b3d
03:14:49 <NotCheibriados> 03DracoOmega02 07* 0.33-a0-542-gf8f82a2dde: Fix Searing Ray crashing when cast 10(61 seconds ago, 1 file, 6+ 3-) 13https://github.com/crawl/crawl/commit/f8f82a2dde9e
04:33:41 <Lantell> Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5249-g4a8afe7061
04:59:36 <Cbrotell> Triskal (L8 CoCj) Crash caused by signal #11: Segmentation fault (D:7)
05:00:04 <Cbrotell> Triskal (L8 CoCj) Crash caused by signal #11: Segmentation fault (D:7)
05:29:58 <Cbrotell> Triskal (L8 CoCj) Crash caused by signal #11: Segmentation fault (D:7)
05:30:21 <Cbrotell> Triskal (L8 CoCj) Crash caused by signal #11: Segmentation fault (D:7)
05:33:58 <Cbrotell> Triskal (L2 SpCj) Crash caused by signal #11: Segmentation fault (D:1)
06:32:54 <Cbrotell> particleface (L3 DgCj) Crash caused by signal #11: Segmentation fault (D:3)
06:33:48 <Cbrotell> particleface (L3 DgCj) Crash caused by signal #11: Segmentation fault (D:3)
06:39:01 <Cbrotell> Eugor (L10 DECj) Crash caused by signal #11: Segmentation fault (D:8)
06:39:23 <Cbrotell> Eugor (L10 DECj) Crash caused by signal #11: Segmentation fault (D:8)
06:45:36 <Cbrotell> Eugor (L10 DECj) Crash caused by signal #11: Segmentation fault (D:8)
07:07:06 <Cbrotell> Doorstop00 (L15 DECj) Crash caused by signal #11: Segmentation fault (Orc:1)
07:23:00 <Discord|> <06w​ensley> bad day for conjurors
07:27:16 <Discord|> <08w​ormsofcan> conjure crash
07:46:53 <Cbrotell> Doorstop00 (L15 DECj) Crash caused by signal #11: Segmentation fault (Orc:2)
07:50:22 <Cbrotell> Doorstop00 (L15 DECj) Crash caused by signal #11: Segmentation fault (Orc:2)
08:07:59 <Discord|> <08n​icolae> a second newborn? or is the childcare for the newborn
08:19:19 <Cbrotell> discipleofbeogh (L3 DgCj) Crash caused by signal #11: Segmentation fault (D:3)
08:19:49 <Cbrotell> discipleofbeogh (L3 DgCj) Crash caused by signal #11: Segmentation fault (D:3)
08:20:14 <Cbrotell> discipleofbeogh (L3 DgCj) Crash caused by signal #11: Segmentation fault (D:3)
08:21:38 <Cbrotell> discipleofbeogh (L2 DgCj) Crash caused by signal #11: Segmentation fault (D:1)
08:23:02 <Cbrotell> discipleofbeogh (L3 DgCj) Crash caused by signal #11: Segmentation fault (D:1)
08:25:35 <Cbrotell> discipleofbeogh (L3 DgCj) Crash caused by signal #11: Segmentation fault (D:4)
08:58:14 <Cbrotell> pants (L4 DECj) Crash caused by signal #11: Segmentation fault (D:2)
09:00:37 <Cbrotell> Doorstop00 (L16 DECj) Crash caused by signal #11: Segmentation fault (Snake:1)
09:05:12 <Cbrotell> Doorstop00 (L16 DECj) Crash caused by signal #11: Segmentation fault (Snake:1)
09:06:37 <geekosaur> oh dear
09:08:48 <Cbrotell> pants (L3 DECj) Crash caused by signal #11: Segmentation fault (D:2)
09:09:10 <Cbrotell> pants (L3 DECj) Crash caused by signal #11: Segmentation fault (D:2)
09:11:33 <Aliscans_> It appears that Crawl really doesn't like it when you call the player a monster.
09:12:38 <Aliscans_> In handle_searing_ray(), there's an "if (agent.is_player() && turn > 1)" line. It tries to cast agent to a monster otherwise, but the player also has turn 1.
09:13:17 <Aliscans_> It seems like no-one other than conjurers bothers with Searing Ray.
09:16:35 * Aliscans_ realises that it's been fixed.
09:23:54 <Cbrotell> ChasedDraco (L2 DgCj) Crash caused by signal #11: Segmentation fault (D:2)
09:25:15 <Cbrotell> ChasedDraco (L2 DgCj) Crash caused by signal #11: Segmentation fault (D:2)
09:34:18 <Cbrotell> mdk (L12 DECj) Crash caused by signal #11: Segmentation fault (Lair:5)
09:35:07 <Cbrotell> mdk (L13 DECj) Crash caused by signal #11: Segmentation fault (Lair:5)
09:36:03 <Cbrotell> mdk (L12 DECj) Crash caused by signal #11: Segmentation fault (Lair:5)
10:03:51 <Cbrotell> pants (L4 DECj) Crash caused by signal #11: Segmentation fault (D:2)
10:06:25 <Cbrotell> Eugor (L10 DECj) Crash caused by signal #11: Segmentation fault (D:8)
10:30:15 <Cbrotell> gabagoolgaming (L3 DrCj) Crash caused by signal #11: Segmentation fault (D:2)
10:30:38 <Cbrotell> gabagoolgaming (L3 DrCj) Crash caused by signal #11: Segmentation fault (D:2)
10:31:44 <Cbrotell> gabagoolgaming (L3 DrCj) Crash caused by signal #11: Segmentation fault (D:2)
10:33:55 <Discord|> <06p​leasingfungus> nicolae: childcare for someone who was a newborn three years ago 😛
10:36:37 <Cbrotell> gabagoolgaming (L3 DrCj) Crash caused by signal #11: Segmentation fault (D:2)
10:48:39 <Cbrotell> gabagoolgaming (L3 DrCj) Crash caused by signal #11: Segmentation fault (D:2)
11:02:30 <Cbrotell> jasper (L3 TeCj) Crash caused by signal #11: Segmentation fault (D:2)
11:02:49 <Cbrotell> jasper (L3 TeCj) Crash caused by signal #11: Segmentation fault (D:2)
11:03:02 <Cbrotell> jasper (L3 TeCj) Crash caused by signal #11: Segmentation fault (D:2)
11:03:44 <Discord|> <06p​leasingfungus> anything we can ??rebuild?
11:42:49 <Cbrotell> MissTea (L6 DECj) Crash caused by signal #11: Segmentation fault (D:5)
11:43:05 <Cbrotell> MissTea (L6 DECj) Crash caused by signal #11: Segmentation fault (D:5)
11:43:22 <Cbrotell> MissTea (L6 DECj) Crash caused by signal #11: Segmentation fault (D:5)
11:45:53 <Cbrotell> MissTea (L6 DECj) Crash caused by signal #11: Segmentation fault (D:5)
11:47:54 <Discord|> <04d​racoomega> Oh damnit, I was too slow T.T
11:48:40 <Cbrotell> MissTea (L7 DECj) Crash caused by signal #11: Segmentation fault (D:6)
11:48:48 <geekosaur> and last I heard cbr2 can't be rebuilt
11:50:21 <Discord|> <04d​racoomega> It can't be?
11:50:35 <Discord|> <04d​racoomega> (I just went and hit the rebuild trigger on it, but I guess I have no idea if it's working properly)
11:51:23 <Discord|> <04d​racoomega> The fast rebuild servers are obviously fine, and it looks like most of the slow ones misse the bad commit
11:51:26 <Cbrotell> MissTea (L7 DECj) Crash caused by signal #11: Segmentation fault (D:6)
11:51:59 <geekosaur> hm, maybe it was finally fixed. I recall it throwing an auth error
11:54:17 <Discord|> <04d​racoomega> Okay, it does appear to finally be responding to the trigger visually
11:54:42 <Discord|> <04d​racoomega> So presumably this will be fixed as soon as it's done
11:56:02 <Discord|> <12g​e0ff> &versions
11:56:29 <Discord|> <04C​erebot> CAO: 0.33-a0-428-g648c01e, CBR2: 0.33-a0-541-g8bf3021b3d, CDI: 0.33-a0-542-gf8f82a2dde, CDO: 0.33-a0-541-g8bf3021b3d, CNC: 0.33-a0-542-gf8f82a2dde, CPO: 0.33-a0-525-gc082a88ec8, CUE: 0.33-a0-533-g9d6bf4ca7f, CXC: 0.33-a0-533-g9d6bf4ca7f, LLD: none
11:57:38 <Discord|> <12g​e0ff> so, CBR2 and CDO have the buggy version (541), and also CAO cannot into update?
11:58:03 <Cbrotell> MissTea (L8 DECj) Crash caused by signal #11: Segmentation fault (D:6)
11:59:19 <Discord|> <12g​e0ff> CAO's 0.33-a0-428 is a Nov 17th commit
11:59:34 <Cbrotell> MissTea (L8 DECj) Crash caused by signal #11: Segmentation fault (D:6)
12:04:46 <Cbrotell> pants (L9 DEEE) Crash caused by signal #11: Segmentation fault (D:6)
12:07:30 <Discord|> <09g​ammafunk> that's odd
12:07:37 <Discord|> <09g​ammafunk> once again, we have broken the cao build
12:07:38 <Discord|> <09g​ammafunk> let me check
12:11:48 <Discord|> <09g​ammafunk>      CXX describe.o In file included from /usr/include/c++/4.7/algorithm:63:0,                  from fixedarray.h:8,                  from externs.h:29,                  from AppHdr.h:309,                  from describe.cc:6: /usr/include/c++/4.7/bits/stl_algo.h: In instantiation of '_RandomAccessIterator std::__unguarded_partition(_RandomAccessIterator, _RandomAccessIterator, const _Tp&, _Compare) [with _RandomAccessIterator =
12:11:49 <Discord|> __gnu_cxx::__normal_iterator<std::pair<int, int>*, std::vector<std::pair<int, int> > >; _Tp = std::pair<int, int>; _Compare = _spell_fail_change_description(const item_def&, bool)::<lambda(std::pair<int, int>&, std::pair<int, int>&)>]': /usr/include/c++/4.7/bits/stl_algo.h:2321:78:   required from '_RandomAccessIterator std::__unguarded_partition_pivot(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator =
12:11:49 <Discord|> __gnu_cxx::__normal_iterator<std::pair<int, int>*, std::vector<std::pair<int, int> > >; _Compare = _spell_fail_change_description(const item_def&, bool)::<lambda(std::pair<int, int>&, std::pair<int, int>&)>]' /usr/include/c++/4.7/bits/stl_algo.h:2362:62:   required from 'void std::__introsort_loop(_RandomAccessIterator, _RandomAccessIterator, _Size, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::pair<int, int>*,
12:11:50 <Discord|> std::vector<std::pair<int, int> > >; _Size = long int; _Compare = _spell_fail_change_description(const item_def&, bool)::<lambda(std::pair<int, int>&, std::pair<int, int>&)>]' /usr/include/c++/4.7/bits/stl_algo.h:5514:4:   required from 'void std::sort(_RAIter, _RAIter, _Compare) [with _RAIter = __gnu_cxx::__normal_iterator<std::pair<int, int>*, std::vector<std::pair<int, int> > >; _Compare = _spell_fail_change_description(const item_def&,
12:11:50 <Discord|> bool)::<lambda(std::pair<int, int>&, std::pair<int, int>&)>]'
12:11:51 <Discord|> <09g​ammafunk> and
12:12:01 <Discord|> <09g​ammafunk> hrm, let me pastbin this
12:13:11 <Discord|> <09g​ammafunk> https://dpaste.com/9UQ3SNCD6
12:14:02 <Discord|> <12g​e0ff> > no known conversion for argument 2 from 'const std::pair<int, int>' to 'std::pair<int, int>&'
12:14:21 <Discord|> <04d​racoomega> Er, what?
12:14:23 <Discord|> <12g​e0ff> which is _spell_fail_change_description() related
12:14:39 <Discord|> <09g​ammafunk> recall that this is gcc 4.7, which has most but not all of C++11
12:15:00 <Discord|> <09g​ammafunk> (may not be relevant, but I know C++11 was discussed in the context of some recent fixes)
12:15:21 <geekosaur> even in c++11 a value is not a reference
12:16:25 <geekosaur> although, then why does it work elsewhere?
12:16:45 <Discord|> <04d​racoomega> I mean, isn't this just passing values into a function that takes references. Isn't that specifically how reference arguments work?
12:17:01 <geekosaur> (and, well, I'm not a C++ person but I kinda treat references as "inverted pointers")
12:17:41 <Discord|> <04d​racoomega> The code is seems to be complaining about is just sorting code (of which I thought there was a bunch of similar stuff elsewhere) C++     sort(spell_sort.begin( ), spell_sort.end( ),             [cur_fail](pair<int, int>& a, pair<int, int>& b)                 { return cur_fail[a.first] > cur_fail[b.first];});     sort(spell_sort.begin( ), spell_sort.end( ),             [](pair<int, int>& a, pair<int, int>& b)                 { return
12:17:41 <Discord|> a.second > b.second;});
12:21:40 <Discord|> <09g​ammafunk> well it's notable that it's saying we're going from const to not const
12:22:06 <Discord|> <04d​racoomega> Oh, I didn't even notice that part
12:22:31 <Discord|> <09g​ammafunk> so maybe you just need to declare your lambda appropriately?
12:22:36 <Discord|> <04d​racoomega> I mean, I can toss a const in front of those, but there's a lot of sort lambdas that don't have it and which seem to have compiled fine
12:22:44 <Discord|> <04d​racoomega> Even on CAO
12:26:22 <Discord|> <04d​racoomega> (It would be nice if there was some way to locally verify that it was okay with whatever)
12:26:47 <Discord|> <04d​racoomega> Scanning through various calls to sort() in the codebase, some of the sorter functions take values, some pointers, some references, some const references...
12:26:50 <Discord|> <04d​racoomega> Seemingly
12:27:20 <Discord|> <09g​ammafunk> well, if people suggest changes I can test them on CAO
12:27:41 <Discord|> <09g​ammafunk> not sure how easy it is to install a local copy of gcc 4.7 these days...
12:27:52 <Discord|> <09g​ammafunk> certainly won't find that in your friendly local debian repository
12:30:32 <Discord|> <04d​racoomega> I suppose I could add a const just because, and push, and see if that fixes it. Since it should be harmless even if it doesn't (and then we can try something else if that isn't it)
12:30:42 <Discord|> <09g​ammafunk> let me just try it locally
12:30:44 <Discord|> <09g​ammafunk> before you push
12:30:52 <Discord|> <04d​racoomega> You have a local 4.7?
12:30:56 <Discord|> <09g​ammafunk> by locally I mean on CAO itself
12:30:59 <Discord|> <04d​racoomega> Oh
12:31:17 <Discord|> <09g​ammafunk> I have rerun the make command from the update log, and it's failing the same way (without any change)
12:31:23 <Discord|> <09g​ammafunk> so I can test changes on CAO directly from here
12:31:35 <Discord|> <09g​ammafunk> if you want to post a proposed diff here in discord, that's helpful
12:31:38 <Discord|> <09g​ammafunk> to make sure we're on the same page
12:32:22 <Discord|> <09g​ammafunk> can do e.g.  ```diff DIFF ```
12:32:41 <Discord|> <09g​ammafunk> where DIFF are the contents, but I think this one is just adding const to the lambda arguments
12:34:47 <Discord|> <09g​ammafunk> ok, I added const to the lambda args in those two sort calls
12:35:12 <Discord|> <09g​ammafunk> it got through describe.cc, so if it finishes with no more errors, we're good
12:35:48 <Discord|> <09g​ammafunk> ah, and now another failure in directn.cc
12:36:09 <Discord|> <09g​ammafunk> abridged error:  directn.cc:1532:91: note: direction_chooser::fill_feature_cycle_points(char)::<lambda(coord_def&, coord_def&)> directn.cc:1532:91: note:   no known conversion for argument 1 from 'const coord_def' to 'coord_def&'
12:36:38 <Discord|> <09g​ammafunk> so a similar const issue no doubt, let me try to fix
12:37:27 <Discord|> <04d​racoomega> I wonder why it's okay with non-constant pointers in sort lambdas, but not non-const references?
12:40:26 <Discord|> <09g​ammafunk> yeah, not sure, the cpp reference at https://en.cppreference.com/w/cpp/algorithm/sort notes that the form of std::sort we seem to be using (3rd in the list) is constexpr since C++20 but that's not much help
12:42:35 <Discord|> <09g​ammafunk> I'm having to change a bunch of other non-const cases in directn.cc as well, but I'll post a final diff when I'm done
12:43:09 <Discord|> <09g​ammafunk> ok through directn.cc...now just seeing if any other files fail
12:43:44 <Discord|> <09g​ammafunk> did you know that  fight.cc: In function 'bool warn_about_bad_targets(const char*, std::vector<coord_def>, std::function<bool(const monster&)>)': fight.cc:1533:48: warning: ISO C++ does not support the 'z' gnu_printf length modifier [-Wformat]
12:44:08 <Discord|> <09g​ammafunk> (this is a really old warning that we've had forever and my understanding is that we can't make it go away)
13:00:09 <Discord|> <09g​ammafunk> phew, only on syscalls.o now
13:00:15 <Discord|> <09g​ammafunk> cao compilation is not exactly speedy
13:02:32 <Discord|> <04d​racoomega> (The cbr2 rebuild page also hasn't moved in forever, so I don't know if that's working properly or not, tbh >.>)
13:03:30 <Discord|> <09g​ammafunk> you probably need to retry it. it's an unfortunate byproduct of how those rebuild CGI scripts work that if your browser closes the connection (e.g. after a period of no output), the process is terminated
13:03:51 <Discord|> <09g​ammafunk> but it should resume from where it was last running pre-termination
13:04:37 <Cbrotell> Unstable branch on cbro.berotato.org updated to: 0.33-a0-542-gf8f82a2dde (34)
13:04:40 <Discord|> <09g​ammafunk> welp
13:04:46 <geekosaur> lol
13:04:49 <Discord|> <04d​racoomega> Nice
13:04:50 <Discord|> <09g​ammafunk> Did you do anything?
13:05:00 <Discord|> <04d​racoomega> I hit reload, but I think that may have been coincidence
13:05:03 <Discord|> <09g​ammafunk> heh
13:05:22 <Discord|> <04d​racoomega> But apparently that took it about 70 minutes
13:05:25 <Discord|> <04d​racoomega> Despite almost no files being changed
13:05:59 <Discord|> <04d​racoomega> Must have approximately 0 cpu assigned to that task
13:06:06 <Discord|> <09g​ammafunk> yeah, not surprising I guess; I wonder if the output was just cached (it's not supposed to be)
13:06:18 <Discord|> <09g​ammafunk> or buffered, rather
13:06:38 <Discord|> <09g​ammafunk> in other happy news, CAO build did complete, here's the final diff:
13:07:33 <Discord|> <09g​ammafunk> https://dpaste.com/HQYF5EB36
13:07:39 <Discord|> <09g​ammafunk> (oops, too long to paste directly)
13:08:09 <Discord|> <09g​ammafunk> so if this looks fine to anyone interested, I'll push
13:08:50 <Discord|> <04d​racoomega> I mean, it looks fine to me
13:10:10 <Discord|> <09g​ammafunk> hrm, slight quandry, can you get a file directly from git diff that can be applied to a local repo
13:10:23 <Discord|> <09g​ammafunk> I don't want to make a commit on cao first but maybe I should
13:10:53 <geekosaur> git format-patch
13:11:04 <geekosaur> hm, that may require a commit
13:11:17 <Discord|> <09g​ammafunk> yeah, but I'm seeing that I can save git diff output to a patch file
13:12:06 <geekosaur> yes, that should be default, no? otherwise add -p
13:12:33 <geekosaur> I feel like I've done that before (back when you couldn't stash untracked files iirc)
13:13:02 <Discord|> <09g​ammafunk> yeah I used git apply on the saved patch file
13:16:26 <Discord|> <04d​racoomega> Thanks a bunch
13:16:35 <Discord|> <09g​ammafunk> No problem. I'm not sure if anything was backported to 0.32
13:16:53 <Discord|> <09g​ammafunk> which might require a cherry-pick so that cao could likewise rebuild 0.32
13:17:04 <NotCheibriados> 03gammafunk02 07* 0.33-a0-543-g5a6c091abe: Fix the build on CAO 10(4 minutes ago, 2 files, 6+ 6-) 13https://github.com/crawl/crawl/commit/5a6c091abe49
13:17:18 <Discord|> <09g​ammafunk> but if that's the case, please feel free to cherry-pick into 0.32 branch (CAO will rebuild 0.32 automatically after that)
13:17:31 <Discord|> <04d​racoomega> No, those are both relatively recent 0.33 things
13:17:39 <Discord|> <09g​ammafunk> great, thanks
13:18:50 <Discord|> <09g​ammafunk> guess I'll also go ahead and rebuild trunk on cao so we actually have this live
13:46:30 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.33-a0-543-g5a6c091abe (34)
13:52:07 <Discord|> <04d​racoomega> Unrelatedly: is anyone actually attached to being able to wield things other than weapons in your hands? I has no functional purpose, and yet there is code in a bunch of different places to verify that the item in your weapon slot is actually a weapon before looking at properties it might give the player.
13:53:16 <Discord|> <04d​racoomega> (As I continue to draft plans for the equipment slot rewrite, I can't help but feel this isn't worth deliberately trying to preserve >.>)
13:55:43 <Discord|> <09g​ammafunk> aside from the comedic value of wielding a snozz cucumber just before ascension (rip), I don't think there's any valid reason to wack monsters with non-weapons.
13:56:36 <Discord|> <12g​e0ff> if you equip a non-weapon before splatting, your ghost will have a very weak melee attack
13:57:00 <Discord|> <09g​ammafunk> but you could also just equip some total garbage weapon to do that
13:57:05 <Discord|> <12g​e0ff> that's the only useful non-turncount thing you can do with it
13:57:45 <Discord|> <09g​ammafunk> technically it's better for your ghost than e.g. a non-weapon but a plain club or even something somehow highly negatively enchanted isn't much better
13:57:53 <Discord|> <12g​e0ff> yeah, but you don't always carry such a weapon, but you usually have a scroll a potion in your inventory
13:58:09 <Discord|> <09g​ammafunk> well, someone with such interesting in making weak ghosts
13:58:15 <Discord|> <09g​ammafunk> surely carries a club for just such a purpose
14:00:14 <Discord|> <09g​ammafunk> obviously currently they have a specially designated potion with the inscription: !!! WIELD ME BEFORE DEATH !!! but after DO nerfs that, they can just do the same with some terrible weapon
14:02:46 <Discord|> <12g​e0ff> also, wielding non-weapons could confuse new players, who might expect some Nethack-like interactions, like hitting an orc with a potion of degeneration to weaken it
14:04:47 <Discord|> <04d​racoomega> Yes, it always felt to me like it was originally a thing in Crawl specifically because a bunch of traditional roguelikes did things with it. But I don't believe it ever actually had a functional purpose in Crawl?
14:06:01 <Discord|> <09g​ammafunk> maybe some weird non-weapon item did have strange melee effects?
14:06:28 <Discord|> <09g​ammafunk> but I don't think you could hit monsters with decks or anything
14:06:38 <Discord|> <09g​ammafunk> oh, you could wield decks to evoke them quickly
14:06:42 <Discord|> <09g​ammafunk> I wonder if that was one reason
14:07:18 <Discord|> <09g​ammafunk> in fact linley himself talked about wanting to retain that feature, as I recall, probably for thematic reasons
14:07:26 <Discord|> <09g​ammafunk> but that's definitely a think you could do with old nemelex
14:07:32 <Discord|> <04d​racoomega> Oh, that's true, right
14:07:34 <Discord|> <09g​ammafunk> I used that frequently in my games
14:07:39 <Discord|> <04d​racoomega> I do remember that now
14:07:56 <Discord|> <04d​racoomega> (You wielded rods also, but those were technically actually weapons too, I believe. Just bad ones.)
14:09:08 <Discord|> <04d​racoomega> (Did you know that there's still code to tell you specifically that you can't put on jewelry that you're currently wielding?)
14:09:15 <Discord|> <04d​racoomega> Except the game doesn't let you wield jewelry either
14:16:04 <Discord|> <04d​racoomega> There's also a fair bit of duplicated code in general from separating wield/wear/puton functions that I can probably unify somewhat. (Not meaning as a change to the interface - w/W/P are arguably useful inventory filters - but the actual act of equipping items uses a lot of the same code in the end)
14:18:27 <Discord|> <04d​racoomega> There's so much foundational code in so many different places, though, that this project is definitely going to take a while to do properly.
14:33:11 <Discord|> <09g​ammafunk> this is the time to rewrite crawl in rust
15:26:26 <Discord|> <04d​racoomega> Am I correct in thinking that basically every place where it checks if the player 'knows' a given artprop (for purposes of warnings or display) is superfluous nowadays?
15:26:53 <Discord|> <04d​racoomega> It's impossible to have an unidentified artifact in you or anyone else's inventory
15:26:57 <Discord|> <04d​racoomega> (Outside of wizmode)
15:31:08 <Discord|> <04d​racoomega> For that matter, tracking which artprops are known and which aren't is itself unnecessary, isn't it?
15:31:12 <Discord|> <04d​racoomega> You either know none or all
15:52:18 <NotCheibriados> 03DracoOmega02 07* 0.33-a0-544-ga893128bbb: Fix bombard having the wrong projectile tile 10(36 seconds ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/a893128bbb63
15:54:31 <geekosaur> we took a while to get everything switched over and I'm not sure I'd swear that there aren't still some missing pieces
15:57:02 <Discord|> <09g​ammafunk> This is or was technically untrue see gammafunk_ghost_icy I think it's called
15:57:12 <Discord|> <04d​racoomega> Oh? Howso?
15:57:30 <Discord|> <09g​ammafunk> It pre-ids only the guaranteed artps
15:57:39 <Discord|> <09g​ammafunk> (Or used to)
15:57:48 <Discord|> <04d​racoomega> I.. I didn't even know that was a possible thing that could be done
15:57:54 <Discord|> <09g​ammafunk> Non inventory item ofc
15:58:00 <Discord|> <09g​ammafunk> Yeah it is
15:58:23 <Discord|> <09g​ammafunk> Shockingly i and not nicolae made use of this fact
15:58:59 <Discord|> <09g​ammafunk> And it's always been controversial and could just be fully ided
15:59:14 <Discord|> <09g​ammafunk> Maybe already is but I can't check atm
15:59:47 <Discord|> <04d​racoomega> I am not sure it visibly IDs anything at the moment
16:00:11 <Discord|> <04d​racoomega> Maybe I'm doing this wrong
16:01:49 <Discord|> <04d​racoomega> %git 47d82705aee2b71f11d1524f00983a8c50f919f6
16:01:50 <Discord|> <04C​erebot> kate- * 0.28-a0-100-g47d82705ae: Fully identify some partially-identified randarts (3 years, 4 months ago, 3 files, 20+ 20-) https://github.com/crawl/crawl/commit/47d82705aee2
16:02:45 <Discord|> <09g​ammafunk> Aha
16:03:17 <Discord|> <09g​ammafunk> Kate ruins everything again!
16:03:44 <Discord|> <04d​racoomega> (Honestly though, if I saw a randart with any props identified, I would genuinely assume that was the complete list)
16:04:25 <Discord|> <09g​ammafunk> Yes this was precisely the confusion that players had when seeing these items
16:07:28 <Discord|> <04d​racoomega> Seems likely this whole infrastructure can be done away with, then
16:10:59 <Discord|> <09g​ammafunk> as I look at this commit, I'm most shocked by the fact that the other person making use of it was minmay!
16:12:16 <Discord|> <09h​ellmonk> lol
16:15:34 <Discord|> <03s​emi_tonal> i think the partially-identified case might still come up currently if an ident:type ring (that isn't explicitly a randart) happens to gets turned into a randart during item generation? but yeah, those could also just use ident:all instead since it wouldn't make any difference normally
16:24:18 <Lantell> memo131 (L8 MDFi) ASSERT(range >= 0) in 'beam.cc' at line 747 failed. (beam 'rocky spike', source 'player', item 'none'; has range -1) (D:5)
16:24:30 <Discord|> <09g​ammafunk> right, and we'd just shorten the parsing of ident:all to ident at that point, I think? Since there would be no other kind of identification (you either have ident or you don't)
16:24:42 <Discord|> <04d​racoomega> Yeah
16:24:54 <Discord|> <04d​racoomega> (Does ident:plus still even exist?)
16:25:15 <Discord|> <04d​racoomega> Or ident:plusses or whatever it was
16:26:06 <Discord|> <09g​ammafunk> not uses of it seen in the codebase according to git grep
16:27:05 <Discord|> <04d​racoomega> Yes, there is still code for ident:pluses and ident:properties
16:27:29 <Discord|> <09g​ammafunk> right, but I mean no actul uses of it in DES
16:27:30 <Discord|> <04d​racoomega> Like, all of this made sense back in the day where you could incrementally identify parts of an item you had, in different ways. But is extremely vestigal nowadays.
16:28:27 <Discord|> <04d​racoomega> Simplifying all of this to a single 'identified' flag and changing map syntax accordingly makes sense to me, at any rate
16:39:20 <Lantell> Unstable branch on underhound.eu updated to: 0.33-a0-544-ga893128bbb (34)
21:59:01 <Discord|> <03i​mplojin> re: simplifying id flags: yes, please
22:32:45 <NotCheibriados> 03regret-index02 07* 0.33-a0-545-g80a0b1252b: Vault review ever-repeating 10(4 minutes ago, 12 files, 256+ 283-) 13https://github.com/crawl/crawl/commit/80a0b1252b9d
23:35:09 <Gretell> Unstable branch on crawl.develz.org updated to: 0.33-a0-545-g80a0b1252b (34)
23:57:23 <Gretell> Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-545-g80a0b1252b