Author Topic: Technical side discussion  (Read 164654 times)

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #340 on: April 25, 2016, 09:44:39 PM »
So, I'm not surprised to learn that a NPC costume is an illegal costume for a bot, but I had my hopes.

It doesn't care about NPC pieces per se, but the same rules that apply for player costumes are in effect. A costume will only be accepted if the scales are in the valid range for players, and if any referenced FX are associated with costume pieces that are available to players.

The geometry and textures are not verified (intentionally, so that some NPC stuff can be used). The FX are, in order to prevent people from using things like power effects, screen space FX, and spamming oneshots in a context designed for maintained FX only (that can eventually lead to a client crash).

Question - Is it well understood how the Halloween costume powers functioned? Is there a possibility of duplicating that function in Paragon Chat? I'm only suggesting this if it's more or less a switch inside of the client where the server sent a message that said "replace your current model with this NPC model".

Changing models to an NPC is easy. The only reason there isn't a method in the protocol to do it currently is because some of the NPC models are a griefer's dream, and I've already had to boot a couple people for spamming the deactivate chrono whatever MOV in pocket D.

Protocol support for changing models is dependent on the permissions framework. Once that's in place, it can be limited to private instances and people who have GM rights. A whitelist of known-good models for use in public zones may be in the cards if there is enough volunteer support to do the legwork for it once the system is ready.

One is that launching the bot with a NPC costume as its initial costume caused it to be invisible, but commanding it to change to a legal costume made it visible. Not a surprise, really. I was sort of hoping that if it was invisible that I could still see its chat bubbles in local and have it pretend to be a static NPC, heh. No dice there.

Two, and more interesting, is that starting with a legal costume and changing to an illegal costume caused no visual change for the bot. I would have expected the bot to become invisible with an illegal costume exception in the /whoall. Instead, it retained its previous costume, from a visual standpoint, even though it's presence was being advertised with an illegal NPC costume.

I'm not sure if this is a bug or a feature?

Neither? Being "invisible" isn't a supported state that something can be in. It's the result of incomplete or inconsistent data that Paragon Chat is unable to reconcile, such as not having a costume at all. If the location data is otherwise good, Paragon Chat creates a placeholder entity to track it, but due to the lack of a valid costume, does not send it to the client yet. This half-formed entity is good enough for the local chat mechanism to work and is what is commonly referred to as "invisible". Only once the entity is fully complete is it sent to the client and becomes visible.

Once the entity is fully realized, trying to switch to an invalid costume won't undo that. It'll just reject the costume change and leave the costume that is currently applied.

So, using an invalid costume doesn't make you invisible. The best way to explain it would be to say using an invalid costume results in "undefined behavior".

What you might be able to get away with is using a valid costume that has no parts (or rather, empty parts). Or just send the bot to some far-off coordinates.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #341 on: April 25, 2016, 10:01:00 PM »
What about sending <presence type='unavailable'/>? Does that have an effect on Paragon Chat?


slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #342 on: April 25, 2016, 10:20:23 PM »
I'm currently trying to figure out why FreeBSD's LSI driver (both of them) stall their writes to Intel 3510s under high random load. Work has me chasing a number of really complex systems problems at the moment.

When I was in college far too many decades ago, I made an attempt (only partially successful) at writing a device driver so that a Unix v6 (Yeah, not even System 7) machine could read an IBM RL01 disk pack. The fact that I didn't know anything about writing device drivers was okay, since nobody else at the time really knew anything about it either.

Personally, I'm glad there's an Arcana to take care of these things in the modern world because I sure haven't got the chops for it today.


Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #343 on: April 26, 2016, 01:23:15 AM »
What about sending <presence type='unavailable'/>? Does that have an effect on Paragon Chat?

Sending it where?

If you send it to the meta channel... well, sending unavailable presence is how you leave a room. So that'll make the bot disappear, but also make it unable to see what is going on in that zone.

Sending it unqualified just disconnects you from the server. Mostly anyway, it doesn't close the stream but most servers will not forward you any stanzas while you're unavailable.

As for directed presence... I don't know, that's kind of a murky area of the XMPP spec. Paragon Chat itself won't do anything with it IIRC, other than maybe make the bot display offline in the global friends list.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #344 on: April 26, 2016, 01:53:15 AM »
What you might be able to get away with is using a valid costume that has no parts (or rather, empty parts). Or just send the bot to some far-off coordinates.

I was thinking the most logical way to be somewhere kinda, but be invisible, would be to change your location to a point directly under the map.  You'd be "there" but impossible to see.  You might also need to set yourself to fly so gravity doesn't yank you to the bottom of the map if you accidentally move downward.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #345 on: April 26, 2016, 02:25:25 AM »
Alright, that's about what I expected.

One last thing for today - another of those, "I'm not sure if this is strictly a bug or more a matter of the bot requiring sane bounds checking" things.

I was experimenting with some costumes that I made straight out of the Paragon Chat costume creator and none of them were loading. Not when I issued a command to the bot, and likewise not even when the costume was the bot's default costume.

After examining the offending costumes, I found they all had something like this in their opening stanzas:

Code: [Select]
{
CostumeFilePrefix male
Scale -3.934e-006
BoneScale -1.192e-007
ShoulderScale -1.192e-007
ChestScale -1.192e-007
WaistScale -1.192e-007
HipScale -1.192e-007
LegScale -1.192e-008
HeadScales  0,  0,  0
BrowScales  0,  0,  0
CheekScales  0,  0,  0
ChinScales  0,  0,  0
CraniumScales  0,  0,  0
JawScales  0,  0,  0
NoseScales  0,  0,  0
SkinColor  255,  178,  155
NumParts 28

The scales turned out to be the source of the problem. The bot didn't do any checking on the values in the scales, it just accepted them on faith. Technically, that makes it a bug in the bot. It should be treating 0.0000000197 as zero rather than blindly accepting it as meaning something.

Essentially, these values are what happens when you skip past the scale sliders without changing them. Adjusting the scales changes the values enough to make them meaningful.

I *think* (but am not positive) that this is new behavior since v0.98a of Paragon Chat. I could be wrong - it might be that I just never made a costume without nudging the sliders a bit.

In any case - bots need to be aware of the possibility that the scales need to be rounded off to some reasonable number of decimal points rather than accepted verbatim.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #346 on: April 26, 2016, 02:30:13 AM »
I was thinking the most logical way to be somewhere kinda, but be invisible, would be to change your location to a point directly under the map.  You'd be "there" but impossible to see.  You might also need to set yourself to fly so gravity doesn't yank you to the bottom of the map if you accidentally move downward.

I'll have to try that. I have a feeling that you'd see the bot actually sink in to the ground as it moved from A to B,  at least based on my other experiments with what happens when I tell the bot to "go to loc X, Y, Z".

.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #347 on: April 26, 2016, 02:47:29 AM »
The scales turned out to be the source of the problem. The bot didn't do any checking on the values in the scales, it just accepted them on faith. Technically, that makes it a bug in the bot. It should be treating 0.0000000197 as zero rather than blindly accepting it as meaning something.

That shouldn't matter. Did you look at the XMPP output to verify that they didn't get turned into something crazy in the XML by the floating point formatter?

I *think* (but am not positive) that this is new behavior since v0.98a of Paragon Chat. I could be wrong - it might be that I just never made a costume without nudging the sliders a bit.

I don't remember exactly when the scale verification went in, it might have been after that. But values near 0 should be perfectly fine, since the baseline is all 0 and valid ranges extend in both the positive and negative direction.

I'll have to try that. I have a feeling that you'd see the bot actually sink in to the ground as it moved from A to B,  at least based on my other experiments with what happens when I tell the bot to "go to loc X, Y, Z".

I don't think I remembered to implement it yet, but I have on my todo list a movement flag for instantaneous, for teleport as well as entering doors.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #348 on: April 26, 2016, 03:15:13 PM »
That shouldn't matter. Did you look at the XMPP output to verify that they didn't get turned into something crazy in the XML by the floating point formatter?

According to my logs, the XML and hash string were just copying the slider values verbatim. That is, the literal string "-1.92e-007". There didn't seem to be any funky formatting happening. Is there a way to tell Paragon Chat to save the contents of the debug window? Next time I do some testing, I'll set a close watch on what Paragon Chat is logging itself as receiving, but I don't anticipate a problem in that area.

I did try setting the scales to "-0.000000192". That had no effect, though I realized later that the scales in a pristine costume file never have a leading zero and that might have invalidated the test.

I also tried loading up the costume in the CoH costume editor and playing with different combinations of slider values. Basically, if any of the sliders reads "-1.192e-007", meaning that it was untouched and set to the default value, then the costume is undisplayable by the bot.

Are those sliders allowed to be zero? Is "-1.192e-007" is just a floating point artifact like 2 + 2 = 3.9999999999, and the actual value is supposed to be zero? If I need to, I can have the bot convert the text string to a float value and then drop anything past six decimal places.

« Last Edit: April 26, 2016, 03:22:49 PM by slickriptide »

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #349 on: April 26, 2016, 03:36:49 PM »
On a different note, I thought I'd toss out a use case for true invisibility via a switch:

Imagine a roleplay session where the GM wants the players to interact with Ms. Liberty. Instead of describing the conversation, the GM can turn his assistant-bot invisible, move it behind Ms. Liberty on the map, change its nick to "Ms. Liberty", and then tell it what to say in local chat so that it appears as if Ms. Liberty is doing the talking.

On a more amusing note, consider this - A wiki-bot stands in Atlas Park, that listens for questions about City of Heroes and responds with wiki entries related to whatever triggered it. On any response, the bot has a 1% chance to "overload" and explode! It plays appropriate dialog and animation, then turns invisible. It then assumes the form of a whistling workman who "arrives" on the scene to effect "repairs" and install a new wiki-bot on the spot. The workman walks off, turns invisible, becomes the wiki-bot again, and then resumes visibility in its normal listening spot.

Granted, that the second case would work just as well using Arcana's suggestion of moving below the ground, as long as the movement was instantaneous. Likewise, there's not really any intrinsic reason to avoid leaving the room to effect "invisibility", though doing that could incur some otherwise unnecessary overhead if your bot was tracking the occupants of the room and had to re-load a bunch of data that it already had before it became "invisible".


Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #350 on: April 26, 2016, 04:26:34 PM »
According to my logs, the XML and hash string were just copying the slider values verbatim. That is, the literal string "-1.92e-007". There didn't seem to be any funky formatting happening. Is there a way to tell Paragon Chat to save the contents of the debug window? Next time I do some testing, I'll set a close watch on what Paragon Chat is logging itself as receiving, but I don't anticipate a problem in that area.

Oh, that's right, Paragon Chat does truncate the slider values to 4 decimal places when hashing/sending the costume, specifically to prevent floating point jitter from causing the hash to not match. It also rounds them to the nearest thousandth when saving/loading costumes, though that's just a safeguard against 0.5 turning into 0.4999 and isn't strictly required.

I need to finish implementing the v2 costume protocol. With that I'm dropping the global costume cache, so it will no longer be required that the hash be generated a specific way. So long as the bot can generate unique identifiers for its costumes in a consistent manner, it won't matter if it isn't doing it the same way Paragon Chat itself does.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #351 on: April 26, 2016, 05:05:22 PM »
Groovy. I'll tell the bot to do the same sort of truncation.

Allowing the hash to be any unique identifier (as simple as MyBot-some_unique_string) would make things much easier on future bot developers, for sure. :-) Not to mention that some_unique_string could be an identifier that's meaningful to bot itself.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #352 on: April 28, 2016, 10:17:54 PM »
Out of curiosity - Given that Openfire (and by extension, I assume most other XMPP servers) can handle thousands of concurrent connections, why are the zones of Paragon Chat set to only a few tens of users before spawning a new instance?

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #353 on: April 29, 2016, 12:28:21 AM »
There are a couple of things that make Paragon Chat difference.

1. XMPP servers handle thousands of concurrent connections, but these are users who occasionally communicate with each other and idle most of the time. They're not in one big chat room together.

2. Even in big MUC rooms, on a regular XMPP server, typically only a few people are talking at a time. The meta channel traffic from Paragon Chat is considerably more frequent than a regular conversation, and depending on how active people are, everyone in the room could be "talking" at once.

3. The above characteristics mean that meta channels are N^2 amplifiers. If 4 people in a zone are sending 1 update per second, then the server is processing 16 messages per second. If 30 people are in the zone, it's processing 9000 messages per second...

4. The exact performance and bandwidth usage was not known when we launched, so I opted to be conservative and set the zone limits rather low. At this point, we can probably safely up it to 50, which would put it on par with the live game.

It's worth noting that Atlas Park and Pocket D are both set to unlimited currently.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #354 on: April 29, 2016, 08:01:14 PM »
What are the odds that the permissions framework you mentioned earlier includes a way for a client to authorize acceptance of a "travel cookie"?

I assume it's obvious that I'm thinking here about a mission door or a temporary train menu destination.

A "travel cookie" wouldn't operate on a map ID #, necessarily. It would supply a map name, a XMPP room name, a map file, and a spawn location. Effectively, a private instance of a map, though it could just as easily point to an existing "global" zone instead.

If I'm handing out a mission, in an ideal world I want to tell the player which room to join and which map she'll be joining, not depend on she and I to agree in advance on room names and map ID numbers, or that the player even knows that map X exists.


slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #355 on: May 02, 2016, 05:12:34 AM »
Getting back to NPC's - in determining why my costumes weren't working, I learned that there are more "legal" body types than just the male/female/huge. BodyType 2 and 3 seem to be generic NPC's, while BodyType 5 is unmistakably a WarWolf.

Experimentation showed that trying various numbers other than 0-5 either resulted in no visible difference from male/female or they crashed the game client.

Rather than brute force I figured I'd just ask about other known usable body types. It's of particular interest to me because I want to make a rikti monkey bot. If the WarWolf has a unique BodyType complete with its own "ready" animation, then do any other NPC's have the same?

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #356 on: May 02, 2016, 02:27:42 PM »
What are the odds that the permissions framework you mentioned earlier includes a way for a client to authorize acceptance of a "travel cookie"?

What you're describing wouldn't be part of the permissions framework. It would be part of the private instance support - which is itself part of the larger work to decouple the XMPP public zone backend from the client communication frontend. The permissions framework is a prerequisite for private instance support.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #357 on: May 02, 2016, 03:01:51 PM »
What you're describing wouldn't be part of the permissions framework. It would be part of the private instance support - which is itself part of the larger work to decouple the XMPP public zone backend from the client communication frontend. The permissions framework is a prerequisite for private instance support.

That makes sense. I was envisioning the "travel cookie" more as a case of a player setting a permission that read, "I will accept a travel beacon from the following people: [X] Anyone [ ] The following list of JID's... [ ] Nobody".

Well, I'll file any similar questions as "wait for private instances".


Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #358 on: May 02, 2016, 04:09:53 PM »
It'll probably be more of an invite based system - the invite includes the info about meta channel name (probably a long hex string) and map file. Although for people who want public areas we'll have to figure out some way to advertise the relevant info to access the instance.

The permissions framework is more along the lines of someone trying to do something like forcibly move a player, change to a restricted costume, spawn an NPC (though that also depends on the pubsub implementation so that people zoning in afterwards can see it), etc. For those privileged actions it has a list of possible ways it can be authorized, such as:

  • Being listed as an administrator or GM in the shardwide config
  • Being inside of a private instance and also owner of that instance
  • Being inside of a private instance and having select abilities delegated by the owner
  • etc.


It's a bit more involved than that, since the permissions framework isn't just about what you can do, it's about giving other players the ability to validate incoming data from untrusted sources. If you receive an XMPP message about something happening that involves a privileged operation, the permissions framework gives the recipient the ability to verify that the sender of the message is authorized to do that, and ignore the message if they're not.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #359 on: May 02, 2016, 05:00:20 PM »
It's a bit more involved than that, since the permissions framework isn't just about what you can do, it's about giving other players the ability to validate incoming data from untrusted sources. If you receive an XMPP message about something happening that involves a privileged operation, the permissions framework gives the recipient the ability to verify that the sender of the message is authorized to do that, and ignore the message if they're not.

Once such a framework is in place - I can't help but notice that XEP-323 and XEP-325 seem to be just the sort of thing that a Gamemaster-bot might use to touch buttons in the client to do things like move an XP meter, create a dialog window and set some contents in it, activate a "BADGE AWARDED!" banner, etc...