Techwizz/pvpgn-server
1
0
Fork 0
Code Issues68 Pull requests2 Projects Releases8 Packages Wiki Activity Actions

PvPGN with Ghost++ (Dota) #35

New issue
Open
opened 2014-06-26 02:33:30 -06:00 by anonbyte · 35 comments
anonbyte commented 2014-06-26 02:33:30 -06:00 (Migrated from github.com)

No Update Feature ?

No Update Feature ?
HarpyWar commented 2014-06-26 03:59:20 -06:00 (Migrated from github.com)

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.

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 commented 2014-06-26 07:50:10 -06:00 (Migrated from github.com)

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

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 commented 2014-06-27 06:50:38 -06:00 (Migrated from github.com)

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.

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 commented 2014-06-27 07:34:30 -06:00 (Migrated from github.com)

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

Ghost++ Major Modification

maybe integrate with this https://github.com/OHSystem/ohsystem Ghost++ Major Modification
HarpyWar commented 2014-06-27 08:09:24 -06:00 (Migrated from github.com)

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++?

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 commented 2014-06-27 08:13:55 -06:00 (Migrated from github.com)

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

yeah, like ghost++ can host own database the developer always accept request and improve
cen1 commented 2014-06-27 08:25:44 -06:00 (Migrated from github.com)

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.

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 commented 2014-06-27 09:39:15 -06:00 (Migrated from github.com)

@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, 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 commented 2014-06-27 10:01:08 -06:00 (Migrated from github.com)

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.

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 commented 2014-06-27 17:13:02 -06:00 (Migrated from github.com)

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

What is goal of your stats synchronization between bots, if they are connected to a single mysql database?
cen1 commented 2014-06-28 14:48:21 -06:00 (Migrated from github.com)

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.
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 commented 2014-07-01 03:18:37 -06:00 (Migrated from github.com)

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

An example of packet headers which might be needed for pvpgn<->ghost++ communications http://xpam.pl/proto_example.txt (taken from our bots)
HarpyWar commented 2014-07-01 06:08:21 -06:00 (Migrated from github.com)

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?

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 commented 2014-07-01 06:54:45 -06:00 (Migrated from github.com)

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.

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 commented 2014-07-02 07:33:21 -06:00 (Migrated from github.com)

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

@cen1, I'm not sure that it is what you want, but leave your opinion there please (maybe I don't realize something?).
cen1 commented 2014-07-02 15:56:03 -06:00 (Migrated from github.com)

It's pretty close. :)

It's pretty close. :)
RElesgoe commented 2014-07-20 02:42:07 -06:00 (Migrated from github.com)

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

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 commented 2014-07-20 15:06:27 -06:00 (Migrated from github.com)

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

If that is just for localhost it won't work.
RElesgoe commented 2014-07-20 15:09:33 -06:00 (Migrated from github.com)

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

The bot can connect with any protocol ID then we can just add the necessary code to PvPGN to recognize that ID
cen1 commented 2014-07-20 15:23:49 -06:00 (Migrated from github.com)

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. :)

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 commented 2014-07-20 15:33:22 -06:00 (Migrated from github.com)

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.

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 commented 2014-07-20 23:04:52 -06:00 (Migrated from github.com)

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

Bot will auth using a command `/pvpgn init` and predefined list with bot names in PvPGN config. I think it's enough.
cen1 commented 2014-07-21 10:16:35 -06:00 (Migrated from github.com)

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.

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 commented 2014-07-21 14:34:38 -06:00 (Migrated from github.com)

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

@cen1 this is really nice idea. I will use it instead of list in config If this fits to all the functions.
HarpyWar commented 2014-07-22 01:09:59 -06:00 (Migrated from github.com)

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.

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 &mdash; 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 commented 2014-07-23 02:42:48 -06:00 (Migrated from github.com)

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?

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 commented 2014-07-23 04:09:38 -06:00 (Migrated from github.com)

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.

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 commented 2014-09-01 06:48:09 -06:00 (Migrated from github.com)

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.
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 commented 2014-09-02 13:40:02 -06:00 (Migrated from github.com)

@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
  1. 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 are you talking about [https://github.com/Grief-Code/OHSystem/issues/279](https://github.com/pvpgn/pvpgn-server/issues/316) 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 commented 2014-09-02 19:24:32 -06:00 (Migrated from github.com)

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?

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?
HarpyWar commented 2014-09-03 00:20:44 -06:00 (Migrated from github.com)

It allows use all commands with the same prefix and without a spamming public chat. And it just looks like a bot is not a hand-made stuff but a solid part of the server.
Also it allows change behavior for the command callback. Lobby commands does nothing by default, but we can send a message to user was slot opened/closed successfully or given wrong slot number in the command args. For instance, game counter output before a game /start can be implemented on PvPGN side - it looks better than the same info sended by a "user" (bot) - also as a solid part of the server.
Only in-game commands should be public like -latency(-lat).
Time and bandwidth are not really waste because these commands are used not so often.

Btw, the same way it is implemented on the iccup and I think that's a nice solution.

I think you should consult with @Grief-Code about integration because he should knows better how to do that. It will be ideally it he writes an abstract layer for this and then you can write the implementation. This is my opinion, but if you have an experience with GHost code may be you know everything for the implementation, without a help.

It allows use all commands with the same prefix and without a spamming public chat. And it just looks like a bot is not a hand-made stuff but a solid part of the server. Also it allows change behavior for the command callback. Lobby commands does nothing by default, but we can send a message to user was slot opened/closed successfully or given wrong slot number in the command args. For instance, game counter output before a game `/start` can be implemented on PvPGN side - it looks better than the same info sended by a "user" (bot) - also as a solid part of the server. Only in-game commands should be public like -latency(-lat). Time and bandwidth are not really waste because these commands are used not so often. Btw, the same way it is implemented on the iccup and I think that's a nice solution. I think you should consult with @Grief-Code about integration because he should knows better how to do that. It will be ideally it he writes an abstract layer for this and then you can write the implementation. This is my opinion, but if you have an experience with GHost code may be you know everything for the implementation, without a help.
ghost commented 2014-09-03 00:49:49 -06:00 (Migrated from github.com)

Hey.

Well I was totally busy the last days, and I dont have a lot of time.
To be able to run this and test, it would be nice to have a VPS where I could connect to and where the pvpgn is set up.
I can offer a vps but you should install the pvpgn in one folder and run it, i will install bot on another and connect through localhost.
I guess thats the best solution.

In 2 weeks I will have once again a lot of time to develope a lot of things, then i will mainly contribute into the relation between pvpgn & ghost.

Hey. Well I was totally busy the last days, and I dont have a lot of time. To be able to run this and test, it would be nice to have a VPS where I could connect to and where the pvpgn is set up. I can offer a vps but you should install the pvpgn in one folder and run it, i will install bot on another and connect through localhost. I guess thats the best solution. In 2 weeks I will have once again a lot of time to develope a lot of things, then i will mainly contribute into the relation between pvpgn & ghost.
HarpyWar commented 2014-09-03 01:04:47 -06:00 (Migrated from github.com)

Well, we can do that! Then I will finish PvPGN commands for GHost in coming days (it's mostly ready but still untested for real usage).
You can send a credentials for VPS on harpywar@gmail.com.

Well, we can do that! Then I will finish PvPGN commands for GHost in coming days (it's mostly ready but still untested for real usage). You can send a credentials for VPS on harpywar@gmail.com.
cen1 commented 2014-09-03 07:54:49 -06:00 (Migrated from github.com)

It should be possible to modify ghost to be able to host several lobbies at once. You basically connect to host with IP and port, player name is not involved anywhere, at least not from my initial research. If any of you know the obstacles for this, bring them up.

It should be possible to modify ghost to be able to host several lobbies at once. You basically connect to host with IP and port, player name is not involved anywhere, at least not from my initial research. If any of you know the obstacles for this, bring them up.
ghost commented 2014-09-03 08:11:09 -06:00 (Migrated from github.com)

I know that this is possible.
I applied it once to my bots, you could switch between lobbies also.

But I removed it after it created to many different issues. But thats not a reason to start once again on this idea in a greater way and association.
We could also create socket communications between the bots and on that way we can easily redirect people between bots. That would be actually possible, but a huge bunch of work.

As said, I will start into this in around 2 weeks.

I know that this is possible. I applied it once to my bots, you could switch between lobbies also. But I removed it after it created to many different issues. But thats not a reason to start once again on this idea in a greater way and association. We could also create socket communications between the bots and on that way we can easily redirect people between bots. That would be actually possible, but a huge bunch of work. As said, I will start into this in around 2 weeks.
Sign in to join this conversation.
No labels
bug
duplicate
enhancement
help wanted
in progress...
information
invalid
not enough info
priority high
priority low
priority normal
question
request
research
wontfix
No milestone
PvPGN 2.0
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Techwizz/pvpgn-server#35
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?