Author Topic: Technical side discussion  (Read 164627 times)

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #240 on: July 31, 2015, 07:13:30 PM »
Yes, for starters the bot just needs to be able to walk around Atlas Plaza but the end game will need to be an emote database that knows the full sequence of any arbitrary animation it might play.

When you get there, there's a tiny little catch to being able to fully predict when an animation will play.  If you simply take the sequencer dump Codewalker posted on the forums a while ago, you won't even need to decode the piggs to get a complete set of at least the MOVs that players can actually play (there are animations that players cannot play that aren't in there, but they aren't relevant to player-lookalike bots).  The sequencers tell you to play this animation, give a start and end frame, and then tell you what to do next.  Since an animation frame is 1/30th of a second, you can calculate at what precise moment the sequencer will start playing the next animation**.

Unless the sequencer says the end frame is zero.  In that case, the sequencer plays the animation until the end, and then moves on.  But how will you know how long that is?  The answer is: you'll have to look up the actual .anim file in the piggs which contain that animation and figure out how long that is.  And you cannot predict precisely from the size of the file.  Fortunately, I discovered that if you look hard enough the actual frame count for the animation is in that file.  Unfortunately, that information is located somewhere in an animation comparison script I can't find at the moment.  When I get there, I will go looking for that.  Theoretically speaking, all you need to do is find the .anim and read byte #XX, and that's the frame count.  For the correct value of XX.  This was something I needed to figure out how to do when I decided to figure out how long combat powers actually rooted the player for, and if that was consistent with what we were told (it was not in all cases).

At some point in this process, a technically proficient person will either guess something or experiment and discover something.  The answer is yes I know, and I think for now its best that the only people that know this are the people that can figure it out for themselves.  It serves no useful purpose for either Icon or Paragon Chat.

** I'm ignoring things like scale here for simplicity sake

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #241 on: July 31, 2015, 08:52:59 PM »
The answer is: you'll have to look up the actual .anim file in the piggs which contain that animation and figure out how long that is.

It is my fervent hope that nothing I want to eventually do will ever come to that.

But then, deciding " to figure out how long combat powers actually rooted the player for, and if that was consistent with what we were told" and then actually *DOING* it is what makes you @Arcanaville. ;-)

Besides, I'm not really sure whether this:

At some point in this process, a technically proficient person will either guess something or experiment and discover something.

is a breadcrumb trail or a "Here Be Monsters" sign, heh.

Have you read _True Names_ by Vernor Vinge? If not, you should. I suspect you'd enjoy it.


Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #242 on: July 31, 2015, 10:05:39 PM »
Besides, I'm not really sure whether this:

is a breadcrumb trail or a "Here Be Monsters" sign, heh.

Have you read _True Names_ by Vernor Vinge? If not, you should. I suspect you'd enjoy it.

Sometimes slavery or greatness rests on the goodwill of one or two persons.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #243 on: August 01, 2015, 05:27:53 AM »
Oy, vey.

Excuse me a moment.

/headdesk /headdesk /headdesk /headdesk

I "get it" now.

I was toying around with assigning velocity vectors to the bot and watching what happened. It was the point where I thought, "I'll have to slow that down if it's going to walk around the plaza" that the first bulb lit up. Then when I changed velocity and saw my bot rubber band back to start point, because I was just setting velocity and not position, the other light bulb lit up. It's not enough to know that I want to go from A to B. I have to know the animation time so that I know what speed to assign and how long it will take to move from a to be while playing that animation.

Geez, this is almost like writing a game from scratch in a lot of ways. It's a good thing I didn't think this through very far before I started or I would have just gone off to play some Hearthstone instead, LOL.


Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #244 on: August 01, 2015, 05:44:40 AM »
So I decided to take "a look" at trying to integrate the simple idea of walking on the ground instead of being a ghost.  I thought I might make some progress on that this weekend.

Yeah, ha ha.  I'm probably going to spend most of that time just thinking about the problem.  In the general, most expansive case, I'd say after thinking about it and seeing what the problem space actually is, this one problem dwarfs every single problem the bot construction has faced to date, combined, by several decimal orders of magnitude.  In fact, I think an accurate description of Paragon Chat is that its a program that performs map and surface calculations on moving objects, that happens to incorporate every other feature as a side project.

That doesn't mean there aren't short cuts.  The entire bot project has in a sense been one giant shortcut around the massive project that is Paragon Chat.  I'm carving a starter key out of balsa wood that starts the Ferrari that is Paragon Chat.  So hope is not lost.  A lot of my weekend is lost, but there's always hope.

I could always just wait around for Codewalker to implement a surface relay API that tells you which surface is closest in the direction of gravity, and what the first collision is between the world and your travel capsule, but that seems lazy and like cheating.  I'm not opposed to lazy, but lazy cheating offends my sense of honor.

When it comes to maps and geometry, I really, really, really wish it didn't.  I'm actually impressed that Paragon Chat implements this as well as it does in only a few months of development work.  Unless Codewalker has been writing 3D virtual reality software for the past decade and hasn't gotten around to mentioning it yet, this is actually one of the most impressive features of Paragon Chat.  For example, I was thinking about this today when I got home and I began to think about surfaces.  I was compelled to log into Paragon Chat to test something.  You swim in Paragon Chat.  If you jump into the water you swim.

It seems like a small thing, but from a programming perspective consider what Paragon Chat is doing.  It understands gravity, it understands geometry, it lets gravity drop you to the water.  It *then* understands that the water is not a collision surface, but the bottom of the lake is.  It understands that that surface is a different kind of surface, and sets the correct modes that alter your character's default animations when standing still and moving.  Some of this is happening "automatically" in the City of Heroes client, but a lot is not.  Bots don't appear to tread water, so the game client doesn't apply that automatically: Paragon Chat has to know this and apply this.  Multiply this by all the different kinds of surfaces there are in the game.  Consider walking up stairs.  Consider walking over a ground surface and under a ceiling surface.  Its not like every 3D game doesn't do this, but reconstructing it is still non-trivial.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #245 on: August 01, 2015, 05:52:17 AM »
Oy, vey.

Excuse me a moment.

/headdesk /headdesk /headdesk /headdesk

I "get it" now.

I was toying around with assigning velocity vectors to the bot and watching what happened. It was the point where I thought, "I'll have to slow that down if it's going to walk around the plaza" that the first bulb lit up. Then when I changed velocity and saw my bot rubber band back to start point, because I was just setting velocity and not position, the other light bulb lit up. It's not enough to know that I want to go from A to B. I have to know the animation time so that I know what speed to assign and how long it will take to move from a to be while playing that animation.

Geez, this is almost like writing a game from scratch in a lot of ways. It's a good thing I didn't think this through very far before I started or I would have just gone off to play some Hearthstone instead, LOL.

Paragon Chat implements prediction.  Or rather Paragon Chat passes the parameters to the game client which implement prediction.  Which means if you set your position to 0,0,0 and your velocity to 0.7,0,0, you're telling Paragon Chat and everyone else's game client that your bot is moving at 0.7 feet per frame, or 0.7 feet every 1/30th of a second, or 21 feet per second.  If you send nothing else, your bot will appear to take off at about 14 miles per hour in that direction.  Everyone will guestimate that in one second your position will be 21,0,0.  However, if you actually send 18,0,0, then you will "rubberband" to 18,0,0.  And then continue to move at 21 feet per second in the x direction.  So to make sure this all works, you have to make sure that every time you send a <u /> your advertised position is consistent with your advertised velocity, or you will rubberband.

It actually did take some thinking to make that relatively smooth walking/running/flying video.  You need to implement velocity, position, and a clock to sync it all up.  That's why I considered it a milestone.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #246 on: August 01, 2015, 07:06:43 AM »
It actually did take some thinking to make that relatively smooth walking/running/flying video.  You need to implement velocity, position, and a clock to sync it all up.  That's why I considered it a milestone.

Yes, that's what I mean by "I get it now". I had thought about individual pieces here and there in regards to motion but I'd held onto this stubborn belief that, at heart, what I was doing was really just a sort of lower level version of Architect Entertainment and that moving from here to there was just a matter of defining what "here" and "there" meant.

What we're actually doing is taking a graphics engine and a lot of premade assets and trying to build a game, or some sort of interative toy at least, on top of it. Not quite from the ground up but a lot closer to the ground than I'd ever really considered it to be.

So, yes, I have a much better appreciation now for what you accomplished there, in a relatively short period of time to boot.




slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #247 on: August 01, 2015, 03:10:26 PM »
Speaking of the game client doing prediction -- I was experimenting with velocity vectors some more this morning and found an interesting effect.

After some fiddling with small values and seeing results I hadn't expected, I gave the bot a command to !setv 0 6 3.

I knew that gravity exists and that flying is basically exerting a plus velocity along the Y axis. What I expected was that setting vY would cause the bot to fly away at a pace dictated by vY and an angle dictated by the interaction of vX and vZ.

What happened instead is that the vY was treated as an instant burst. The predictive code moved the bot's avatar as expected, but not at a constant vY velocity. Instead of telling my bot to fly, I shot it out of a cannon and the game client automagically applied gravitational pull to it after that as it moved forward along the z axis.

In effect, my bot super jumped from the feet of Atlas to a spot out near the park south of Ms. Liberty.

What this means is that any time there's natural force in play along an axis of motion, that it takes a constant assertion of counter force to resist it. Flying isn't just a matter of sending a <U> with upward velocity. You have to send a stream of <U>'s that reinforce your position and heading. If the game supported a zone with "head winds" or currents in water, you would have to actively resist those forces in the same way.

The question this raises is -- How is my bot supposed to figure out ahead of time where its landing point is supposed to be? I can't query your client to ask where it put my bot's avatar.

There are probably some standard physics equations that can handle that problem, but that really hilights a challenge that is facing any bot writer - namely, that every single bot basically has to carry around in its brains a collection of all of the stats and equations that would normally be held by a single central server in a more typical client/server architecture.

A bot ought to be a specialized kind of client but by necessity we're having to make them be more of a specialized kind of mini game server.

In an ideal world, I would tell the server to move my avatar from A to B using method C and the server would generate the movement stream that made it so.

Even in a world where my bot might need to send its own <U> stream to be properly tracked by other clients, a bot would want to be able to query the server for a path and the server would reply with a list of <U> stanzas that would implement the path.

At a bare minimum, it seems like a server ought to be able to define its "world rules" and respond to a service discovery query from a bot with a summary of the rules; like, for instance, "How strong is the pull of gravity in your world?"

Openfire would handle something like this through its plugin system. Instead of every bot carrying a bunch of physics around and reinventing the wheel a dozen times, the physics would be handled by the server and the bot would *ask* for something like "move me from point A to point B and tell me how long it will take travel between them and what special animation stream or movement stream I need to use while doing it".

« Last Edit: August 01, 2015, 03:43:11 PM by slickriptide »

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #248 on: August 01, 2015, 05:52:19 PM »
In fact, I think an accurate description of Paragon Chat is that its a program that performs map and surface calculations on moving objects, that happens to incorporate every other feature as a side project.

Loading the geometry is the hardest part, but we've had a working geo viewer for some time. That's from 2013, but the initial post of those images on our private development forum is dated March 27, 2012. Combined with the bin formats that had been fully decoded since discovering the Rosetta stone embedded in the client exe in late 2011, most of the information is there, but you're right that putting it all together is not trivial.

When it comes to maps and geometry, I really, really, really wish it didn't.  I'm actually impressed that Paragon Chat implements this as well as it does in only a few months of development work.

I don't want to quote myself, but I did mention that Paragon Chat builds on work that has been going on for much longer. So while the idea for using XMPP as a communications medium and the work that went into making that a reality happened over a few months (closer to half a year), a lot of the other pieces you mention have been under more or less constant development for the last 2, 3, or in some cases even 4 years.

It also helps that the client itself has a fairly complete implementation of the same physics and collision processing, even though it only uses it for local player prediction, ripe for picking apart with a debugger to figure out exactly what formulas to use to come up with similar results.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #249 on: August 01, 2015, 07:01:34 PM »
What happened instead is that the vY was treated as an instant burst. The predictive code moved the bot's avatar as expected, but not at a constant vY velocity. Instead of telling my bot to fly, I shot it out of a cannon and the game client automagically applied gravitational pull to it after that as it moved forward along the z axis.

That's a Paragon Chat thing, intended to make jumping appear less jerky and more natural, since velocity updates only come in every second or so. It continuously applies gravitational acceleration to any nonzero Y velocity value. If the remote PC and game client are doing the same thing on their end, any updates should be relatively close to the predicted value, with some margin of error for inconsistent latency.

That's part of why flying requires extra protocol support, because it will need a tag to tell other clients to disable that prediction and use velocity as-is.

The question this raises is -- How is my bot supposed to figure out ahead of time where its landing point is supposed to be? I can't query your client to ask where it put my bot's avatar.

If you want to try to match the prediction, COH's default gravity is 0.065 units/frame^2 when moving upward, or 0.0975 units/frame^2 when moving downward or at rest.

You can also use 1.95 units/frame/sec or 2.925 units/frame/sec, respectively, to make the math a little easier if you're using seconds as your unit of time. Just don't forget that velocity on the wire is always in units/frame.

Yes, the COH universe has bizarre physics where the force of gravity is different depending on which direction you're moving. I have no idea why. It's probably one of the many, many things that the developers did by feel rather than by math. That's why I continue to say that any attempt to recreate the game in an off-the-shelf engine will never 'feel' quite the same.

Assuming I'm not screwing up the math completely, and assuming the usual convention of 1 world unit = 1 foot, that comes out to around 17.8 m/s^2 when rising and a whopping 26.7 m/s^2 when falling. That doesn't seem right to me as it doesn't seem like it's that much higher than real world gravity, so it's possible I'm missing a conversion factor somewhere.

I'll note that gravity does not affect flying entities at all; they get to ignore it completely and do not have to exert a balancing upward force. The effect you're encountering is only due to Paragon Chat's prediction and the fact that it doesn't know you're flying.

Quote
There are probably some standard physics equations that can handle that problem, but that really hilights a challenge that is facing any bot writer - namely, that every single bot basically has to carry around in its brains a collection of all of the stats and equations that would normally be held by a single central server in a more typical client/server architecture.

For non-vertical movement, the formula is exceedingly simple: deltaP = v * deltaT, where deltaT is in frames.

But yes, the XMPP protocol used by Paragon Chat is not really so much a protocol to talk to a game server but rather a means of synchronizing the state of many independent game engines.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #250 on: August 01, 2015, 07:35:40 PM »
I knew that gravity exists and that flying is basically exerting a plus velocity along the Y axis. What I expected was that setting vY would cause the bot to fly away at a pace dictated by vY and an angle dictated by the interaction of vX and vZ.

What happened instead is that the vY was treated as an instant burst. The predictive code moved the bot's avatar as expected, but not at a constant vY velocity. Instead of telling my bot to fly, I shot it out of a cannon and the game client automagically applied gravitational pull to it after that as it moved forward along the z axis.

Actually, I believe when a City of Heroes entity flies, setting the fly mode effectively makes them immune to gravity.  Codewalker said somewhere else I believe that if your delta-Y is non-zero, Paragon Chat applies gravitational acceleration.  If it is exactly zero, it does not.  So the correct way to mimic flying in Paragon Chat today is to explicitly set deltaY to zero, and set your Y position to whatever.  That way Paragon Chat won't attempt to predict your next Y position and won't apply gravity.  What *will* happen is that your vertical motion will be significantly more jumpy than your horizontal motion, but so long as you confine flying to a relatively xz plane-ish motion, it won't be too bad.


Quote
There are probably some standard physics equations that can handle that problem, but that really hilights a challenge that is facing any bot writer - namely, that every single bot basically has to carry around in its brains a collection of all of the stats and equations that would normally be held by a single central server in a more typical client/server architecture.

A bot ought to be a specialized kind of client but by necessity we're having to make them be more of a specialized kind of mini game server.

That is both problem and opportunity in my opinion.  For example, right now Paragon Chat doesn't support flying.  But my bot can fly, in a way.  It doesn't support teleporting, but my bot can teleport.  Because the bot is required to enforce its own rules - like every other Paragon Chat instance does - and because Paragon Chat only loosely enforces certain rules on what everyone else can do, bots can do things that Paragon Chat *users* can't do, but Paragon Chat implicitly supports allowing.


Quote
At a bare minimum, it seems like a server ought to be able to define its "world rules" and respond to a service discovery query from a bot with a summary of the rules; like, for instance, "How strong is the pull of gravity in your world?"

That's an interesting idea, actually.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #251 on: August 01, 2015, 07:54:51 PM »
If you want to try to match the prediction, COH's default gravity is 0.065 units/frame^2 when moving upward, or 0.0975 units/frame^2 when moving downward or at rest.

You can also use 1.95 units/frame/sec or 2.925 units/frame/sec, respectively, to make the math a little easier if you're using seconds as your unit of time. Just don't forget that velocity on the wire is always in units/frame.

Yes, the COH universe has bizarre physics where the force of gravity is different depending on which direction you're moving. I have no idea why. It's probably one of the many, many things that the developers did by feel rather than by math. That's why I continue to say that any attempt to recreate the game in an off-the-shelf engine will never 'feel' quite the same.

Part of that bizarreness is almost certainly due at least in part to SuperJump.  In beta, superjump worked in a particular way (I wasn't in beta, so I can't comment on the precise way it was different, but I know it was different in significant ways).  Very early on, they changed the way it worked mechanically to change the way players controlled jumps and to affect how the leaps appeared.  There was a lot of consternation by players already used to the previous superjump mechanics and the devs tweaked it to make sure superjump experts could regain the same level of control or better with the new version.  That required tweaking with the physics of superjumping, and of course that means tweaking how gravity works; particularly how it works when you're going up and independently how it works when you are going down.  In fact I'm not convinced normal gravity is actually working when you are in the upward half of a superjump and completely different physics are happening there.  It doesn't *feel* like gravity - any kind of gravity - when I'm superjumping.

Quote
Assuming I'm not screwing up the math completely, and assuming the usual convention of 1 world unit = 1 foot, that comes out to around 17.8 m/s^2 when rising and a whopping 26.7 m/s^2 when falling. That doesn't seem right to me as it doesn't seem like it's that much higher than real world gravity, so it's possible I'm missing a conversion factor somewhere.

That doesn't feel right to me either: its twice normal gravitational acceleration in the upward direction and three times normal gravitational acceleration in the downward direction.  Its worth some additional investigation.  I think I have a way to do this in a controlled and relatively precise manner.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #252 on: August 01, 2015, 08:53:23 PM »
Interestingly, my low precision tests (putting my bot at various heights in the air and setting downward velocity to -0.0001 and letting Paragon Chat drop them and timing the result on a stopwatch) fairly consistently measure downward acceleration as being about 50-60 feet/sec^2, or about 16-20 meters/sec^2.  There are potentially large margins for error on that measurement, but its interestingly consistent within +-20%. 

Does Paragon Chat apply any frictional forces or velocity cap on downward motion?

I'll see about trying to create a higher precision version of this test (using video motion extrapolation) later this weekend.


Just as an FYI I added a new command to my bot: /experiment.  Its a cutout that lets me invent functions to test, like /experiment fall XXX which causes the bot to teleport XXX feet higher than current position, set downward velocity to -0.0001, and let Paragon Chat drop them.  Works with /comehere which teleports the bot to within five feet of my position (because you have to reset your position after every drop, because your bot doesn't actually have a consistent position with Paragon Chat after the fall).

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #253 on: August 01, 2015, 08:55:03 PM »
PS: is this why I got a college degree?

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #254 on: August 01, 2015, 10:25:47 PM »
Interestingly, my low precision tests (putting my bot at various heights in the air and setting downward velocity to -0.0001 and letting Paragon Chat drop them and timing the result on a stopwatch) fairly consistently measure downward acceleration as being about 50-60 feet/sec^2, or about 16-20 meters/sec^2.  There are potentially large margins for error on that measurement, but its interestingly consistent within +-20%.

Hmmmm, interesting. In the meantime, I built a modified version of Paragon Chat with the gravity values set to what I calculated as appropriately representing 9.8 m/s^2. I then turned off clientside prediction so the client wouldn't get into a rubber-band fight. It felt like walking on the moon.

I suspect the issue may instead lie with the assumption that 1 world unit = 1 foot. Nothing has ever been particularly well scaled according to that, regardless of what in-game marker distances may say.

Quote
Does Paragon Chat apply any frictional forces or velocity cap on downward motion?

It does apply friction (with a coefficient varying based on the surface parameters) to the local player, but not to other players that are being received over XMPP. It treats those as frictionless and expects that the remote instance will reduce the velocity accordingly.

There is a speed cap (base of 1.0 magnitude IIRC), and it is applied to all three dimensions while flying, but only to X/Z when walking/falling. Again that is to the local player only and is not applied to XMPP-driven players; it would just be one more thing to have to synchronize. So bots should be able to exceed the speed cap.

Quote
In fact I'm not convinced normal gravity is actually working when you are in the upward half of a superjump and completely different physics are happening there.  It doesn't *feel* like gravity - any kind of gravity - when I'm superjumping.

Correct, there is no gravity when you're jumping, and you maintain a constant upward velocity while the key is held down. Once it's released (or the timer runs out), the lower gravity kicks in first to counter your upward momentum, then it switches to the higher gravity as soon as you start moving downward.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #255 on: August 01, 2015, 10:37:27 PM »
PS: is this why I got a college degree?

You need a better reason? :-p

Codewalker - I wouldn't put this high on any "to do" list, but if a bot is focused on a particular player anyway as part of a "quest" or something, it might be useful to send an IQ to that player's client and ask it "Hey, where do *YOU* think I am located?" I don't have any specific reason to ask a client that question at the moment, but somehow it strikes me that it could be an interesting thing to know; particularly if a script was running that was based off of stuff happening relative to the player and not necessarily happening at an absolute position in Paragon space.

Okay, here's a made-up example. Suppose I have a NPC who patrols between three points, but the only time he ever sends out a<U> message is when he reaches a vertex of his patrol triangle and changes course. While Mr. NPC is walking between B and C, a player steps up and stops the bot by saying, "Hey, Mr. NPC! Tell me about X!".

My bot knows that he last emmitted a <U> at timestamp X, and he can determine that Y number of seconds have passed and from that he can calculate the distance he must have traveled in the meantime. Maybe, though, what he cares about more is to ask the player's client "Where am I right now, according to you?" and then setting his absolute location to be the same as that relative location. If there was any sort of data transmission lag, or even just a small amount of time required to processing things before the bot established its location, then setting its location by the client's coordinates would eliminate potential rubber-banding caused by jumping to the bot's more accurate idea of location.

Like I said, not something with any kind of priority but still maybe something that could have uses in certain situations.


slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #256 on: August 01, 2015, 11:22:24 PM »
Another feature request, along the lines you mentioned awhile back of "knowing when you've been clicked".

If a player has another player targeted when he sends a <U> stanza, can the <U> stanza include a "target=JID" or "target=CharacterName" attribute?

The cool consequence of that is that a bot can register a call back specifically for "<U target='myJID'>" and if, say, someone emotes "/em punch3" while the bot is targeted, the bot can respond by tipping itself 45 degrees, launching itself backwards 100 feet and shouting, "Curse you SuperduperMan! You haven't seen the last of The Claw!"


Ohioknight

  • Celebrating Columbus Day
  • Elite Boss
  • *****
  • Posts: 736
  • 65 years old
Re: Technical side discussion
« Reply #257 on: August 02, 2015, 12:49:32 AM »
I suspect the issue may instead lie with the assumption that 1 world unit = 1 foot. Nothing has ever been particularly well scaled according to that, regardless of what in-game marker distances may say.


I usually set my characters to average height (under 6ft, maybe 5'9") and have often noticed that I seem to be much shorter than that as I go about the city.
"Wow, a fat, sarcastic, Star Trek fan, you must be a devil with the ladies"

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #258 on: August 02, 2015, 12:50:31 AM »
You need a better reason? :-p

Codewalker - I wouldn't put this high on any "to do" list, but if a bot is focused on a particular player anyway as part of a "quest" or something, it might be useful to send an IQ to that player's client and ask it "Hey, where do *YOU* think I am located?" I don't have any specific reason to ask a client that question at the moment, but somehow it strikes me that it could be an interesting thing to know; particularly if a script was running that was based off of stuff happening relative to the player and not necessarily happening at an absolute position in Paragon space.

Okay, here's a made-up example. Suppose I have a NPC who patrols between three points, but the only time he ever sends out a<U> message is when he reaches a vertex of his patrol triangle and changes course. While Mr. NPC is walking between B and C, a player steps up and stops the bot by saying, "Hey, Mr. NPC! Tell me about X!".

My bot knows that he last emmitted a <U> at timestamp X, and he can determine that Y number of seconds have passed and from that he can calculate the distance he must have traveled in the meantime. Maybe, though, what he cares about more is to ask the player's client "Where am I right now, according to you?" and then setting his absolute location to be the same as that relative location. If there was any sort of data transmission lag, or even just a small amount of time required to processing things before the bot established its location, then setting its location by the client's coordinates would eliminate potential rubber-banding caused by jumping to the bot's more accurate idea of location.

Like I said, not something with any kind of priority but still maybe something that could have uses in certain situations.

I'm uncomfortable about this.  As a source of information, it might be useful in some circumstances.  But as a crutch, I'm less supportive.  I think bots should track their own internal state well enough to not require asking clients what they think the bot might have been doing.  For example, *who* do you ask?  Every single Paragon Chat client is doing its own predictions.  Its not necessarily kosher to ask a specific client for positional correction information even if they happen to be the one interacting with the bot.  Its also vulnerable to poisoning: if I know your bot does that, I can write a bot that specifically interacts with your bot and then sends it to the moon.

If and when Codewalker adds a bot-API, that's the point where these kinds of questions can be better addressed.  Because the correct thing to ask "where am I" if you happen to not know is not another player, but your own Paragon Chat instance.  So maybe a future Paragon Chat will allow you to connect to it rather than directly to an XMPP server.  You would start Paragon Chat, and then instead of launching the CoH client, you would launch your bot and connect to PC.  PC would handle all of the XMPP, and your bot would talk directly to PC and send it entity commands.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #259 on: August 02, 2015, 12:53:04 AM »
Another feature request, along the lines you mentioned awhile back of "knowing when you've been clicked".

If a player has another player targeted when he sends a <U> stanza, can the <U> stanza include a "target=JID" or "target=CharacterName" attribute?

The cool consequence of that is that a bot can register a call back specifically for "<U target='myJID'>" and if, say, someone emotes "/em punch3" while the bot is targeted, the bot can respond by tipping itself 45 degrees, launching itself backwards 100 feet and shouting, "Curse you SuperduperMan! You haven't seen the last of The Claw!"

http://www.cohtitan.com/forum/index.php/topic,10956.msg187675.html#msg187675