What version are you using?

There are MANY different flavors in this thread and it sounds like your using an older version before the shadow styles are fixed.

I would suggest going backwards in time from the last post until you find one, then you are for sure to get the best version of code.

Without additional dynamic data, no.

If that data becomes available to the client, we will see.

I use the version from post number 257 and I think, that's the latest at this time. I think it's not an issue of an old version because of the very similar problems with the delay-value in the original autoattack-calc-window from gm9.

Regards,

Dionys

Yes. I didn't use combat bubbles, they lag to much and to many problems with them.

What????? :confused:

I have no idea :|

Raz maybe?

I assume that much, but not letting the cat out of the bag is disheartening.

Its more fun trying to figure it out... who just wants the answer?

Without the use of combat bubbles we need something that updates everytime an autoattack is made. Brainstorm on that.

We have the chat window that gets spammed during combat.
Look into the primary, secondary and ranged inventory slots.

Anyone think of other possibilities?

I was. useful talking only please.

Need help on how to get it show, posted screen shot. was killing training dummy.

Ok, now this is going a bit beyond simply using the interface, but it could be accomplished as follows.

You'd need a chat window with 2 tabs, one tab that contains your outgoing damage, and one tab that is a custom channel.

In the Chat Tab you'd need a custom script that triggers when a line of text is added, the script would issue a dofilecommand command, pointing a file that is created by ACT.

In ACT you'd need to create a custom plugin that reads your combat log and outputs a word to a file if the last line read is an autoattack, or clear the file if its not. The file would be something like /1 Attack

Back in EQ2, on your tab that contains the /1 channel, you'd need to put your autoattack bar trigger script in there, to fire whenever a line is added to the window.

I'm not the best at explaining my thoughts, so I know that sounds confusing. Maybe someone else can word it better :)

There's no command that I am aware of like an OnNewTextLine. It doesn't exist as far as I know. I was just looking at that.

That's the combatbubble lag issue.

The ProfitUI window, i.e. the one Jida asked for one page 1 of this thread (long ago) does not even show your weapon delay but the number of CAs you can cast between auto attacks.

Yes, samejima is razieh if you didn't know.

And every miss. Could be anything, maybe one of the weapon or auto-attack related DynamicData elements triggers OnShow for each attack/miss or triggers an effector. Would have to be tested.

There's no autoattack related data. Only data that has to do with attack are RangedAutoAttack and AutoAttack. There might be a DynamicData that updates upon hit, but IDK. AFAIK the only things we have to work with are CombatBubbles, DynamicData, and possibly the Chat window.

We might be overlooking something simple.

Yes, You are right, my fault. I meant the number of CAs, used the wrong word (english is obviously not my native language). So the number is 40, when it should be only 4, or 35 when it should be 3,5 and so on. Every time off by 10 times the real value.

Regards, Dionys

I think it's all good effort, but I don't think using these tools yields a solid enough turn out. I'm fairly certain there's nothing you can currently do from the text that appears in the chat window.

What about the OnShowEffector event of the chat_textbox style? If you can't manipulate the actual chat page, can you manipulate the style of the text showing?

What about DynamicDataFilters for Primary_Weapon DD's. Maybe "0x1000" which is an event trigger. If not that, then maybe there is another one that can be used to trigger when an autoattack is landed with a primary, secondary, or ranged attack.

Another thought is to read the chat window somehow. Then trigger once a certain text "autoattack swing" is shown. If your able to read CombatBubbles, then there might be a way to do the same with the Chat Window. This is a very viable option although it may seem impossible since you can't directly accomplish this. There could be a way around it.

That is my 2 cents anyway.:)

Where are you getting the 0x1000 from? Is there a document on dynamic data that I haven't read? :)

NM I found it in the official documentation lol

As far as I know, the default filter is 0xFFFF which enables all available data. If you wanted nothing but the event, I suppose 0x1000 works okay, but I don't even know what an event would be in this context. I cannot think of anything that uses it. Usually we hook onto events like OnShow which is triggered by visibility (0x0001?).

OK, What?!?! Did this turn from XML to C++? I am so seriously lost (my newbness is showing isn't it?)

It's nothing really that complicated. When you attach DynamicData to something, it will try to change that element dynamically. But say you wanted the DynamicData to only change something's Color and Text, but not it's visibility or anything else... you'd need to use a DynamicDataFilter.

The filter is a bitfield converted to a four character hex string.
0x0000 being 0000000000000000
0xFFFF being 1111111111111111

Essentially it's the same as having sixteen booleans.

Color is 0x0400 being 0000010000000000
Text is 0x0002 being 0000000000000010
Combined is 0x0402 being 0000010000000010

The thing is, 0x1000 is not required to handle an OnShow event from an element, so I have no idea what an "Event Trigger" is in context of DynamicData.

This is taken from the official documentation. What is boolean value, long value, and floating point value?

Any thoughts on what our next step could be and how we could use this to our advantage?????? Event trigger doesn't do anything besides change values, right? And there's not an OnEventTriggered property.

I've always assumed that the event trigger filter if applied would filter out any events the DD may have. So if you applied EFFF none of the the events would be fired.

All other are kind of self explanatory.