• IS THIS SITE UGLY? Click "RG3" at the very bottom-left of this page to change it. To dismiss this notice, click the X --->
Resource icon

Plugin - MQ2DanNet 0.72

dannuic

Moderator
Joined
Sep 12, 2004
Likes
75
RedCents
4,529¢
#1
dannuic submitted a new resource:

MQ2DanNet - It's not just for Dans anymore

Here we have an auto-discovery peer to peer networking plugin that utilizes ∅MQ and zyre. I have linked the README.md on the github for command/TLO/ini reference.

The gdrive link points to the latest live build, but the source compiles for ROF2 and Test without modification, so feel free to clone https://github.com/dannuic/MQ2Dan and compile it (all required libs are built and statically linked along with it). I usually have a test build available since I play on test, so...
Read more about this resource...
 

Maskoi

So old and salty he grew scales
Moderator
Joined
Sep 28, 2005
Likes
411
RedCents
65,560¢
#2
Some Notes about Setup
  • Some complicated network topologies won't be supported (a server interface is a better solution)
  • If for some reason the peers aren't self-discovering on a local network
    • check the output of /dnet interface
    • set one of the discovered interface names with /dnet interface <name>
    • failing that, I'll have to look into why, so contact me with as much info as possible
Use
There are 2 basic uses
  1. Set up an observer
  • Methods of setting up an observer
    • /dobserve <name> <query>
    • ${DanNet[<name>].Observe[<query>]} or ${DanNet[<name>].O[<query>]}
  • Reading an observer's data: ${DanNet[<name>].Observe[<query>]} or ${DanNet[<name>].O[<query>]}
  • Dropping an observer: /dobserve <name> <query> drop

  1. Single-use direct query
  • Submitting a query: /dquery <name> [-q <query>] [-o <result>] [-t <timeout>]
    • Combines /delay with /varset
    • timeout is optional, and the default can be configured
    • result is optional, will just write out the result if omitted
    • If not run in a macro, ignores result and just writes out
Queries

A query is simply a normal TLO access from the perspective of the peer with the external ${} stripped Examples:
  • Me.CurrentMana
  • Target.ID
  • Me.Current$\{thing} -- this will evaluate ${thing} on the peer before sending a response
Names

A fully-qualified name is <server>_<character>, but if you only intend to communicate on your own server, you can ommit the first part and use just <charactername> in all these commands. Examples:
  • Locally talk to fatty: /dtell fatty You smell.
  • Talk to fatty on the test server: /dtell test_fatty I can still smell you from this server!
Commands

I have added some simple echo commands in addition to /dinfo and /dobserve, as well as a way to join/leave arbitrary groups.
  • /djoin <group> [all|save] -- join a group, and optionally write to [General] or [server_character] (all or save, respectively)
  • /dleave <group> [all|save] -- leave a group, and optionally write to [General] or [server_character] (all or save, respectively)
  • /dtell <name> <text> -- echo text on peer's console
  • /dgtell <group> <text> -- echo text on console for all peers in group
  • /dexecute <name> <command> -- executes a command on peer's client
  • /dgexecute <group> <command> -- executes a command on all clients in a group (except own)
  • /dgaexecute <group> <command> -- executes a command on all clients in a group (including own)
  • /dnet [<arg>] -- sets some variables, gives info, check in-game output for use
  • /dobserve <name> [-q <query>] [-o <result>] [-drop] -- add an observer on name and update values in result, or drop the observer
  • /dquery <name> [-q <query>] [-o <result>] [-t <timeout>] -- execute query on name and store return in result
TLO Members
  • Name -- current node name (fully qualified)
  • Debug -- debugging flag
  • LocalEcho -- local echo flag (outgoing echo)
  • CommandEcho -- command echo (incoming commands)
  • FullNames -- print fully qualified names?
  • FrontDelim -- use a front | in arrays?
  • Timeout -- timeout for implicit delay in /dquery and /dobserve commands
  • ObserveDelay -- delay between observe broadcasts (in ms)
  • Keepalive -- keepalive time for non-responding peers (in ms)
  • PeerCount -- number of connected peers
  • Peers -- list of connected peers
  • GroupCount -- number of all groups
  • Groups -- list of all groups
  • JoinedCount -- number of joined groups
  • Joined -- list of joined groups
  • O Observe -- observe accessor, accessed like: ${DanNet[peer_name].Observe[query]}
  • Q Query -- query accessor, for last executed query

Both Observe andQueryare their own data types, which provide aReceivedmember to determine the last received timestamp, or 0 for never received. Used like${DanNet.Q.Received}`

INI entries (MQ2DanNet.ini)
  • [General]
    • Groups -- |-delimited list of groups for all characters to auto-join, default empty
    • Debugging -- on/off/true/false boolean for debugging output, default off
    • Local Echo -- on/off/true/false boolean for local echo, default on
    • Command Echo -- on/off/true/false boolean for remote and local command (/dgex, &c) output, default on
    • Full Names -- on/off/true/false boolean for displaying fully-qualified names (on means that all names are displayed as server_character), default on
    • Front Delimiter -- on/off/true/false boolean for putting the | at the front for the TLO output of DanNet.Peers &c, default off
    • Query Timeout -- timeout string for implicit delay in /dquery and /dobserve, default is 1s
    • Observe Delay -- delay in milliseconds for observation evaluations to be sent, default is 1000
    • Keepalive -- timeout in milliseconds before an unresponsive peer is dropped, default is 30000
    • Tank -- short-name class list to auto-join the tank channel, default is war|pal|shd|
    • Priest -- short-name class list to auto-join the priest channel, default is clr|dru|shm|
    • Melee -- short-name class list to auto-join the melee channel, default is brd|rng|mnk|rog|bst|ber|
    • Caster -- short-name class list to auto-join the caster channel, default is nec|wiz|mag|enc|
  • [server_character]
    • Groups -- |-delimited list of groups for this specific character to auto-join, default empty
 
Last edited:
Joined
Feb 16, 2018
Likes
16
RedCents
411¢
#3
So i'm curious. Is this a plugin written to control multiple clients on the same subnet for the purpose of playing on your own emu server?
 

dannuic

Moderator
Joined
Sep 12, 2004
Likes
75
RedCents
4,529¢
#4
So i'm curious. Is this a plugin written to control multiple clients on the same subnet for the purpose of playing on your own emu server?
No, this is more towards the purpose of coordinating all of your clients, and providing an interface for remote execution of commands without needing a server.
 

Maskoi

So old and salty he grew scales
Moderator
Joined
Sep 28, 2005
Likes
411
RedCents
65,560¢
#7
Code:
check the output of /dnet info interface
set one of the discovered interface names with /dnet info interface <name>
so is this the correct command?
 

dannuic

Moderator
Joined
Sep 12, 2004
Likes
75
RedCents
4,529¢
#8
ahh, it's actually just `/dnet interface` and `/dnet interface <name>` sorry, forgot to update that bit -- updated now
 

joojoobee

A Member to Remember
Joined
May 15, 2016
Likes
89
RedCents
2,534¢
#11
Can we get some actual examples? For instance, what is the sequence of commands to "observe" whether another character is targetting something? Or whether it has a given buff?

I tried a few iterations but I am clearly too stupid to understand the explanations.

Thx.
JJB
 
Joined
Jan 13, 2018
Likes
35
RedCents
2,000¢
#14
Client freezes when doing an observer as a data var without doing /dobserve first. Pretty easy to reproduce, this locks up: /echo ${DanNet[somechar].O[Me.Name]}
 
Joined
Jan 13, 2018
Likes
35
RedCents
2,000¢
#19
Client freezes when doing an observer as a data var without doing /dobserve first. Pretty easy to reproduce, this locks up: /echo ${DanNet[somechar].O[Me.Name]}
Disregard this, had an old version of another plugin causing some stack corruption and this just happened to be where it all fell down :(
 
Joined
Jul 6, 2018
Likes
27
RedCents
220¢
#20
Disregard this, had an old version of another plugin causing some stack corruption and this just happened to be where it all fell down :(
What plugin was causing the issue? Having the same issue not using anything out of the ordinary from what comes with the redguides build.
 
Joined
Jan 13, 2018
Likes
35
RedCents
2,000¢
#21
Yah so a plugin not the problem as it turns out on testing some more. Looking like a linking issue, will need to be sorted out in the compile as soon as someone figures out how...
 
Joined
Mar 21, 2014
Likes
112
RedCents
10,263¢
#22
OK. Time for stupid questions. I have 2 characters running MQ2DanNet and trying to test using /dquery CharacherName -q Me.Name from the command line. using /dnet info shows both characters in the list and using /btell CharacterName Hello work fine. How can I get this to work for testing NOT using a Macro?
 
Joined
Mar 21, 2014
Likes
112
RedCents
10,263¢
#23
This plugin does will NOT update Outer Variables from a Sub Routine, it can't even see the Outer Variables. If you create the variables in the sub routine as local variables it works fine.

Never Mind. I figured it out.
 
Last edited:
Joined
Mar 20, 2015
Likes
6
RedCents
18¢
#24
was wondering if someone could explain the intended purpose of observers vs. queries. I am working on developing a macro framework that is entirely based on MQ2Dannet at it's core. When I tried to use observers I found it made my routines very unstable and unreliable, so I wonder if I misunderstand what they truly do. I have to say though that being able to access TLO's on the fly using /dquery is awesome and lightning fast compared to methods used to gather data by other macros.
 
Last edited:
Joined
Mar 21, 2014
Likes
112
RedCents
10,263¢
#25
From the way I understand it, observers are a more of a connection you create that get refreshed. Where a query is just that, get me what I ask for when I ask for it.

Something to keep in mind when using /dquery. Use global variables in your query. DanNet will throw errorrs when using local variables, if Dannet is not able to return the /dquery data, while your still in the routine, where you issued the /dquery call.

What I did, to try and fix that issue, was move all local variables to Outer variables, and the second, I set a variable to an initial value and used that variable as the Response variable. Then did a /delay checking the response. See Below:

/varset DResponse @[email protected]
/dquery "WhoToQuery" -q Me.Name -o DResponse
/delay 20 ${DResponse.NotEqual[@[email protected]]}

That's all I can suggest for now..
 
Joined
Mar 20, 2015
Likes
6
RedCents
18¢
#26
From the way I understand it, observers are a more of a connection you create that get refreshed. Where a query is just that, get me what I ask for when I ask for it.

Something to keep in mind when using /dquery. Use global variables in your query. DanNet will throw errorrs when using local variables, if Dannet is not able to return the /dquery data, while your still in the routine, where you issued the /dquery call.

What I did, to try and fix that issue, was move all local variables to Outer variables, and the second, I set a variable to an initial value and used that variable as the Response variable. Then did a /delay checking the response. See Below:

/varset DResponse @[email protected]
/dquery "WhoToQuery" -q Me.Name -o DResponse
/delay 20 ${DResponse.NotEqual[@[email protected]]}

That's all I can suggest for now..
I really hadn't encountered this error myself... Until I was working on checking for buff stacking. To test my routine for doing so, I created a level 1 cleric and ran the macro on it. It worked fine until I switched back to my main cleric and ran the macro again. Suddenly it was having problems updating local variables and was double casting buffs. Totally closed out of both my cleric and target characters session and restarted eq and the problem went away. The double casting is the same issue I was having when accessing observers repeatedly. It's like /dquery and observers are leaving phantom copies that return double results when accessed from different perspectives.

code I used that caused the issue in this circumstance :

Code:
        /if (${hpbuff.NotEqual[NULL]}) {
            /dquery ${Group.Member[${gmember}]} -q "Me.Buff[${hpbufftocheck}].ID" -o hpbuffcheck
                /if (!${hpbuffcheck} && !${Me.Casting.ID}) {
                    /call castspell "${hpbuff}" ${Group.Member[${gmember}].ID} "${Group.Member[${gmember}]}"
                }
        }
There is a lot more to the macro obviously but this is where the error occurred. Under normal circumstances with a clean eq session, it works 100% even using local variables.
 
Last edited:
Joined
Mar 21, 2014
Likes
112
RedCents
10,263¢
#27
I would try adding a delay after the /dquery, like I did in my example. That will help, but could still be issues. Moving all the variables to outer will correct the problem with error messages, but it will not fix the problem. The task at hand, is to find a way to make sure the /dquery has completed before letting you macro continue.

What is happening is the plugin is getting stalled, but your macro is continuing to run. Once the plugin finally catches up, your macro has exited the routine that issued the /dquery and is working in another routine.
 
Top