01:29:42 <CrawlCycle> Do we allow a monster see itself?
01:34:25 <Gretell> Unstable branch on crawl.develz.org updated to: 0.26-a0-665-gefeb406119 (34)
01:34:43 <CrawlCycle> there is no unit test for actor_near_iterator in act-iter.h
01:36:41 <CrawlCycle> I guess actor_near_iterator is a const_iterator over all viewers of a coordinate or central actor
01:37:35 <CrawlCycle> But looking at the code closely, I find little things that contradict this guess.
01:40:01 <CrawlCycle> Internally, the iterator has a "bool valid(const actor* a) const" method that checks if a is a valid viewer for the iterator.
01:41:35 <CrawlCycle> By viewer, I mean a monster or player that is visible to the coordinate or central actor.
01:43:24 <CrawlCycle> The valid function first checks if a is nullptr or *a is not alive. If that is the case, a is not valid.
01:43:50 <CrawlCycle> That is reasonable.
01:47:25 <CrawlCycle> The 2nd check, if I understand correctly, checks if the iterator is not pointing to you and a is not visible to the actor that the iterator points to. If that is the case *a is not a valid viewer.
01:49:10 <CrawlCycle> But, I think a valid viewer doesn't have to be visible to the previous viewer.
01:49:48 <CrawlCycle> A valid viewer only needs to be visible to the coordinate or the central actor.
01:51:19 <CrawlCycle> Part of the 2nd check ask if a is visible to the current viewer that the iterator points to, instead of if a is visible to the coordinate or the central viewer.
01:54:36 <CrawlCycle> I actually mean "or the central actor."
01:55:12 <Gretell> Windows builds of master branch on crawl.develz.org updated to: 0.26-a0-665-gefeb406119
02:05:14 <CrawlCycle> For example, the player P can see invisible and can see a visible monster A and an invisible monster B.
02:05:27 <CrawlCycle> A cannot see invisible.
02:07:13 <CrawlCycle> If an iterator would iterate over all actors visible to P, it should iterate over P, A, and B.
02:07:38 <CrawlCycle> But the valid function means once it goes to A, since A can't see B, the iterator won't visit B.
02:13:26 <CrawlCycle> ok .. I guess I get it now. The iterator class operates in two modes.
02:16:53 <amalloy> CrawlCycle: i don't understand this explanation. AFAICT viewer never changes: it's the source whose POV we're looking from
02:20:21 <CrawlCycle> yea. the iterator operates in two modes
02:20:55 <CrawlCycle> The iterator iterates over all monsters visible to a coordinate when viewer is nullptr
02:21:51 <CrawlCycle> i mean all actos visible to the coordinate...
02:22:25 <CrawlCycle> When viewer points to a central actor, the iterator iterates over all actors visible to the central actor.
02:22:49 <amalloy> i wouldn't call that modes. having a viewer just adds one extra check on top of the viewerless behaviour
02:24:01 <amalloy> but if thinking of it as bimodal helps you i don't see anything harmful about that
02:27:54 <CrawlCycle> also not const_iterator. I think env.mon and player are global and not const.
02:30:59 <CrawlCycle> When the viewer is a monster, does the iterator iterates over the monstrous viewer as well?
02:31:11 <CrawlCycle> Can the monster see itself?
02:53:29 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.26-a0-665-gefeb406119
03:18:33 <CrawlCycle> i guess it can, but that means wind drakes can damge itself, which doesn't seem to be true.
03:31:11 <Kelbell> Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-3603-ge1cc4b0452
03:46:50 <Kelbell> Fork (bcadrencrawl) on crawl.kelbi.org updated to: 0.22.1-3043-g185df2fc77
04:14:02 -!- amalloy is now known as amalloy_
06:22:09 -!- Tiobot is now known as Guest4534
08:09:07 <Discord|> <12e​bering> CrawlCycle: this gets back to the "locally sensible, globally requires a lot of context" . Your questions about actor_near_iterator can be answered from lookingn at its usage if that helps.
08:18:01 <Discord|> <12e​bering> CrawlCycle: Also I'm not sure exactly what you're saying about const_iterator. const_iterator is a specific method of stl containers.
08:18:53 <Discord|> <12e​bering> Actor near iterator has some member methods declared const, which are the ones that can be called on a const actor_near_iterator though since that iterator can't be advanced I'm not sure its used anywhere.
09:49:45 <CrawlCycle> For now I rely purely on reading the code to figure out what is going on
09:50:04 <CrawlCycle> .
09:51:23 <CrawlCycle> It would be easier to test if an actor_near_iterator would iterate over the viewer with a unit test
09:52:03 <aidanh> !source actor_near_iterator
09:52:03 <Sequell> 1/3. https://github.com/crawl/crawl/blob/master/crawl-ref/source/act-iter.cc#L15
09:52:03 <CrawlCycle> I mean if a monster can see itself
09:53:56 <CrawlCycle> I think it can after reading the definition of actor::visible_to
09:55:16 <CrawlCycle> But that would mean wind drake can hit itself
09:55:49 <CrawlCycle> with wind_blast in evoke.cc, which uses the actor_near_iterator
10:01:02 <CrawlCycle> docs/develop/testing.md didn't provide example to set up unit tests for different cases
10:03:15 <aidanh> !source docs/develop/testing.md
10:03:15 <Sequell> Can't find docs/develop/testing.md.
10:03:15 <aidanh> hrmph
10:04:19 <CrawlCycle> crawl/crawl-ref/docs/develop/testing.md
10:04:23 <aidanh> CrawlCycle: well the basic idea is to create a test file in catch2-tests/
10:05:30 <aidanh> !source test_files.cc
10:05:31 <Sequell> https://github.com/crawl/crawl/blob/master/crawl-ref/source/catch2-tests/test_files.cc
10:05:53 <aidanh> they are named after the corresponding file that they test; e.g. that one tests source/files.cc
10:07:04 <CrawlCycle> how to create an arena and place the player and specific monster in it?
10:07:41 <CrawlCycle> I am thinking about placing the player and one monster, frozen in time.
10:08:03 <CrawlCycle> and then test if the actor_near_iterator would iterate over the viewer
10:09:22 <aidanh> ...that's what's known in the industry as 'left as an exercise to the reader'
10:11:42 <CrawlCycle> oh. i don't think i see a test that place a specific monster
10:14:26 <CrawlCycle> maybe i can read the monster utility code
10:14:26 <aidanh> so for any tests like that, there's going to be a bit of gnarly awful code that sets up just enough required state
10:14:37 <aidanh> !source test_player_fixture.cc
10:14:38 <Sequell> https://github.com/crawl/crawl/blob/master/crawl-ref/source/catch2-tests/test_player_fixture.cc
10:14:59 <CrawlCycle> that one doesn't place any monster
10:15:03 <aidanh> this is an example, although it's not too bad
10:15:31 <aidanh> that's because 1) it's for testing the player, not monsters, and 2) it's a test fixture, not tests
10:15:36 <aidanh> !source test_player.cc
10:15:37 <Sequell> https://github.com/crawl/crawl/blob/master/crawl-ref/source/catch2-tests/test_player.cc
10:16:15 <aidanh> ^ the actual tests are here, and each one of them uses that fixture, which isolates the horrible setup/teardown code
10:17:22 <aidanh> any tests which rely on specific monster/player positions are going to require implementing such a fixture, which is the hard bit
10:17:40 <aidanh> after that, actually writing the test cases is the same as writing ordinary crawl code
10:37:16 <CrawlCycle> after creating a new test_act-iter.cpp file in the catch2-tests, the Makefile won't automatically add the new file to the catch2-tests build target.
10:39:22 <aidanh> right, that's also required
10:40:20 <CrawlCycle> how to add that in the Makefile?
10:40:34 <CrawlCycle> if a bunch of people write new unit tests at the same time...
10:40:46 <CrawlCycle> will they have merge conflict over the Makefile?
10:42:26 <Discord|> <12e​bering> Probably yes but that's not the end of the world.
10:42:26 <CrawlCycle> following the trail of targets in Makefile, there is a variable called "TEST_OBJECTS"
10:42:34 <aidanh> !source Makefile.obj
10:42:34 <Sequell> https://github.com/crawl/crawl/blob/master/crawl-ref/source/Makefile.obj
10:43:21 <CrawlCycle> this should be in the documentation after anyone figure this out
10:44:41 <CrawlCycle> thanks. so it is in Makefile.obj
10:46:33 <CrawlCycle> can the Makefile just glob every .cc file in catch2-tests directory?
10:48:40 <aidanh> no, some cc files are fixtures
10:51:03 <CrawlCycle> TEST_OBJECTS defined in Makefile.obj contains test_player_fixture.o
10:52:20 <CrawlCycle> after adding test_act-iter.o to TEST_OBJECTS, the catch2-tests target would build my test
10:53:50 <aidanh> hm, then a glob could work
10:59:37 <CrawlCycle> the test_player_fixture also doesn't call init_monsters()
10:59:51 <CrawlCycle> while the monster utility does
11:00:29 <CrawlCycle> erh... i guess i will just copy the initialization in the monster utility
11:00:43 <CrawlCycle> and see if that works.
11:00:52 <aidanh> these fixtures do the bare minimum
11:01:32 <aidanh> they're fairly brittle as a result; but that's to be expected somewhat
11:02:02 <CrawlCycle> make sense... or we have to start testing the fixtures as well
11:03:05 <CrawlCycle> do i have to call the init_xyz functions in a particular order?
11:03:21 <CrawlCycle> if that is the case, can i still use the test_player_fixture?
11:03:54 <aidanh> testing the fixtures themselves is not worthwhile; if they break, the tests using them will fail, so that's enough
11:04:51 <aidanh> I couldn't tell you off the top of my head
11:14:31 <CrawlCycle> whoops. if i copy the initialization in the monster utility to my test file, i get multiple definition because test_main also does the initialization
11:15:26 <CrawlCycle> and the catch2-test build target builds one executable for all tests
11:16:38 <CrawlCycle> maybe i can try test_mon-util.cc
11:19:06 <Cheibriados> New branch created: cleanup-globals (1 commit) 13https://github.com/crawl/crawl/tree/cleanup-globals
11:19:06 <Cheibriados> 03Aidan Holm02 07[cleanup-globals] * 0.26-a0-666-ga1e3d4a: Remove references to globals across files 10(16 minutes ago, 4 files, 24+ 22-) 13https://github.com/crawl/crawl/commit/a1e3d4a2d460
11:36:27 <dcss-ci> 04Build failed for 08cleanup-globals @ a1e3d4a2 06https://github.com/crawl/crawl/actions/runs/306764726
11:43:00 <advil> scrollback response: actor_near_iterator::operator* does not return a const so it's definitely not analogous to a stl constant iterator
11:43:16 <advil> for a test that involves placing a monster it's going to be extremely hard to do it as a catch2 test afaik
11:43:24 <advil> better done with the lua testing infrastructure
11:44:02 <advil> which is very similar in many ways but not structured around c++ style "units"
11:44:19 <advil> here is a test that places many monsters: https://github.com/crawl/crawl/blob/master/crawl-ref/source/test/monplace.lua
11:44:31 <advil> you wouldn't ordinarily do this in the arena per se, but just in a blank dungeon area
11:45:05 <advil> it would not at all surprise me if a monster "can" hit itself but doesn't as a matter of AI except under unusual circumstances
11:45:36 <advil> under confusion for example
11:50:01 <advil> wind blast has a specific check against `ai->pos() == agent->pos()`
11:50:13 <advil> I expect you'll find that in many effects of this sort
11:59:00 <CrawlCycle> i copied the #includes in fake_main.hpp, monster-main.cc, test_mon-util.cc to my test_act-iter.cc
11:59:37 <CrawlCycle> and i can use the initialize_crawl() function, copied from monster-main.cc in a unit test
12:00:07 <CrawlCycle> thanks for pointing out the check
13:01:09 <CrawlCycle> yup. the actor_near_iterator would iterate over the viewer when the viewer is a monster
13:06:56 <DrPraetor> ??lugonu wrath
13:06:57 <Sequell> lugonu wrath[1/1]: ABANDONMENT: 50 penance. RETRIBUTION: 50% tloc miscast (and keep going), else 16% teleport, 8% blink. Even if a preceding effect occurred, continue to: create some abominations, thrashing horrors and ancient zymes, maybe a single tentacled starspawn, wretched star or starcursed mass.
13:07:11 <DrPraetor> ??lugonu wrath
13:07:11 <Sequell> lugonu wrath[1/1]: ABANDONMENT: 50 penance. RETRIBUTION: 50% tloc miscast (and keep going), else 16% teleport, 8% blink. Even if a preceding effect occurred, continue to: create some abominations, thrashing horrors and ancient zymes, maybe a single tentacled starspawn, wretched star or starcursed mass.
13:42:31 -!- cebolla is now known as spicycat
14:21:08 <CrawlCycle> I add wild card search for catch2-test/*.cc to Makefile.obj to make the cathc2-test target automatically search for the tests.
14:21:50 <CrawlCycle> I can make a pull request for that.
14:22:33 <CrawlCycle> But afterwards, if I make another commit that depends on this commit
14:22:40 <CrawlCycle> and then do another pull request
14:22:52 <CrawlCycle> the 2nd pull request will depend on the 1st pull request
14:23:18 <CrawlCycle> do I simply just submit the two pull requests?
14:25:58 <CrawlCycle> oh. I guess I should just make the 1st pull request
14:26:02 <CrawlCycle> wait for it to get merged
14:26:10 <CrawlCycle> before making the 2nd pull request
15:14:42 <Cheibriados> New branch created: pull/1586 (1 commit) 13https://github.com/crawl/crawl/pull/1586
15:14:42 <Cheibriados> 03CrawlCycle02 07https://github.com/crawl/crawl/pull/1586 * 0.26-a0-666-g14e8565: build: Make the catch2-tests target look for tests 10(61 minutes ago, 1 file, 3+ 16-) 13https://github.com/crawl/crawl/commit/14e8565c4bc9
17:49:43 <CrawlCycle> Is it true that the positions of monsters can't be (x, 0) or (0, y) but the position of the player can be at (0, 0)?
18:05:16 <CrawlCycle> probably can't place monster at (x, 0) or (0, y) because there is a margin of 1 around the playing area, as defined in defines.h
18:24:00 <CrawlCycle> i set up a 3 body case of the player, an orc, and an invisible bat in a catch2-test
18:26:01 <CrawlCycle> The minimal initializaiton seems to need init_monsters(), init_mon_name_cache(), init_show_table(), dgn_reset_level()
18:28:32 <CrawlCycle> After reducing the initialization to the minimal, I can do the initialization in each test without causing segmentation fault.
18:30:04 <CrawlCycle> somehow if the initialization contains init_element_colors(), then the first test can run fine but the 2nd test get segmentation fault.
18:30:59 <CrawlCycle> what is the correct way to tear down the initialization done by init_element_colors()?
18:36:35 <CrawlCycle> running the initialization twice doesn't seem to reset the env.
18:36:57 <Aliscans> The problem may have nothing to do with init_element_colors(), as whether a segmentation fault occurs depends on the precise details of the compiled binary. If I were you, I'd try to find out which pointer I'd misused.
18:37:01 <CrawlCycle> I mean env.mons still contain the 1st orc and bat that I put in the 1st test.
18:39:32 <CrawlCycle> maybe. I tested some combination of initialization function a few times.
18:40:33 <CrawlCycle> I can delete all code that I write and just run the initialization twice.
18:41:01 <CrawlCycle> the initialization code is copied from the monster utility's code
18:41:35 <CrawlCycle> but i didn't include the fake_main because that gives me multiple definition
18:43:32 <CrawlCycle> running the minimal initialization for 100 times doesn't give segmentation fault
18:44:04 <CrawlCycle> adding init_element_colro back in and i get segmentation fault again
18:44:52 <CrawlCycle> anyway, I need to figure out how to reset the monsters before running for the next test.
18:45:54 <CrawlCycle> bah. not surprising that people haven't written unit tests that involves monster.
18:57:33 <Aliscans> First you need to find out if you need to "reset the monsters". Me, I don't know if that's a concept Crawl has.
18:58:12 <CrawlCycle> the monster_die function in mon-util is super long
18:58:59 <CrawlCycle> it will surely leave some corpse
18:59:14 <CrawlCycle> but then i might want to test the code with corpses around
19:00:03 <CrawlCycle> put 3 bodies; kill all monsters; repeat;
19:10:46 <CrawlCycle> mons_remove_from_grid(...) in mon-util.cc set the env.mgrid(pos of monster) to NON_MONSTER
19:11:06 <CrawlCycle> but that alone doesn't seem to reset env.mons
19:12:58 <CrawlCycle> does crawl have reset function for the global data structure, such as env and you?
19:13:33 <CrawlCycle> i guess not, never mind.
19:18:08 <CrawlCycle> FixedVector doesn't seem to have a reset method
19:19:48 <CrawlCycle> oh it doesn't need one anyway
20:05:31 <CrawlCycle> the _rest_game function in main.cc seems to do the trick.
20:33:19 <twelwe> You rampage towards the orc wizard! You hit the orc wizard.
20:34:15 <twelwe> please come on please tell me you guys reconsidered wu jian and rampaging, i havent even found a jian altar yet and i get this message??
21:30:22 <Implojin> hi twelwe: re: rampage and WJC, what behavior, exactly, would you like it to have?
21:31:12 <Implojin> i promise absolutely nothing in this regard, but i've looked at the wjc code and it's probably not intractable to make them work together; however, from a gameplay balance perspective, some of those interactions seem possibly broken if they were allowed
21:32:15 <Implojin> for example, i don't necessarily think that allowing rampaging to work with serpent's lash would be a good idea
21:32:27 <Implojin> but i'm willing to have a conversation about it?
21:35:51 <Implojin> wheals had previously mentioned possibly just locking out rampage while playing with WJC; this seems to me like a possibly acceptable alternative too if players would prefer god powers over the ego there
21:36:19 <Implojin> to be honest, i never play WJC, and I didn't take it into account during the rampage implementation; i've seen this question come up a few times and i'd like to smooth that out a bit
21:37:35 <Implojin> my interpretation is that heavenly storm would need no special checks? wall jump probably shouldn't work with rampage at all since it's targeting a wall
21:37:52 <Implojin> serpent's lash seems like it would be pretty broken if it were allowed to have rampage-moves
21:38:36 <Implojin> lunge and whirlwind would be nice to have working with rampage, probably? but there's a technical side to it that both of them take movedelay into account for their damage calcs, I think? and rampage-moves take zero delay
22:03:51 <twelwe> hey thanks, sorry for ducking out for a second. when i first found rampaging it was on a wu jian character and it did not synergize with lunge. it appears to me now that rampaging now triggers an attack if you move one tile towards an enemy
22:03:59 <Implojin> rampage has always done that, but that behavior is separate from the wu jian lunge attack
22:04:58 <Implojin> i think (?) that wjc-lunge will trigger 1 space beyond your actual move, if i remember correctly? (i don't have a crawl build in front of me atm)
22:05:10 <twelwe> i don't understand why rampaging towards an enemy two tiles away does not trigger a lunge
22:06:15 <twelwe> thats my issue
22:06:39 <Implojin> okay
22:06:45 <Implojin> that's understandable
22:06:58 <twelwe> if rampaging effectively gives lunge for free one tile away from an enemy, i don't get why it restricts the god conduct two tiles away
22:08:03 <Implojin> basically, it is the way it is for technical reasons; i wrote the rampage stuff to act instantly (it doesn't even call world_reacts), and the wjc calls are all separate and delay-based if i remember correctly
22:08:11 <twelwe> and just to answer your earlier question i don;t have any feelings about serpent lash with rampaging. i use lash defensively unless i have absolute zero
22:08:19 <Implojin> but that's not to say it's impossible to make it work a little more smoothly together
22:09:28 <twelwe> i play jian more than any other god at the moment and actively avoid rampaging because of the problems with lunge
22:09:28 <twelwe> its good to hear it isnt intentional design though
22:09:39 <Implojin> if i remember, i think i had an attempt at wjc compat written into one of the early rampage commits, but ebering removed that bit before it got merged (probably because it wasn't working)
22:11:08 <twelwe> but in my dream world as a formicid of jian i can lash dig stab serpent lash rampage through two walls towards a detected enemy in zero turns
22:14:21 <twelwe> back in my day a fella could serpent lash and dig out of los of anything
22:35:20 <advil> CrawlCycle I'd again mention that the lua test infrastructure might be a better fit, there's various reset functions there, and the specific one for that case is `dgn.dismiss_monsters()`
22:35:25 <advil> !source moncast.lua
22:35:26 <Sequell> Can't find moncast.lua.
22:35:55 <advil> https://github.com/crawl/crawl/blob/master/crawl-ref/source/test/moncast.lua
22:35:58 <advil> for an example
22:37:28 <advil> in that case most of the test is written in c++, but it still uses lua to set up the monster scenario, because it is *much* easier to do that
23:13:37 <twelwe> testing now with jian, i am definitely attacking off a rampage instead of a lunge one tile away. no way of knowing if this is good, bad, or the attacks are equal
23:14:23 <twelwe> i get stabs on both, so thats great for now
23:16:55 <twelwe> ok to be frank i don't even see why rampaging gives a free attack on movement. this is like 2/3 of offensive jian for free on any armour
23:17:09 <Implojin> hm how do i link a commit here
23:17:15 <Implojin> %git 8bb0483
23:17:15 <Cheibriados> 07ebering02 * 0.26-a0-424-g8bb0483: Prevent Wu Jian martial attacks while rampaging or digging 10(3 months ago, 2 files, 15+ 15-) 13https://github.com/crawl/crawl/commit/8bb0483f987b
23:17:47 <twelwe> ebering ruined that for me specifically by the way
23:17:54 <Implojin> well
23:18:12 <twelwe> the digging part at least
23:18:13 <Implojin> i think it's more likely that ebering ruined it because making it work properly would have involved a bunch of small edge cases
23:18:35 <Implojin> i just didn't write that code to work with WJC stuff at all and nobody brought it up explicitly in review
23:19:19 <twelwe> dig stab lunging wasn't that problematic but i didn't know it was done at the same time as rampaging
23:19:54 <twelwe> i think whirlwind should not work with rampaging for sure
23:20:25 <Implojin> i think it would be okay, in principle, to make wjc lunge activate post-rampage
23:20:46 <Implojin> probably it would also be fine to make whirlwind work?
23:21:06 <Implojin> for the player to get free whirlwinds off of that they'd still have to have a rampage target nearby
23:21:07 <twelwe> first i want to say that i don't agree with rampaging giving an attack, but that if it does, it should absolutely stack with WJ lunge
23:21:38 <twelwe> thats 1
23:22:18 <Implojin> the thing about rampage giving an attack
23:22:18 <Implojin> hm let me see if i can find my design notes
23:22:20 <twelwe> thats 1+ whirlwinds on a single turn
23:22:47 <Implojin> oh, right
23:22:54 <Implojin> i found it
23:22:54 <twelwe> so, imagine you can rampage whirlwind, then lash back for two more
23:22:55 <Implojin> ok
23:23:10 <twelwe> thats four attacks on one turn
23:24:10 <Implojin> so the thing about rampage granting an attack, is that it's implemented as an instant reposition in move_player_action, prior to the player move taking place
23:24:34 <twelwe> so, not intentional?
23:25:16 <Implojin> well, it's an intentional part of the design, but it's also that implementing it differently would have required some big refactoring of move_player_action
23:26:08 <Implojin> it would have been possible to implement it as an active ability, but i explicitly didn't want to do that because crawl targeters are irritating
23:26:47 <twelwe> no, walljump as activated is already hard enough that it discourages movement active abilities
23:27:54 <twelwe> ok that clears up everything i wanted to know. i would like to just advocate for lunge and rampaging to stack at this point
23:27:54 <Implojin> but the consequence of implementing it that way as an instant "free move" prior to the actual move or attack action
23:28:02 <Implojin> is, well
23:28:17 <Implojin> all of that extra stuff that uses the rampaged bool lower down in move_player_action
23:28:39 <Implojin> and wjc is one of those things
23:28:59 <Implojin> the vague "host of complications" that was mentioned in that commit
23:29:07 <Implojin> yeah.
23:29:24 <twelwe> i understand WJ is hugely problematic with movement in the current code
23:29:28 -!- amalloy_ is now known as amalloy
23:29:42 <Implojin> the movement code, in general, seems to have kind of a lot of special checks running through it
23:30:09 <Implojin> i didn't want to write any of that stuff; i just wanted to implement that ego as a single call of move_player_to_grid and be done with it
23:30:16 <Implojin> but nothing is ever that easy
23:30:56 <twelwe> beyond the technical discussion, what do you think balance-wise about jian and the ego overlapping in these ways?
23:32:01 <Implojin> my opinion is that it's not a big deal and the ego seems fun to me, but i'm totally biased, obviously, and i never play wjc to begin with
23:33:30 <Implojin> i'd be willing to take a look at fixing up lunge / whirlwind compat, when i have the time
23:33:41 <twelwe> some thoughts then from a hugely frequent WJ player is that it steps on too many toes of the god to both move that quickly and attack freely, because mobility and free attacks are the entire concept of the diety
23:34:08 <Implojin> i think? it's probably not worth the time to try to make rampage/lash work together
23:34:25 <Implojin> that seems likely to end up horribly broken balance wise
23:34:42 <twelwe> lash and rampage would be way to powerful
23:35:10 <twelwe> i'm more concerned with lessening the bonds between jian and rampaging than strengthening them
23:36:05 <twelwe> lash and rampage working is effectively a 0 turn range 4 controlled blink and dithmenos has that territory
23:36:31 <twelwe> not 0 turns for dith, but you get what i mean
23:39:16 <twelwe> i just think its so weird that you can worship jian, rampage from one tile away and get a free attack, rampage from two tiles away and get no benefit. closing thoughts.
23:40:02 <Implojin> sure, i hear that
23:40:30 <Implojin> (please remember i do not have commit access to crawl repo)
23:40:42 <Implojin> but i can look at fixing that up and putting in a pr sometime
23:41:16 <twelwe> oh its all good man, ill burn dev piety for this
23:41:42 <twelwe> they took my lash dig lunge stabbing away, its war
23:46:00 <twelwe> rampaging is also seeming to block lunge when i swap positions with an ally towards an enemy
23:46:41 <twelwe> excuse me, that is incorrect