Accomplice and Collaborator Problems

[Ulth]

These job abilities are meant for keeping hate off the squishy people in the party right? Only the squishy people can't be anywhere near the bosses anymore. Sort of defeats the purpose of keeping hate off the white mage if to do so thieves have to drag the mobs over and it kills him with an AoE attack. That is why the range on these job abilities needs to be increased. Basically if the mages are in range to cast cures on the thief, the thief should be able to pull hate off them.

[Grekumah]

As the system process involved in checking the enmity surrounding the player causes additional stress on the server, we do not have any plans of adjusting the range of Accomplice and Collaborator.

[Malthar]

Ok Grekumah, I know you're new and just translating the dev's response, but that statement makes no fricken' sense!

He wasn't asking about checking the enmity surrounding the player, he was only asking if the range of accomplice and collaborator can be expanded.

Are you sure you're responding to the right thread?

[Bayohne]

He wasn't asking about checking the enmity surrounding the player, he was only asking if the range of accomplice and collaborator can be expanded.
Similar to the scholar's special ability Caper Emissarius, using those two abilities would affect the enmity of characters other than yourself, which as we mentioned, places an additional strain on the server. Therefore, it was decided to limit their effective radius to what it is currently.

[FrankReynolds]

Similar to the scholar's special ability Caper Emissarius, using those two abilities would affect the enmity of characters other than yourself, which as we mentioned, places an additional strain on the server. Therefore, it was decided to limit their effective radius to what it is currently.

Did that make sense in your head as you wrote it? Seriously. Think about it. It makes no sense. Distance has nothing to do with server load.

[Balloon]

Eh. I read it as "Since the ability causes some strain to the server we intentionally limited it's usefulness, making it so that it is less likely to be used." The ability causes the same amount of strain at any distance, but it's less likely to be used when you have to run over to the whm to use it. It's an incredibly disappointing response, either way, since it's usefulness in long battles is hampered by how quickly melees cap enmity.

Either that or they've just started playing Mad Libs with their responses.
As the system process involved in ________ causes ______, we do not have any plans of adjusting the ___ of ____.

Funny thing is though, I'm sure that they've gone on record as saying they want THF to be able to manipulate party members enmity more, to be able to control the flow of battle. Hampering an ability like accomplice isn't exactly conducive to that.

[Vold]

I was with Frank all the way on this til this:


Eh. I read it as "Since the ability causes some strain to the server we intentionally limited it's usefulness, making it so that it is less likely to be used."

So now it's like, ooooooohhhh yeah that actually makes sense to me at 2am. And I wish they could dump the PR speak and make sense in their responses. But, alas, the pain of the PPM MMORPG overlords.

[Malthar]

Just how much server load does a one/five minute ability generate with all the tons of abilities and spells flying back and forth; I wonder...

[dasva]

Yeah the more I think about this the more I'm curious myself. Why does effecting the enmity of another player effect server strain and what does distance have to do with that? Heck you can gain enmity on a mob from farther than you can see if you know what you are doing so not sure why 1/3 that distance is too much if it's another player

For that matter what about Trick Attack and Decoy Shot? They effect the enmity of other players and work at ranges twice that of collaborator. Fairly certain Super jump with spirit surge does as well

[FrankReynolds]

Eh. I read it as "Since the ability causes some strain to the server we intentionally limited it's usefulness, making it so that it is less likely to be used." The ability causes the same amount of strain at any distance, but it's less likely to be used when you have to run over to the whm to use it. It's an incredibly disappointing response, either way, since it's usefulness in long battles is hampered by how quickly melees cap enmity.

Either that or they've just started playing Mad Libs with their responses.
As the system process involved in ________ causes ______, we do not have any plans of adjusting the ___ of ____.

Funny thing is though, I'm sure that they've gone on record as saying they want THF to be able to manipulate party members enmity more, to be able to control the flow of battle. Hampering an ability like accomplice isn't exactly conducive to that.


All I can think is that maybe the spaghetti code checks the emnity of everyone around every time you use it even though it is single target and for some reason they can't / won't figure out how to limit that to party members, or just the target? Anyways, terrible logic.

They say they want thief to have a way to get rid of emnity. They may as well give them MP and put them on some staves if it's gonna involve running all over the place.

[Balloon]

Yeah the more I think about this the more I'm curious myself. Why does effecting the enmity of another player effect server strain and what does distance have to do with that? Heck you can gain enmity on a mob from farther than you can see if you know what you are doing so not sure why 1/3 that distance is too much if it's another player

Server strain is becoming their new PS2 Limitations - but that response is just incredibly poorly worded.

Though transferring enmity is just a case of removing enmity for one player and adding enmity to another. I don't see what kind of strain that can really give considering near enough every JA and spell in the game adds an amount of enmity, including hitting things, and some remove enmity, like high jump, volatile lowering on it's own, and getting hit. Enmity changes are performed thousands of times per second in this game, so.. a couple of hundred thfs being able to accomplish would cause undue strain to the server? I don't see how..

[Calatilla]

Because THF getting anything useful would be bad, they gave the party hate stripping ability to SCH and then turn round and tell us that enmity is the main focus of THF. And now they`re saying our broken abilities are working as intended.

Heres a suggestion Dev Team, go play THF for a week and tell me it's fine.

[Byrth]

If what they've said in this thread was accurate, a valid form of protest would be spamming Collaborator every minute whenever possible. I'm pretty sure it's not, though, so such a protest would be a waste of time.

[Kjotu]

Server strain is becoming their new PS2 Limitations - but that response is just incredibly poorly worded.

Though transferring enmity is just a case of removing enmity for one player and adding enmity to another. I don't see what kind of strain that can really give considering near enough every JA and spell in the game adds an amount of enmity, including hitting things, and some remove enmity, like high jump, volatile lowering on it's own, and getting hit. Enmity changes are performed thousands of times per second in this game, so.. a couple of hundred thfs being able to accomplish would cause undue strain to the server? I don't see how..

you're missing an important part of how the ability works: enmity is stored on a mob, not a player. the problem is that when a player uses accomplice on another player, the server does not have a simple way to access all enmity towards the player. the only way to get this is by iterating over every nearby mob, and iterating again over each of their enmity lists checking to see if they have enmity towards the player.

it should be easy to see at this point that in certain situations, increasing the range could have a pretty significant impact on performance

[Byrth]

If the OP was asking about increasing the radius of monsters that are checked when someone uses collaborator, yeah.

But he just wanted to be able to use it from further away, so it's purely a "we made it less useful so you wouldn't use it as much" deal.

[Balloon]

you're missing an important part of how the ability works: enmity is stored on a mob, not a player. the problem is that when a player uses accomplice on another player, the server does not have a simple way to access all enmity towards the player. the only way to get this is by iterating over every nearby mob, and iterating again over each of their enmity lists checking to see if they have enmity towards the player.

it should be easy to see at this point that in certain situations, increasing the range could have a pretty significant impact on performance

That's a good point, one that I didn't think of when writing. I'm not really that knowledgeable on the intricacies of enmity, but I know that the enmity stolen from accomplish is based on the user, not the target, and stops working when the user is 20.6 yalms away from the mob - Even if the target is outside this range the hate will be stolen. In that sense, I feel it just checks the enmity tables of monsters nearby the user, and not both players. So using it on a member 20 yalms away shouldn't increase or decrease the performance vs using it on a member 2 yalms away.

I also wonder how different this operation is than casting cure on someone, in both instances hate tables have to be updated for the user and target, and the users hate table has to be updated for all the ones the target has acted on.

That said, a lot less simple than the example I outlined, so yeah. I was wrong about that.

[Aeron]

As the system process involved in checking the enmity surrounding the player causes additional stress on the server, we do not have any plans of adjusting the range of Accomplice and Collaborator.

And yet another example of why PS2 support needs to be dropped and the servers overhauled!

[Ulth]

you're missing an important part of how the ability works: enmity is stored on a mob, not a player. the problem is that when a player uses accomplice on another player, the server does not have a simple way to access all enmity towards the player. the only way to get this is by iterating over every nearby mob, and iterating again over each of their enmity lists checking to see if they have enmity towards the player.

it should be easy to see at this point that in certain situations, increasing the range could have a pretty significant impact on performance

I'm not asking to have the range of the mobs it affects to be increased, I'm asking to increase the range of the player it is used on. If it's stored on the mob that's all the better. It just checks all the mobs AROUND THE THIEF at the same distance as before, 8.5 yalms. At which point it checks those mobs' hate list, finds the hate value for the player it was used on, who can be far away, then decreases it by an amount, and increases the thief's hate by the same amount. I don't see how that is anymore strain on the system than before. Unless the strain is from thieves actually being able to make use of it now.

[Kjotu]

If the OP was asking about increasing the radius of monsters that are checked when someone uses collaborator, yeah.

But he just wanted to be able to use it from further away, so it's purely a "we made it less useful so you wouldn't use it as much" deal.

both CM responses seemed to indicate that the OP was asking about the steal radius (that's what I thought too, actually), and balloon was wondering how the radius would affect the server

[Byrth]

Well, the OP was talking about putting mages in danger by having a THF (potentially with hate) run over to them to activate these JAs. The JAs have a 12.6 yalm activate range, but work on any monsters in a circle with radius 20.6 yalms around the target. So the issue is not the effect range (which is sufficient and would cause the increased server load per use if increased), but the activation range.

Assuming the Community Rep knew what they were talking about, their statements indicate that Accomplice/Collaborator ranges are small so they won't be used as much because they cause unreasonable server load when used under the current conditions.

[Balloon]

I was talking about distance, not radius too. I do wonder if the Community reps were talking about radius now. . . But I still interpret it as intentionally limiting it.

[Bebekeke]

Anyone who's ever DC'd in an important fight whilst in an alliance with a THF is now never going to invite THF again because of the extra server load that they can cause...

[Grekumah]

Greetings, everyone.

Since there seems to be some confusion, I’d like to clarify with a longer explanation about how this actually works.

When it comes to range for abilities there are two types:


Range needed for ability usage
Range that is checked internally when an ability is used


The requests in this thread to increase ability range fall into the former category, and the server stress that was mentioned in the previous post is referring to the latter.

When using Accomplice and Collaborator, the game internally checks the enmity of all characters and monsters in a certain range around the player using the ability. As another example, when using Trick Attack, Decoy Shot, or Super Jump, the system checks the enmity of the players and monsters in front or behind you. For these abilities, the range of what is checked is limited to directly in front or behind you, and because of this valid distance is longer than Accomplice and Collaborator.

With that said, it’s not as simple as increasing the range (#1 above) without giving consideration to the effects on #2. Meaning that if we were to increase the range for these abilities so they can be used at a greater distance, the range for the internal enmity check would also increase causing increased server stress.

Additionally, when Accomplice and Collaborator were created, the development team pushed the settings to the limit for the internal enmity checks, and due to this it is not possible to expand the range any further.

[Malthar]

Hmm... Take back our servers they took for FFXIV so we can have a greater limit? ^.^

[Selindrile]

Thank you for the clarification Grekumah, and that's as we suspected, but why not increase the range of (1), without increasing (2), we would accept and understand that this would potentially sometimes make the effect we hoped for fail, if the monster in question was outside of the range of (2), but I believe this would be an acceptable risk and compromise for most of us, just clearly explain the max range of both (1) and (2) with the change in the help text.

[Malthar]

What he's saying is that you can't increase (1) without (2). They go hand in hand and wouldn't make sense otherwise.

[Dazusu]

I find it interesting that the server 'stresses' checking the enmity of monsters in a 10 yalm radius; I find it more interesting there's concern about doubling that radius to 20 yalms. As a software engineer; today I learned that iterating through an NPC array within a 20 yalm radius is intensive. Oh boy... smh.

Not to mention there's usually <1000 people logged in at all times now.

Perhaps they're using Pentium II processors (...or working with legacy spaghetti code)

[Xsilver]

I wonder how the supposed limitations he talked about affect hate reset AoE TP moves from NMs that have a range of more than 15-20'.

[Glamdring]

Greetings, everyone.

Since there seems to be some confusion, I’d like to clarify with a longer explanation about how this actually works.

When it comes to range for abilities there are two types:



Range needed for ability usage
Range that is checked internally when an ability is used



The requests in this thread to increase ability range fall into the former category, and the server stress that was mentioned in the previous post is referring to the latter.

When using Accomplice and Collaborator, the game internally checks the enmity of all characters and monsters in a certain range around the player using the ability. As another example, when using Trick Attack, Decoy Shot, or Super Jump, the system checks the enmity of the players and monsters in front or behind you. For these abilities, the range of what is checked is limited to directly in front or behind you, and because of this valid distance is longer than Accomplice and Collaborator.

With that said, it’s not as simple as increasing the range (#1 above) without giving consideration to the effects on #2. Meaning that if we were to increase the range for these abilities so they can be used at a greater distance, the range for the internal enmity check would also increase causing increased server stress.

Additionally, when Accomplice and Collaborator were created, the development team pushed the settings to the limit for the internal enmity checks, and due to this it is not possible to expand the range any further.

thanks for the explanation. unfortunately, this leads to abilities that are virtualy useless under current game play. with most parties making absolutely no effort to keep hate on the tank the thief is forced to move all over the map. with this system as currently implemented the thief has to run almost to the backline to use Accomplice/collaborator then run back to the tank-carrying all the hate he's trying to shift in the hopes that for the time it takes to get off an SATA WS on the mob from behind the tank and then freeze it with conspirator, all while the mob is shifting position and the party is chasing it. Pulling it off is a miracle. and I don't understand the load, WE are manually designating the target when we use either ability so why the need to check all enmity? a single check, only on the designated character is all that is necessary. making it instant means no need for a continuous check. and if these are all a flat numerical value at the time of use... well what's the problem? change the mechanism in line with how the ability is supposed to work, because it sounds like as is you created a lot of unnecessary load for single-target abilities. Now, if the ability stole the enmity for all in range and put it on the thief, I could see the issue.

[Karbuncle]

Greetings, everyone.

Since there seems to be some confusion, I’d like to clarify with a longer explanation about how this actually works.

When it comes to range for abilities there are two types:


Range needed for ability usage
Range that is checked internally when an ability is used


The requests in this thread to increase ability range fall into the former category, and the server stress that was mentioned in the previous post is referring to the latter.

When using Accomplice and Collaborator, the game internally checks the enmity of all characters and monsters in a certain range around the player using the ability. As another example, when using Trick Attack, Decoy Shot, or Super Jump, the system checks the enmity of the players and monsters in front or behind you. For these abilities, the range of what is checked is limited to directly in front or behind you, and because of this valid distance is longer than Accomplice and Collaborator.

With that said, it’s not as simple as increasing the range (#1 above) without giving consideration to the effects on #2. Meaning that if we were to increase the range for these abilities so they can be used at a greater distance, the range for the internal enmity check would also increase causing increased server stress.

Additionally, when Accomplice and Collaborator were created, the development team pushed the settings to the limit for the internal enmity checks, and due to this it is not possible to expand the range any further.

I wish I wasn't the only who understood you the first time :(

[Kari]

I wish I wasn't the only who understood you the first time :(

It wasn't a lack of understanding the situation, it was "How the hell are your servers and code THAT awful?"
There's no reason this should cause any noticeable stress. Unless this ability is used thousands of times in a short period...

[Karbuncle]

I agree it shouldn't, but, yah, some people did miss the concept of his first post entirely.

Also, based on how he described it, the background server load of this ability might be higher than you think... Its technically running "checks", maybe not a thousand times a second, but a high amount of checks to constantly keep track of both enmity generated and # of applicable players in range, so your entire party. So I mean, there's a good chance that it having to run checks to keep up with enmity and players in range you can steal from (with those players moving in and out of range alot), recalculating their enmity when they come back in range (if thats how it works) and the fact its a 13 year old game clearly not able to use the efficiency we enjoy in todays computers... I can see their reason as at least plausible.

maybe not true, but I can conceive of its plausibility.

[Ulth]

I think I might still be confused. The cause of the stress is from the number of mobs it has to check. You don't want to increase the range because you think it would cause more mobs to be checked. Wouldn't it make more sense instead limit the number of mobs it can check? Because if you aggro a room full of mobs they aren't going to politely wait outside of 10 yalms. I've seen people farming have a whole zone worth of mobs right on top of them. Also why does it need to check all the characters' enmity, wouldn't you need only the enmity of the character who is the target, and the character who is the user?

[MDenham]

Perhaps they're using Pentium II processors (...or working with legacy spaghetti code)If they're still using the original servers from 2002, they may very well be Pentium IIIs running at sub-1GHz speeds.

[FrankReynolds]

I'm confused because on the server side, it should need to keep track of EVERYONE's emnity in order for the game to function at all. If the server didn't always know who had hate and how much, some clever programmer would have skipped the claim bot and went straight to the "Take anything you want" bot.

This reminds me of the time our website went down a slot in google's search rankings and the SEO manager calmly explained to the president that we had pissed off the robots.

[Dazusu]

I agree it shouldn't, but, yah, some people did miss the concept of his first post entirely.

Also, based on how he described it, the background server load of this ability might be higher than you think... Its technically running "checks", maybe not a thousand times a second, but a high amount of checks to constantly keep track of both enmity generated and # of applicable players in range, so your entire party. So I mean, there's a good chance that it having to run checks to keep up with enmity and players in range you can steal from (with those players moving in and out of range alot), recalculating their enmity when they come back in range (if thats how it works) and the fact its a 13 year old game clearly not able to use the efficiency we enjoy in todays computers... I can see their reason as at least plausible.

maybe not true, but I can conceive of its plausibility.

Technically how the ability works; it needs to check the enmity of the player on mobs within an 11~ yalm radius. If you're standing within 11 yalms of 1 mob; it should run one loop (assuming the collection of monsters is narrowed down by radius); or 768 possible NPCs if not; but 767 of these would be empty cycles with no result or action taken.

Hardly intensive; in any programming language.

Enmity is reduced by a % for each mob that qualifies; and the ability cycle ends.

I would assume checks on enmity are only made if the monster being iterated over is within your range.

Then again, this is SE, who knows how it works.

I can see Geomancer abilities being far more server intensive with continual radius checks.

[Malithar]

I can see Geomancer abilities being far more server intensive with continual radius checks.

These are actually handled in a really annoying way. They're applied in tics like most other things, but this means that it's entirely possible to miss a tic if you step out of a bubble at the wrong time, and be without the buff for 3 seconds. Awkwardly enough, I've even missed my own Indi buff before when moving.

[Randnum]

Well, two points, which I'd be happy to have 'torn apart'.

Firstly, haven't we all known for the longest time that there's something additional done when hate values change largely? Hate resets on mobs don't cause them to immediately change their target, something else must happen. I think we're all familiar with things like Resheph's Tarsal Slam where the hate reset takes place after. This might be a consequence, or it might be a workaround of something else, but either way it's a strong indication that when hate values change heavily for things other than damage, at least, weird mechanics are involved (possibly trigger based?).

The second thing is, as I'm understanding this, if you want the range increased, you are talking about the THF being able to attempt to steal enmity for target player on all mobs within a certain range of the THF, right? We want to 'stay closer to mob yet take more enmity off targets'. I'd see how the 'reduce number of mobs checked' would work. I don't know about others but I actually purposely do use those abilities often to grab hate off a large number of enemies.

It sounds like what is desired should still be possible though. Increase range at which THF can target another player, leave range of 'enemies around THF that are checked for enmity change' the same. This should only matter if the two are related, right? No matter where the load comes from, if the only thing changed is 'distance that target player can be at', there should be no change in load.

[Karbuncle]

Technically how the ability works; it needs to check the enmity of the player on mobs within an 11~ yalm radius. If you're standing within 11 yalms of 1 mob; it should run one loop (assuming the collection of monsters is narrowed down by radius); or 768 possible NPCs if not; but 767 of these would be empty cycles with no result or action taken.

Hardly intensive; in any programming language.

Enmity is reduced by a % for each mob that qualifies; and the ability cycle ends.

I would assume checks on enmity are only made if the monster being iterated over is within your range.

Then again, this is SE, who knows how it works.

I can see Geomancer abilities being far more server intensive with continual radius checks.

Hardly intensive for what is assuredly a 13 year old MMO server? IDK, maybe, but thats just one equation among many others.

[FrankReynolds]

Hardly intensive for what is assuredly a 13 year old MMO server? IDK, maybe, but thats just one equation among many others.

I'm sure that whatever it runs on has / can be moved to a VM on incredibly cheap hardware by today's standards quite easily. They really have no excuse.

[Dazusu]

I'm 99% confident that a few years ago the game was down for almost 20 hours while they performed server "hardware" upgrades. At that point, one of several things happened:

- The servers were moved to multiple virtual machines running on one super-computer (ie, 32 processors, 256GB RAM etc) - This is now a common practice with server farms to save space and be more energy efficient. Not to mention it's cheaper.
- The Hardware was actually upgraded to today's standards.

As for the language the server software is programmed in - no one can truly know, but i'd hazard a guess at C. While programming languages have become easier to use and more accessible; the power of their ability to work with numbers isn't that different between 'then and now'. When you compile it, it all ends up as ASM anyway.

I just feel this excuse is a poor one; or as I suggested earlier the current developers were left legacy spaghetti to work with - which isn't optimized and therefor causes artificial strain. More trouble than it is worth to clean up. Who knows.

[Karbuncle]

the spaghetti code has been the cause of many a blunder... I wouldn't be surprised if thats the root of it.

Pets getting Samba

SATA working with ranged WS

Elemental Siphon animation not working properly, they fix it then the text is broken, so they just reverted it and said "fuggit".

so on lol

[Malthar]

I'm 99% confident that a few years ago the game was down for almost 20 hours while they performed server "hardware" upgrades. At that point, one of several things happened:

- The servers were moved to multiple virtual machines running on one super-computer (ie, 32 processors, 256GB RAM etc) - This is now a common practice with server farms to save space and be more energy efficient. Not to mention it's cheaper.
- The Hardware was actually upgraded to today's standards.

As for the language the server software is programmed in - no one can truly know, but i'd hazard a guess at C. While programming languages have become easier to use and more accessible; the power of their ability to work with numbers isn't that different between 'then and now'. When you compile it, it all ends up as ASM anyway.

I just feel this excuse is a poor one; or as I suggested earlier the current developers were left legacy spaghetti to work with - which isn't optimized and therefor causes artificial strain. More trouble than it is worth to clean up. Who knows.
It compiles down to machine code (instruction set). Assembly (ASM) is a language that is very close to machine code.