Author Topic: Technical side discussion  (Read 164666 times)

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #360 on: May 02, 2016, 06:27:52 PM »
Direct access to the client like that isn't something I was planning to expose over XMPP. The vision is that XMPP is used not as a control protocol, but as a synchronization protocol.

Paragon Chat is not directly translating the COH mapserver protocol to XMPP. That would be impossible, there's far too much disparity between the two. PC has no central server. Everybody is running their own server, and those servers synchronize globally visible state over a shared communication bus (XMPP). XP and dialog boxes make no sense to synchronize, since those things are specific to each player. Nobody cares about your exact XP total but you.

Things like you're talking about are a much better fit for the plugin / lua scripting architecture. With that, a plugin can hook directly into the local server state and update it, such as by changing the amount of XP that the player has, or using functions to show contact dialogs. Whether those plugins are local-only or if they coordinate with other players who have the same plugin installed is up to the author.

Since a hypothetical plugin would have access to the XMPP stream, I suppose if you really wanted to, you could write one to accept XEP-325 messages and take action based on them.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #361 on: May 02, 2016, 08:23:42 PM »
I can see what you're saying, but I was imagining it more like X-Windows, where the bot (or the XMPP server itself with some sort of game management plug-in) is the "client" and Paragon Chat is the "terminal server". It wouldn't know anything about game state. It would only know how to display the graphical representations of game state as instructed by the GM-bot. That would be in keeping with the "keep Paragon Chat from being a game in and of itself" premise of it.

A smart, LUA-enabled client would be capable of a lot more stand-alone functionality, which is also exciting and interesting. ;-)

« Last Edit: May 02, 2016, 08:50:33 PM by slickriptide »

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #362 on: May 06, 2016, 02:49:09 AM »
The CoH client has a built-in web browser.

Is it possible to present a http:// link in chat or in a character's Info window that invokes the web browser?


slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #363 on: May 16, 2016, 05:49:23 AM »
An update and a question.

I'm currently reorganizing and re-writing the core of my bot, for a few reasons.

 I want to move all of the SleekXMPP code into a specialized Paragon Chat backend that can be divorced from the "front end" so that someone receiving the bot as a package doesn't have to worry about the details of low level communication protocols.

I want to move most of the bits and pieces into a single consolidated Avatar() class that holds all of the character presence data as well as  the methods to update and publish that data.

I want to leverage the plug-in capabilities if Errbot to modularize function so that, for instance, a bot that  stands in place doesn't have to keep movement code loaded and taking up resources.

One thing the bot does is load the zone.cfg into memory to know when a a room is a "zone" with a "_meta" room. What zone.cfg does not provide is a hint for default coordinates. I've looked at a few maps from geobin.pigg. All of them seem to have player spawn points listed as coords 0,0,0, even though the CoH game client seems to know the real coords of the label in the zone.cfg.

Is there a way to find the x, y, z coords of the playerspawn points short of brute force visiting every map and recording the spawn in /loc?

« Last Edit: May 16, 2016, 01:03:23 PM by slickriptide »

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #364 on: May 21, 2016, 01:57:57 AM »
Well, it wouldn't be a week in Paragon City if I didn't have some new questions and desires.

Today's topic is chat text color.

Let me state up front that I am assuming I'm going to be disappointed but nothing ventured, etc...

The short version - is it possible to alter the colors of the chat dialog text or are the colors hard-coded to correspond only to the channel colors listed in the channel selection list? When the game was live, the channels expected that Pet Dialog, Battle Damage, and Help messages, for instance, would each be different colors and you'd identify the source of the text in your current chat tab by its color. In Paragon Chat, the text in the current "channel" is colored the same as the channel title.

On a related note, is it possible to color individual bits of a chat balloon or is it hard-coded to be one foreground color and one background color for the entire chat balloon?

The attached picture shows what I want to do:



PCBot is sending this message body: "<color blue>Hello, %s</color> <color green>How's things?</color>"

As you can see, the color has no effect on the "Broadcast" channel text. PCBot's chat balloon defaults the whole sentence to the last color tag it received.

In an ideal world, what I want to do is arbitrarily color individual words, like so: "Hello, %s. There's been a lot of <color red>gang activity</color> recently and we could really use your <color red>help</color>." (The idea being that someone would say, "What gang activity?" and the bot would respond with more info about activities it wants the person to participate in.)

This actually works in non-chat related dialogs, as the Description in the upper-left illustrates.

Is there any way to make this work in chat as well, or does the client programming make this a no-go?

What if you marked up your chat text as if it was from one of the built-in channels, like "Pet Damage Received"? Would the game client give it the appropriate colors, and would it apply them to just the marked up text or would it apply to an entire message?

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #365 on: May 21, 2016, 02:17:49 AM »
I don't know and I'm not actively developing in Paragon Chat at the moment, but I do know that the colors in the chat box are due to formating hash tags: they actually show up in the combat/chat logs.  You might try experimenting with sending those and just see what happens.

What the game can do and what we were allowed to do are different things, and Paragon Chat may sometimes bypass limitations that were imposed upon us.  I'm thinking specifically about the chat-pocalypse that happened during one of the betas when someone discovered you could trick the client into embedding graphics within chat dialog.  The devs decided to remove that feature, but it was only there in the first place because the chat rendering could do some interesting tag processing in the first place.

Experimentation might be the only way to authoritatively know what can and cannot happen in this area.  Or I suppose Codewalker can figure it out as well.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #366 on: May 21, 2016, 03:30:36 AM »
The short version - is it possible to alter the colors of the chat dialog text or are the colors hard-coded to correspond only to the channel colors listed in the channel selection list? When the game was live, the channels expected that Pet Dialog, Battle Damage, and Help messages, for instance, would each be different colors and you'd identify the source of the text in your current chat tab by its color. In Paragon Chat, the text in the current "channel" is colored the same as the channel title.

The colors come from the channels, not the chat tags. That's handled by the client - the 'server' piece just sends the channel ID, it doesn't set the colors. Even the customizable channel colors are controlled by the client; the server just acts as dumb storage for the chat settings.

Internally the text drawing may use the tags to do it, but that's an implementation detail. Probably the client strips off any formatting tags from the incoming text and encloses it in one to set the correct color for the channel that the text arrived over.

On a related note, is it possible to color individual bits of a chat balloon or is it hard-coded to be one foreground color and one background color for the entire chat balloon?

Pretty sure the balloon text can't switch formatting mid-stream. You can't even have different font sizes in a balloon together; it changes the whole thing.

What if you marked up your chat text as if it was from one of the built-in channels, like "Pet Damage Received"? Would the game client give it the appropriate colors, and would it apply them to just the marked up text or would it apply to an entire message?

That isn't controlled by markup at all. For it to show up in that channel, it has to actually be sent over that channel.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #367 on: May 21, 2016, 04:19:11 AM »
That was poor language choice on my part. By "marked up as a channel" I meant embedding a <channel> substanza with an ID of "pet_damage_received" or whatever the actual label would be.


slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #368 on: May 21, 2016, 04:40:57 AM »
devs decided to remove that feature, but it was only there in the first place because the chat rendering could do some interesting tag processing in the first place.


Well, if I'm being honest I'd already figured that out by examining the various *message bin files and I was hoping that I could get it to display at least a badge icon or other graohic. From what you've said, that may be unavailable (though it may work in the description dialog).


slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #369 on: May 21, 2016, 11:10:26 PM »
Channels are not working the way I would expect them to work.

Here's a sample of a message being sent to Paragon Chat, as copied from the Paragon Chat debug log:
Code: [Select]
xmpp DEBUG RECV: <message type="groupchat" to="slickriptide@cjj-pc/Slickriptide"
 lang="en" from="atlaspark@conference.cjj-pc/ErrBot"><body>&lt;color blue&gt;Hel
lo, Slickriptide&lt;/color&gt; &lt;color green&gt;How's things?&lt;/color&gt;</b
ody><channel id="request" xmlns="pc:message"/></message>

I would expect that PCBot's responses would come out colored as Request chat.

That isn't what happens.

There are four channels that can communicate with another player: Local, Broadcast, Request and Global.

Example 1: No channel stanza.
Local - Bot reply formatted as a /tell (due to the way local is implemented, the bot sees a private message and replies in kind)
Broadcast - Bot muc reply colored and labeled as "Broadcast"
Request - Bot muc reply colored and labeled as "Broadcast"
Global - Bot reply received as a /tell, and client prompt labeled and colored in the Global tab as Local.

So, anomaly #1 - Global is behaving as an alias for Local. Is this a bug?  It remains true for all of the following examples, so I'll omit Global from here on out.
Anomaly #2 = Request defaults to Broadcast as its default formatting.
Anomaly #3 - the fact that the channel the client sends from even has an influence on how it interprets the channel a message is received on.

Example 2:
A channel stanza is sent but no ID is set.
Local - The bot reply is labeled and colored as Local. The existence of a <Channel> stanza is enough to cause the private tell to be treated as "local chat".
Broadcast - The bot reply is labeled and colored as Broadcast
Request - The bot reply is labeled and colored as Broadcast

Example 3:
A "legal" channel is set as the channel ID, where "legal" means one of Local, Broadcast, Request, or Global
Local - The bot reply is labeled and colored as Local, regardless of the ID
Broadcast - Broadcast and Request are displayed as specified, Local is displayed as Broadcast
Request - Broadcast and Request are displayed as specified, Local is displayed as Broadcast

Example 4:
An "extras" channel is set as the channel ID; for instance, Friends, Arena, or League
Local - The bot reply is labeled and colored as Local
Broadcast - The bot reply is labled and colored as Broadcast
Request - The bot reply is labeled and colored as Broadcast

The patterns are consistent for other values of channel ID.

Given how a lot of this comes down to how the CoH client handles the information that Paragon Chat is passing to it, I don't know if the above is strictly a bug. It's just not the straight across "set a channel ID stanza at one end and get that channel display at the other end" correlation that I expected.



Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #370 on: May 22, 2016, 04:05:53 AM »
Here's a sample of a message being sent to Paragon Chat, as copied from the Paragon Chat debug log:
[-snip-]

I would expect that PCBot's responses would come out colored as Request chat.

That message should be coming in over request, unless there's some subtle typo that I'm not seeing. Since you're also trying to manipulate the color, do you have broadcast and request split out to different chat tabs so you can tell which channel it's actually arriving over instead of looking at the color?

There are four channels that can communicate with another player: Local, Broadcast, Request and Global.

What is "global"? There is no "global" channel. Do you mean global channels? Each one is a separate channel that is associated with the JID of the room for it.

I think you're misinterpreting the purpose of the channel stanza. It isn't there to say which in-game channel the message is supposed to be sent over. It's there to distinguish between different sub-channels that are multiplexed over the same XMPP communication method.

There is not a 1-to-1 mapping between COH chat channels and methods of communicating in XMPP. The semantics of various channels are different and don't always map to similar XMPP capabilities. Some channels share the same underlying XMPP transport method with others that have the same semantics. Request and broadcast are a good example because they are both zone-wide and prefer character names over globals. So they share the zone's broadcast room instead of having two separate rooms. Incoming messages from that room default to broadcast and the presence of the channel stanza signals that it's request instead.

Ultimately the transport that the message arrived over (type=chat/groupchat, which room it came from, etc) determines where it is routed.

The way it should work:

Groupchat messages arriving over the room associated with a global channel -> That channel
Groupchat messages arriving over the zone's broadcast room that have a channel tag with an id of 'request' -> Request
Groupchat messages arriving over the zone's broadcast room -> Broadcast
Chat messages containing a channel tag with an id of 'emote' -> Emote
Chat messages containing a channel tag -> Local (Paragon Chat sends 'local' for this, but the presence of the channel stanza triggers routing of the message into the local chat handler. That handler only checks for emote and defaults everything else to local. This behavior may change so it's best to not depend on it and always use 'local')
All other chat messages -> Private tell

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #371 on: May 22, 2016, 04:38:21 AM »

What is "global"? There is no "global" channel. Do you mean global channels? Each one is a separate channel that is associated with the JID of the room for it.

In the CoH chat window, there is a row of buttons for selecting the channel you want to chat in. L = Local, B = Broadcast, T = Team, etc... The last one is labeled 'A' and when you click it, it changes the chat channel to 'Global', which does not start with 'A' and which behaves like 'Local' in Paragon Chat.

Quote
I think you're misinterpreting the purpose of the channel stanza. It isn't there to say which in-game channel the message is supposed to be sent over. It's there to distinguish between different sub-channels that are multiplexed over the same XMPP communication method.

And here is the heart of the matter. You're absolutely correct. I was treating <channel> as "use this client channel", especially since Broadcast and Request appeared to be working just like that.

Okay, so that pretty much invalidates most of what I posted and once again my desire to send some sort of hilighted text is stymied, heh.

On the other hand, if Emote is its own channel then maybe I can use that for "out of character" text. I'll give it a try and see how it looks.

So, the only real reason for a bot to care about channels is make sure that Local chat and maybe emotes get handled properly.

So, what's the point of the Request channel? Does it have an intended use other than being broadcast in purple?
« Last Edit: May 22, 2016, 04:48:50 AM by slickriptide »

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #372 on: May 22, 2016, 04:51:20 AM »
In the CoH chat window, there is a row of buttons for selecting the channel you want to chat in. L = Local, B = Broadcast, T = Team, etc... The last one is labeled 'A' and when you click it, it changes the chat channel to 'Global', which does not start with 'A' and which behaves like 'Local' in Paragon Chat.

Oh, 'A' is Active, which means to use the default channel of whatever chat tab has focus (it should be a different color).

I think the name of one of the default tabs created by the client is Global. That's probably where it's coming from. That tab must have local set as its default channel. The default channel can be set in the edit chat tab window.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #373 on: May 22, 2016, 04:54:20 AM »
So, what's the point of the Request channel? Does it have an intended use other than being broadcast in purple?

*shrug* No idea, really. Sometimes it would get used by Hamidon / mothership raid leaders because of it being a different color.

Since it's functionally identical to broadcast, implementing it in paragon chat took no time at all, so I figured why not.

The emote channel is also identical to local, with only cosmetic differences - but the messages are formatted in italics and the chat bubbles show up as thought bubbles.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #374 on: May 22, 2016, 08:51:04 AM »
So, what's the point of the Request channel? Does it have an intended use other than being broadcast in purple?

I think it was originally intended to be a kind of trade request channel.  Hey, anybody wanna trade a Mutant Acc SO for a Tech Dmg SO?  That kind of thing.  Needless to say it was almost never used for that purpose, or as far as I'm aware, any purpose.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #375 on: May 22, 2016, 03:24:19 PM »
After a bit more experimentation, I've determined that Arcana is, sadly, correct that the devs must have disabled format tags entirely in chat text. OTOH, formatting in other dialog windows seems to work just fine. See the Description window below:


The chat text at the bottom contains the same tags as the Description window.

So, chat pictures and formatted chat text are out, but if Paragon Chat someday acquires a LUA engine that can launch dialog windows, those windows will render formatting tags.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #376 on: May 23, 2016, 03:13:44 PM »
***edit***

Moved this post to a topic of its own.
« Last Edit: May 23, 2016, 04:51:48 PM by slickriptide »

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #377 on: May 28, 2016, 01:35:52 PM »
Does Paragon Chat currently do anything with the <show> element?

Getting back to this question of hiding a bot. Let's say I want to emulate the old CoH thankyou behavior. I want the bot to run to a player, say "Thank you", run a few feet away and fade away.

Accomplishing that fadeout by leaving the metadata MUC puts you in for a whole load of overhead when you rejoin the room; especially if you're tracking all of the users in the room.

If Paragon Chat treated <show>XA</<show> as "Don't render this avatar" then the NPC could fade out without having to leave a metadata room that it intends to immediately rejoin.

A bot could move from point A to point B instantly without Paragon Chat rendering the motion, by turning invisible before relocating.

I guess that however it's accomplished, it would be useful to have a bot capable of becoming invisible without leaving or creating a deliberate costume error status in the process.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #378 on: May 29, 2016, 03:38:37 AM »
The only things it does with that element are to make a player appear AFK, and also update their status in the global friends list.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #379 on: May 29, 2016, 04:50:53 PM »
Putting aside my normal semi-unrealistic wish list -- A person who uses Paragon Chat solely as a chat client will occasionally want to "lurk" and hear what's going on even though she isn't actively participating. That's why text-only clients have options like "away", "do not disturb", and "extended away" instead of just forcing the person to disconnect.

A person in "lurk mode" may prefer that his avatar be hidden to avoid the appearance of inviting conversation, or of ignoring someone who doesn't realize they are AFK.

It's a valid answer to say, "Then they should just use Pidgin for that" but you ordinarily don't want to tell someone that they have to use two different clients to do one job.

Likewise, putting the responsibility of typing "/afk" on the user is a valid answer. I'd just suggest that sometimes a better answer is to remove the illusion of presence entirely. At least, the option would give a user choice in how to make themselves be "afk".

Something for the feature suggestion list.