Author Topic: BGB Qt Client Post Disaster  (Read 21251 times)

BGB

  • Global Moderator
  • Full Member
  • *****
  • Posts: 226
    • View Profile
BGB Qt Client Post Disaster
« on: July 10, 2014, 01:59:44 PM »
Github has been updated with changes. I was going to wait and let my client run over the weekend, but figured if there were some brave souls out there that wanted to start with it, then I might as well put it out.   https://github.com/BGBHUC/huntercoin 

Compiled exe is here: http://www.huntercoin.info/huntercoin-qt-bgb.zip

I also started putting some info on the website for this, but I only have a few minutes left today.

The Windows PC I was doing the easywinbuilder on before is out of commission right now, so I was not able to see if that process still worked.

I am testing a few bots with this client. There is at least one BGB_Test player in each colors coin area closest to the spawn. Just in case you wanted to watch some of their behaviors. This is the configuration file I am using with them.

startBlock=0
debug=1
enabled=1
mode=GATHER
maxLoot=200000000
maxMaxLoot=200000000
startDelay=60
maxLootDistanceAtDest=3
maxLootDistanceInRoute=3
transfer=
maxMoves=5
maxBorn=1
maxCreate=1
createOnBlock=1
minCreateBalance=2000000000
stickToDest=0

desty=BGB_Test 75,68
desty=BGB_Test2 77,69
destb=BGB_Test3 73,432
destb=BGB_Test7 73,432
destg=BGB_Test4 428,431
destg=BGB_Test8 428,431
destr=BGB_Test5 427,67
destr=BGB_Test6 427,67


The general purpose of this "GATHER" bot is to send player(s) to a destination coordinate, pick up loot, and then return back to the spawn area. Then rinse and repeat.

On the web for more information and help building a config file: http://www.huntercoin.info/bgbBotClient

If you feel the urge to donate some HUC because this works well for you, please send it to the general HUC development fund or to SnailBrain.

  • Multiple colors in same wallet via the dest(r|g|y|b) paramter
  • Use customized names as part of the 'dest' parameter
  • Game map coordinates displayed on map view helping to get 'dest' coordinates
  • Bots will search for coins near destination
  • Assume manual control immediately over all bots (enbled=0)
  • Config loaded every block
  • Bots will look for empty tiles near their destination
  • Bots will seek loot while in route to destination
  • Can transfer players to wallet using transfer parameter
  • Bots know what each others loot targets are in same client
  • Pending name_update after 20 blocks are automatically deleted
  • Can set minimum wallet balance for bot creation via parameter
  • Can limit the amount of times a player is created (maxBorn parameter)
  • While using 'maxMoves' parameter, players in spawn will still get a priority move
  • Framework in place to use multiple waypoints
  • Bots stick to an area within destination instead of exact destination (configurable)
  • Can change maxLoot realtime and bots in route to spawn will continue to spawn
  • Two maxLoot parameters to be able to pick up as much loot as possible
  • Shortest spawn calculation and random spawn location return
  • Verify dest coords in config before creating player
  • Assume manual control over individual bots by commenting out dest
  • Add and remove bots on the fly in config without client restart

« Last Edit: July 11, 2014, 08:08:04 PM by BGB »

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: BGB Qt Client Post Disaster
« Reply #1 on: July 12, 2014, 12:10:50 AM »
i've compiled and ready to test.

Is there a way (think you said earlier)

to use some wild cards for the players, or it always/only create the players specified in the config file?

e.g. what if someone else create player with same name (unlikely, but maybe someone will do to screw things up -- maybe is ok for now though)


--

eventually/end game...it would be good to be able to select hunters in QT, enable "Gather Mode", select radius, press go.
maybe someone who can do QT code can add to the qt (zyon/domob), along with config creator or realtime confg creator (without closing client). Maybe it reads settings from client every few blocks, or whenever you click "re-read config file" (apply button).

just noticed it checks config file every so often.. i.e. i changed conf file and it auto updated inside qt without closing it down

Also auto attack if zyon still working on it, would be some icing on the cake.

<3

will let you know how it goes.

--

« Last Edit: July 12, 2014, 01:47:35 AM by Snailbrain »

zy0n

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
    • GithubHUCRepo
Re: BGB Qt Client Post Disaster
« Reply #2 on: July 12, 2014, 12:19:32 AM »
i've compiled and ready to test.

Is there a way (think you said earlier)

to use some wild cards for the players, or it always/only create the players specified in the config file?

e.g. what if someone else create player with same name (unlikely, but maybe someone will do to screw things up -- maybe is ok for now though)


--

eventually/end game...it would be good to be able to select hunters in QT, enable "Gather Mode", select radius, press go.
maybe someone who can do QT stuff can add to the qt (zyon/domob), along with config creator or realtime confg creator (without closing client). Maybe it reads settings from client every few blocks, or whenever you click "re-read config file" (apply button).

Also auto attack if zyon still working on it, would be some icing on the cake.

<3

will let you know how it goes.

--

I actually have the auto-attack done. It's on my other workstation at my friends, I just didn't publish the branch. The only thing I need to do is modify it so that you can't auto-attack if you're moving.

As for gather mode and other auto-mated features i've already built a proper system for that with the auto-destruct :)
so those aren't too far off, I spoke with domob about them a few times
« Last Edit: July 12, 2014, 12:21:19 AM by zy0n »
HUC: HJHB5CLKStCfZjWxEcXsoMT4dEL7oNSP6k

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: BGB Qt Client Post Disaster
« Reply #3 on: July 12, 2014, 12:55:49 AM »
i've compiled and ready to test.

Is there a way (think you said earlier)

to use some wild cards for the players, or it always/only create the players specified in the config file?

e.g. what if someone else create player with same name (unlikely, but maybe someone will do to screw things up -- maybe is ok for now though)


--

eventually/end game...it would be good to be able to select hunters in QT, enable "Gather Mode", select radius, press go.
maybe someone who can do QT stuff can add to the qt (zyon/domob), along with config creator or realtime confg creator (without closing client). Maybe it reads settings from client every few blocks, or whenever you click "re-read config file" (apply button).

Also auto attack if zyon still working on it, would be some icing on the cake.

<3

will let you know how it goes.

--

I actually have the auto-attack done. It's on my other workstation at my friends, I just didn't publish the branch. The only thing I need to do is modify it so that you can't auto-attack if you're moving.

As for gather mode and other auto-mated features i've already built a proper system for that with the auto-destruct :)
so those aren't too far off, I spoke with domob about them a few times

i'm using bgb client now.. has extra info in also that i noticed.

I really like it, and seems to be working flawlessly atm.

autodestruct while moving could be optional?


Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: BGB Qt Client Post Disaster
« Reply #4 on: July 12, 2014, 01:47:23 AM »
just noticed it checks config file every so often.. i.e. i changed conf file and it auto updated inside qt without closing it down

BGB

  • Global Moderator
  • Full Member
  • *****
  • Posts: 226
    • View Profile
'
« Reply #5 on: July 12, 2014, 02:54:52 AM »
to use some wild cards for the players, or it always/only create the players specified in the config file?

e.g. what if someone else create player with same name (unlikely, but maybe someone will do to screw things up -- maybe is ok for now though)

The code does check for name conflicts, of course it couldn't be created anyway by the client. It will report this problem in the debug.log. Also it will check the dest coords to make sure they are valid before creating the name so you don't lose coins in the spawn area if the player can't move to them.

eventually/end game...it would be good to be able to select hunters in QT, enable "Gather Mode", select radius, press go.
maybe someone who can do QT code can add to the qt (zyon/domob), along with config creator or realtime confg creator (without closing client). Maybe it reads settings from client every few blocks, or whenever you click "re-read config file" (apply button).

just noticed it checks config file every so often.. i.e. i changed conf file and it auto updated inside qt without closing it down

Also auto attack if zyon still working on it, would be some icing on the cake.

The client does read the config file before processing every block. This allows you to add/remove and comment out (#) players in order to take manual control if need be. Also you can change the parameters such as maxLoot on the fly etc... Characters already going home will continue to go to spawn and not accept the maxLoot until leaving the spawn area.

It would be cool to have this built into the GUI but its not really my thing. Zyon or Mithral are much better suited to tackle this especially with this project being the first time I have ever seen a line of CPP or QT. I am open to any constructive criticism since I am new to this. Of course I have quite a bit of functionality regarding attacking, guarding, hunting, recycling, etc... that aren't exposed here. Most of them are built into behavior methods that can be chained together much like what Mithral is looking to do. Obviously for the coin sake it would be good if I started to share those with the open source client, but they are all setup via the config file which of course causes it to get more complicated. I  would think 'John Q' public isn't comfortable with using a config file even with a 'config tool' on the web, which I hope to do for this.

zy0n

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
    • GithubHUCRepo
Re: '
« Reply #6 on: July 12, 2014, 04:09:52 AM »
to use some wild cards for the players, or it always/only create the players specified in the config file?

e.g. what if someone else create player with same name (unlikely, but maybe someone will do to screw things up -- maybe is ok for now though)

The code does check for name conflicts, of course it couldn't be created anyway by the client. It will report this problem in the debug.log. Also it will check the dest coords to make sure they are valid before creating the name so you don't lose coins in the spawn area if the player can't move to them.

eventually/end game...it would be good to be able to select hunters in QT, enable "Gather Mode", select radius, press go.
maybe someone who can do QT code can add to the qt (zyon/domob), along with config creator or realtime confg creator (without closing client). Maybe it reads settings from client every few blocks, or whenever you click "re-read config file" (apply button).

just noticed it checks config file every so often.. i.e. i changed conf file and it auto updated inside qt without closing it down

Also auto attack if zyon still working on it, would be some icing on the cake.

The client does read the config file before processing every block. This allows you to add/remove and comment out (#) players in order to take manual control if need be. Also you can change the parameters such as maxLoot on the fly etc... Characters already going home will continue to go to spawn and not accept the maxLoot until leaving the spawn area.

It would be cool to have this built into the GUI but its not really my thing. Zyon or Mithral are much better suited to tackle this especially with this project being the first time I have ever seen a line of CPP or QT. I am open to any constructive criticism since I am new to this. Of course I have quite a bit of functionality regarding attacking, guarding, hunting, recycling, etc... that aren't exposed here. Most of them are built into behavior methods that can be chained together much like what Mithral is looking to do. Obviously for the coin sake it would be good if I started to share those with the open source client, but they are all setup via the config file which of course causes it to get more complicated. I  would think 'John Q' public isn't comfortable with using a config file even with a 'config tool' on the web, which I hope to do for this.

I'm working on my botting-qt addition right now.
I have some plans for the config feature aswell
But if you could share some of your functionality with me so I can incorporate it into what I'm trying to accomplish?? Pretty pl0x :P
HUC: HJHB5CLKStCfZjWxEcXsoMT4dEL7oNSP6k

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: '
« Reply #7 on: July 12, 2014, 04:24:53 AM »
to use some wild cards for the players, or it always/only create the players specified in the config file?

e.g. what if someone else create player with same name (unlikely, but maybe someone will do to screw things up -- maybe is ok for now though)

The code does check for name conflicts, of course it couldn't be created anyway by the client. It will report this problem in the debug.log. Also it will check the dest coords to make sure they are valid before creating the name so you don't lose coins in the spawn area if the player can't move to them.

eventually/end game...it would be good to be able to select hunters in QT, enable "Gather Mode", select radius, press go.
maybe someone who can do QT code can add to the qt (zyon/domob), along with config creator or realtime confg creator (without closing client). Maybe it reads settings from client every few blocks, or whenever you click "re-read config file" (apply button).

just noticed it checks config file every so often.. i.e. i changed conf file and it auto updated inside qt without closing it down

Also auto attack if zyon still working on it, would be some icing on the cake.

The client does read the config file before processing every block. This allows you to add/remove and comment out (#) players in order to take manual control if need be. Also you can change the parameters such as maxLoot on the fly etc... Characters already going home will continue to go to spawn and not accept the maxLoot until leaving the spawn area.

It would be cool to have this built into the GUI but its not really my thing. Zyon or Mithral are much better suited to tackle this especially with this project being the first time I have ever seen a line of CPP or QT. I am open to any constructive criticism since I am new to this. Of course I have quite a bit of functionality regarding attacking, guarding, hunting, recycling, etc... that aren't exposed here. Most of them are built into behavior methods that can be chained together much like what Mithral is looking to do. Obviously for the coin sake it would be good if I started to share those with the open source client, but they are all setup via the config file which of course causes it to get more complicated. I  would think 'John Q' public isn't comfortable with using a config file even with a 'config tool' on the web, which I hope to do for this.

Well, you have done insanely well :D

I think Mithrilman doesn't know QT, but i know he will eventually add bots etc to his own interface.
Maybe Zy0n can do or domob if he gets time.

I like your attitude to donations - but If we can get some of this stuff into the official QT - Gather, Auto Attack (still wondering about instant network enforced, might make it remove some luck/randomness [is that bad or good]) and Alarms - then humans can compete - I think we could add some decent bounty from the huntercoin development fund, and it will take a lot of the work load off domob.

I can see how the hardfork has made it much harder for the bots. Before hand with this (and no one attacking) it must have been much easier.
I think probably still possible to dominate until some sort of  attack/guard afk things are added.

@zy0n, will you make public?

I believe it will be very positive for the project. We (the community) need to experience, use, understand and adapt so that we can improve and have a stable fair Huntercoin. The whole point of the game is to distribute the coins fairly.
Of course, if you have some advanced bots which fake joust or use some complex tricks I wouldn't expect these to be released (for free or until you upgrade them :))
« Last Edit: July 12, 2014, 04:34:11 AM by Snailbrain »

Snailbrain

  • Developer
  • Hero Member
  • *****
  • Posts: 1001
    • View Profile
Re: BGB Qt Client Post Disaster
« Reply #8 on: July 12, 2014, 04:36:49 AM »
One thing i noticed, but probably will be more difficult.

If there are several coins on the ground, it will do 1tx for each coin.

It would be better if it could plot a route with waypoints through the coins. not sure how difficult for you to do.

This would reduce number of tx in the chain (and obviously pick-up coins faster for the player). But, maybe more complex if someone else picks up one of the coins (maybe could be ignore or recheck).

zy0n

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
    • GithubHUCRepo
Re: '
« Reply #9 on: July 12, 2014, 04:56:23 AM »
to use some wild cards for the players, or it always/only create the players specified in the config file?

e.g. what if someone else create player with same name (unlikely, but maybe someone will do to screw things up -- maybe is ok for now though)

The code does check for name conflicts, of course it couldn't be created anyway by the client. It will report this problem in the debug.log. Also it will check the dest coords to make sure they are valid before creating the name so you don't lose coins in the spawn area if the player can't move to them.

eventually/end game...it would be good to be able to select hunters in QT, enable "Gather Mode", select radius, press go.
maybe someone who can do QT code can add to the qt (zyon/domob), along with config creator or realtime confg creator (without closing client). Maybe it reads settings from client every few blocks, or whenever you click "re-read config file" (apply button).

just noticed it checks config file every so often.. i.e. i changed conf file and it auto updated inside qt without closing it down

Also auto attack if zyon still working on it, would be some icing on the cake.

The client does read the config file before processing every block. This allows you to add/remove and comment out (#) players in order to take manual control if need be. Also you can change the parameters such as maxLoot on the fly etc... Characters already going home will continue to go to spawn and not accept the maxLoot until leaving the spawn area.

It would be cool to have this built into the GUI but its not really my thing. Zyon or Mithral are much better suited to tackle this especially with this project being the first time I have ever seen a line of CPP or QT. I am open to any constructive criticism since I am new to this. Of course I have quite a bit of functionality regarding attacking, guarding, hunting, recycling, etc... that aren't exposed here. Most of them are built into behavior methods that can be chained together much like what Mithral is looking to do. Obviously for the coin sake it would be good if I started to share those with the open source client, but they are all setup via the config file which of course causes it to get more complicated. I  would think 'John Q' public isn't comfortable with using a config file even with a 'config tool' on the web, which I hope to do for this.

Well, you have done insanely well :D

I think Mithrilman doesn't know QT, but i know he will eventually add bots etc to his own interface.
Maybe Zy0n can do or domob if he gets time.

I like your attitude to donations - but If we can get some of this stuff into the official QT - Gather, Auto Attack (still wondering about instant network enforced, might make it remove some luck/randomness [is that bad or good]) and Alarms - then humans can compete - I think we could add some decent bounty from the huntercoin development fund, and it will take a lot of the work load off domob.

I can see how the hardfork has made it much harder for the bots. Before hand with this (and no one attacking) it must have been much easier.
I think probably still possible to dominate until some sort of  attack/guard afk things are added.

@zy0n, will you make public?

I believe it will be very positive for the project. We (the community) need to experience, use, understand and adapt so that we can improve and have a stable fair Huntercoin. The whole point of the game is to distribute the coins fairly.
Of course, if you have some advanced bots which fake joust or use some complex tricks I wouldn't expect these to be released (for free or until you upgrade them :))

Of course I plan to make it public, the community is who I do this for!! :)
HUC: HJHB5CLKStCfZjWxEcXsoMT4dEL7oNSP6k

BGB

  • Global Moderator
  • Full Member
  • *****
  • Posts: 226
    • View Profile
Re: BGB Qt Client Post Disaster
« Reply #10 on: July 12, 2014, 07:58:26 AM »
One thing i noticed, but probably will be more difficult.

If there are several coins on the ground, it will do 1tx for each coin.

It would be better if it could plot a route with waypoints through the coins. not sure how difficult for you to do.

This would reduce number of tx in the chain (and obviously pick-up coins faster for the player). But, maybe more complex if someone else picks up one of the coins (maybe could be ignore or recheck).

I have this capabity in my version, but I am still experimenting with it. The public version does support multiple waypoints, it's just not calculating them yet. When I am a little happier with how they work I will add it. 

edit: One thing that I think will make more sense with the multi waypoints (and make the bots more efficient) is to reverse the way 'targets' are obtained. Right now the bots look for the closest coin. This works okay if you use a good combination of max distance settings and keep the destinations apart.  However, it should really be the coin looks for the closest bot. Then if two coins find the same bot, then the multi waypoints are constructed. I have it all worked out in my head, I just need to sit down and type it out.

Thanks to Zyon for the multi point construction since I just copied his append waypoints block for this.
« Last Edit: July 12, 2014, 01:15:21 PM by BGB »

Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: BGB Qt Client Post Disaster
« Reply #11 on: July 12, 2014, 05:29:15 PM »
edit: One thing that I think will make more sense with the multi waypoints (and make the bots more efficient) is to reverse the way 'targets' are obtained. Right now the bots look for the closest coin. This works okay if you use a good combination of max distance settings and keep the destinations apart.  However, it should really be the coin looks for the closest bot. Then if two coins find the same bot, then the multi waypoints are constructed. I have it all worked out in my head, I just need to sit down and type it out.

yes, could work, but this way it didn't consider loot value
sometimes is better to loose a coin near me but rush to another that has more value
as soon as i finish some other things for the client, i'll go deeply into bot system, and i think that one the first bot i'll try to assemble would be, except the easier hearthseeker, the gathering bot
but i'd like to test something more advanced that involve the loot value and i'm not yet sure about how to do that.

maybe taking advantage of the A* alghoritm i can build a little map of the coin area near the bot, setting different coefficient about the single cells, less the value higher the cost to travel over that  cell, so as a destination point i could set nearest coin and see how the path is constructed
not sure if this will work

then another problem would be taking into account near foreing hunters, that could grab a coin before me, etc...
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

BGB

  • Global Moderator
  • Full Member
  • *****
  • Posts: 226
    • View Profile
Re: BGB Qt Client Post Disaster
« Reply #12 on: July 12, 2014, 06:05:00 PM »
.... And once the coin areas get swamped again with stacking, coin searching doesn't apply. And when there are a bunch of bots in the coin areas, you could probably only search one move away, then be prepared to split the value. So I am not sure how much value sinking a lot of time into a coin area algorithm is worth. Except for right after each disaster. Nonetheless it is interesting to think about.

Mithril Man

  • Hero Member
  • *****
  • Posts: 589
    • View Profile
    • Mithril Man Web!
Re: BGB Qt Client Post Disaster
« Reply #13 on: July 12, 2014, 06:24:46 PM »
So I am not sure how much value sinking a lot of time into a coin area algorithm is worth. Except for right after each disaster. Nonetheless it is interesting to think

well, this alghoritm could be used even as aggressive behaviour, you blowup and then gather, and chosing which one to gather and the path to take, has meaning
Alternative GUI client for Huntercoin http://www.mithrilman.com
HUC donation: HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE
BTC donation: 1DKLf1QKAZ5njucq37pZhMRG67qXDP3vPC

BGB

  • Global Moderator
  • Full Member
  • *****
  • Posts: 226
    • View Profile
Re: BGB Qt Client Post Disaster
« Reply #14 on: July 12, 2014, 07:02:24 PM »
... And the gather bots see the attack coming and either defend or just leave... :)

This is why this game being so simple is yet complicated as we could go round and round...