PvPGN with Ghost++ (Dota)

[anonbyte]

No Update Feature ?

[HarpyWar]

If you mean that there are no new commits with new functionality last days, then it because of I'm implementing a localization part now. It was not easy to find a better way to do this, but now it all tested and I will finish it on the week. Next feature is DotA support.

[anonbyte]

Dota Support? yeah like this so much...

i have idea EXP, Level system when play dota and maybe PSR like HoN or MMR in DotA 2

[HarpyWar]

By Dota I mean better connectivity between PvPGN and GHost bot. GHost is also needed some code modification for that.

I will not implement custom rating system, but it will be possible to do using Lua.

[anonbyte]

maybe integrate with this https://github.com/OHSystem/ohsystem

Ghost++ Major Modification

[HarpyWar]

Thanks for the link, as I see that project has a high activity, I will consider closer this project and create an issue there with detailed info of my vision.

Is this centralized hosting bot that is connected on their web server stats, or it can be used stand-alone like an original ghost++?

[anonbyte]

yeah, like ghost++ can host own database the developer always accept request and improve

[cen1]

We have a master-slave implementation with a single guard bot and several slave hostbots which communicate via UDP. Master basically delegates the hostbots and collects the stats. I guess such a master functionality will have to be in PvPGN in one way or another.

It would be nice if you could open a seperate issue and lay down the overview of the design and implementation when you start working on it. I'd like to adopt the functionality into our bots later on. Not only for dota but also for PG.

[HarpyWar]

@cen1, thanks for the info. Are you a developer of that project? Have you info about how the bot works with gproxy? AFAIK gproxy is a client-side app.

[cen1]

It was developed by lagabuse.com admin MyUberNick who is mostly inactive at the moment but our server inherited the league and the code so I am personally maintaining it at the moment.

We also use gproxy extensively on that league. It sits between W3 and ghost, proxying the connection and extending the protocol with gpsprotocol. When you connect to a lobby, gproxy and ghost do a handshake and that connection is then marked as disconnection protected. When your internet drops mid-game and then comes back, gproxy and ghost can renegotiate the connection and get you back in.

How "exactly" gpsprotocol works I don't personally know because I never went too deep into it but the source code is available.

[HarpyWar]

What is goal of your stats synchronization between bots, if they are connected to a single mysql database?

[cen1]

There are a few reasons.

1. Original ghost++ spawns new mysql connections like crazy, it can get up to a few tens of connections over the time. There is no pool or recycling going on.
2. Due to our hosting provider limitations we were required to limit number of connections to 1
3. Hostbot stats cache would get out of sync if every one of them was responsible for it's own data. If you make them dumb and relay all the stats handling to master you have a single point of interaction with the db. I guess you could keep them in sync but you'd need to refresh the cache a lot more.

[cen1]

An example of packet headers which might be needed for pvpgn<->ghost++ communications http://xpam.pl/proto_example.txt (taken from our bots)

[HarpyWar]

At the moment I think that it is better to fix Ghost++ to use a single persistence database connection. Could you give an example when hostbot stats cache would get out of sync?

[cen1]

The sync problem does not apply here because you send commands directly to pvpgn. In our case you send commands to the actual hostbot while you're in-game so each hostbot needs to have a local cache of the stats. A single db connection is OK since ghost only needs to write the game stats.

Anyway, most of the headers linked above do not even deal with the database, just with creating the games, checking if ghost is available, checking if it's full etc. Unless you are including ghost++ into pvpgn directly (like as a seperate thread of pvpgn process) you will need some kind of protocol to tell the bot to host a game and do other stuff.

Also, each pvpgn will have to communicate with several ghosts which might not even be on the same server. Imagine you setup ghosts around the world in EU, USA and BR and then when player wants to join a game you pick the one with lowest ping. In such a case you need some kind of UDP/TCP protocol to communicate with them over LAN or internet.

[HarpyWar]

@cen1, I'm not sure that it is what you want, but leave your opinion there please (maybe I don't realize something?).

[cen1]

It's pretty close. :)

[RElesgoe]

Maybe Ghost++ should be modified to use a custom protocol ID if we want the server to give it special privileges or something. See #66

[cen1]

If that is just for localhost it won't work.

[RElesgoe]

The bot can connect with any protocol ID then we can just add the necessary code to PvPGN to recognize that ID

[cen1]

What exactly prevents some random person to spoof such an ID? Pretty sure you need verification per account to give any privileges. And what privileges are we talking about exactly?

Maybe I just don't understand what exactly you mean. :)

[RElesgoe]

Maybe there could be some additional packets for authentication(send a hash of the hostbot's software, idk). I'm just saying that if you want to treat hostbots differently from regular players, this is probably a good way to go. For example, maybe hostbots will automatically join a channel only for hostbots.

[HarpyWar]

Bot will auth using a command /pvpgn init and predefined list with bot names in PvPGN config. I think it's enough.

[cen1]

Actually.. why not simply add this to CG functionality? Make CG 9 a hostbot account and problem solved. Config is a bad place for this because you can't dynamically change it.

[HarpyWar]

@cen1 this is really nice idea. I will use it instead of list in config If this fits to all the functions.

[HarpyWar]

For all that It's better explicitly define Bot list in config, to make sure that only bots have access to the special commands. Otherwise it can be abused by privileged users with the same cg for hacking stats. What about config — this is not a problem, because it will be implemented in Lua. Lua virtual machine can be reloaded in runtime by /rehash lua. Also, PvPGN will check this list when user login and send a command /pvpgn init to activate "pvpgn mode" on a ghost side.

[cen1]

In order to get a CG9 status you need to be a server admin so abuse is hardly a problem. At that point you might as well use /set commands to give yourself stats.

I actually have nothing against config but prefer the CG way so it can be done by any capable admin and not just the ones who have ssh access to the pvpgn server to edit configs. Unless there is another way to change configs from outside?

[HarpyWar]

It's better to reduce possible ways to access for bot commands or adding a new bot. If necessary config can be changed from a web interface, or from a new created command in runtime, even without a rehash. But in most cases bot list is a persistent value that will be changed very seldom.

[cen1]

I will start adding initial support for this in our ghost fork so we can test the implementation.

Some observations:

1. Why do we need to relay /open, /close, /start etc from pvpgn to ghost? GHost already knows these commands. I am not sure that relaying all commands from lobby and in-game through pvpgn really provides any benefit.
2. Should bot refuse to return ping if it's in lobby and unable to host? We need to only pick between bots that are actually available.

[HarpyWar]

@cen1 are you talking about https://github.com/Grief-Code/OHSystem/issues/279 implementation ?

1. We need wrappers for these commands because:

• most of new commands-wrappers have username in arguments
• we need appropriate callbacks (output) for each command for futher processing them on PvPGN (by default ghost sends callback to game owner but not PvPGN)
• we need to save compatibility with previous mode - "pvpgn mode" shouls be enabled on demand when ghost receives a command /pvpgn init

2. Bot should be modified to host multiple games. This feature will be also enabled on PvPGN for allowed bots. And again - this feature should be enabled only when "pvpgn mode" is activated on a bot.

[cen1]

I still don't understand why implement something like /open. This is a lobby command, has nothing to do with pvpgn and pvpgn has no info to gather from this command. We just relay it and do nothing else with it. Anything in lobby and beyond is none of pvpgn business right? So why waste time and bandwith for relaying if these can be native ghost commands?