[ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain

[bigminner]

>There are also too many faults of game map.

What faults are you talking about?

If you are a heavy user of this game, you can find it.   

[1714680256]

1714680256

[1714680256]

1714680256

[1714680256]

1714680256

[BayAreaCoins]

I dont think its limiting how well they can do, its making the game more interesting.  I have no idea how I would actually raid the middle, it would cost me alot and I would probably fail since I think they have it well defended.  Making them take more trips to the wallet would make it alot more fun in my opinion, cause at least the little guys would have a chance

Hum bug!

Now is the time to try/fail something with this since the market is so damn low

Its so low for a reason.  

150 on coin market cap! Thats horrible for the coolest coin out there.

This is going to be a top 10 coin.  

Honestly, I'm not even to worried about it.

Someone just needs to nut up and make a HunterRoad. Dropshipping/relisting all the major dark market top vendors + accept vendors (joking[ish])

Imagine how many players would be playing rofl. Crackheads/sick players everywhere!

[mikeyfinn]

Ok, so i set a couple of parameters in the domob bot files, put a total of 140 HUC in my game wallet, loaded up the mithrilman client, and then started mainGather. No errors in the cmd window and it shows in my wallet and the window 4 players created. However, it shows in the wallet 0 huc taken for the updates and only the cmd window shows the 4 players and their moves ("Already moving to center" it says for the 4 of them). they do NOT show up in the mithril player windows, so i dont actually see them. Gonna close the mithril client and open the qt i think to see what happens. Or should i do something else?

edit: Actually it looks like it did take 10 huc * 4 for the 4 players it says it created. They are not listed in my player window.

[BGB_HUC]

>There are also too many faults of game map.

What faults are you talking about?

Does the dev teams know about the faults? If they are items that are not listed/posted lets talk about them... The game needs more players and fixing faults surely won't hurt.

These are the major items I am aware of and I am pretty sure domob/snail are working on it, or they are aware:

1) Pruning
2) Destruct causing double spends (pendings)

Personally, the destruct problem is a big one for me and one reason I am holding out from playing right now (except for disasters and running experiments). Since I am a "casual" player based on the actual amount of time I have, I have to solely rely on bots to do the work. With the aggressive nature of the board right now, pendings are too prevalent and too costly when I can't watch the client all the time to fix the problem.

The only other annoying problem I have seen with the actual game board is that sometimes the path algorithm doesn't quite work and you get stuck at rocks or trees. This isn't a problem if you aren't using a bot that will issue new waypoints when they get stuck.

[mikeyfinn]

Ok, so i set a couple of parameters in the domob bot files, put a total of 140 HUC in my game wallet, loaded up the mithrilman client, and then started mainGather. No errors in the cmd window and it shows in my wallet and the window 4 players created. However, it shows in the wallet 0 huc taken for the updates and only the cmd window shows the 4 players and their moves ("Already moving to center" it says for the 4 of them). they do NOT show up in the mithril player windows, so i dont actually see them. Gonna close the mithril client and open the qt i think to see what happens. Or should i do something else?

edit: Actually it looks like it did take 10 huc * 4 for the 4 players it says it created. They are not listed in my player window.

OK, i searched for the player names, and i do seem to have 4 players, 1 of each color. I have no control, dont see them as my players, and have no idea what reward address they are using.

[bigminner]

>There are also too many faults of game map.

What faults are you talking about?

Does the dev teams know about the faults? If they are items that are not listed/posted lets talk about them... The game needs more players and fixing faults surely won't hurt.

These are the major items I am aware of and I am pretty sure domob/snail are working on it, or they are aware:

1) Pruning
2) Destruct causing double spends (pendings)

Personally, the destruct problem is a big one for me and one reason I am holding out from playing right now (except for disasters and running experiments). Since I am a "casual" player based on the actual amount of time I have, I have to solely rely on bots to do the work. With the aggressive nature of the board right now, pendings are too prevalent and too costly when I can't watch the client all the time to fix the problem.

The only other annoying problem I have seen with the actual game board is that sometimes the path algorithm doesn't quite work and you get stuck at rocks or trees. This isn't a problem if you aren't using a bot that will issue new waypoints when they get stuck.

The above is really most important problems, especially the second problem--"Destruct causing double spends" .  The key of adjusting game mechanism is keeping BALANCE among different sides.

[mikeyfinn]

Ok, so i set a couple of parameters in the domob bot files, put a total of 140 HUC in my game wallet, loaded up the mithrilman client, and then started mainGather. No errors in the cmd window and it shows in my wallet and the window 4 players created. However, it shows in the wallet 0 huc taken for the updates and only the cmd window shows the 4 players and their moves ("Already moving to center" it says for the 4 of them). they do NOT show up in the mithril player windows, so i dont actually see them. Gonna close the mithril client and open the qt i think to see what happens. Or should i do something else?

edit: Actually it looks like it did take 10 huc * 4 for the 4 players it says it created. They are not listed in my player window.

OK, i searched for the player names, and i do seem to have 4 players, 1 of each color. I have no control, dont see them as my players, and have no idea what reward address they are using.

I closed the mithrilman client. When huntercoind and the mithrilman exe stopped, so did the cmd window with mainGather. I then opened the regular, 11e wallet. I can see my origianl 3 guys AND my 4 new ones, 1 of each color, each with a path set. Next plan is to now close this and reopen the mithrilman client and see if i can see the new bot players there now. Also, they seemed to use the default reward address i have set, so that looks good too.

After reopening the mithrilman client the guys are there now. I assume, however, that the closing of the mainGather window means the new guys will just go to the spots and stop.

question: if i wanted to create say 4 of each color, moving together, for a total of 16 players, all right at the new disaster, i'd add and/or remove lines from mainRunner.py addGatherer?

update: i haven't tried adding more than 1 guy/color yet, but other than that it seems to be working with the mirthrilman client, other than on 1st create. I'll see in the morning if any new players were created and if so whether or not they are viewable right in the client, or do i again have to go to the qt to "register" then back to mithrilman. we'll see.....

[domob]

Regarding some of the latest questions about my library:  Currently, it is not supported to set the reward address (i. e., rewards will go to your player address unless you manually change the reward address while the bot library is not running and then restart it).  This is simply because I didn't yet bother to implement it, since it seemed not too high priority.  It should be easy to add, and if you believe it is a useful feature, I'll think about how to do it best.

Apart from that, you have already noticed how things are:  The MithrilMan client updates the list of players only on startup (and, I think, when you manually click "refresh" - at least in a newer version), so it won't notice your players.  But they should be there and should be fine.  You may also try to control them while the bot framework is running, but in that case it *may* crash (happens when you issued a pending move and the bot framework also wants to move them before your move is confirmed).  This is something that can also be "fixed" in case it is useful to you.  It actually may well be.  Let me know.

If you close the window:  Yes, as you presume, it will stop controlling the hunters.  They will just finish their current move and then stop.  If you restart the script, it should continue where it left off - depending on whether or not you delete the "gather.state" file, it will either continue exactly where it was (if you leave the file) or start fresh but make use of the hunters that are already in your wallet (if you delete it).  The latter should be done if you changed the parameters.

Finally about the disaster runners:  Yes, exactly.  Just add more of these "addGatherer" lines and then fire up "mainRunner.py".

[mikeyfinn]

Regarding some of the latest questions about my library:  Currently, it is not supported to set the reward address (i. e., rewards will go to your player address unless you manually change the reward address while the bot library is not running and then restart it).  This is simply because I didn't yet bother to implement it, since it seemed not too high priority.  It should be easy to add, and if you believe it is a useful feature, I'll think about how to do it best.

Apart from that, you have already noticed how things are:  The MithrilMan client updates the list of players only on startup (and, I think, when you manually click "refresh" - at least in a newer version), so it won't notice your players.  But they should be there and should be fine.  You may also try to control them while the bot framework is running, but in that case it *may* crash (happens when you issued a pending move and the bot framework also wants to move them before your move is confirmed).  This is something that can also be "fixed" in case it is useful to you.  It actually may well be.  Let me know.

If you close the window:  Yes, as you presume, it will stop controlling the hunters.  They will just finish their current move and then stop.  If you restart the script, it should continue where it left off - depending on whether or not you delete the "gather.state" file, it will either continue exactly where it was (if you leave the file) or start fresh but make use of the hunters that are already in your wallet (if you delete it).  The latter should be done if you changed the parameters.

Finally about the disaster runners:  Yes, exactly.  Just add more of these "addGatherer" lines and then fire up "mainRunner.py".

This morning finds all seemingly going well. One of my bot guys was killed, but another of the same color was made to take his place. However, naturally, I cant see this new guy. I closed mithrilman client, waited for it to finish up, reopened it, and the new player still didnt show, so I had to open the qt wallet, close it, then reopen mithrilman to get access.

Another question: Let's say the programs are running with 1 player of each color. I want to change the spot used for one of the guys to gather at. Do I simply close the gather program, change the specs in the py file and kill gather.state then restart it?

[mikeyfinn]

Hmmm..... it seems that i can't see the new yellow guy created automatically after a yellow death. It seems to be following it's normal bot moves, but it's not listed in my player window in either the mithrilman client or the qt.

edit: now, at like the 3rd - 5th move, the yellow guy appeared in my mithrilman window. woohoo!!

[domob]

Another question: Let's say the programs are running with 1 player of each color. I want to change the spot used for one of the guys to gather at. Do I simply close the gather program, change the specs in the py file and kill gather.state then restart it?

As long as there are no pending player creations (name_new without the name_firstupdate yet), you should be more or less fine to kill the process, delete the gather.state file, change the parameters and restart.  The bot will then reassign players to the defined gatherers, but it will take colours into account.  If you have, for instance, two blue gatherers (hunters in the wallet), then it may happen that they swap places and waste some time going to the other's spot in the process.  But if you don't mind this and/or only have one of each colour, then it should be perfectly fine to restart including removing the .state file.

[mikeyfinn]

Another question: Let's say the programs are running with 1 player of each color. I want to change the spot used for one of the guys to gather at. Do I simply close the gather program, change the specs in the py file and kill gather.state then restart it?

As long as there are no pending player creations (name_new without the name_firstupdate yet), you should be more or less fine to kill the process, delete the gather.state file, change the parameters and restart.  The bot will then reassign players to the defined gatherers, but it will take colours into account.  If you have, for instance, two blue gatherers (hunters in the wallet), then it may happen that they swap places and waste some time going to the other's spot in the process.  But if you don't mind this and/or only have one of each colour, then it should be perfectly fine to restart including removing the .state file.

Great! So now I have some gatherers out and runners set up. I wish I knew code, I'd add next the defense/guard bot and save you some trouble. I actually started trying to learn python once....

[mikeyfinn]

Another question: Let's say the programs are running with 1 player of each color. I want to change the spot used for one of the guys to gather at. Do I simply close the gather program, change the specs in the py file and kill gather.state then restart it?

As long as there are no pending player creations (name_new without the name_firstupdate yet), you should be more or less fine to kill the process, delete the gather.state file, change the parameters and restart.  The bot will then reassign players to the defined gatherers, but it will take colours into account.  If you have, for instance, two blue gatherers (hunters in the wallet), then it may happen that they swap places and waste some time going to the other's spot in the process.  But if you don't mind this and/or only have one of each colour, then it should be perfectly fine to restart including removing the .state file.

Great! So now I have some gatherers out and runners set up. I wish I knew code, I'd add next the defense/guard bot and save you some trouble. I actually started trying to learn python once....

One of my players was killed. A replacement was made and sent to replace him and it did show up in my player window once it became active. Very nice. Mithrilman client + domob bot == WOOHOO!!! 

[MithrilMan]

as pointed out by domob, last mithril edition client version has a button to force refresh player list, you can use it in case like the one you are facing (or when someone transfer a player to you)

read up http://www.mithrilman.com/Huntercoin/News/9 "Refresh Players List"

[redbeans2012]

So noone thinks limiting how many coins a player can hold is a good idea?  I'm not a gamer, but when I used to be there was always a limit before I had to deposit in the "bank". 

oh well just throwing out my thoughts. 

[BGB_HUC]

So noone thinks limiting how many coins a player can hold is a good idea?  I'm not a gamer, but when I used to be there was always a limit before I had to deposit in the "bank". 

oh well just throwing out my thoughts. 

This wouldn't be at the top of my list, but I see your points . To continue the discussion, what kind of limit are you thinking? 50, 100, 500, 1000?

[redbeans2012]

So noone thinks limiting how many coins a player can hold is a good idea?  I'm not a gamer, but when I used to be there was always a limit before I had to deposit in the "bank". 

oh well just throwing out my thoughts. 

This wouldn't be at the top of my list, but I see your points . To continue the discussion, what kind of limit are you thinking? 50, 100, 500, 1000?

I was thinking around 100.  Make the big guys in the middle come back to the wallet more often.  Give others a chance to steal their coins more often.  I think it could balance things a bit more. 

I realize its not top priority, but maybe something to talk about more once other bugs etc are sorted out.

[mikeyfinn]

Another domob bot question:

I set up runners, but i left the default of 10 threshold. If i change that, can i just delete runner.state, change the mainRunner.py threshold from 10 to whatever i want, then restart mainRunner and that will just adjust the threshold for the reserve guys? I wouldnt want them to start after a disaster and go back to cash in with only 10 coins. That seems like a time to stock up.... "I don't want it to create a whole new set of runners, i just want it to change the threshold on the existing reserve guys.

[bigminner]

So noone thinks limiting how many coins a player can hold is a good idea?  I'm not a gamer, but when I used to be there was always a limit before I had to deposit in the "bank". 

oh well just throwing out my thoughts. 

This wouldn't be at the top of my list, but I see your points . To continue the discussion, what kind of limit are you thinking? 50, 100, 500, 1000?

I was thinking around 100.  Make the big guys in the middle come back to the wallet more often.  Give others a chance to steal their coins more often.  I think it could balance things a bit more. 

I realize its not top priority, but maybe something to talk about more once other bugs etc are sorted out.

You are right. Although the modification is very easy, but the dev team can not see it's importance. The bot lib is important, but it is not necessary and urgent. The pruning is also not urgent. But the problem of double spending of wallet is very very urgent to be processed. They work hard here and there, but not hit the key problem.

[BayAreaCoins]

So noone thinks limiting how many coins a player can hold is a good idea?  I'm not a gamer, but when I used to be there was always a limit before I had to deposit in the "bank".  

oh well just throwing out my thoughts.  

This wouldn't be at the top of my list, but I see your points . To continue the discussion, what kind of limit are you thinking? 50, 100, 500, 1000?

I was thinking around 100.  Make the big guys in the middle come back to the wallet more often.  Give others a chance to steal their coins more often.  I think it could balance things a bit more.  

I realize its not top priority, but maybe something to talk about more once other bugs etc are sorted out.

You are right. Although the modification is very easy, but the dev team can not see it's importance. The bot lib is important, but it is not necessary and urgent. The pruning is also not urgent. But the problem of double spending of wallet is very very urgent to be processed. They work hard here and there, but not hit the key problem.

You don't need the dev team to stop being a vagina and attack the middle... The way I see it, the middle dudes are pretty much giving away free coins!

Embrace it!