EQ2Interface

EQ2Interface (https://www.eq2interface.com/forums/index.php)
-   DrumsUI (https://www.eq2interface.com/forums/forumdisplay.php?f=47)
-   -   Drums response to devs? (https://www.eq2interface.com/forums/showthread.php?t=17980)

diashto 01-29-2015 06:44 AM

Drums response to devs?
 
So i've come across a couple threads on the EQ2 official forums that are blaming Drums, Profit, and the like on massive raid lag.

Specifically, in this thread, Gninja says

Quote:

"Any of the UIs that have heavy use of the doFile command can cause lag to the person using it as well as those in raid with them."
I'm not a UI writer, i've tweaked some things once or twice, but i'm not sure what a doFile command is, and more importantly, i have no idea how that would conceivably lag someone other than the pc that Drums is installed on.

Any insignt?

Maozem 01-29-2015 10:33 AM

I can't speak to the technical side of the servers and the lag, but as a heavy user of Drums, Profit, Darq, and several other UI's including combinations of the above in not only high end raiding but multiboxing as well...I haven't seen any noticeable lag from any of the above combinations. In my general experience the lag usually comes from the isp (pore ping times and high latency) or server load. These tend to peak when a new x-pac comes out as well.

Just my two cents worth.

Thanks to all the UI coders out there, your work is truly appreciated:)

Mystara0001 01-29-2015 11:47 AM

A "do_file" is a text file that contains multiple command that are executed by calling the file into game using the "do_file_commands FILENAME.txt" command in game.

It's the type of file used to post parses from programs such as ACT using a macro rather than copy/paste.


This wouldn't normally cause lag unless it's a HUGE number of commands and they are constantly being called. Even then, it would most likely cause latency only for the person using them, not the entire raid.

tknarr 01-29-2015 01:02 PM

I've maintained ProfitUI, and it doesn't use /do_file at all. I've also raided, and never see any external software (ACT, RaidHub and so on) cause lag. The only time I've seen /do_file used in fact is in ACT to report parses, and that's usually done after the fight is over. It's possible to build files with commands that'd cause lag and execute them via /do_file, but it's more common for those same commands to be executed manually since they're just the correct reaction to an event during the raid.

The biggest causes of lag that I know of are:
1. Effects during raid that cause cascades of proc checks, eg. an ability used by the mob that when it lands on a player puts a detrimental on them that procs, causing more checks and when it lands causes more procs which cause more checks etc. etc..
2. Particle effects from group-effect spells, since raids have more players and pets active than normal groups and so cause group-effect spells to generate more effects. Stuff like this is why raiders play with minimal graphics quality and aim the camera at the floor, and why Profit and other custom UIs have buttons to switch between graphics configurations easily.
3. Effect mechanics that've been abandoned because they caused too much server-side calculation, eg. the de-leveling effect in Mistmoore raids.

Drumstix42 01-29-2015 11:03 PM

The things that are claimed to cause lag are what people use in hotbars/macros part of the standard UI. People use "megamacros" still, and it can be like..... Cast 10 items at once.

At one point spell casting/queue or something like that was moved to client side to reduce strain, but I don't think it can really work 100% because of all the items, and clickies, and insta cast abilities.

--

In some cases, people may be using macros like this in click buttons, but it's really no difference than having 10 hotbars open with mega macros, like a lot of people do.

--
Food for thought about EQ2 lag:
Determine the number of chat messages that gets sent to/from a person in combat on average, multiply it by 24, and then send it to all party members in the raid *constantly*.
24 people sending data to the server that gets sent to all 24 people each. Just look at the data transfer graph during combat...
Then add in all the other raids, and groups, and people playing. I dunno. I just think there's like a million times more chat spam than needed.

Some people claim a full raid force using default UI may benefit, and I would probably agree, but only because any extra windows in the UI lower your FPS, lower FPS lowers your UI/keyboard response time, and this probably has people trying to do less because they're not clicking things as effectively. I dunno. I think it's conjecture, but all in all: I think the game is just a mess and that's the real problem ^_^

Drumstix42 01-30-2015 09:41 AM

Also Gninja talks about UI's automating targeting and checking targets, which I don't have any of going on.

tknarr 01-30-2015 03:17 PM

Quote:

Originally Posted by Drumstix42 (Post 105819)
Also Gninja talks about UI's automating targeting and checking targets, which I don't have any of going on.

Ditto Profit. I've seen something like that, with raiders setting up buttons to target a particular mob by name because it'll be buried in a pack of others or you'll be constantly losing your target, but it's usually done with hotbar buttons since they're easily edited without having to restart the client.

Drumstix42 01-30-2015 03:26 PM

Yeah I used targeting macros all the time for fights as a tank/off tank. I would just edit them per fight, or drag the needed one from the Macros window.

diashto 01-30-2015 05:54 PM

See, the only thing i can think of is things like was mentioned in a "how to Paladin" thread, where the author of that post said that a pally should make a rez macro for the entire raid.. so they can click one button and rez anyone if they're close enough in the raid.

Drumstix42 01-31-2015 12:42 AM

Yeah mega macros can be bad, but like something like that, would be a situational megamacro at best. There would be no reason to press very often.

In the end, I don't think we or they know the actually issue at it's root without investigating it more.


All times are GMT -5. The time now is 02:33 AM.

vBulletin® - Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
© MMOUI