Author Topic: Technical side discussion  (Read 164783 times)

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #280 on: August 03, 2015, 04:09:42 PM »
The goal queue idea is brilliant and I will probably steal from that idea at some point.

I suppose I'm going to have to get setup with Git just because my framework software is already setup to load modules directly from Git.

I've got my Paragon Chat back end to ErrBot going. With a decent working knowledge of all of the moving parts at this point, it was a trivial operation to define a new backend instance based on the XMPP backend and override the event handling stuff to make it send the XML payload up to ErrBot along with the basic presence and message events.

So trivial, that I was tempted to contact the ErrBot guys and ask, "Why didn't you guys just make this an option in the first place?"

That got me thinking about my goals for this project and the whole concept of "frontend" and "backend".

Ideally, what I want is for the person coming behind me to be able to be someone who wants to just say, "Load this costume file", or "tell me who is near me", or "tell me who is in the zone with me", or something similar. That person won't need to know about stanzas except as a means to perform "advanced" programming of the bot.

Another thing, though, is the whole concept of the "bot" as dispatcher and manager of a bunch of NPC's and the implications of doing that, where a lot of the work is going to have to happen at the "backend" side of things as far as managing multiple connections for multiple avatars.

The upshot being that maybe I *don't* want to just push the stanzas up a level, but instead make a separation between tasks that clearly belong at a "low level" compared to tasks that don't need to understand the underlying protocols to generate an effect.

I might actually have to take this seriously enough to draw up some kind of design document for it, if only to solidify for myself what it is that I actually want this thing to do beyond walk around Atlas Plaza and pretend to be knocked back if I pretend to hit it.

I actually have some specific things in mind but first  I need to be able to follow someone and that means defining where all the pieces of that function fit, which puts me back at this point, heh.

Which leads me to some questions that I'm going to put in a seperate post just for the sake of clarity.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #281 on: August 03, 2015, 04:35:44 PM »
Here's the basic question - What are the implications of managing a group of NPC's?

Imagine this:

A group of five Hellions are lounging around in front of City Hall. A hero walks up. Four of them scatter and the fifth one interacts with the hero in some way.

What are the implications from the standpoint of the XMPP server, and from the standpoint of Paragon Chat?

We've established, I think, that all five of these Hellions need to have presence in the atlaspark and atlaspark_meta rooms. They all need costumes. They each need to have their own XMPP connection in order to communicate their presence and position. They each, therefore, need to have their own thread or their own process that is controlling their personal XMPP connection.

What does this mean for the server? Do the individual Hellion NPC's each need a unique JID? That is, does the bot login as mybot@chat.cohtitan.com with password "mybot" or does each Hellion require its own Titan account? Can one account join a chat room five times under five different nicks?

How is this many connections going to affect the server from a performance standpoint? Obviously, five isn't a lot, but five today in Atlas Park could scale up to 100 per zone in twenty different zones at once. (We should be so lucky as to be that popular, but dream big.)

From the "bot" standpoint, this encounter means forking and managing five connections while the Hellions are standing around, and then closing and releasing four of them after they flee, while sending the fifth one into whatever encounter handler takes care of its interaction with the player.

There are probably more implications that need thinking about but those are what come to mind initially.

If I create this encounter, am I going to be "hogging" resources on the server? What sort of resources should a bot owner be priveleged to use and to be considered to be "playing nice" with the other people who might be doing the same thing with their own resources?



Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #282 on: August 03, 2015, 07:38:33 PM »
If I create this encounter, am I going to be "hogging" resources on the server?

All good questions, but I think that's something that can only be answered through experimentation.  Which is why I strongly advocate bot writing pioneers to run on their own private server during development, so that these questions can be characterized and answered.

At some point, Codewalker will allow NPC spawning in some fashion.  I think the most efficient means of ultimately making a large number of NPCs function is to give bots spawning abilities and let them remote control actual NPCs.  In effect to make the bot a remote mapserver of sorts.  Until then, bots are going to potentially burn more resources per entity than desirable.  But its difficult to be certain: it depends on what you want the entities to do, and how interactive they need to be.  The devs had to deal with this kind of problem as well: the difference between the resource costs of a power like quickness vs a power like invincibility were enormous: it was possible for a single player to burn as much CPU resources as dozens of others under the right circumstances.  Optimizing that, and in some cases simply not doing certain things, were all part of the development requirements.

Dream big, but start small.  Honestly, federation might solve many problems in this area: GMs could host their own XMPP server and therefore spam it with as much traffic as desired to effect the kinds of gameplay they want, without hurting anyone else.  You'd zone into that XMPP room, and then zone out.  Doing this in *public* zones on *public* servers is where you have to be a lot more careful.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #283 on: August 04, 2015, 08:50:25 AM »
Because my experiments suggest that actually interpreting maps is something that might not be completely necessary at this stage, and because its kind of daunting, I've temporarily moved on to what might finally be the holy grail of my bot experimentation: implementing sparring.  And when I think about shadow boxing, I realize that my bot needs another system.

With each iteration of the bot, I've been adding layers of abstraction and command and control.  Its gone from literally doing exactly what I told it to do, to executing a set of instructions to do what I'm telling it to do, to finally trying to achieve a goal.  You could say its gone from "do A' to "execute function B" to "execute function B until condition C."  Do, do{}, and do until.  Turns out I need one more: if/then.

Goal queues make sense when trying to execute a script of instructions, one at a time, one after the other, each one requiring performing a set of actions until a condition is met.  But its not capable of emulating, in effect, the algorithmic equivalent of if/then/else, or alternatively "switch."  And combat needs that, because combat is about reacting in different ways to different conditions.  I need to be able to tell the bot "if you are more than seven feet away from the target, try to move to the target."  "If you see the target facing you and executing an attack, at the right time react as if the attack hits (or misses)."  "If you see this specific attack executed, fall down."  The problem with the cmdQueue is that its designed to execute its instructions one at a time in order.  But this type of thing doesn't happen in order, it happens as necessary.  Basically I need to give the bot a set of "reactions" and the best way to perform those reactions is with a set of if/then style event driven commands.

So I'm making a new goal-like structure similar to the cmdQueue, which I'm currently calling "triggers."**  The triggers list will contain individual elements similar to command queue goals, but instead of having a command and a set of parameters (which implicitly define a goal, like "turn towards this target" or "follow that entity"), it will have a conditional and a goal (identical in nature to the original goals).  And unlike the cmdQueue which is explicitly intended to be executed in order, with command #2 only executing when command #1 completes, the triggers queue will be processed by having all entries checked on every clock tick to see if they should fire.

"Combat" would then be setting the right set of triggers: if distance > 7 then follow target.  If distance <=7 and target facing bot and target animation in (attacks) then execute bot.reaction.  If distance <= 7 and target not animating and random.chance then execute bot.attack_animation.  The bot would now have both the ability to execute commands and have a stimulus-response set of behaviors that is also programmable.  In fact, what I see happening is that combat will be enabled by command: "/t ArcanaBot, /fightme" would cause the bot to execute "/fightme sender" which would itself add a set of triggers to the bot's trigger list.  "/t ArcanaBot, /nofightme" would delete those triggers.  "/t Arcanabot, /fight target" would cause the bot to add the same triggers, but with a specified target rather than sender.  With this command, a player could send the right commands to two separate bots that would then fight each other until commanded otherwise.

At that point, I will have achieved near proof of concept***.  And then I can start bothering Codewalker to add FX spawning.  I wonder if I can have this working by the weekend.

Also, one other thing.  I started thinking today about authentication; well, I've been thinking about it since the beginning, but I started thinking about the specifics today.  There are some ways in which I want the bot to respond to anyone that interacts with it.  And then there are some commands I don't want just anyone to be able to send in some cases.  So I've been thinking about a way to perform an authentication with the bot to put yourself on its whitelist, whereupon it will accept any command from you.  If you don't, it will not respond to certain commands being sent its way.  I could just hardcode a whitelist into the bot, but having the ability to do this dynamically has certain advantages.  For one thing, you can support opt-in.  Meaning, some things the bot will do to anyone, like maybe responding to a tell saying "hi."  Some things the bot will do to anyone, provided they first opt-in to the bot's behaviors, like telling the bot "/opt-in" could cause it to allow you to say "/faceme."  But if you try to teleport it away with "/comehere" the bot won't necessarily obey that command.  For that, you'd have to login with "/admin password" and then the bot would start obeying all of your commands.

I'm not quite sure how I want to do this yet.  But the time to start thinking about it is before I implement too many commands.


** "Triggers", "behaviors", "reactions" - I often spend an inordinate amount of time thinking about what to call something, because it bothers me later if I give something a bad name or I end up using it in a way completely contrary to its name.  Even the cmdQueue is something I wished I had called the "goalQueue" but I'm not going to find/replace that one just to fix it at this point.

*** I won't be completely satisfied until the bots can brawl in Pocket D while being knocked off the walls and kicked into the furniture.  So at some point, geo processing will become necessary.  Its a small benefit requiring a huge amount of effort, but I refuse to let that mental image go.

Dyne

  • Lieutenant
  • ***
  • Posts: 54
  • Gluer of Gears
Re: Technical side discussion
« Reply #284 on: August 04, 2015, 10:02:23 AM »
Here's the basic question - What are the implications of managing a group of NPC's?

(snip)

We've established, I think, that all five of these Hellions need to have presence in the atlaspark and atlaspark_meta rooms. They all need costumes. They each need to have their own XMPP connection in order to communicate their presence and position. They each, therefore, need to have their own thread or their own process that is controlling their personal XMPP connection.

I am intending to use this exact structure, except it would be for contacts scattered across various zones, not random street mobs in one cluster.  I'm not intending to replicate COH combat, just some narrative semblance of missions (i.e. "something to do").  And yeah, from the player's standpoint, they are talking to five different characters, but really they are talking to the same bot wearing five different masks in five different places.

Quote
What does this mean for the server? Do the individual Hellion NPC's each need a unique JID? That is, does the bot login as mybot@chat.cohtitan.com with password "mybot" or does each Hellion require its own Titan account? Can one account join a chat room five times under five different nicks?

Obviously it is possible to join multiple rooms with one account, because Paragon Chat is doing exactly this for the zone room, zone meta room, and every global chat channel you are on.  But a single account can also join a single room multiple times.  That's how running multiple copies of PChat and COH works when both clients are in the same zone.  I've even been logged into the same zone three times on a few occasions already.  One via Pidgin, and two via PChat.

For example, in the screenshot here the two characters on the left are me.  If I also happened to be in the main galaxycity room via Pidgin at the time, that'd be a single account joining that room three times, and the galaxycity_meta room twice (one less because Pidgin doesn't care about the meta, though I could join it too if I wanted).  Technically, I was also on various global channels multiple times as well, especially paragonchat.

Unless the server is set to cap the number of simultaneous logins on one account, there's no reason it can't be more than three.  And there's certainly no reason a bot can't do the same thing that I do manually.

Quote
What does this mean for the server? Do the individual Hellion NPC's each need a unique JID?

The full JID differs, but only by resource name.  The bits without the resource name are the bare JID, which I believe remain constant as long as the XMPP server name you log into and the account you use to log into it remain constant.  The resource name can be set to anything (Paragon Chat puts your character name there).  It gets auto-assigned by the server if you don't bother (which in openfire seems to gives the bot a hex number as a resource).

Which reminds me that the bare JID is one way that players can trust NPCs, at least to the extent they can trust anything.  Imagine a mission that has a "go talk to Statesman in Independence Port" step, and the player walks up and sees three different Statesmans lounging around.  Rather than being the City of Heroes equivalent of a "Reign of the Supermen" scenario, it probably just means there are missions run by three different bots that each have a "go talk to Statesman in IP" step.  So which one do you actually talk to?

If the Statesman for your mission had a separate account from whatever bot you have that sends the player there to see him, the player would have no way of knowing which Statesman was correct other than trying to interact with each one until they get an interaction that makes sense (if any, given that bot writing skills do not equal story writing skills).

On the other hand, if your set of NPCs all use the same bot account, the bare JID will be identical for each NPC it controls, so players sent from one NPC to another could distinguish between NPCs that happened to have the same character name and costume.  So there's a legitimate reason (aside from convenience) to code multiple NPCs as a unified system rather than as a bunch of independent bot accounts.

Another (probably more likely) scenario is a griefer version of Arcana's MirrorBot, cloning your Statesman to distract players from the "real" one.


Quote
If I create this encounter, am I going to be "hogging" resources on the server? What sort of resources should a bot owner be priveleged to use and to be considered to be "playing nice" with the other people who might be doing the same thing with their own resources?

My rule of thumb is always whether it, as a whole, improves the experience for players.  There's no hard line, and I tend to assume members of the bot community are generally well-meaning and care about that.  There is obviously potential for griefing, or even a DOS attack, but that potential exists already.  Bots didn't create it.

The first bot on the public servers giving players "stuff to do" will be very beneficial.  For bots 2 through N (where N is some unknown number), the drop due to declining novelty is way more than offset by the variety.  Still, each is offset a little less than the previous one.  Eventually there are too many bots using resources, and adding another one on the pile is more likely to subtract from the overall experience, even if the newest bot is the greatest thing since sliced bread.

Also, bear in mind that server resources aren't the only consideration here.  XMPP is inherently less efficient than the normal COH protocol (as was discussed back when Codewalker posted the protocol), so a hundred bots in one area in Paragon Chat are going to be much worse on network bandwidth on the client end than a hundred mobs were in the same situation when the game was live.  It uses higher resources strictly on each client machine as well, since there's an extra XMPP -> COH translation step going on as well as communication between PChat and COH.  As Codewalker said awhile back, performance was not the primary design consideration.

Among the implications, it behooves you to default to NOT put any given bot or NPC into Atlas Park without a reason, as that will inevitably be the zone that sees the most traffic.  My intent was to have a single avatar in each of the starting zones to direct people to "contacts" in less well-traveled zones, like blueside initial contacts, and even that was more for visibility than out of necessity.  (I was never a huge fan of AP, but I recognize the practicality of it being the primary starting zone.)


Of course, all of this presupposes that I can ever wrap my head around sleekxmpp.  The official docs are ... special.  Fritzy's are a little better, but the info here didn't help.  Turning to code, the demos are enough to let me figure out how to log in but don't seem to handle enough of what I need to know to implement PC's protocol, and the example code that ostensibly does is missing some context.  I'm also apparently missing something important in the code posted here.  I resorted to looking at the XEP plugins, but so far it hasn't helped me get any further than a more elaborate version of the MUC bot demo.

But damn have I nailed using Python's argparse and logging modules.  I got your timestamps.  I got your fancy loglevels.  I got your multiple log streams, so I can have both console and file debugging without duplicating every single message as both a print statement and a call to a logging method.  I can even have different loglevels for the logfile and the console.

Based on the debug messages sleekxmpp itself generates in my logs, the bot is receiving u stanzas and such; it just isn't reacting to them.  So it has to be something I've done wrong.

I did quickly put in a quit command, though, so I can stop the bot more easily.
« Last Edit: August 04, 2015, 10:21:58 AM by Dyne »
-= Virtue Server - 2004-06-13 to 2012-11-30 =-
hortis publicis gemini in aeternum

Usurper Dyne, Still Heart, River Elemental, Saul Invictus, Grim Grinner

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical side discussion
« Reply #285 on: August 04, 2015, 01:06:29 PM »
so a hundred bots in one area in Paragon Chat are going to be much worse on network bandwidth on the client end than a hundred mobs were in the same situation when the game was live.

The XMPP server that we're running is set to limit each zone to a max of 30 players in order to keep the exponential scaling of network traffic under control. Pocket D may be set higher (50 I think) as many people stand in one place for long periods of time there.

That's implemented as a cap on the number of occupants of the meta channel. The broadcast channels are set a bit higher so that people can join them from other XMPP clients.

To reference an earlier example, if you logged in 5 times as players pretending to be Skulls, then you'd be taking up 5 slots in the zone. If you created 29 Skulls that way, only one player could actually get into King's Row to see them. Any subsequent players would be unable to join the room, and their client would fall back to joining "King's Row 2" instead.

Dyne

  • Lieutenant
  • ***
  • Posts: 54
  • Gluer of Gears
Re: Technical side discussion
« Reply #286 on: August 04, 2015, 01:43:34 PM »
The XMPP server that we're running is set to limit each zone to a max of 30 players in order to keep the exponential scaling of network traffic under control. Pocket D may be set higher (50 I think) as many people stand in one place for long periods of time there.

Yeah, there's that, too (I'm running Openfire as well). 

I just mentioned a hundred as an arbitrary large number to emphasize the point.

Quote
To reference an earlier example, if you logged in 5 times as players pretending to be Skulls, then you'd be taking up 5 slots in the zone. If you created 29 Skulls that way, only one player could actually get into King's Row to see them. Any subsequent players would be unable to join the room, and their client would fall back to joining "King's Row 2" instead.

Which just made me notice a wrinkle for bots ... they will not automatically appear in extra zone instances.
« Last Edit: August 04, 2015, 02:04:42 PM by Dyne »
-= Virtue Server - 2004-06-13 to 2012-11-30 =-
hortis publicis gemini in aeternum

Usurper Dyne, Still Heart, River Elemental, Saul Invictus, Grim Grinner

FloatingFatMan

  • An Offal
  • Elite Boss
  • *****
  • Posts: 1,178
  • Kheldian's Forever!
Re: Technical side discussion
« Reply #287 on: August 04, 2015, 03:25:53 PM »
Which just made me notice a wrinkle for bots ... they will not automatically appear in extra zone instances.

Good! If they did auto-spawn in new instances, then given CW's scenario, we'd have hundreds of instances with only 1 person in each!

I think perhaps we'll need bots to be authorised by the server somehow, so that there aren't too many running and taking up people-slots...

Dyne

  • Lieutenant
  • ***
  • Posts: 54
  • Gluer of Gears
Re: Technical side discussion
« Reply #288 on: August 04, 2015, 05:13:11 PM »
Good! If they did auto-spawn in new instances, then given CW's scenario, we'd have hundreds of instances with only 1 person in each!

I realize that.  I wasn't arguing they should; I was just pondering the implications for bots operating as a mission chain.

When the bot sends someone to Skyway to talk to another NPC contact, it can't rely on the player actually being able to locate the NPC there; the bot might be in a different instance.  Ok, its really unlikely for that zone, but still.

Of course, a bot can check which instance its avatars are in and direct the player accordingly, but that doesn't help when the player can't actually get in a specific instance.

I suppose one possible solution is to give the player the ability to tell the bot which instance they are in and have the bot try to move the npc to meet them.
-= Virtue Server - 2004-06-13 to 2012-11-30 =-
hortis publicis gemini in aeternum

Usurper Dyne, Still Heart, River Elemental, Saul Invictus, Grim Grinner

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #289 on: August 04, 2015, 07:02:53 PM »
Good! If they did auto-spawn in new instances, then given CW's scenario, we'd have hundreds of instances with only 1 person in each!

I think perhaps we'll need bots to be authorised by the server somehow, so that there aren't too many running and taking up people-slots...

Unfortunately, *these* bots are people, or rather operate identically to people.  At some point Paragon Chat could have a bot API, which means anyone that anyone using it would be distinguishable from actual players.  But you'd always have to deal with the possibility that some of the players logged in are not actual people.  Even without XMPP bots, there are ways to bot the City of Heroes client itself.

The presumption is that in a chat system with little gaming infrastructure and no rewards, there is little incentive to do anything that isn't of at least some nominal community service.  But its one of the reasons my particular project is focused on programmers and not users.  I have no intention of making an end-user friendly bot, so to speak, because I'm more interested in helping programmers write their own.  I'm currently operating under the compromise position that people with skin in the game, so to speak, are less likely to abuse the privilege.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #290 on: August 04, 2015, 07:24:48 PM »
I realize that.  I wasn't arguing they should; I was just pondering the implications for bots operating as a mission chain.

When the bot sends someone to Skyway to talk to another NPC contact, it can't rely on the player actually being able to locate the NPC there; the bot might be in a different instance.  Ok, its really unlikely for that zone, but still.

Of course, a bot can check which instance its avatars are in and direct the player accordingly, but that doesn't help when the player can't actually get in a specific instance.

I suppose one possible solution is to give the player the ability to tell the bot which instance they are in and have the bot try to move the npc to meet them.

Or you can make sure that the bot is always in an instance that has a low population count, even going so far as to deliberately spawn a new instance to make sure its empty (except for the bot) and directing players to go there.  In a sense, you'd be instancing the zone into a pseudo-private map.

None of these problems will have complete solutions because we are dealing with a system that currently has many technical limitations.  However, there's two ways to approach those limitations.  You can try to technology your way past them, or you can try to invent gameplay that works around them.  If you are writing a bot for a specific gameplay purpose, then in a sense you're a game dev, and your task is to do both and try to meet in the middle.  You have to simultaneously try to create the technology you need, while accepting the fact the technology you have will never be perfect and your gameplay ideas have to accommodate those limitations.

Incidentally, I believe players should announce their instance in their presence stanzas along with their map location.  I'm pretty sure that's part of the map attribute, although I haven't had to deal with that yet directly (since I've never had more than three entities on a map simultaneously and I'm on my own server).

FloatingFatMan

  • An Offal
  • Elite Boss
  • *****
  • Posts: 1,178
  • Kheldian's Forever!
Re: Technical side discussion
« Reply #291 on: August 04, 2015, 08:16:32 PM »
How about something like an extra meta channel, for bots only, that can only be joined programatically and that would sidestep the zone limit, but have it's own limit?

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #292 on: August 04, 2015, 08:59:15 PM »
How about something like an extra meta channel, for bots only, that can only be joined programatically and that would sidestep the zone limit, but have it's own limit?

The reason why zones have limits in the first place is because XMPP can, in some circumstances, increase its traffic quadradically with number of people in the room.  That's because I say something and everyone else has to hear it, given n players, the number of XMPP messages scales as some factor k * n * (n - 1).  Actually, its worse than that because XMPP sends you back your own messages, so really its k * n * n or kn^2.  And this happens most strongly in the meta channel.  So long as bots participate in the zone meta channel, they would be contributing to the reason for the zone limit.  If they didn't participate in a zone's meta channel, they wouldn't be able to track the locations of other players in that zone and would be invisible.

If there was a way to segregate bots that would still allow them to functionally exist within the zones, we could generalize that solution to break up players into subrooms as well and allow more players per zone instance without suffering from the quadratically scaling message issue.  That's actually a technical idea that was discussed earlier, but its complicated and unlikely to arrive anytime soon.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #293 on: August 04, 2015, 10:30:27 PM »
Well, we work with the system we're given. There are a ton of mission maps as well as zone maps, and if I need to tell someone to "Go to  Jacaranda Vista ((/mapmove 1134))" and make it known ahead of time that people need a zone.cfg that has the latest collection of maps in it, well, that's the price of admission for directing someone to a place where you can reasonably expect that running twenty NPC's at once is going to be acceptable from the standpoint of any live people visiting the zone.

A considerate bot would keep a list of possible mission maps and first check whether a "_meta" for the proposed mission currently exists and if it does, try another one down the list.


slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #294 on: August 05, 2015, 12:59:43 AM »
Okay, I knew there was a reason why the "Where do you think I am?" question was interesting.

Our bots are blind. They live in Paragon Space where they are surrounded by impassable barriers but they cannot detect them.

The only way for my bot to know what is in front of it is to either know how to read and interpret a map of the city's geometry or to be able to ask some central authority, "I am at point X, Y, Z. What is around me?"

Or, at a bare minimum, tell the client my bot is focused on to "Hey, be my eyes."

Sure, in an ideal world, I'd load up a map of the city and analyze it for collisions. The plain fact of the matter is, though, that I not only don't know how to do that, I just don't care about doing that. All I care about is getting my bot from point A to point B following reasonably close to the path taken by the player.

I'm as impressed as Hell with Arcanabot, but I wonder what happens if you hop a fence and then tell her to /followme?

With no knowledge of the existence of the fence, Arcanabot is either going to get hung up or she's going to end up teleporting past the obstacle when, by her own calculations, she ought to be much farther along her path and she spits out a <U> that puts her where she "ought to be".

I've called it a cheat up until now, but in a world where a bot is blind, becoming the bloodhound that sniffs along the player's trail isn't a cheat, it's the only practical way to travel along a route that you know will take you where you want to go without teleporting all over the place or simply moving through large obstacles like buildings and trees and mountains and mid-air for that matter.





slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #295 on: August 05, 2015, 01:13:31 AM »
There's another alternative, that goes back to the running on rails thing.

You could create your own map of the city that has rails running around the major obstacles. When a bot finds itself near a rail, it has the option to hop onto it, ride it to the end, and then hop off and resume its goal seeking.

That won't help with flying into a building but it would cover the basic ground-pounding follower scenario.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #296 on: August 05, 2015, 09:42:58 AM »
I'm as impressed as Hell with Arcanabot, but I wonder what happens if you hop a fence and then tell her to /followme?

With no knowledge of the existence of the fence, Arcanabot is either going to get hung up or she's going to end up teleporting past the obstacle when, by her own calculations, she ought to be much farther along her path and she spits out a <U> that puts her where she "ought to be".

This is why experimentation is important.  Actually, neither of those things happens.  First of all, collisions occur between player capsules and surfaces.  There aren't really any solid objects in City of Heroes: when you collide with a building, you collide with one of its walls (or rather a polygon that's part of the wall).  But if you get past the wall, you are now within the structure and there aren't any more collisions until you hit another wall.  You don't get stuck on one side of a building until you suddenly teleport to the other side.  At worst, you momentarily collide with the outer surface of the building for all of one frame of animation, and then when you send a <u /> that places you past that surface your bot "teleports" the tiny distance it takes to get from one side of that 2D surface to the other side.  Its something you can't even see.  See this: https://www.youtube.com/watch?v=JWj3IXMwzNo

Note the bot basically just walks smoothly through that building and the short wall.

However, that's not to say that the combination of "ghosting" and client-side prediction can't make strange things happen.  Take a look at this: https://www.youtube.com/watch?v=SKOdqohZSiI

I should point out that at no time *ever* does my bot *ever* touch roll.  I only touch pitch and yaw.  In every single <u /> my roll angle is zero.  So what's happening here?  Obviously, the bot's defiant belief its intangible combined with a client side predictor that doesn't believe that combine to create some very odd effects which are not obviously emergent.  Because the bot is visibly "rolling" over the wall in a weird sort of almost-hop over, and yet its only being told to walk straight through the wall.  The only place that behavior can come from is client-side prediction.  Why prediction predicts that is quite frankly inexplicable to me, but I'm sure there's a good reason.  But without full knowledge of the precise algorithms for prediction, you'll probably have to experiment to figure out what can happen.

Bottom line, though, is that without the bot calculating collisions it will always ultimately get to where you tell it to go, without getting "hung up" on geometry and it won't get there by jumpy teleports.  It might get there with some odd movement prediction, but that seems to be a corner case.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #297 on: August 05, 2015, 09:54:00 AM »
There's another alternative, that goes back to the running on rails thing.

You could create your own map of the city that has rails running around the major obstacles. When a bot finds itself near a rail, it has the option to hop onto it, ride it to the end, and then hop off and resume its goal seeking.

That won't help with flying into a building but it would cover the basic ground-pounding follower scenario.

City of Heroes uses a technique called "beaconing."  The maps have invisible "beacons" placed at strategic locations and paths laid out between them.  When a critter needs to get from point A to point B, it locates the nearest beacon and travels to it.  Then it finds the beacon path to the beacon that is the closest to B.  Then it runs along that path to B.  Then it goes from that beacon to B.**  The beacons and beacon paths act as safe "highways" for the critters to navigate the map, knowing someone else has "cleared" those paths.  The only problematic parts then become the path to get from A to the nearest beacon, and the path to get to B from the nearest beacon.

You could build your own beacon system for each map you want the bots to nagivate, placing*** beacons and paths strategically to the only locations you care about.  If you choose your beacon locations carefully enough, you don't even need to worry about ground height, because you can ensure that the path from beacon Alpha to beacon Beta is always parallel to and close enough to the ground between those beacons (sticking to roads and sidewalks helps).

Beacons don't help me for what I want to do, although the alternative for me is a do-it-yourself simplified space map of boundary boxes that roughly approximate the map volume I care about.  But I think I have a legitimate shot at figuring out the basics of geo-mapping; at least enough to compute volumetric maps out of them.  It can't be all that much harder than trying to figure out the animations sequencer or power database starting from nothing.****


** At least that's how I understand the system to work.  I've never really messed around with the beacons to be honest, because my travels through the City of Heroes game system never required I master NPC pathing.  Until now, of course.

*** Understanding that you don't literally need to "place" anything anywhere, you just need the bot to know where you decided they should go.

**** Yes it can.

slickriptide

  • Elite Boss
  • *****
  • Posts: 356
Re: Technical side discussion
« Reply #298 on: August 05, 2015, 03:09:04 PM »
Ah, I was still stuck in my "set it and forget it" frame of mind. Arcanabot has a fast clock. Fast enough, at least, that the duration between ticks, and therefore the duration between <U> footprints is so short that she isn't noticeably impeded by the barrier.

That "rolling over the top of the fence" effect is pretty interesting. I have a theory about that based on what I've seen happen when two bots collide, or when I've blocked my bot with my own avatar.

I'd theorize that on occasion Arcanabot emits a <U> that causes her collision box to intersect the collision box of the fence, requiring that they repel each other until they're both outside of each other's bounds. Since Arcanabot already has "forward" velocity, the game engine helpfully repels her "up" instead of repelling her "back" or in some other direction. The temporary pitch/roll alteration might even be baked into the fence - I seem to recall that there were NPC's that appeared to put their hand on top of a fence or wall and vault over it as opposed to just jumping like a player would do. A change in pitch to the angle demonstrated by Arcanabot would accommodate a change in animation that involved kicking your legs out to vault over a wall.

At any rate, the fence can't move. By altering Arcanabot's apparent orientation and velocity, the game gets her out of the "red zone", so to speak, and then Arcanabot's own movement code puts her back on the correct path and orientation.

This still leaves us with the problem that Arcanabot is Kitty Pride. She just phases through anything that gets in her way.

With no map server to tell you where surfaces exist, though, I suppose that's going to be an unavoidable fact of bot life.

I haven't had a lot of time to work on my bot lately but I think I'm going to go ahead and try out the bloodhound approach just to see if it looks "unnatural" and to what extent it appears that way. I'm thinking that the CoH devs probably had the best idea with the beacons and rails assisting what was otherwise a seeker that was probably similar to what Arcanabot uses.


Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical side discussion
« Reply #299 on: August 05, 2015, 06:11:32 PM »
Arcanabot has a fast clock.

By default, 30 ticks per second, adjustable:

Code: [Select]
    while pcbot_keyboardTracker.processPyEvents():
        pcbot_meta_key.processKeyState(pcbot_keyboardTracker)
        pcbot_meta_key.take_action(pcbot_meta)
        pcbot_meta.doGoal()
        pcbot_meta.move_bot() # goals set movement flags, so move must be after goal
       
        clientClock = time.clock() * 1000
        clientLoop = clientLoop + 1
        #print "Debug: clock loop: " + str(clientClock)
        clockAlign()

clockAlign does this:

Code: [Select]
def clockAlign():
    miltick = (time.clock() * 1000 % 1000)
    nexttick = (int(miltick / 33.33) + 1.01) * 33.33 + 1
    #print "Debug: sleep:",miltick,nexttick,nexttick-miltick
    time.sleep((nexttick - miltick)/1000)

Yanked right out of my "MMO 0.001" experiment.  Also, "clientClock" is used to timestamp every roster update with a millisecond timestamp, which I'm going to use for prediction when I implement prediction.  I could adjust this up or down by adjusting the clockAlign calculations to 1 frame per second, 8 frames per second, or whatever.

Quote
I'd theorize that on occasion Arcanabot emits a <U> that causes her collision box to intersect the collision box of the fence, requiring that they repel each other until they're both outside of each other's bounds. Since Arcanabot already has "forward" velocity, the game engine helpfully repels her "up" instead of repelling her "back" or in some other direction. The temporary pitch/roll alteration might even be baked into the fence - I seem to recall that there were NPC's that appeared to put their hand on top of a fence or wall and vault over it as opposed to just jumping like a player would do. A change in pitch to the angle demonstrated by Arcanabot would accommodate a change in animation that involved kicking your legs out to vault over a wall.

You're probably close.  City of Heroes has a way of calculating which surface is "the ground" by performing a calculation that determines which surface is the closest to the entity in the downward direction.  Meaning, given the entity - in this case the bot - position(x,y,z), calculate a vector pointing in the downward direction and see what is the first polygon that vector intersects.  That is "the ground."  Generally speaking, its the ground.  However, if I set position to a point within a "solid" object like the wall, that calculation could generate a normally nonsensical result: it could end up pointing, say, right at a funny tessellation in the wall.  Finding "the ground" is important because it tells City of Heroes things like what friction to apply to the character, and of course also what the surface normal is - what angle the ground currently slopes.  If City of Heroes picks up a weird surface as "the ground" at the instant I phase through the wall, it could cause it to believe "the ground" is sloped at a weird angle and force my bot to roll in the direction of the slope.  Its also possible that the collision code could bump me in a strange direction at the same time, which could combine to produce the effect.

Its still a strange effect because while that all makes sense on the surface, there's still a few unanswered questions about why it does it quite the way it does.  There are still some things about the client I don't fully understand, if not what it does then why it does it.  For example its interesting to me that if you change an entity's location dramatically, the original devs decided the entity should move there at supersonic speed rather than just teleport there.  I know that it happens, but not what the thinking was.  Maybe they just thought it was cool.