Touche, I just noticed in one of the dorp threads that the Marduk legs had the -enm listed.
Touche, I just noticed in one of the dorp threads that the Marduk legs had the -enm listed.
I haven't been following the thread very closely recently, but my wife has full Marduk so if I can figure out the controls for an enmity value test, I can do it.Originally Posted by Ashira
I don't think her character or my friend's char has any merits in enmity. I'm assuming if I look back a few pages I'll find the controls, but I'll do it later tonight.
i know that there has been work showing that sentinel caps +enmity at 100, but has any work been done to show that this is the actual cap and not just a static value used while sentinel is in effect? eg if(sentinel){enmity=100}else{enmity=sum(gear)}
also, has anyone tried using the horror head to find out if the rules for -enmity function all the way down to -100? it occurs to me that there may be some bizzare corner situations where the insane sum of planning to hit -100 enmity may be useful, not to mention just knowing if there would be any possible application of a -enmity setup such as for benediction or if it caps out too early. by my calculations using "realistic" gear (not mahatma cape, not the red vs blue obi, etc) it's possible to accrue -68 enmity with merits on whm (think full raven, etc). can anyone think of a situation where this might be useful?
Curebombing a SE-Kclub Drk and trying to live afterwards?
I calculated you could actually get about -85 with a full merit Dirge BRD. I don't know if Ghorn affects Dirge right now though (lvl3 Dirge is -16 enmity).
Also, I believe the person who ran the Sentinel test actually did attempt to use a +1 or +2 gear in addition to Sentinel and received the same 100% increase.
i didn't even figure in dirge... good point. i'm told that gjallarhorn does effect it, but i can't test it for several dozen more jadeshells. (why did i start this suicide course...) i think dexter did some research on it after he got his horn and concluded that it was nice, but probably not worth capping out over troubadour. think he settled on 3tro, 1ni, 1 dirge, 1 sirv.Originally Posted by Kaeko
as for the sentinel test, that's actually what i was referencing. it's possible that sentinel simply fixes your enmity at 100. IE it may be that you could actually exceed +100 enmity, but sentinel overrides your natural enmity and replaces it with 100 while active. EG if using dispel:
if(sentinel)
{CE+=dispel_CE*(1+1)}
else {CE+=dispel_CE*(1+enmity/100)}
such that if your enmity gear exceeded 100, sentinel might actually negatively affect enmity. while i'll admit this is highly improbable and that sentinel probably simply sets enmity to the cap, it might be a curious test to try if bored. as i don't own a horror head II, i can't test it myself though.
I didn't realize anyone had tested Dirge with Ghorn. I know a lot of BRDs were interested in this info in a BRD Merit thread awhile back. I'd love to see whatever he did on this since it's actually something directly useful in merit choice.
Also, to Wizard, if your wife could test Marduk feet that would be awesome. All you have to do is have a 3rd party pull, then other 2 people match Enmity Merits. Then 1 person goes naked, other naked + Marduk Feet.
Cast Dispel one after the other.
Then repeat but alternate who goes first.
In both instances, the 2nd caster should maintain hate. This is if the 2 players match Enmity. If they do not match, you can safely say that the - enmity stat on Marduk does exist. This is the simplest way to test w/o getting into very formal methods.
Little update...
Following jobs are 100% Completed...
MNK
WHM
BLM
RDM
THF
PLD
BRD
BLU
COR
SCH
I ran the test Ismarc suggested about having 3 players, player with 2nd highest hate zones, then player with highest hate zones. The mob then goes for the player of lowest TE... Check if the player with 2nd highest hate had enmity reset...
Result was that both players that zoned had enmity reset. This means it is possible to get your enmity reset without zoning/logging while with hate. I think from this my conclusion is that...
Enmity Reset occurs ONLY if the mob chooses the player as the target, but cannot reach him. If the mob does not attempt to target the player, an enmity reset cannot occur.
Also, dying when the mob has not targeted you will not reset enmity. We tested this by having a NIN mijin another mob while not currently with hate, reraising, then checking to see if enmity was reset - was not. Practical example of this is if a player dies from Hurricane Wing at Fafnir when it was not on him, his TE will not reset when he reraises unless the dead player has the highest TE while dead (would require those on top to drop).
You see that in Campaign a lot too.
Someone gets on hate list, get's AoE'd to death, runs off to heal.
Mob beats up whoever it was fighting, runs over and kills the weakened person, laughter ensues.
Interesting. I'm still convinced we could do some advanced enmity bouncing using THF.
If indeed hate is reset upon the mob checking for the character, and not only on zoning/dying when hate, then you could do something like this to remove hate from every DD at once in certain situations:
- Main tank has capped hate. All DDs do their thing until they are close to capped hate (maybe they pull hate once and then chill for a bit)
- THF takes half of tank's hate, bringing him below all the DDs
- ES sleep if possible, or bind, etc so DDs have a chance to logout.
- Mob goes for the DDs. All DDs logout (or zone out if zone is close). When the mob wakes up it should go down his enmity list of DDs, they are all not available, everyone gets reset until the mobs gets down to the Tank.
- THF transfers hate back to tank.
- DDs zone back in.
- Repeat.
Although, maybe that situation could cause a mob to go yellow...
I'm assuming there's the exception for any AoE hate-reset moves such as Anticas' "Sand Trap" move...? Which, in particular, seems odd since, although it will obviously go after mages that are out of range upon hitting all of the melee/tanks with this move, it never seems difficult at all to re-establish enmity immediately afterwards. Perhaps Sand Trap is only an enmity reduction... although I don't think I can recall ever seeing Sand Trap not cause the mage(s) to be on the top of the hate list. I can't think of any other AoE enmity reduction/reset moves at the moment to compare it to.
Maybe Sand Trap et.al. only marks people as inactive on the hate list, like when you log out and back in, you don't get hate back until you tag the mob again, and then you go back to your original enmity value.I'm assuming there's the exception for any AoE hate-reset moves such as Anticas' "Sand Trap" move...? Which, in particular, seems odd since, although it will obviously go after mages that are out of range upon hitting all of the melee/tanks with this move, it never seems difficult at all to re-establish enmity immediately afterwards. Perhaps Sand Trap is only an enmity reduction... although I don't think I can recall ever seeing Sand Trap not cause the mage(s) to be on the top of the hate list. I can't think of any other AoE enmity reduction/reset moves at the moment to compare it to.
Heavy Strike too.
For a while I was under the assumption that it cleared hate, then I decided to be a tard and full on 2hr WC a steel cyclone into him, and he nailed me with two while I was being curebombed, and then critted me into the floor before turning to someone else.
Probably didn't help that I was landing crits the whole time.
you make a very compelling argument. maybe sand trap does NOT reset enmity, but is a reduction and sets the HC to false. also, i can't believe i was right about that hate reset on death if not the target! woo! i found something new! /em has a cookie.Originally Posted by Freysi
here's an odd question for you. how does the hate cap interact with accomplice and collaborator? if the use of the ability would put the thf over the hate cap, does it still steal hate? it seems to me that there's 4 possible outcomes from most to least likely:
a.) thf steals hate as normal, but simply reach enmity cap and do not receive all of the enmity stolen.
b.) thf steals only as much hate as is needed to cap out both categories and no more.
c.) thf steals full enmity from other player and excess CE/VE is converted to uncapped type and applied there.
d.) thf steals full enmity from other player and somehow exceeds hate cap. (NOT LIKELY)
let me postulate a situation. you're pretty late into a fight and your pld has built up capped CE and a considerable chunk of VE, but your mages are closing in on capped CE and you're afraid that if he gets clocked, your mages are going to beat his TE. numerical example:
PLD: 10,000 CE
5,000 VE
WHM: 8,000 CE
3,000 VE
if a thf uses accomplice while at capped CE but 0 VE, they could effectively negate all the heavy CE that the whm has been building up since the start of the fight from cure5's. while i'm not sure how often this would be applicable (what requires that much finesse and control over hate, really?) having more tools in your toolkit are never a bad thing. after all, batman never knew when he'd need some odd gadget from his utility belt, right? ^^
Would be incredibly hard to test something like Sandtrap so that'll be pretty much speculation
The Accomplice thing I can look into.
Another issue I'm looking at (more like just formulating rather than testing for now) is rethinking the idea of this HC. We really have no clue how SE truly programs this stuff in so the best we can do is model things as simply as possible such that all observable cases are covered amply.
My new theory is that the mob doesn't store some separate HC counter, but only a list of TE values and the players to go along with it. It's the CHARACTER that stores a list of mobs he has pissed off. This may explain how you can 'clear' hate by zoning and logging but not clear your enmity.
So based on this potential theory, the mob stores TE values and the players with it only. The mob can remove players and their associated TE by attempting to target the character but failing. Before the mob attempts to target someone at the top of its TE list though, the game checks the PLAYER in question to see if the mob wanting to target is listed. If the mob is not listed on the player's list, the mob chooses next target (does TE reset occur here? possible test). The player's list can be wiped by simply zoning, dying etc.
what if u bind the mob by a zone, have a person that isnt on top of the hate list get in range (to get the mob to target him) then zone? I dont think it would work, just an idea.
You could test sandtrap to answer a couple of questions pretty easily. Usually a tank vokes immediately after sandtrap and gets hate back, but that could just be the VE from voke exceeds the whm TE. Instead have the tank simply hit the antican once and see if he gets hate right back. If he does, it should mean that sandtrap just takes you off the list until the next action, but you keep TE. If it doesn't, then sandtrap most likely reduces TE to minimum (1 CE?) and it is the VE from voke that gets hate back.
why the new formulation and discarding of the hate counter? this seems unnecessarily complicated and occam's razor tells us that we may be overthinking this. just my 2c till i see the reasoning though.Originally Posted by Kaeko
I think if I were to be truly scientific about it, there is 0 reason to formulate a new theory simply because the current one amply describes all test situations thus far. The reason I felt it necessary has to do with the illogical way this system would have to be programed. According to the system I described in the post, the mob "knows" the player has zoned right when that happens, which requires a check for this constantly... This seems overly complex.Originally Posted by Spekkio
In this new idea, certain data is stored or associated with the player, while certain data is stored with the mob. By saying the "mob list" is associated with the player, it is extremely simple to "wipe" this list when the PLAYER makes an action. I just found it illogical that something a player does would be immediately checked by a mob, who isn't doing anything?
I hope that made a bit of sense. Also, I feel the old model will fail if we start to look at situations with Sleep.
i'm not sure i totally agree. the mob needs to update its TE list constantly and it needs to identify the top player on the hate list. you said yourself that it updates hate at fixed intervals (some obscure case where it would flip flop hate i think in the VE testing) and as such, it must examine every player. it's possible that the mob will actually sort the list of players (i think DL will spawn his copies at the 3 top enmity targets, but don't quote me on that) and since checking for validity is O(n) vs sorting which is at best O(log(n)) iirc, (been out of CS for 2 years. fuck IT hell...) it may be that the system sets a validity bit (the HC in your nomenclature) so that when it sorts for hate in a list of potentially fifty targets or more (oh hey! that's a cool test! is there a limit to the number of people who can be in a hate list? can one hundred people be on it at the same time? might give us some hints there.) that could be a significant savings computationally. while i'm not discounting that the theory of the HC may be wrong as it always seemed a little unnecessary to me in the first place, i think there may still be more merit in it than you give credit.Originally Posted by Kaeko
please don't misconstrue my comments as insults or put downs though. my only goal here is to give you constructive, productive criticism. i have the utmost respect for the work you've accomplished and the scientific rigor you've applied to your tests. you have a fascinating, repeatable series of experiments with good controls and have done more to further the understanding of a completely misunderstood field than any ten people i know. just as an example (and not to toot my own horn) knowing that when i get back up at faf after getting winged out, i may end up high on the hate list from even a cure 1 or a blindna, that may cause me to reconsider hitting with that extra nuke while weak. alright, faf's a bad example b/c lolfaf, but you get the point.