Kevnuke said:
This might be a stupid question, but if I used the telnet plugin callbacks in a plugin that doesn't send it's information from OnPluginTelnetSubnegotiation outside the plugin it's in, do i even need to use PPI. Can i just assign it to a local variable in the plugin and have it completely self contained?
You can, and there's nothing inherently wrong with that. The reason we have reusable protocol plugins is so that you don't have to handle the protocol-level details. Also, there can be issues with multiple plugins attempting to negotiate with the server, so it's better to have a single plugin do the talking.
The GMCP plugin I posted is a self-contained module that makes its data accessible to other plugins. It needs PPI or some other mechanism to do that. For example, the ATCP plugin I originally inherited used BroadcastPlugin() and the OnPluginBroadcast hook to notify plugins about new data, but it wasn't especially flexible. And neither approach can reliably call back to the world script-space.
Kevnuke said:
Personally, I'm also in favor of having the functionality of OnPluginTelnetRequest and OnPluginTelnetSubnegotiation as a client function in the main script space, so that they could be called in my script file or make them a premade hard-coded trigger that's available each time you create a new world file. MUSHclient already handles MCCP MXP and Pueblo in a behind the scenes manner. Why not ATCP and GMCP the same way?
From a design perspective, it's better to make things modular. Certainly the interfaces we have now aren't the greatest, but MUSHclient is over 15 years old at this point. It's pretty hard to tell what you're going to need 15 years down the road.
From a practical perspective, the codebase is now old and crufty, and it's a testament to Nick's skill that the client is one of the best I've used. It might not be worthwhile to add another protocol in a part of the code that hasn't been touched in a long time.
That said, I'm in favor of giving the world space more of the plugin-only callbacks. I also wish we could use CallPlugin to call into the world, since that's the only reason I remember why you can't use PPI from the world to talk to the GMCP plugin.
Kevnuke said:
It seems kinda stupid when I spend more time trying to figure out how to make a new idea work than actually playing the game that it's for when I want certain information to come from GMCP instead of from triggers or defining the variables manually myself.
Couldn't it be as simple as this?
health, maxhealth, mana, maxmana, endurance, maxendurance, willpower, maxwillpower, levelpercent = GetGMCPInfo ("Char.Vitals")
or
ash, bayberry, bellwort, bloodroot, cohosh, echinacea, elm, ginseng, goldenseal, hawthorn, kelp, kola, lobelia, moss, myrrh, pear, sileris, skullcap, valerian = GetGMCPInfo ("IRE.Rift")
Not really. Imagine if you just want the valerian? And how does the computer know what order to return the numerous (potentially optional) fields in? It'd be better to return a table and let you pick what fields you want, like the GMCP plugin does now.
Kevnuke said:
One more thing. Twisol, in the GMCP plugin you made codes.IAC_DO_GMCP is initialized but I don't see it actually used anywhere in the plugin. Is it there and i missed it, or is that index unnecessary?
That's a remnant from before OnPluginTelnetRequest, when we had to hijack OnPluginPacketReceived and send our own IAC DO GMCP request. It's not necessary, no. |
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top