This was reported a while ago. Prior to the last patch it was confirmed as fixed and moved to the resolved forum. After the patch it seems that they once again are not headshotable. Were the Eom Sentiens, and possibly Pli Liakos changed to Greater Akhevans after the patch? Also what mob types are the liquid shadows supposed to be?
Same in Aten Ha Ra raid - formerly headshottable Pli Liako are no longer headshottable. I'm hearing same applies to shadows in Doomshade (no longer headshottable) but haven't experienced that one myself. Guessing Oubliette chainers likely have the same issue too.
Sorry to you rangers out there who have grown to love their headshot but not to the ones who make a ranger for easy mode soloing with OP damage for eras being hunted in. Personally I have never liked the headshot ability (even as a main ranger when it first came out). So I for one welcome any and all nerfs to headshot. If Headshot and assassinate had their damage tuned down to more what decap looks like then i’d have no problems with them. But, again I stress, this is my personal stance and opinions and am not trying to create any sort of contention about the topic. Just my humble 2 cents.
Bug or not, all of the raids where body types have been changed so headshot/assasinate/decap no longer work (so they now to they take longer to die) need to be adjusted especially those with enrage mechanics, even if it is just making the enrage timer later.
I said it in a different thread but... They just need to disassociate headshot/assassinate/decapitation from body typing. Put a flag on the NPC's that can be toggled 0 or 1. Either it has a head an can be shot/lobbed off or not. Have a separate one for assassinate for NPC's deemed by the development team to be susceptible. They would then have better control over all of these abilities (and possibly other future ones, using a similar method). NPC's that require a special threshold to not break an event/script could use these flags from preventing the script/event from being inadvertently broken. (this issue comes up more frequently with a handful of lower-level events, like Ranger and Berserker epic 1.5/2.0, but could apply to one-shotting Vishimitar before the script locks HP values, etc..)
I agree 100%. Mobs should not have a body type "template"...they should just be mobs that have attributes/flags. Is it an animal? 1 for "yes", 0 for "no". Is it undead? Yes or no. Can it be headshot? Yes or no. Is it immune to root/snare? Yes or no.
If everything with a head could be headshotted that would be way more powerful than headshot was designed to be. Theyd have to remove heads from half the mobs.
The Body Types change was made for performance and coding improvements. What you suggest are four operations in sequence checking against a list of 'flags', or properties of an object. So that's four times the calculations made upon a bloated database where every mob has new fields for these little bits of data. The Body Type holds all the discrete answers to the four questions you ask, in one single data point. If you understand coding you understand why they made this change, and how they aren't going to back away or make a bunch of 'flags' for every special case, that defeats the purpose. If people have identified a real point of pain that these changes have made (Headshot in this thread's example) You would do best to understand completely the mechanic you are after, and propose a new body type to cover that. My belief is they should break the Undead body type out into two categories (helping the invis and headshot issue): Undead Corporeal, Undead Non-Corporeal. I.E. You can headshot a zombie, you can't headshot a ghost (shade,spectre,etc.). They might be willing to break out some of the rigid Body Types to more specific use cases, I doubt they just hobble the performance benefit with 'flags'.
It's likely the way the post was worded.. but from a coding standpoint. This does not have to be the case. Ranger attacks w/ bow, attack checks if HS is available (HS/m) if yes, check mob vulnerable to HS (y/n). Continue. This happens already with body types. Same goes for snare, undead, assassinate, decap, etc.. There is 0 reason to cascade those checks. None of the abilities overlap like that. Each would be an individual check... which is how it currently operates.
If the Body Types change was not for performance over the current code, will it improve performance over the current method in the future? If the change wasn't for performance, what was it for? If it was a change purely for coding convenience that would kind of upset me, in a game design changing way for convenience? seems weird.
My assumption.. is that is is a single variable used for multiple checks. Mob type X is immune to snare, HS, Decap, and Sees invis. Mob type Y is immune to snare, HS, Decap Mob type Z is immune to snare. This would reduce DB bloat and object size when dealing with the code checks. Instead of having every possible flag, you associate a specific variable to have all of those desired properties. This makes the program smaller, thus easier to distribute (especially early Digital Download days), easier to reference, easier to mass create new content. The problems come in when you start changing that... and we're seeing it with the consolidation of body types.
and either way of it, these changes should have been on test server longer and game breaking patches should not be pushed live. How would they measure metrics of lag if so many people can't play their characters (I sat 6 accounts out while they sorted out broken specializations) The magic excuse of the week is LAG, but Laggy game > no game play at all because it's broken, or really awful QoL changes to HS and SI, etc that weren't asked for or intented, but went live.
Agree with both of you. Just sayin' Body Type consolidation is a done deal at this point. Posting to test, then patching next day, and patching day after that, then going live. Bad idea, but it really screams to me they aren't backing down from that consolidation. I proposed a solution, which may suck or not, in Vets lounge. That's about all I have to contribute.
I don’t think the changes had anything at all to do with lag and that they were indeed making a better template for new content designers going forward so that the coding side is not quite as cumbersome as it has been for the past.
Fair enough, that's a good enough reason I suppose. Honestly maybe I was too harsh in my statement, if it was only for coding convenience. But while I'm telling the truth, I get the sinking feeling, day by day, there just keeps being too much changed for me to have fun re-learning.
All of these people who have payed and loved Everquest for so long must have wanted a whole new game. Too much change for the sake of change. I know devs gotta dev, but Everquest is already a damned good game, maybe YOU, the devs, should like it more. Or like who plays it more? Sometimes the development, or at least the response to players is like calling them Filthy Casuals, or Elitist "Do you not have phones?" Work to preserve Everquest, not overwrite it aight?
