If the scripting allowed in the events are advanced enough, you could have it check at the start of the timer to see if two weapons were equiped, and if so display the dual wield variant. However since in most cases these days, most dual wield weapons have the same delay (4.0), it isn't as crucial.

Dw?
 

There aren't dual wield anymore. You can use any 2 sec and any 5 sec delay weapons or anywhere in between as long as thew ar 1h weapons.

yeah i know there aren't any dual wield weapons any more :) What i meant is that almost all weapons have a 4.0 delay in RoK, so having two bars is pretty much unnecessary anymore. There are rare cases where you'd have two weapons that don't match up though.

Well I don't think that would be a problem with duel wield because we have the dynamic data for primary/secondary attack delay. I wouldn't mind two bars and a single bar (for those who dont duel wield). The bars wouldn't be unnecessary because the times secondary/primary attack will still be different, the primary will always hit first, followed by the secondary.

I haven't taken a look at the code, but isn't there some way to automate the use of Recovery, Casting, and Reuse instead of having to manually input them? I mean logically I would think that it should apply when you enter autoattack, but how would you set that? IDK just thinking. I for sure would rather have it automated than having to put in the codes because there are many aa's, items, spells, and combat arts that modify haste, casting speed, attack speed, and reuse speed when used during combat.

I don't know about "most" but my Dirge mythical is a 3.5 delay and I know I have seen others with the delay below 3.5.

A fact to keep in mind is that, when dual wielding, delays are increased by 33%.

EDIT : grr. *I have seen others with the delay below 4 seconds.

bard mythicals are being changed to 4.0 delay, as well as all the other 3.5 weapons. The non uniform delay weapons are sparse, and generally not that great of weapons anyway :)

But back on topic, keep brainstorming about how to get this to work ;)

There appears to be a contradiction here, but maybe I misunderstand.

The problem is that the dynamic data comprises the % sign. As I mentioned somewhere towards the beginning of this thread you could do a string comparison to automate it.

Well, what I was referring to wasn't T8 raid gear. Some of us have T3 and T4 scouts using mastercrafted weapons ranging from 3-5 delay =P Yeah, the dualwield bar would probably be able to be automated, although, I am unsure as to what the secondary delay looks like when there isn't a second weapon equipped. I'm sure it could be set to only show second weapon when that value isn't default. Everyone should be petitioning to remove the % symbol from those 2 dynamicdatas =) That is why we can't (easily) automate them. I am wondering though, as to how much of a performance impact would this really have?

He is referring to having weapons of different delay

Yes :D 1234

Found it gm9. I personally would like to have 250 string comparisons because manually changing stuff becomes very tedious especially in groups and raids. I also believe that it would only cap at 100.

I'm not sure how it would effect the performance, but I have a mod that has over 120 pages of hotbar reuse information and around 730 lines of .xml dedicated to update every time a spell or CA is used on the hotbar (but is all released through DD). My point is that I see little to no performance problems with all the dynamic data/pages/lines.

A visual representation of what I mean in my mod (and the huge amount of info):

Um... what?

Earlier in the thread gm9 was talking about automating the spell reuse/recovery/casting. He said that in order to do that, he would have to have many string comparisons, which might compromise performance. I talked about one of my mods saying that it has many pages/lines/data and that it didn't impact the performance that much, so I'm thinking that it would be the same for his mod. The visual representation was to show that there are many pages as well as other things inside of them (visually explaining what I was talking about).

It was kind of a bad example because the image itself as well as my mod had nothing to with this mod, except for the performance issue, which is what I was trying to get across...but still...best example I could conjure.

Pretty much what I was saying is that my mod had a heavy amount of info and I feel little performance impact from it and if he did implement automation, I would compromise some performance for it...but I don't think performance will take a huge hit because of my mod not taking it. But it might just be my PC or the amount of code involved in my mod.

Lol sorry for the confusion

Heh if it makes you feel better I understood you the first time. ;)

I have run into performance (or rather timing) issues with string comparisons in the past but whatever the cause was (would have to be UI mechanics) I do not think it is a problem anymore, so I agree with you.

Why am I not seeing the window after using the /show_window Custom.ProfitUI_AutoAttackTimer command? Downloaded the new UI yesterday, but when I use tthe command, nothing happenes :(:confused:

There is a button in the Control Center for the calculator window. The timer bars do not exist yet on this site, we are discussing here how to implement them.

Hmm. How would you do that when the progress uses a decimal instead of a percentage? Integer converting? (I still don't fully understand it lol) Well have to set something up. I'm thinking that you would have to also use a good amount of automation for this as well.

I can tell right now that this is going to be a mission...

Me thinks a request to get this as dynamic data would be more constructive, unless they've stated that it won't happen?

DynamicData would certainly be the easiest. I have not talked to any dev about this and am not aware of any dev statements in this respect. Someone go ask them.

Without DD the code basically becomes a huge mess for it's size. You would have to do the math in the UI drago after converting the input string into a number (same style as subclass detection).

I knew it involved math! When I'm out of school/work I try to steer clear of any mathematical situation. I despise it. But in this case I will look more into it. :p



So what all Dynamic Data are we asking for?

Well if we can choose I'd take three DDs for Primary, Secondary and Ranged auto-attack reuse timers (or whatever they are called, basically the same thing we have for spells now).

Sounds like essentially what is in the /weaponstats command. Could probably make an entire DD node out of it. Can't be any worse than the Arena and Data nodes.

Now why didn't we think of asking for a dynamic data before I started racking my brain =P

I suggest someone PM Rothgar or Aeralik or Zoltaroth (devs who have dealt with the UI/DD before) on the main forum. Unfortunately I'm at work right now and for some odd reason the official forums are blocked :(.

Looks like someone posted it on the beta forums: http://forums.station.sony.com/eq2/p...opic_id=435380 (if you've got access).

Beta is in feature lock already however, therefore it is slightly pointless to ask for new features there. I'd say wait until beta is over and then start some publicity for the idea somewhere.

From my experience it is next to impossible to get SOE to implement new stuff like this unless someone is already working on something related, in which case it is fairly easy. So if you hear a dev talking about auto attack hit them up. ;)

I just asked Rothgar for this new DD we talked about as a reply to an earlier convo. I talked to him a few days ago about a bug within the new gamedata for beta (regarding an extra poison mitigations and the lack of poison damage reduction/percent) and I requested DD for Beneficial/Detrimental effects that include Name/Target/Duration/AmountRemaining (pretty much the same as maintained). His reply the other day was "I can't make any guarantees about when I'd be able to add more dynamic data. Some of that data you requested may not even be sent down to the client until you mouse-over it to get the tooltip. So doing this might be more complex than it seems."

So I'm thinking that he is going to say the same thing about this new request for auto-attack timers.

I'll just wait for a friendly reply. :cool:

EDIT: Or maybe if we get enough people to ask him he will give in to our demands!!!!! Landiin as hostage!!!!

lol. Well I can see why about the buffs window.

But a textual dynamic data for time until next melee attack... dunno. I guess it depends what data is being sent.

Or
 

An alternative would be to remove the % symbols from those 2 dynamic data we already have =P That would make this original idea a possibility =P

as I mentioned somewhere we can handle that via the UI already, I just did not implement it yet.

drago is still in discussion with Rothgar about the timer, but it's too early to say what we'll be getting, there are some complications on the server.

Posted this on my beta thread but I'll post it here too:
My question is this, why can't this be done:

Just as spell casting looks at the spell's casting time/recovery time, in order to generate the bar, why can auto attack not be done the same way?

The bar doesn't change mid way when your casting speed changes, so why can't there be a bar made that reads the delay from the weapon, [which is dynamic data isn't it (I mean it is in my top bar of profit reborn)] and use the delay the same way you use the cast time of a spell read from the spell? I'm guessing this is how it would be done.

That's the understanding I gained from all this discussion as well, I used to think the time base could change between auto-attacks but as I keep saying, I don't know much about auto-attack mechanics. And you are right, that makes it quite easy. It will just be much more efficient and exact if we get a dynamic data feed from Rothgar to move the bar and to provide nearly exact synchronization to when you actually swing (the spell casting timers are also implemented via dynamic data).

Is this the data you need sir? /GameData.Stats.Ranged_Delay

That's just static dynamic data that represents a value that reflects your character's stat :p

We need a value that will countdown to zero and repeat, over, and over, and over again.

:rolleyes:

Well.. from looking at the video there is already a way to do it. And gm9 even said it is made easy since the number for the delay doesn't change mid swing. Thus in essence you can make a feature that could count off from a ranged attack or ranged auto being toggled, same for melee.

Or even, I know for rangers the delay is almost ALWAYS the same for high end ones at least. the delay is 4 seconds. So a timer for 4 seconds that will only reset when it hits 0 + is not mid ranged ca.

I tried doing this through ACT by using the custom triggers for logs but I would set it for 4 seconds and it would still count down to negative 15 after I do it, and thus the timer be incorrect. Maybe there is another way to do it? I put the trigger in the triggers act tab and the timers tab too cuz just the act tab didn't work.

But how do you account for being out of range, lag, swings not going off because you're casting, etc?

For the last one we have dynamic data and could delay restarting of the timer, but for the first two I don't think you can do anything (there is no onscreen message or anything, is there?), that's one of the reasons why Rothgar's new dynamic data would be helpful.

I was meaning to test last night but totally forgot with raids and all but seem I recall AA fires if you OOR or not. So not sure being OOR is a issue, There isn't really any thing u can do about lag dynamic data or not unless there would be DD that says AAFired or something.

That's true... I clearly remember being able to test double attack chance by attacking something out of range and going afk for a while. You'd get two OOR messages for a double attack. So of course this suggests that being OOR does not store up your next auto attack, but consumes it.

Even better, that means lag is the only unknown and I suppose you can live with that.

As fast as fights are, it would be easy to find out when you went back into combat and lag would only be an issue on fights that lasted a long time.

This means we have a workaround, yes?

Oh, I'm so giddy that this is going to happen.

Thanks for all of the developers putting time into making the idea even better than it was :nana:

Devastatin of Unrest
Aka Johnathon on flames :P