Author Topic: Technical side discussion  (Read 164624 times)

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #180 on: July 21, 2015, 06:52:30 PM »
So what can I do with costume stanza support.  Well, I can do this:

https://www.youtube.com/watch?v=6WkWLy6wDsk

Its a little jumpy, but its interesting to me that at least some of the time the bot is both animating and resizing.  It suggests there's a lot of room for improvement.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #181 on: July 21, 2015, 08:37:16 PM »
Pivoting away from troubleshooting mode back to implementation mode, now that I've had my fun with size manipulation, I'm going to go back to making a combat dummy.  And it occurs to me that I'm basically going to refactor a lot of ancillary code again.

To be able to test the bot, I added keyboard controls.  The bot is really a remote controlled drone.  The problem is that the keyboard controls are a hack that directly fiddle with the bot's position and orientation.  My goal is for the bot to be semi-autonomous, meaning I can give it very simple goals like "move to this position" and the bot will do so, stupidly at first and perhaps more intelligently later.  This is important for a target dummy because the dummy needs to be able to do things like face an opponent, move towards it, and periodically initiate attacks.  Scripting that is possible, but not optimal.  I would like to be able to create goals and feed them into an execution engine like "move to X, turn towards Y, and execute animation Z."  It would be really nice if goals could be nested under prereqs: Goal "Execute Animation Z" prereq "RangeTo Y 7 feet".

That's not difficult, but it means rethinking keyboard controls.  Rather than have keyboard controls mess with the bot's position directly, keyboard controls should work with the goal seeking system by creating high priority tasks that basically tell the bot to honor the keyboard input.  So if I press W, what the keyboard system should do is say "player is pushing FORWARD, I will make a high priority goal causing the bot to want to move to a location about ten feet in the direction of its current orientation."  If the player releases W, I then revoke the goal (so the ten feet thing is really arbitrary, it just has to be larger than the maximum distance the bot could travel in one clock tick).

I'm thinking of making a pcGoal class, with three main elements: a prereq clause, an action clause, and a flags clause.  I'm thinking of a few basic action primitives: MoveTo (location), ExecuteAnim (animation), TurnTo (target).  At the moment two prereqs: RangeTo (target, val) (i.e range is less than val), CurrentLoc (loc) (i.e. I'm at loc within margin of error).  And a few flags (Orientation? would disable the default behavior of facing in the direction of motion).  Then some kind of structure to process them.  Still thinking about the best way to do that, and whether I want to be able to execute more than one goal at a time (imagine a bot that had two goals: MoveTo location and ShootTarget.  The bot could execute the first and keep checking the prereq of the second one, shoot when in range, and keep on moving.

The ski slope bot would not have been as fun as a goal seeking semi-autonomous pseudo-combat bot.  Now if only I had gotten this working *before* Codewalker put the clamps on size scalers.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #182 on: July 22, 2015, 06:23:33 PM »
Hey, all. I've got a presence-related question.

About this:
Quote
A visible bot MUST announce Presence using <pc /> and <character /> stanzas in the pc:presence and pc:character namespaces respectively, when you login, when you zone, and when you change costumes.  Presence will be automatically sent to new Paragon Chat users when they first login to Paragon Chat: you do not need to periodically announce Presence (pro forma XMPP, but mentioned here for completeness sake).

That "automatically sent" part - is that strictly true?

Your XMPP framework will send standard XMPP presence when someone new logs into your chat room, but don't you still have to track presence changes and send a copy of your bot's special Paragon Chat presence when you see someone new arrive?

"Automatic" in this context means that "you have to program your bot to automatically send presence when someone logs in", not "your XMPP client will remember your previously sent presence and repeat it whenever it sees someone new", correct?


Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #183 on: July 22, 2015, 06:43:18 PM »
No, per the MUC spec, chat rooms are required to keep a copy of the last presence stanza received from each member and send it to new members when they join. Once you send it to the room you never need to send it again unless its contents change, and doing so is just a waste of bandwidth.

"Special Paragon Chat presence" is standard XMPP presence, just with an extra namespaced XML element. There's no reason to ever send a presence stanza without that element if you are Paragon Chat or a Paragon Chat-compatible bot.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #184 on: July 22, 2015, 07:19:13 PM »
Speaking specifically about SleekXMPP, a ClientXMPP object can only connect to one room (well, not strictly true, but I wouldn't try anything else).  So if you want your bot to zone into Atlas Park and actually participate in the Atlas Park broadcast channel, you need to join both atlaspark and atlaspark_meta.  You need one ClientXMPP object for atlaspark and one for atlaspark_meta.  In the atlaspark ClientXMPP object you would initially announce presence to myaccount@conference.server/CharacterName per xmpp standard.  You would do similar in the atlaspark_meta room (as far as I'm aware, the nicknames can but don't need to be the same for connections coming from the same bot, although you would want your nickname in the broadcast channel to be what you want your chat to look like its coming from - no one sees the meta channel traffic).

Sample code tends to show the session_start function for ClientXMPP as doing a self.send_presence() and self.get_roster().  You would replace the "send_presence()" with your own function, or override send_presence before doing that.

Once you send Presence, the only time you need to resend it is if any parameter in the Presence message has changed, and the most likely reason for that to happen is if your bot changes costume.  That changes the hash, and you need to send Presence again this time with the new hash in place of the old one (send the entire thing: don't just send the hash).  Also, *initial* Presence should be sent to account@conference.server/nickname, but *updates* should be sent to just account@conference.server (no nickname)**.  That's probably more standards stuff, but I checked the debug logs to see what Paragon Chat would do in that circumstance (costume change) and emulated that behavior.  That's faster than reading the entire spec in many cases :)

An important rule to remember about XMPP is that (like most XML based protocols) XMPP is a take what you need, leave the rest behind protocol.  In other words, <presence /> is a special XMPP message that has proscribed processing.  There are special rules for how to handle that.  But when Paragon Chat "piggybacks" its own data in presence stanzas, that doesn't change how presence is handled at all.  Its still a <presence /> stanza, so XMPP servers will do exactly the same things to it that it would do to any other presence stanza.  It caches presence from you.  It sends it to people joining that context.  When I log into Paragon Chat with pidgin, pidgin gets that same stanza packet.  Pidgin has no idea what to do with <pc /> or <character /> but that's fine: pidgin takes what it needs, and leaves the rest behind.  When I connect with Paragon Chat, Paragon Chat gets the exact same presence stanza but it actually looks for those <pc /> stanzas, and when it finds them it uses them.

This form of piggy backing is how XMPP can be extended in a way that applications can add features which everyone else will just ignore, while continuing to process everything else the same way it did before.


** Apparently when you change costume Paragon Chat sends two presence updates, one to the room and one with no destination - basically root.  I don't think the second one is strictly necessary, but for now I'm emulating Paragon Chat's behavior until I get a chance to loop back around to looking it up

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #185 on: July 22, 2015, 07:53:03 PM »
Also, *initial* Presence should be sent to account@conference.server/nickname, but *updates* should be sent to just account@conference.server (no nickname)**.

Oops, that's a mistake. Presence updates to rooms are supposed to be sent to your occupant JID with the nickname, not to the room JID. Openfire apparently does the right thing, but that needs to be fixed as other implementations may not.

** Apparently when you change costume Paragon Chat sends two presence updates, one to the room and one with no destination - basically root.  I don't think the second one is strictly necessary, but for now I'm emulating Paragon Chat's behavior until I get a chance to loop back around to looking it up

That's because the costume hash is included in the presence. The one sent to the server itself is remembered by the server and is used for updates to people who have a presence subscription to you (i.e. you're on their friends list), and is broadcast to them when updated. If it weren't updated, the server would remember an old copy of it with a stale costume hash, and send that stale hash to your friends when they log in.

The costume hash could probably be omitted from the roster presence without ill effect, as it only needs the character name and map in order to show in the global friends list, but I was trying to keep the presence generation code somewhat generic instead of having so many special cases.

The very first proof of concept iteration actually included the full XML of the costume in your presence inside the <character>, but I very quickly decided that would be too unwieldy.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #186 on: July 22, 2015, 08:27:19 PM »
The one sent to the server itself is remembered by the server and is used for updates to people who have a presence subscription to you (i.e. you're on their friends list), and is broadcast to them when updated. If it weren't updated, the server would remember an old copy of it with a stale costume hash, and send that stale hash to your friends when they log in.

That's what I figured, although I wasn't certain.  What I should have said is that I don't think its strictly necessary for bots, because I don't think too many bots would end up on friends lists.  Although that's not a good assumption to make.

Its for the same reason that I currently skip a lot of the xmpp protocol like discovering conference server name.  A bot writer wouldn't necessarily need to do that if they know what it is on the target server, although it would be nice to autodiscover.  I don't do any significant disco of anything, because the bot isn't likely to operate in generic random environments at the moment although once again, at some point it would be nice to do.  However, I'm making a tactical decision not to add too much code to autoperform things a bot writer would just know and be able to hard code in with a lot less code, because it makes the bot more readable.  Eventually, I'll library-out more xmpp compliance stuff.

In fact, my bot currently can't zone.  Its hard coded to go to Atlas Park.  Not a problem at this stage of the game.  But I am continuing to compile notes on what is necessary, and what should happen, for the guide to bot writing I'm still compiling.  Which is getting longer, and longer, and longer (but still, honestly, not all that hard).

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #187 on: July 22, 2015, 08:32:12 PM »
I generally test in Ouroboros instead, it loads much quicker than Nouveau-Atlas, resulting in shorter test cycles.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #188 on: July 22, 2015, 08:51:11 PM »
I generally test in Ouroboros instead, it loads much quicker than Nouveau-Atlas, resulting in shorter test cycles.

Hmm, didn't think of that.  I guess my brain just defaulted to Atlas after years of thinking of that as the first CoH zone.

On the subject of testing, not directly related to bot implementation but it would be nice if /seqbits was reimplemented in Paragon Chat.  That would make it much quicker to experiment with animations than editing emote.cfg and restarting Paragon Chat.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #189 on: July 22, 2015, 10:25:42 PM »
Quick progress report, not that I imagine anybody is waiting with bated breath,lol.

The bot can load a costume file, compute its hash,and save the resulting <Costume> stanza as a costume.xml file. I'm on the fence about whether this is a value add or not, but it does mean the bot can easily implement a costume cache if that becomes a useful thing to do.

The bot defaults to "reasonable initial values" for costume, zone, etc...; things that will be made configurable at some point. At startup, it reads a copy of zone.cfg and creates a mapping of chat room names to map files.

It initially joins Atlas Park (heh) as a "reasonable default", along with Paragon Chat.

When it joins any room, it grabs the name of the room and compares it to its list of zones. If the room name matches one of them, then it:
  • Joins the appropriate metadata room
  • Initializes a new presence stanza for that room
  • Copies the default costume record to an array of costumes by zone chat room (so, a dict in Pythonese or an associative array anywhere else)
  • Set's the costume attribute and loads up the new presence stanza with the <pc> and <character> stanzas, then saves the completed presence stanza in another dict keyed on zone chatroom name
  • Sends the presence

When it leaves a chat room that matches a zone name, it also leaves the metadata room and it deletes the associated presence and costume stanzas.

So far, so good

Next steps -

Initialize the starting point on a per zone basis. This is a bit sticky as far as "reasonable default" values go. I might have to visit all of the zones and build a database of "default" locations for each one. Once I have that, then I'll have another mapping similar to the costume and presence mappings that hold a location+orientation per zone. (Eventually all of these individual bits will be normalized into a single record but for now the individual bits are easier to work with.)

Once the bot knows where it is in any given zone, then we start broadcasting <U> stanzas. Motion is a stretch goal here, so that will come later. I'll have to experiment with the polling routines I've got easily available but I'm thinking to emulate Paragon Chat - Watch for a presence change, advertise location, wait a semi-random amount of time, then check again.

Finally, setup handlers for the costume and bio IQ stanzas and reply to them as triggered.

The result of all of this is that the bot won't be a single avatar. It will be an avatar in every zone it joins, capable of carrying on conversations with multiple people at the same time. How that works out from a performance standpoint remains to be seen. However, at a bare minimum, the bot becomes a kind of "NPC Dispatcher". Without needing to move at all, it could greet a player as NPC A in Atlas Park, then as NPC B in Perez Park, then as NPC C in Galaxy City, all the while tracking the progress of the player from A to B to C and back again, while having all three avatars appearing to be in the game at the same time.

Voila. Quest chain.

How to use that creatively within the current constraints of interaction is a different matter, but the basics will be there.

The bot could potentially communicate with a website that records the player's activities and keeps a kind of "quest scoreboard" with the player's achievements recorded for everyone to see. It's not "inf" but it's a cookie for completing a "mission".

Anyway, that's where I'm heading with this. Motion is obviously an important stretch goal but it's still a stretch goal and I'm happy to let Arcana lead the way on the stuff that is undoubtedly going to get mathy pretty quickly.

The interesting thing to me here is that the bot is not an avatar or an NPC; it's the brain behind a stable of NPC's. How big a stable is difficult to guess at this point. Once it can carry on a conversation with one person, we'll see how well it does with multiple simultaneous conversations.


***EDIT***

One of the associated goals is to build a database of "points of interest". That is, a database of zones and locations labeled and possibly with a description. The goal would be to command the bot "!teleport Icon" and have it move the avatar for the current zone (whatever "current zone" means)  to the front step of the local Icon store. Likewise, "!teleport Icon Steel Canyon" would lookup the avatar in that zone, add one if none existed, and place it in the appropriate spot.




« Last Edit: July 22, 2015, 10:33:34 PM by slickriptide »

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #190 on: July 22, 2015, 11:13:04 PM »
Say....

Going along the same "bootstrapping" lines as wearing a costume you know is in cache:

Couldn't you setup your bot to record a series of U stanzas from a metadata room and play them back?

Your "real" City of Heroes client avatar could lay down the rails between point A and point B in a zone, and the stream of U stanzas it generates would then be the "beacons" that tell your bot how to travel on the rail. For most outdoor areas, flight would just be a matter of minorly adjusting the Y axis (yeah, that's a little weird but there it is) and using appropriate animations.


Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #191 on: July 22, 2015, 11:21:09 PM »
The interesting thing to me here is that the bot is not an avatar or an NPC; it's the brain behind a stable of NPC's. How big a stable is difficult to guess at this point. Once it can carry on a conversation with one person, we'll see how well it does with multiple simultaneous conversations.

SleekXMPP is threaded, which means every ClientXMPP runs its own stanza processing threads.  If you load each ClientXMPP instance with its own message processing logic (or even copies of the same processing logic) then every ClientXMPP object servicing an XMPP room presence can carry on (essentially) simultaneous conversations.


Quote
One of the associated goals is to build a database of "points of interest". That is, a database of zones and locations labeled and possibly with a description. The goal would be to command the bot "!teleport Icon" and have it move the avatar for the current zone (whatever "current zone" means)  to the front step of the local Icon store. Likewise, "!teleport Icon Steel Canyon" would lookup the avatar in that zone, add one if none existed, and place it in the appropriate spot.

One thing you should consider doing is having your bot respond to commands as tells.  So when you're logged into Paragon Chat, you can send your bot a command like /tell SlickBot "SlickBot: !teleport Icon" and that SleekXMPP instance would then teleport itself to that location.  Although I have keyboard controls to test things like movement (because it makes more sense), I can also send my bot tells (i.e. <message />) to do things.  Helps a lot for testing, and would be interesting to give you a means to control the bot from within Paragon Chat itself.  You can add a special directive that prevents others from sending the bot commands: I do that with a magic number: /tell ArcanaBot "ArcanaBot6871: anim ThunderKick" tells the bot to play the ThunderKick emote (defined in my emote.cfg) and the 6871 nonsense is a preprogrammed ID for the bot that is not broadcast to anyone.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #192 on: July 22, 2015, 11:30:01 PM »
Say....

Going along the same "bootstrapping" lines as wearing a costume you know is in cache:

Couldn't you setup your bot to record a series of U stanzas from a metadata room and play them back?

Your "real" City of Heroes client avatar could lay down the rails between point A and point B in a zone, and the stream of U stanzas it generates would then be the "beacons" that tell your bot how to travel on the rail. For most outdoor areas, flight would just be a matter of minorly adjusting the Y axis (yeah, that's a little weird but there it is) and using appropriate animations.

Case in point: you could program SlickBot to automatically record your position whenever it saw you do something, like send it a tell.  So you could log in with Paragon Chat and run around, and when you wanted to record a position you could say "/tell Slickbot "Slickbot: record 'This is Atlas tram'" and it would record your jid, position, and message to a file (you could do this from multiple alts if you wanted to, or you could even have volunteers help, thus recording the source of the tell).

If you know the order you're going to visit locations and you don't need to record text and you just want to record a sequence of locations, and you want SlickBot to be really slick about it, have Slickbot watch for jump to show up in your MOV in the <u /> and when it sees that, record the location.  Then you can run around and when you want to record a location, you can just hit the space bar.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #193 on: July 23, 2015, 12:45:41 AM »
One thing you should consider doing is having your bot respond to commands as tells.  So when you're logged into Paragon Chat, you can send your bot a command like /tell SlickBot "SlickBot: !teleport Icon" and that SleekXMPP instance would then teleport itself to that location.

This is one area where building on an existing bot framework buys me something. My bot is being built as a plug-in to Errbot, a chat bot that runs on top of SleekXMPP and that actually supports around a dozen modular backends. If Codewalker took it into his head to switch to an IRC server, I could handle that with some minor reprogramming of the room logic.

Bot commands like !Teleport have a simple definition template and bang, they work. Likewise, they're configurable so that some commands are "administrator only" and others are "public".

I don't have to manage rooms, for instance. I just tell the bot to !room join atlaspark@paragon.chat.cohtitan.com and it handles the rest. My code only has to worry about handling the callback when a room is joined and doing something in reaction (like joining the appropriate metadata_room).

The downside is that it's another moving part to learn, particularly when I end up having to fix the occasional bug in Errbot, and when the interfaces between Errbot and SleekXMPP aren't documented in any  way. Never mind that certain things still have to be done at the lowest levels of SleekXMPP's client interface so I still have to learn all that crap anyway, lol but I also have to do them in Errbot's XML stream and, did I mention about how well (ahem) some parts of it are (un)documented?

Yeah.

It'll all be worth it in the end but right now I'm in the middle of four simultaneous and criss-crossing learning curves between XMPP, Python, SleekXMPP and Errbot. How starry-eyed was I to imagine that I was going to just use an existing bot and "abstract away" all the nuts and bolts?

Yeah, heh

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #194 on: July 23, 2015, 02:57:47 PM »
Let's say I have a bot that starts transmitting presence, messages, et al from two different JID's: bot@chat.cohtitan.com/ClarkKent and bot@chat.cohtitan.com/Superman.

Assuming that the presence, character, U stanzas, all of that are consistent and correct for the two different full JID's, will that cause Paragon Chat to display two different avatars in the zone or will it simply display one avatar who keeps changing his identity between ClarkKent and Superman?


Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #195 on: July 23, 2015, 03:06:40 PM »
Assuming you're using two separate XMPP connections (which you have to; the server won't let you spoof the 'from' address as a JID other than the one you logged in with), you'll get two separate avatars.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #196 on: July 23, 2015, 06:38:32 PM »
Let's say I have a bot that starts transmitting presence, messages, et al from two different JID's: bot@chat.cohtitan.com/ClarkKent and bot@chat.cohtitan.com/Superman.

Assuming that the presence, character, U stanzas, all of that are consistent and correct for the two different full JID's, will that cause Paragon Chat to display two different avatars in the zone or will it simply display one avatar who keeps changing his identity between ClarkKent and Superman?

It just occurred to me to ask a question: you're overriding Errbot's presence routines, right?  Because presence is an integral part of XMPP chat, so Errbot by default probably sends presence automatically as part of its housekeeping.  If you are constructing your own presence stanzas and sending those "raw" so to speak, strange things might happen if Errbot also sends presence stanzas because depending on who sends when Errbot's could override yours (you don't get the superset of both presence stanzas, you get whatever the last one was, period). 

I ask because it just occurred to me that in your progress report you mention that you don't send <u /> stanzas yet, which means your bot can't be visible yet.  Are you certain that your presence stanzas are actually working correctly, and you aren't sending stanzas you shouldn't be sending?  I'm assuming you're testing all of this on your own Openfire server and can check things like whether or not Paragon Chat is happy with what you're sending by watching its debug logs even if you haven't gotten to <u /> stanzas yet.  Also, I would have thought Errbot would automatically handle setting from in your Presence stanzas.

Also, Codewalker's point is an important XMPP point.  Presence isn't just an information message, in many ways its almost like a pseudo-login name.  XMPP connections are authenticated with a login name and password, but every time you join a room its Presence that says "this is who I am."  Its not semantically correct to say "this is who I am, and also that is who I am."  Your jid can be different in different rooms, because your nickname/resource can be different.  But while Paragon Chat itself would be perfectly happy seeing you send two different Presence stanzas with two different jids, that's not kosher for XMPP itself and most servers won' t let you do that.

If you write your bot to make two separate XMPP connections, then of course anything it does in one of them would be independent of the second one, and that situation is indistinguishable from running two copies of the bot software itself.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #197 on: July 23, 2015, 08:05:54 PM »
It just occurred to me to ask a question: you're overriding Errbot's presence routines, right?  ...(you don't get the superset of both presence stanzas, you get whatever the last one was, period). 

So far, I haven't had to do that. It's been enough to establish a callback that happens *after* a room is successfully joined. This question is why I was asking recently about how Presence worked in certain situations. I was exactly concerned with the question you've raised.

My testing so far shows that as long as I establish a callback that triggers after the room has been joined and post my presence at that time, that my presence is the last one received by the server and that's the one that gets sent to other clients that join the room.

If I do establish that there are problems in this area then I'm prepared to copy the XMPP backend and hack on it to make a special Paragon Chat backend that inserts the presence at the lowest levels of the bot's communication framework.

Quote
Also, I would have thought Errbot would automatically handle setting from in your Presence stanzas.

Errbot handles things just fine but it's built on SleekXMPP so I can do anything to Errbot's client connection(s) that I can do to custom generated client connection. That means that I'm registering stanzas and writing handlers pretty much like you are probably doing it, but I'm accessing the code from higher up in Errbot instead of defining them explicitly as a SleekXMPP plugin. Handling Iq "get" requests will show whether that's going to continue to be a realistic way to handle things or if an explicit SleekXMPP plugin is going to be necessary.

In an ideal world, when this is all finished, I'd hand the package to someone and say, "Install X, Y, Z and you're golden" and they'd never have to learn any of this stuff.

Quote
If you write your bot to make two separate XMPP connections, then of course anything it does in one of them would be independent of the second one, and that situation is indistinguishable from running two copies of the bot software itself.

Yeah, and as you already mentioned, SleekXMPP is threaded so that's the "right" way to do such a thing. I have to ask about the lazy way, though. ;-)

It occurred to me that Paragon Chat uses the resource but the server mostly ignores it. If the server doesn't care what your resource is from minute to minute, and Paragon Chat treats the resource as a significant part of an avatar's "signature", so to speak, then it occurred to me that it might treat "bot@chat.server.com/Name1" and "bot@chat.server.com/Name2" as different identities and display them both. The fact that messages to both of them would be going to the same bare JID destination in the end would be irrelevant.

I expected to be told that it wouldn't work for the obvious reasons of a full JID being a full JID even if the server doesn't care what you assign to your resource when you login; it still wants it to stay constant for the duration of your session. But if that was *NOT* the case, well, that would make certain things a heckuva lot easier to implement.


« Last Edit: July 23, 2015, 08:14:06 PM by slickriptide »

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #198 on: July 23, 2015, 08:16:13 PM »
Paragon Chat doesn't care what your resource is. It tends to use your character name as the resource for the sake of other non-PC clients, but it doesn't really care about what other players set it to. The only thing it uses the resource for is a unique identifier to tell multiple connections on the same account apart from each other.

Note that the server *does* care what your resource is from minute to minute. Namely, once you log in, that's your resource for the duration of the session, you can't change it.

You can change your nickname in a chat room, but that's equally as unimportant. You can't join the same room multiple times from the same "from" resource; if you try to join again with a different nickname, what you're actually doing is signaling that you want to change your nick.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #199 on: July 23, 2015, 10:17:10 PM »
If the server doesn't care what your resource is from minute to minute, and Paragon Chat treats the resource as a significant part of an avatar's "signature", so to speak, then it occurred to me that it might treat "bot@chat.server.com/Name1" and "bot@chat.server.com/Name2" as different identities and display them both. The fact that messages to both of them would be going to the same bare JID destination in the end would be irrelevant.

Hypothetically speaking Codewalker could have done something like that, but that would violate the XMPP standard, and break normal chat using that protocol.  As a rule, I think its fair to state that in all respects Paragon Chat is a perfectly legal XMPP chat client that does everything basically by the book as a chat client, and only *extends* the protocol to add City of Heroes game client information, it doesn't break or otherwise change the protocol in any way.  So if a chat client can't or shouldn't do it, Paragon Chat won't do it either (at least in terms of protocol: I'm excluding things like jid leakage as a question of best practice, not adherence to protocol).