[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Plugins
. . -> [Subject]  trying to make atcp2 plugin to work

trying to make atcp2 plugin to work

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Pages: 1  2  3  4 5  6  7  8  9  

Posted by Cburke   (11 posts)  [Biography] bio
Date Reply #45 on Tue 13 Jul 2010 10:04 PM (UTC)
Message
Sorry for the simplistic question, but I'm just trying to "get off the ground" with this plugin. I've got it loaded and I'm browsing through the code. Is there a simple script I can run which will just continuously dump all the incoming gmcp data to the screen or something like that? At this point I'm primarily interested is seeing exactly what the messages from IRE look like.

Thanks,

-C
[Go to top] top

Posted by Maxhrk   USA  (76 posts)  [Biography] bio
Date Reply #46 on Tue 13 Jul 2010 10:48 PM (UTC)
Message
I will make some examples have it uploaded to github sometime today.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #47 on Tue 13 Jul 2010 11:00 PM (UTC)

Amended on Wed 14 Jul 2010 04:37 AM (UTC) by Nick Gammon

Message
This is a small plugin that negotiates ATCP2, and displays what it receives. You can see the general idea of the protocol here.

Template:saveplugin=ATCP2_Logger To save and install the ATCP2_Logger plugin do this:
  1. Copy between the lines below (to the Clipboard)
  2. Open a text editor (such as Notepad) and paste the plugin into it
  3. Save to disk on your PC, preferably in your plugins directory, as ATCP2_Logger.xml
  4. Go to the MUSHclient File menu -> Plugins
  5. Click "Add"
  6. Choose the file ATCP2_Logger.xml (which you just saved in step 3) as a plugin
  7. Click "Close"



<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>

<muclient>
<plugin
   name="ATCP2_Logger"
   author="Nick Gammon"
   id="4a33087c6b66ca6c4611afed"
   language="Lua"
   purpose="Displays ATCP2 info"
   date_written="2010-07-14"
   requires="4.40"
   version="1.0"
   >

</plugin>

<!--  Script  -->


<script>
<![CDATA[

require "json"
require "tprint"

local IAC, SB, SE, DO = 0xFF, 0xFA, 0xF0, 0xFD

local ATCP = 200
local ATCP2 = 201

function Send_Telnet_Packet (what)
    SendPkt (string.char (IAC, SB, ATCP2) .. 
             what .. 
             string.char (IAC, SE))
end -- Send_Telnet_Packet

function OnPluginTelnetSubnegotiation (msg_type, data)
  if msg_type ~= ATCP2 then
    return
  end -- if not ATCP2
  
  ColourNote ("darkorange", "", data)
  
  message, params = string.match (data, "([%a.]+)%s+(.*)")
  
  if not message then
    return
  end -- if
  
  if not string.match (params, "^[%[{]") then
    params =  "[" .. params .. "]"  -- sigh
  end -- if 

  local t = json.decode (params)
  
  if type (t) == "table" then
    tprint (t)
  end -- if
   
end -- function OnPluginTelnetSubnegotiation

function OnPluginTelnetRequest (msg_type, data)

  if msg_type == ATCP2 and data == "WILL" then
    return true
  end -- if
  
  if msg_type == ATCP2 and data == "SENT_DO" then
    Note ("Enabling ATCP.")
    Send_Telnet_Packet (string.format ('Core.Hello { "client": "MUSHclient", "version": "%s" }', Version ()))
    Send_Telnet_Packet ('Core.Supports.Set [ "Char 1", "Char.Skills 1", "Char.Items 1" ]')
    return true
  end -- if ATCP login needed (just sent DO)
  
  return false

end -- function OnPluginTelnetRequest

]]>
</script>

</muclient>



Sample output (my name x'd for privacy):


Char.StatusVars { "name": "Name", "fullname": "Full Name", "level": "Experience Level", "xp": "Experience To Next Level", "class": "Class", "city": "City", "house": "House", "order": "Order", "race": "Race" }
"order"="Order"
"class"="Class"
"xp"="Experience To Next Level"
"house"="House"
"race"="Race"
"city"="City"
"level"="Experience Level"
"name"="Name"
"fullname"="Full Name"
Char.Status { "name": "Cxxxxxxxx", "fullname": "Cxxxxxxxx", "level": "6", "xp": "2%", "class": "Paladin", "city": "(None)", "house": "(None)", "order": "(None)", "race": "Troll" }
"order"="(None)"
"class"="Paladin"
"xp"="2%"
"house"="(None)"
"race"="Troll"
"city"="(None)"
"level"="6"
"name"="Cxxxxxxxx"
"fullname"="Cxxxxxxxx"
Char.Skills.Groups [ "Vision Inept", "Avoidance Inept", "Tattoos Inept", "Survival Novice", "Weaponry Inept", "Riding Inept", "Devotion Inept", "Chivalry Inept", "Constitution Inept", "Thermology Inept", "Frost Inept", "Antidotes Inept", "Fitness Inept", "Galvanism Inept", "Philosophy Inept" ]
1="Vision Inept"
2="Avoidance Inept"
3="Tattoos Inept"
4="Survival Novice"
5="Weaponry Inept"
6="Riding Inept"
7="Devotion Inept"
8="Chivalry Inept"
9="Constitution Inept"
10="Thermology Inept"
11="Frost Inept"
12="Antidotes Inept"
13="Fitness Inept"
14="Galvanism Inept"
15="Philosophy Inept"


The caustic voice of Pandemonium clamours from the heavens as He shouts, "If My
heritage is all that You can think to disparage, then We will soon see the
continent drown beneath Your righteous ichor! To battle! To War!"


Char.Vitals "H:594/594 M:440/468 E:1870/1870 W:1240/1240 NL:2/100 "
1="H:594/594 M:440/468 E:1870/1870 W:1240/1240 NL:2/100 "


The plugin uses the Lua JSON module to decode the JSON. If you don't have that, just omit the couple of lines that do the decoding (although you will probably want to have it, to make more sense of the JSON code).

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Cburke   (11 posts)  [Biography] bio
Date Reply #48 on Wed 14 Jul 2010 04:15 AM (UTC)
Message
Perfect.

This is exactly what i needed, I'm up and running. I'd recommend this (or something similar) be added to repo.

-C
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #49 on Wed 14 Jul 2010 04:40 AM (UTC)
Message
The GMCP plugin discussed here is hosted at GitHub [1], and incidentally it has a #gmcpdebug alias that outputs any GMCP data received.

[1] http://github.com/druuimai/gmcp.plugin

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Cburke   (11 posts)  [Biography] bio
Date Reply #50 on Wed 14 Jul 2010 04:58 AM (UTC)
Message
Twisol,

Ah - I see. That's exactly what I wanted (to be able to see the atcp2/gmcp output from IRE). Once I restarted the "world" and fed in the "#gmcpdebug" command, I started seeing output. More than one way to skin a cat I see.

Thanks so much for your help.

-C
[Go to top] top

Posted by Lasher   USA  (22 posts)  [Biography] bio
Date Reply #51 on Mon 26 Jul 2010 07:52 PM (UTC)
Message
Cburke said:

Twisol,

Ah - I see. That's exactly what I wanted (to be able to see the atcp2/gmcp output from IRE). Once I restarted the "world" and fed in the "#gmcpdebug" command, I started seeing output. More than one way to skin a cat I see.

Thanks so much for your help.

-C


If you want to do this the other way around and see exactly what the *server* is receiving at both byte level and JSON level, feel free to use the information on the following link:

http://www.aardwolf.com/wiki/index.php/Clients/GMCP

It is the Aardwolf test server, but can be used to get a JSON level or byte-level dump of any data received via GMCP.

[Go to top] top

Posted by Bast   (78 posts)  [Biography] bio
Date Reply #52 on Tue 27 Jul 2010 09:06 PM (UTC)
Message
I hope this is the best place to ask this question and voice my concern.

Maybe I am not understanding this correctly, but let me try to explain

Ok, in the GMCP spec, you can Enable Modules. Do you have to send an updated full list every time with new modules you want added, or can you just enable the new module and the server keeps all the other modules that were previously enabled in the same state?

Also, my concern is when multiple plugins use the same modules. In OnEnable/OnInstall, the plugin asks to enable a module, then in OnDisable/OnClose, the plugin asks to disable the same module. What happens to the other plugins that need this data? Do we have to keep up with what modules have been requested on the client side with a counter and then when that counter gets to 0 disable the module? I ask this because I like to save bandwidth whenever possible and I don't want modules enabled that aren't needed or the plugins that used them are not enabled any longer.

I hope that made sense.

Bast

Bast

Scripts: http://github.com/endavis
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #53 on Tue 27 Jul 2010 10:43 PM (UTC)
Message
Bast said:
Ok, in the GMCP spec, you can Enable Modules. Do you have to send an updated full list every time with new modules you want added, or can you just enable the new module and the server keeps all the other modules that were previously enabled in the same state?

According to the IRE GMCP spec [1], you can use Core.Supports.Add to achieve this.

Bast said:
Also, my concern is when multiple plugins use the same modules. In OnEnable/OnInstall, the plugin asks to enable a module, then in OnDisable/OnClose, the plugin asks to disable the same module. What happens to the other plugins that need this data? Do we have to keep up with what modules have been requested on the client side with a counter and then when that counter gets to 0 disable the module? I ask this because I like to save bandwidth whenever possible and I don't want modules enabled that aren't needed or the plugins that used them are not enabled any longer.

Some kind of reference counting would be good. For each module, keep track of which plugins have enabled the package. When you cross from 0 to >1, send Core.Supports.Add. When you cross from >1 to 0, send Core.Supports.Remove.

[1] http://www.ironrealms.com/gmcp-doc

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Lasher   USA  (22 posts)  [Biography] bio
Date Reply #54 on Tue 27 Jul 2010 11:25 PM (UTC)

Amended on Tue 27 Jul 2010 11:38 PM (UTC) by Lasher

Message
Twisol said:

According to the IRE GMCP spec [1], you can use Core.Supports.Add to achieve this.


Looks like we're already into implementation differences. On Aardwolf, once you turn an option on it stays on until you turn it off. Turning on another option does not reset everything else.

In terms of the reference count, it would be relatively easy to add the reference count mud-side so that this doesn't have to be solved in every client separately, although this might be too far away from the base GMCP spec.
[Go to top] top

Posted by Bast   (78 posts)  [Biography] bio
Date Reply #55 on Tue 27 Jul 2010 11:46 PM (UTC)
Message
Twisol said:

According to the IRE GMCP spec [1], you can use Core.Supports.Add to achieve this.


[1] http://www.ironrealms.com/gmcp-doc


Ok, I did not see this because I thought the spec was only in the mudstandards forum and the Core spec in that forum did not include the Core.Supports.Add. Thanks for the link.

Aylorian said:

Looks like we're already into implementation differences. On Aardwolf, once you turn an option on it stays on until you turn it off. Turning on another option does not reset everything else.

In terms of the reference count, it would be relatively easy to add the reference count mud-side so that this doesn't have to be solved in every client separately, although this might be too far away from the base GMCP spec.


Mud-side would be great.

Bast

Bast

Scripts: http://github.com/endavis
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #56 on Wed 28 Jul 2010 12:47 AM (UTC)

Amended on Wed 28 Jul 2010 12:48 AM (UTC) by Twisol

Message
Aylorian said:

Twisol said:

According to the IRE GMCP spec [1], you can use Core.Supports.Add to achieve this.


Looks like we're already into implementation differences. On Aardwolf, once you turn an option on it stays on until you turn it off. Turning on another option does not reset everything else.

Presumably they expect .Set to be used once at the start, and .Add for anything else later on. I agree that just having .Add would have been simplest.

Aylorian said:
In terms of the reference count, it would be relatively easy to add the reference count mud-side so that this doesn't have to be solved in every client separately, although this might be too far away from the base GMCP spec.

Hmm... I'm not sure I agree, honestly. What if client-side issues cause one plugin to die without .Remove-ing its dependencies? The client is in the better position to handle this and other things.

It's really not that hard to implement this kind of refcounting, either. This could be done in Lua extremely simply; here's an example table:

modules = {
  ["Foo.Bar"] = {
    [0] = 2, -- refcount
    ["plugin id 1"] = true,
    ["plugin id 2"] = true,
  },
}


In short, it doesn't seem like the MUD should need to concern itself with what appears to be a decidedly client-side implementation issue.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #57 on Wed 28 Jul 2010 04:20 AM (UTC)
Message
Aylorian said:

Twisol said:

According to the IRE GMCP spec [1], you can use Core.Supports.Add to achieve this.


Looks like we're already into implementation differences.

Really? Good thing so much time was spent standardizing this before running into implementation...

(sorry... I just get bothered by so easily avoidable problems)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #58 on Wed 28 Jul 2010 04:43 AM (UTC)
Message
I agree. GMCP would have been better built by writing incremental implementations rather than laying everything flat up front.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #59 on Wed 28 Jul 2010 05:02 AM (UTC)
Message
I don't see how either end can safely remove modules. The server won't know if the client has had a plugin crash, which stopped it removing a module. Or indeed the client might erroneously remove the module once too often.

But for the client to do it, every plugin would need to know exactly what every other plugin needs, which surely is far too much interdependency?

I would suggest that, if both the client and server are designed to cope with a certain number of message types (eg. room changes, battle information, inventory) then once requested, they should be sent until the connection is broken. After all, the player installing a module, and then removing it, but remaining connected for weeks, is surely an unlikely scenario? And if the system can't cope with that many messages, then you have a problem in the first place.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


260,109 views.

This is page 4, subject is 9 pages long:  [Previous page]  1  2  3  4 5  6  7  8  9  [Next page]

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]