• You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙‍♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋

  • A TLP without truebox has thawed (Very Vanilla ready)
    Frostreaver

Perfect Cure Restless Ice in TOV based on DanNet (1 Viewer)

Joined
Nov 11, 2012
RedCents
688¢
I personally have a this cure structure running in my raid and it helped us to conquer many modern raids.

With this kind of structure, you don't need to actually target anything to gain the debuff information ( plus even you targetting some pc/npc you still can't get the song buff information anyway)

1st to build DanNet Observer from healer and update it every pulse:

Sub DeclareFlags /if (!${Defined[tovdot1]}) /declare tovdot1 int outer 0 /if (!${Defined[tovdot2]}) /declare tovdot2 int outer 0 /if (!${Defined[tovdot3]}) /declare tovdot3 int outer 0 /if (!${Defined[tovdot4]}) /declare tovdot4 int outer 0 /if (!${Defined[tovdot5]}) /declare tovdot5 int outer 0 /if (!${Defined[grptovdot]}) /declare grptovdot int outer 0 /return Sub HealerObserve /call DeclareFlags /declare i int local 1 /for i 1 to 5 /if (${DanNet.Peers.Find[${Group.Member[${i}].CleanName}]}) { /if (!${DanNet[${Group.Member[${i}].CleanName}].Observe.Find[Restless Ice]}) /dobserve ${Group.Member[${i}].CleanName} -q "Me.Song[Restless Ice].ID" -o tovdot${i} } /varset tovdot${i} ${DanNet[${Group.Member[${i}].CleanName}].O["Me.Song[Restless Ice].ID"]} /next i /if (${tovdot1}||${tovdot2}||${tovdot3}||${tovdot4}||${tovdot5}) { /if (${grptovdot}!=1) /varset grptovdot 1 } else { /if (${grptovdot}!=0) /varset grptovdot 0 } /return

2nd Step, in your healer's loop, add something like this,
/call HealerObserve

3rd Step, now is time to cure,
/if (${grptovdot}||${Me.Song[Restless Ice].ID}) /call Cure
To not interrupt your main heal line too often, you prolly will need to add this at the end of your heal logic by using “else /if”
else /if (${grptovdot}||${Me.Song[Restless Ice].ID}) { /call Cure }

Enjoy.
 
But beware, there is a bug of DanNet, sometimes the observer seems got borked then you might got flag==1 even you don't have the debuff, in that case, just unload then reload the DanNet plugin ,and zone one time.
 
No, it won’t work with EQBC.

Netbot prolly yes but I don’t think Netbot has the ability to obtain song information from other clients plus you will need to tweak the code to make it work for Netbot.
 
Also, I'd just like to point out that even if you use eqbc, there is nothing stopping you from also running dannet for things like this.
 
Also, I'd just like to point out that even if you use eqbc, there is nothing stopping you from also running dannet for things like this.

i thought running dannet and EQBC together was causing problems...

@Redbot
@ctaylor22
@eqmule

I’m pretty sure I’m not making that up.
 
I'm not sure anyone's tested that!

i suggested running both in parallel a while back and was shot down. I might try it and see if it causes issues.
 
I remember Dannuic saying that the made dannet more as a replacement for mq2netbots and it just happened to also overlap with eqbc functionality. I used to have both plugins running before I shut off eqbc so :shrug:
 
I more or less have a fix for the TOV DOT for kissassist, but I am waiting on results from some testers that are testing the code. The best fix would be to have MQ2 include debuffs in the song window as well as the Buffs window when using the character TLO for Debuffs, like poison, cursed, diseased and so on.
 
My problem is I've experienced more crashes since loading dannet then it really helps me with anything :(
In recent updates? Is it frequently enough that you would say you could reproduce it?

Answering the other question, no reason you can't run both. They overlap in some functionality, but they don't conflict.
 
In recent updates? Is it frequently enough that you would say you could reproduce it?

Honestly yes and I'm not entirely sure how to reproduce it but I know when I'm running all the groups if i load dannet within 3p minutes I'll start getting crashes. I only run KA and Chat's plugins.

Sorry I can't give exact circumstances to reproduce and when I do crash I don't get a dump file the window just disappears.
 
The more characters you load while using DanNet the more Hangups you get.. I can load a full group and my shaman will sooner or later hang up. There is no crash so there is no crash dump. Using Task Manager you can see the EQGame.exe with (not responding) next to it. I have to end the task using Task Manager. If I load up 2 groups, all using DanNet, I start getting multiple hangs over and over to the point I just turn DanNet off.
 
I more or less have a fix for the TOV DOT for kissassist, but I am waiting on results from some testers that are testing the code. The best fix would be to have MQ2 include debuffs in the song window as well as the Buffs window when using the character TLO for Debuffs, like poison, cursed, diseased and so on.
I'd be willing to help test this
 
I have them both loaded with no problems. If I just use DanNet for sending messages I have yet to have any issues, but once I turn on DanNet in KissAssist, so that DanNet is responsible for updating information between characters. That is when the problems start.
 
I use both all the time and have really No issues. but primarily i use it for messages between characters not observers
 
I have to look at kiss. The people who have reported issues lately were all using DanNet in kiss, so I'm wondering if it's related to how it's being used there.

Core users don't have the same issue, so it's less likely to be something in DanNet itself. Though, perhaps some guards can be added to prevent the issue once found.
 
Last edited:
its a curse so yes netbots can pick it up

${NetBots[Name].Cursed}

and yes you can use eqbc to find it using the same kind of sub in your healers macro.

/if (${NetBots[${Group,Member[1].Name}].Cursed}) /call cure
etc
etc

or

${NetBots[${Group,Member[1].Name}].ShortBuff[Restless Ice]}

Netheal can also pickup curse counters on someone which is what you want anyway who cares about the spell name.
 
Just edit kissassist and search for /dquery Kiss only used /dquery to ask for the data it needs from other characters. I spent plenty of time with Dan himself when writing the DanNet code, just to make sure I was doing things the way he intended. I also had to use ${Parse[]} in one of the /dquerys to pass a string unparsed. @Knightly you helped me out to get that working.

The basic structure of all /dquery commands used in KissAssist is as Follows:

Code:
/dquery WhoToQuery -q WhatINeed -o PutInfoHere
/delay 20 ${DanNet.Query.Received}

Here is a little snapshot of some of the code:

Code:
                        /if (${WhileFlag}==1) {
                            | Is buff in Blocked Buff List?
                            /dquery ${TryToBuffName} -q "Me.BlockedBuff[${IniTempBuff}].ID" -o DNout
                            /delay ${DanNetDelay} ${DanNet.Query.Received}
                            /if (${Bool[${DNout}]}) /continue
                            /dquery ${TryToBuffName} -q "Me.Buff[${IniTempBuff}].ID" -o DNout
                            /delay ${DanNetDelay} ${DanNet.Query.Received}
                            /if (${Bool[${DNout}]}) /continue
                            /dquery ${TryToBuffName} -q "Me.Song[${IniTempBuff}].ID" -o DNout
                            /delay ${DanNetDelay} ${DanNet.Query.Received}
                            /if (${Bool[${DNout}]}) /continue
                            /dquery ${TryToBuffName} -q "Spell[${IniTempBuff}].Stacks[0]" -o DNout
                            /delay ${DanNetDelay} ${DanNet.Query.Received}
                            /if (!${Bool[${DNout}]}) /continue
                        } else /if (${WhileFlag}==4) {
                            |Do I have a pet?
                            /dquery ${TryToBuffName} -q "Me.Pet.ID" -o DNout
                            /delay ${DanNetDelay} ${DanNet.Query.Received}
                            /if (!${Bool[${DNout}]}) /continue
                            /varset TryToBuffID ${DNout}
                            /dquery ${TryToBuffName} -q "Me.BlockedPetBuff[${IniTempBuff}].ID" -o DNout
                            /delay ${DanNetDelay} ${DanNet.Query.Received}
                            /if (${Bool[${DNout}]}) /continue
                            /dquery ${TryToBuffName} -q "Me.Pet.Buff[${IniTempBuff}]" -o DNout
                            /delay ${DanNetDelay} ${DanNet.Query.Received}
                            /if (${Bool[${DNout}]}) /continue
                            /dquery ${TryToBuffName} -q "Spell[${IniTempBuff}].StacksPet[0]" -o DNout
                            /delay ${DanNetDelay} ${DanNet.Query.Received}
                            /if (!${Bool[${DNout}]}) /continue
                            /dquery ${TryToBuffName} -q "Me.Pet.CleanName" -o DNout
                            /delay ${DanNetDelay} ${DanNet.Query.Received}
                            /varset TryToBuffName ${DNout}
                        }
 
The more characters you load while using DanNet the more Hangups you get.. I can load a full group and my shaman will sooner or later hang up. There is no crash so there is no crash dump. Using Task Manager you can see the EQGame.exe with (not responding) next to it. I have to end the task using Task Manager. If I load up 2 groups, all using DanNet, I start getting multiple hangs over and over to the point I just turn DanNet off.

This.

This is why I stopped using Dannet and back to EQBC. Too many crashes. No fun :(
 
Couple things I would probably recommend.
1.) Since it's a macro and you're pushing dannet queries to variables, I would check to make sure the peer exists. I'm guessing repeatedly sending a broadcast out with no return is going to muck up the return variable. It should timeout after 1s and give you NULL, but that's one issue I see.
2.) There are a lot of delays in there which would only server to slow down your loop (if not for item 3). I'm not sure what ${DanNetDelay} is set to in that, but most of the time you're either going to get something back quick or you're not. I'd probably just tag a -t onto the query for whatever you're using with DanNetDelay.
3.) Possible I'm misunderstanding intent in either case, but I don't think .Received works the way you think it works. You're getting a timestamp for the last time a query was received and I thought it was supposed to be for a specific query. Regardless, I think you are using it to mean "I got a response back" and that's not what it does. I would just drop all of that altogether because the code as it stands right now is always going to move on to the next line after the first query you send ever (while DanNet is running) and I don't think that's your intent. It's similar to saying /delay ${DanNetDelay} 1.
 
Last edited:
i thought running dannet and EQBC together was causing problems...

@Redbot
@ctaylor22
@eqmule

I’m pretty sure I’m not making that up.
I run them both regularly together and have had no issues with stability more than usual. I have set KA to only use Dannet. I also only run a single group.
 
I have to look at kiss. The people who have reported issues lately were all using DanNet in kiss, so I'm wondering if it's related to how it's being used there.

Core users don't have the same issue, so it's less likely to be something in DanNet itself. Though, perhaps some guards can be added to prevent the issue once found.

Seemingly no issues with IHC so far either. It only uses queries and no observers. Also checks for members to be online prior to issuing a query.
 
Couple things I would probably recommend.
1.) Since it's a macro and you're pushing dannet queries to variables, I would check to make sure the peer exists. I'm guessing repeatedly sending a broadcast out with no return is going to muck up the return variable. It should timeout after 1s and give you NULL, but that's one issue I see.
2.) There are a lot of delays in there which would only server to slow down your loop (if not for item 3). I'm not sure what ${DanNetDelay} is set to in that, but most of the time you're either going to get something back quick or you're not. I'd probably just tag a -t onto the query for whatever you're using with DanNetDelay.
3.) Possible I'm misunderstanding intent in either case, but I don't think .Received works the way you think it works. You're getting a timestamp for the last time a query was received and I thought it was supposed to be for a specific query. Regardless, I think you are using it to mean "I got a response back" and that's not what it does. I would just drop all of that altogether because the code as it stands right now is always going to move on to the next line after the first query you send ever (while DanNet is running) and I don't think that's your intent. It's similar to saying /delay ${DanNetDelay} 1.

Well what you see is what Dan himself said I should use. The old code use to set DNout to null the issue the /dquery and then /delay checking the bool[DNout]. something like this.

/varset DNout @@
/dquery ${TryToBuffName} -q "Me.Pet.ID" -o DNout
/delay ${DanNetDelay} ${DNout.NotEqual[@@]}

Dan said I could use the -t as you suggested, but he also said that using the /delay with the ${DanNet.Query.Received} would accomplish the same thing.

And as far as checking for the peers, I only /dquery from the list I pull from using ${DanNet.Peers[all]} so the clients I am /dquery ing has a connection at the time I start my loop.

When I first started using dannet I was getting a lot of null values returned from /dquery. Adding a /delay after the /dquery fixed that issue. That led me to doing what I listed above. After Dan reviewed, he suggested, what I am doing now. I haven't tried using the -t(timer) option. I guess I can give that a try, but I don't have much confidence that it will make a difference.
 
We are totally derailing this poor man's thread...

But, what I would guess Dan meant about received was you could check Received for the query you sent. ${DanNet.Query.Received} is just telling you the timestamp for the last time ANY query was received on the toon you're actually on which isn't relevant to what you're doing. For what I think your intent is, you would want to do ${DanNet[${TryToBuffName}].Query[DNout].Received}
 
This is not a derail for me lol. I actually use the similar structure of Ctaylor’s post to buff by adding lots of delay DanNet.Query.Received.
Matter fact it did accomplish the job somehow slow down my main loop A LOT. I do have some spamming a certain spell sub to test it, with lots of DQuery, the spamming was not right after the GCD but slow down for couple secs which is not acceptable (mainly raid circumstance)

I then rebuild the part with Observer and it works perfect, even in raid.
 
Last edited:
Feel free to PM me any crash dumps you want me to look at. I've not really found any so far that are helpful outside of the kiss ones which I'm working with CTaylor on. The more the merrier.
 
i run dannet with 4 groups without any crashes for hours, only issues i get are loading mq2 after i have unloaded it before and all accounts will shudder
 
Perfect Cure Restless Ice in TOV based on DanNet

Users who are viewing this thread

Back
Top
Cart