Author Topic: Technical side discussion  (Read 164688 times)

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #80 on: July 14, 2015, 01:37:41 PM »
Incidentally, why do you apparently send presence to atlaspark_meta@ConferenceServer.FQDN/Resource when sending to atlaspark_meta@ConferenceServer.FQDN seems to work just as well?

  • Standard compliance.

    Quote from: XEP-0045
    In order to participate in the discussions held in a multi-user chat room, a user MUST first become an occupant by entering the room. In the old groupchat 1.0 protocol, this was done by sending presence with no 'type' attribute to <room@service/nick>, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room

    If the user does not specify a room nickname (note the bare JID on the 'from' address in the following example), the service MUST return a <jid-malformed/> error:

    (the next section explains that MUC builds on the old groupchat protocol and adds an extra namespaced 'x' element to signal MUC capabilities).

    Openfire is apparently being more lenient than is allowed by the spec in generating a nickname for you. Either that or slickxmpp is silently fixing it before sending.

  • The resource used when joining a room is used as the 'nickname' and is what shows up in the member list in clients like Pidgin, as well as the name the chat messages are attributed to. Paragon Chat tries to pick a suitable nickname for the context of the room -- if joining a global chat channel it will use your global name, if the room is for zone broadcast it will use your character name.

    It also uses the room nickname as a fallback if it can't resolve the sender back to a character name or global handle. This can happen when non-Paragon Chat clients are in an anonymous room that doesn't allow members to see the full JID. We are not using any anonymous rooms on the Titan server, but the logic is there for completeness.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #81 on: July 14, 2015, 02:48:14 PM »
SleekXMPP treats the resource as an option and distinguishes between a "bare" JID and a "full" JID. I'd wager that it's OpenFire that is assigning the "abc123" style of resource to clients that supply a "bare" JID.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #82 on: July 14, 2015, 04:04:04 PM »
I figure it won't be long before you ask me for a notification via XMPP when a player is 'clicked'. I'll start thinking about how to do it efficiently, probably by including some sort of indication in the presence that this player is interested in receiving events about it.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #83 on: July 14, 2015, 06:35:43 PM »
SleekXMPP treats the resource as an option and distinguishes between a "bare" JID and a "full" JID. I'd wager that it's OpenFire that is assigning the "abc123" style of resource to clients that supply a "bare" JID.

Yup.  But to be honest, because I was just trying to get off the ground, there's a lot of the XMPP implementation I shortcut around and am now going to implement for completeness, so I wasn't even running into boundjid/boundjid.bare issues because I was hardcoding jid.

I'm human, though (that's the story my parents keep telling), so I actually spent last night getting walk cycles to work.  Because implementing service discovery protocol is fun and all, but watching your bot moonwalk (because of yaw cosine sign reversal) will keep you awake till 2am.

I have no specific plans to reimplement the sequencer (yet) so that too is being cheated in for now.  Not sure I'm as ambitious as Codewalker in that regard, and I'm still going to have to do something with maps at some point, unless Codewalker beats me to version 1.3 first.

Also, bots don't have to obey gravity, and can enter any movement cycle that exists, so:



If you can construct the correct messages in the right order, bots can fly.

This is currently my bot's "brain" that is doing nothing more than obeying my keystrokes:

Code: [Select]
jog_moves = ['RUNPOST', 'RUNPRE', 'RUN_BACK_PRE', 'RUN_LEFT_PRE', 'RUN_RIGHT_PRE']
fly_moves = ['A_FLYPOSE1_POST', 'A_FLYPOSE1_PRE', 'A_FLYPOSE1_PRE','A_FLYPOSE1_PRE','A_FLYPOSE1_PRE']
pc_moves = []
pc_moves.append(jog_moves)
pc_moves.append(fly_moves)

class Pcbot_brain:
    def __init__(self):
        self.oldkeys = sets.Set()
        self.newkeys = sets.Set()

    # newkeys has only recently pressed keys, oldkeys has all currently depressed keys
    def processKeyState(self, kt):
        #print "Debug: oldkeys: " + str(self.oldkeys) + " new keystate: " + str(kt.keystate)
        self.newkeys = kt.keystate.difference(self.oldkeys)
        if len(self.newkeys) > 0:
            print "Debug: newkeys: " + str(self.newkeys)
        self.oldkeys = kt.keystate.copy()
        #print "Debug: new oldkeys: " + str(self.oldkeys)
        return

    def take_action(self, pcbot):

        move_speed = 0.3
        turn_speed = 0.05

        move_mode = (303 in self.oldkeys) # Right-Shift
       
        if 112 in self.newkeys: # P
            pcbot.send_pcPresence()
            print "Debug: sending pcPresence based on keypress"
           
        if 119 in self.oldkeys: # w
            pcbot.position[2] = pcbot.position[2] + move_speed * math.cos(pcbot.orientation[1])
            pcbot.position[0] = pcbot.position[0] + move_speed * math.sin(pcbot.orientation[1])
            if pcbot.animation != pc_moves[move_mode][1]:
                pcbot.animation = pc_moves[move_mode][1]
            pcbot.send_pcu()
        elif pcbot.animation == pc_moves[move_mode][1]:
            pcbot.animation = pc_moves[move_mode][0]
            pcbot.send_pcu()
        if 97 in self.oldkeys: # a
            pcbot.position[2] = pcbot.position[2] + move_speed * math.sin(pcbot.orientation[1])
            pcbot.position[0] = pcbot.position[0] - move_speed * math.cos(pcbot.orientation[1])
            if pcbot.animation != pc_moves[move_mode][3]:
                pcbot.animation = pc_moves[move_mode][3]
            pcbot.send_pcu()
        elif pcbot.animation == pc_moves[move_mode][3]:
            pcbot.animation = pc_moves[move_mode][0]
            pcbot.send_pcu()
        if 115 in self.oldkeys: # s
            pcbot.position[2] = pcbot.position[2] - move_speed * math.cos(pcbot.orientation[1])
            pcbot.position[0] = pcbot.position[0] - move_speed * math.sin(pcbot.orientation[1])
            if pcbot.animation != pc_moves[move_mode][2]:
                pcbot.animation = pc_moves[move_mode][2]
            pcbot.send_pcu()
        elif pcbot.animation == pc_moves[move_mode][2]:
            pcbot.animation = pc_moves[move_mode][0]
            pcbot.send_pcu()
        if 100 in self.oldkeys: # d
            pcbot.position[2] = pcbot.position[2] - move_speed * math.sin(pcbot.orientation[1])
            pcbot.position[0] = pcbot.position[0] + move_speed * math.cos(pcbot.orientation[1])
            if pcbot.animation != pc_moves[move_mode][4]:
                pcbot.animation = pc_moves[move_mode][4]
            pcbot.send_pcu()
        elif pcbot.animation == pc_moves[move_mode][4]:
            pcbot.animation = pc_moves[move_mode][0]
            pcbot.send_pcu()
           
        if 113 in self.oldkeys: # q
            pcbot.orientation[1] = pcbot.orientation[1] - 0.1
            pcbot.send_pcu()
        if 101 in self.oldkeys: # e
            pcbot.orientation[1] = pcbot.orientation[1] + 0.1
            pcbot.send_pcu()

        if 32 in self.oldkeys: # SPACE
            pcbot.position[1] = pcbot.position[1] + move_speed
            pcbot.send_pcu()
        if 120 in self.oldkeys: # x
            pcbot.position[1] = pcbot.position[1] - move_speed
            pcbot.send_pcu()
           
        return

It doesn't batch updates, it doesn't do prediction, and my send_pcu code doesn't quite correctly send the initial sequence once (its supposed to send MOVE_PRE once and then stop sending but I goofed in a simple to correct way, but I'm rethinking the entire process) so it studders if you hold down movement keys because it keeps re-entering _PRE.  But, you hold down the shift key, and she flies.  For a few feet at a time, anyway.  Then you release shift and she starts walking in the middle of the air.

Also, because of the way Paragon Chat works, there's a lot of lag.  I'm not sure if that lag is because of how Paragon Chat works, because of Openfire latency, or what, yet.  But that lag places limits on how instantly interactive a bot can be.  But at least I am in striking distance of the original goal for the bot project, which was to make a bot that can shadow box and fall down.  The lag I'm seeing makes the prospect of implementing react-moves almost comical, but we'll see what happens.

There's a difference between knowing, and seeing.  There's a lot about the animation system I know.  But its different when you have to pull every string, and you see what failing to pull a string or pulling the wrong string does.  I didn't think I needed to do this, but now I'm thinking I should implement inertia.  Movement just doesn't look right without it.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #84 on: July 14, 2015, 06:51:06 PM »
I figure it won't be long before you ask me for a notification via XMPP when a player is 'clicked'. I'll start thinking about how to do it efficiently, probably by including some sort of indication in the presence that this player is interested in receiving events about it.

Now that you mention it, I was thinking of asking for a "t=" target attribute for <u />, such that <u /> messages with t payload are unicast to the targeted entity rather than multicast throughout the meta room.  You wouldn't even need to put a target in the attribute, because if you get a t= message you're guaranteed to be the target.  If you later decide there's a benefit to everyone knowing who is targeting who, you could multicast that message with a target specified.  So if you get a message with t= but no target (t="") presume the target is you.  If you get a message with t=TARGET, presume this message means sender is targeting TARGET, which may or may not be you.  Private rooms could be flagged to allow broadcast targeting for special cases, while general rooms normally only unicast target.

Just thinking out loud.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #85 on: July 14, 2015, 06:54:25 PM »
Shiny!

I was wondering about whether bots would be subject to gravity or not.

Now, you realize, that right now, with no further modifications at all, you could just put your bot on a rail where she flies over Atlas every five minutes and you'd be freaking everyone out, lol.

Congrats on your accomplishment. :)


Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #86 on: July 14, 2015, 07:11:40 PM »
I was wondering about whether bots would be subject to gravity or not.

So long as you keep the Y velocity equal to 0, they should be able to ignore gravity. If you have any Y velocity at all, PC will apply gravitational acceleration to its prediction model and cause the bot to appear to fall, then it'll rubber-band back where it was on the next position update.

When 1.1 comes around with travel modes, I'll add an extra attribute to updates to indicate flight mode and disable that.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #87 on: July 14, 2015, 07:17:01 PM »
Now, you realize, that right now, with no further modifications at all, you could just put your bot on a rail where she flies over Atlas every five minutes and you'd be freaking everyone out, lol.

I wouldn't do that to Codewalker.  At least, not if he implements a VFX spawn primitive.  If not, and I get bored because I can't spawn Power Blast projectiles, who knows *what* I might do.  <sarcasm xmlns="Arcana:sarcasm" type="whistle" mode="nonchalant" dir="upward" />


Actually, Codewalker knows I would never do that to him because that would be mean.  I *would* load two bots into Paragon Chat that started fighting each other in Pocket D, because *that* would be mean but awesome, and there's the EULA to think about.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #88 on: July 14, 2015, 07:18:57 PM »
Actually, Codewalker knows I would never do that to him because that would be mean.  I *would* load two bots into Paragon Chat that started fighting each other in Pocket D, because *that* would be mean but awesome, and there's the EULA to think about.

Only if you put them in the monkey fight club ring. I think that would be sufficiently awesome.

Ironwolf

  • Stubborn as a
  • Elite Boss
  • *****
  • Posts: 1,503
Re: Technical side discussion
« Reply #89 on: July 14, 2015, 08:56:26 PM »
So a question - in the character creator all power animations are there, where are those stored?

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #90 on: July 14, 2015, 09:03:41 PM »
powers.bin, sequencers.bin, fxinfo.bin, particles.bin, and a few others... same as for regular power execution.

The character creator screen has a VERY hacked version of the sequencer and Fx spawning that would be sent from the server. I poked at it a while back but so many details are hardcoded that it's useless for anything except the power customization screen. It would be more productive to create a new power execution engine from scratch than to try to adapt that.

It's not like we don't have people who understand in complete detail exactly how to generate the visuals for any given power activation from the data. That's not an issue. It's implementing it where others can see it and doing something useful with that takes some work.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #91 on: July 14, 2015, 09:07:36 PM »
So a question - in the character creator all power animations are there, where are those stored?

I'm not sure I understand the question.  They are stored in the client, in various places in pigg files depending on the specific technical question you're asking.  The power database contains references to power animation files, one (basically) for each power.  Each of those files contains the sequence bits the client should trigger at specific moments during the power activation.  The animation sequence engine references a sequence database, also in a pigg file in the client, that tells the game client which animation "MOV" to play when a particular set of animation bits are activated, and also what to do by default after an animation plays (its called a sequence engine because when an animation is triggered, the sequence engine plays (or can play) a sequence of animations after that initial one without any further guidance or directive from the game servers).  Each animation MOV references an animation file, also contained in the pigg files, that describes precisely how to move the individual skeleton elements of an entity, frame by frame, to perform a fluid atomic motion.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #92 on: July 14, 2015, 09:15:27 PM »
Only if you put them in the monkey fight club ring. I think that would be sufficiently awesome.

I was thinking of spawning them looking like NPC patrons chatting, and when they detected enough players announcing presence in the zone, they would start arguing, and eventually start punching and kicking each other.

But there's a lot of stuff I would want to do before unleashing these guys on the live server.  For example, I noticed this morning that if the bot enters the zone second, Paragon Chat sees it, but when the bot enters the zone first Paragon Chat doesn't always see it.  Must be another presence thing.  Also, without inertia, gravity, and ground detection, knockdown and knockback isn't feasible to simulate.  And I need to match PC's prediction with velocity vectors, or things will look jumpy on the PC side.

Also, dammit I really can't see any way around implementing a sequence engine if I want my animations to look right.  Have to dig up my root calculator and adapt that.  Not exactly hard, just ugh.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #93 on: July 14, 2015, 09:42:46 PM »
Also, dammit I really can't see any way around implementing a sequence engine if I want my animations to look right.  Have to dig up my root calculator and adapt that.  Not exactly hard, just ugh.

Heh. I suspect that your "ugh" is most people's idea of "exactly hard".

Question for @Codewalker - Okay, two questions, or maybe one question and one feature request -

If I'm already planning to use an SQL database for various sorts of persistent data storage, and I see some mileage in having access to the PC character/costume database, is there any downside to just tossing my bot's tables into ParagonChat.db? Aside from the obvious "we might decide to delete the whole .db file during a software update" kind of downside, that is.

Given that pretty much all of the other costume info is in there, would it affect the database adversely to save the costume's hash in there as well? While that's a blatant bid on my part to avoid having to learn yet another new thing,it's something you have to compute anyway so having it in there where a bot can just "grab and go" would be extremely handy.


Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #94 on: July 14, 2015, 10:12:10 PM »
Heh. I suspect that your "ugh" is most people's idea of "exactly hard".

Question for @Codewalker - Okay, two questions, or maybe one question and one feature request -

If I'm already planning to use an SQL database for various sorts of persistent data storage, and I see some mileage in having access to the PC character/costume database, is there any downside to just tossing my bot's tables into ParagonChat.db? Aside from the obvious "we might decide to delete the whole .db file during a software update" kind of downside, that is.

Given that pretty much all of the other costume info is in there, would it affect the database adversely to save the costume's hash in there as well? While that's a blatant bid on my part to avoid having to learn yet another new thing,it's something you have to compute anyway so having it in there where a bot can just "grab and go" would be extremely handy.

I believe Codewalker would likely say what any experienced programmer would say. 



Paragon Chat's database is a sqlite database.  There's bindings for sqlite all over the place, and if you're going to use Paragon Chat's databases in any capacity you're going to have to learn that either way.  But its far safer to store your own data in your own sqlite database file, and just use Paragon Chat's database as a read only information resource.  In fact, you have to use a command line switch just to prevent sqlite from locking the entire thing in the first place.

Even in shared mode, having two separate programs writing to the same database program unaware of each other is generally a no-no.  Having two separate programs writing to the same database one of which is being patched every nine seconds and could conceivably change schema one day is a definite no-no.

The learning curve is exactly the same either way (in terms of technicals), but one is safe and the other is banana hat bonkers.

As to storing the costume hash?  I see where you're going there: you're lazy and don't want to implement the costume hash algorithm.  I like the way you think.  However, storing it in the Paragon Chat database seems like the wrong way to do that for a number of reasons, but in particular as it will only have hashes for costumes you literally create in the character creator.  You need to think bigger, and lazier.  I was thinking that maybe Paragon Chat could be convinced to give us the costume hashes, since it knows how to make them and all, and also that is implementation specific and could change over time.  You should ask Codewalker to implement an Iq message where a bot can send to a Paragon Chat client a costume, and get the official hash returned**.  Hypothetically speaking, then, the bot could ask any Paragon Chat client to help it compute hashes and then store them for any costume.  Let me know what he says about that.  I was going to get around to implementing hashing later, but maybe he'll take pity on you.  I think he would just tell me to get off my ass and implement the hash.


**  Tell Codewalker you think the costume exchange reminds you of ARP, and you want him to implement an analogous RARP.  We technical types love to talk protocols.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #95 on: July 14, 2015, 10:20:35 PM »
but one is safe and the other is banana hat bonkers.

Well, I'll admit that I expect him to probably say, "Hell, no, just export the database to your own database", but curiosity and all that. Plus it's one less thing to have to explain in the eventual documentation of the bot.

You need to think bigger, and lazier.  I was thinking that maybe Paragon Chat could be convinced to give us the costume hashes, since it knows how to make them and all, and also that is implementation specific and could change over time.  You should ask Codewalker to implement an Iq message where a bot can send to a Paragon Chat client a costume, and get the official hash returned**. 

Yeah, I thought that big already and when I said it to myself it came out sounding a lot like, "Hey, Codewalker, why not give us a Paragon Chat RPC API in your abundant free time?" and I decided to ask for something that sounded like it would take a few minutes to implement. :-p

Though I like the ARP/RARP analogy!

The plain fact is that the "ARP" would only be useful if the bot is making up new costumes on the fly. For most situations that the bot is going to change its costume, it should already have the costume defined and know the hash ahead of time. Basically, for any particular costume, the bot is already going to have a record identical what's already in the PC costume/costumeparts tables for any costume it might wear, though it would also have the hash already computed ahead of time, to save compute cycles if for no other reason.

« Last Edit: July 14, 2015, 10:33:49 PM by slickriptide »

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #96 on: July 14, 2015, 11:34:03 PM »
Yeah, I thought that big already and when I said it to myself it came out sounding a lot like, "Hey, Codewalker, why not give us a Paragon Chat RPC API in your abundant free time?"

That's the spirit.

Or, you know, if you really want to recreate that City of Heroes developer nag feeling, ask Leandro to implement it instead.

Firi1

  • Underling
  • *
  • Posts: 4
Re: Technical side discussion
« Reply #97 on: July 15, 2015, 02:00:17 AM »
I've been lurking. So far what y'all have come up with on such short notice is pretty amazing, nor going to lie. I have been day dreaming about the possibilities.

2 things that come to mind (and I saw this was touched on a little earlier at some point on regards to the ski timer). I was trying to watch the debug log but in all the jumble I didn't see anything- I know that the maps have different entities and triggers -- teleports, spawn points, gate 'zones' on the ski slopes, etc does the trigger zone information get passed to PC/other players or is it ignored? Any chance it could be if it isn't? Or would there be more problems to solves before that might be possible?

The other thing is thumbtacks. I forgot to check if these are working, so pardon me on this... Would this be shared with pc and possibly set by PC at some point in the future?


I hope to be able to dive into this more this week end. Keep up the awesome.!
//I hate typing on tablets...

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #98 on: July 15, 2015, 02:04:23 AM »
That's the spirit.

Or, you know, if you really want to recreate that City of Heroes developer nag feeling, ask Leandro to implement it instead.

*laugh* This forum really  needs a "like" button.


Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #99 on: July 15, 2015, 02:26:49 AM »
I've been lurking. So far what y'all have come up with on such short notice is pretty amazing, nor going to lie. I have been day dreaming about the possibilities.

2 things that come to mind (and I saw this was touched on a little earlier at some point on regards to the ski timer). I was trying to watch the debug log but in all the jumble I didn't see anything- I know that the maps have different entities and triggers -- teleports, spawn points, gate 'zones' on the ski slopes, etc does the trigger zone information get passed to PC/other players or is it ignored? Any chance it could be if it isn't? Or would there be more problems to solves before that might be possible?

Except for players and doors, most of the rest of the world in Paragon Chat is "inert" - it was the server that handled all of that, and we don't have mapservers.  But, there are things we can do that are not what the servers were capable of doing, but could in some cases creatively replace them.  For example, if you were looking at the debug console, one of the things you saw (whether you understood it or not) was everyone constantly announcing their positions in space, so everyone else's game client could display them properly.  Well, if you know where people are, and you know where things are, there are things you could do.  For example, and we discussed this earlier, suppose you wanted to allow players to run a race course, like the Ski slopes.  Until Codewalker makes those elements of the game function somehow, you can't actually use the active elements of the race course.  But you could monitor the location of players, and notify them when they crossed the starting line if you personally know where it is.  That's just geometric programming.  You could also detect when they crossed a finish line, and you could time those two events and announce it to players.  Lag would be potentially problematic, and the players don't get visual feedback beyond chat messages, but its something.

Out of convention, Codewalker is calling Paragon Chat's version 0.97-something-whatever Beta, but the truth is this is all really 0.03 early Alpha.  We're just scratching the surface of what's possible.  And some of what's going to be possible will be seeing how far Codewalker is willing and able to push the platform.  And some of what's going to be possible will be seeing how far other people are willing and able to push the boundaries of what the system is capable of doing with the right extra add-ons.  That's sort of where I've decided to play in all of this.

Standing between those that are trying to build it and those trying to use it is, actually, not entirely unfamiliar territory for me.


On the subject of costume hashes, I decided to break down and start thinking about it, so I can bang out the code when I get home.  However, I did notice some ambiguities in the spec.  For example, when the costume file data has quotation marks surrounding the name of the element, I am guessing those are just for the file format and they get stripped when the costume file is uploaded into City of Heroes.  What I don't know is whether the quotation marks are escaped and sent in costume replies, and whether they are preserved and used within the hash computation.  Second, for the 3D scales byte order is not explicitly specified.  It actually says the data is packed into a 32-bit integer and then converted back into hex, but the intervening int representation poses an odd and avoidable ambiguity.  Is it sufficient for that data to be directly converted to four hex strings, such that if the tuple is (X, Y, Z) what gets hashed is 00zzyyxx, where xx is the hex representation (minus the 0x) of X if X is positive, and abs(X)+128 if X is negative.

Quote
The other thing is thumbtacks. I forgot to check if these are working, so pardon me on this... Would this be shared with pc and possibly set by PC at some point in the future?

I suspect the only things that Paragon Chat will actually send to XMPP are things other players need to know.  No one needs to know where your thumbtacks are located, any more than other players need to know what your power tray looks like.  But as a separate issue, I don't think those have been implemented yet on any level.