Topic: [ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain - page 150. (Read 879551 times)

Note that the 10-HUC treshold does not apply to the "first" run - on the first run, hunters collect until no more coins are visible in range around their centre.  They only go back when they have both 10 HUC and no more coins are immediately lying around.  Maybe this resolves your question already.  Apart from that, I have to admit that I think it is not easily possible right now to change the configuration of the runner guys - since they are currently in registration, you would lose the name_new coins if you delete the runner.state file.

One solution is to remember the name/rand/txid values (found in the runner debug output) and then restart the process.  It will create new reserve players (costs you HUC again), but with your rand/txid values, you can always manually activate the others and make use of them in normal play (or for the gatherers, for instance).

redbeans2012 got a great idea. I believe that would be appropriate.

haha nah I'm going to be the one spawn killing once I can play within 5 minutes with a bot!

I just understand the markets right now and paper wallets.

I can't even get HUC to sync personally

Well I guess I found out one of the people in the middle. 

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!

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.

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.

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.

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?

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. 

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"

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!!! 

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

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.

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!!

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?

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".

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

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.

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.