GMCP Event for Wilderness Map

It would be great if a GMCP event was sent just before any wilderness map was displayed.  This would be most useful for Seafaring since the usual GMCP Room.Info events don't get raised when your ship changes locations, so currently we're required to trigger on the various ship movement messages.

It would also be helpful to receive a similar GMCP event after the wilderness map is finished, so that we can stop whatever we were doing with the map (redirecting it to another window, logging it, etc).

Thoughts?

Comments

  • NizarisNizaris The Holy City of Mhaldor
    @Malaphus: I'm afraid that this wouldn't work well at all, unless the GMCP event contained the wilderness map itself. Trying to base capture off of timing is ... imprecise. I talk about timing because GMCP is in a different channel from the regular output from the MUD, and receipt of the two channels by your computer isn't necessarily synchronized due to things like lag. Ultimately, this would lead to things that aren't the map being displayed in the map console window.

    Instead, it would be best for you to take triggers from the same channel that the wilderness map is displayed in (ie. the normal text channel). Doing a quick google search for "achaea wilderness map capture" turned up this comment by @Eld that might be helpful. It's very old, but it's a good place for you to start.
    image
  • I'm not sure why lag would be a problem.  TCP ensures that all packets arrive and are in proper order, you should never get a GMCP event that isn't in the order it was sent, meaning as long as the game sends the theoretical GMCP startMap and endMap events before and after the map respectively, you should always receive them in this order.  If this wasn't the case none of your other multiline triggers would work and you would often see room descriptions before room names, death messages before the last damage dealing message in a fight, etc etc.
  • GMCP always arrives before the displayed text. This is something I've been wanting for awhile, and have been trying to figure out a way around. I think the only thing that's necessary though is a flag in gmcp that indicates what map you'll receive by the MAP command in game. Using that, you can trigger which window to show (Mudlet mapper or wilderness capture), and you can capture the wilderness by opening the triggers on a room title and closing them on the following prompt.
    image
  • Aye, but I think we only receive the GMCP data before other text because that's the way the game sends it to us.  I obviously don't have all of the back-end details but I'm not sure why two new events (mapStart and mapStop) can't be sent in some other order.

    If this isn't possible for some reason, then even raising Room.Info event (or some other new event) when your ship changes locations would be helpful.
  • No, I think Mudlet processes the start and end map events which come before and after a map as GMCP events at once at first and then you get the usual text.

    It would be handy to check against the GMCP spec, but the website hosting the draft wasn't maintained by IRE and the domain expired. So who knows now how is it supposed to be.
  • Perhaps a CONFIG option to add start and end tags before and after the wilderness map?
  • TectonTecton The Garden of the Gods
    We added some tags around the wilderness map recently to allow for redirection within the next version of the HTML5 client. I think it's under the IRE Display module - Ohmap start/stop.
  • edited January 2014
    Tecton said:
    We added some tags around the wilderness map recently to allow for redirection within the next version of the HTML5 client. I think it's under the IRE Display module - Ohmap start/stop.
    Can you supply any details on how this might be used?  I see the Ohmap start and stop messages coming in after registering the display module but a packet capture (compression disabled) doesn't indicate that these events happen before/after the wilderness map is displayed.

    Also, any chance we can get the IRE gmcp doc updated to reflect this (and any other undocumented modules) updated?

    Thanks!
Sign In or Register to comment.