Accomplice and Collaborator Problems

[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.

[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.

[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.