For the first time, it's also 3 minutes from starting to play to collecting a first coin, unless we get insane amount of players, then it would be 3 minutes to kill or die

Btw, in the updated clients, all hunters already display a "0" or "(0)", when the fork hits, this is the invulnerability counter that new hunters get when they spawn, it will tick up to 5 (5 blocks invulnerability for everyone) and then disappear.

Updated Windows builds of the legacy Qt client, and betterQt client in safemode:

these can be used for both mainnet and testnet (testnet server: addnode=178.62.17.234)

huntercoin-safemode-win32-20161112b.zip, 14.6 MB
https://mega.nz/#!HM13QKyR!-46vBHRMEmFLM9VNgKzhmnLQk4l_yQQvh9Cv6Su4yEM

The 2 clients are like a very old bitcoin client (v0.6) and a very new bitcoin client (v0.13). That's about the difference.

If you want a fast and easy way to sync Huntercore, use the pruned chain from
http://forum.huntercoin.org/index.php/topic,22255.msg26622.html#msg26622

You need 2 clients for this, old Huntercoin (with up-to-date blockchain), and Huntercore, connected. Then Huntercore would "download" the chain from old Huntercoin and store it in its own format.

The blockchain formats are like the difference between bitcoin 0.6 and bitcoin 0.13, you can sync the new one from scratch, or use the old one to sync the new one locally (even while offline), or just be stubborn and keep using the old one.

Snailbrain set up a node for testnet and we did a testing session last night which went very well.
The official testnet is now past fork height, by 2 coin ghosting periods

This also means game rules of the "timesave" fork will remain as they are, and the fork will happen
on mainnet in a few weeks. (the exact block height is not set yet)

Windows executables:
Theoretically can be used on mainnet too, at the user's own peril, Being able to sync mainnet without error was of course part of the tests.

huntercoin-testnettimesave-win32-20161026.zip, 28.0 MB

huntercore-testnettimesave-win32-20161026.zip, 21.0 MB (wallet only)

source:
https://github.com/wiggi/huntercore/tree/master-timesave5
https://github.com/wiggi/huntercoin/tree/master-timesave5



Timesave fork list of changes ("timesave" because it makes getting into and out of action go much faster)

Reduction of possible player spawn tiles, and reduction of possible bank tiles:

Banks can't spawn on all walkable tiles but only on coin harvest tiles 'c' and adjacent tiles '.'

Logout on bank tile in 1 block (i.e. you can't be on a bank tile and not logout)

Player spawn tiles work like banks, faster than pre-fork banks (2 blocks until logout)

New hunter cost 1 HUC (down from 5)

Destruct cost 1 HUC (down from 20)

Refundable cost of a hunter is halved to 100

Hunter invulnerability after spawn for 5 blocks (ends if waypoints set)
Hunters can also choose to stand still to become spectator

Spectators are invulnerable and also can't move, refund normally 15 blocks after becoming one.

Ghosting to break up attempts of domination (with "phasing in") :
- repeated every 500 blocks so that every "timezone" has one event per day,
  1 ghosting event will accumulate about 700 coins that are released for the hunters at once when it ends
- when ghosting is in effect, coins spawn normally, but can't get picked up and accumulate on map
- ghosting is visualized with semi-opaque coins (Qt client)

Ghosting schedule:
at block 300 out of full 500, every 4th coin spawn is ghosted (game continues normally but coins already accumulate)
at block 450 out of full 500, 3 out of 4 coin spawns are ghosted (2 out of 4 would look ugly graphically)
at block 480 out of full 500, full ghosting
at block 500, return to normal

Misc:

All banks reset at once when fork hits

If banking on player spawn strip, the Crown of Fortune will remain with this hunter

(Qt client) The number behind hunter names is the counter for spawn invulnerability

Counter for spawn invulnerability will remain at 0 during the last 10 blocks before ghosting ends, for newly spawned hunters.
(so they have more time to consider strategy before the new war begins)


Once the mainnet fork height is set, I'm sure we can write an actual "Player's Handbook" from this and GameLogicChanges.txt

This is the key point (or 1 of the 2 key points), time.

Everyone is still free to make 60, or 120 or more hunters, but if they show one weakness, like having an hunter attacked and not reacting properly, the prewarn time for the world of hurt that will come is now down to 4 minutes. Plus, the prewarn time for having that hunter attacked in the first place is now also down to 4 minutes.

Being able to play 24/7 is no longer an advantage, until now it was the decisive advantage, with the map being an abyss of time.

better wait until the game rule change is in effect, or you won't have much fun

final testnet in a box:
http://forum.huntercoin.org/index.php/topic,22265.msg30111.html#msg30111

I played with this for 1000 blocks after fork, and the new Huntercore node and the old Qt clients work well together. No bugs.

And, partial ghosting of coins is in:

By now they respawned, were picked up again, and have respawned a third time (and were picked up again). 5 zombies have harvested gems, one of them 2 times.

If you see a lemure that does nothing then it's not a bug, they can't cast without magicka.



It's 2 totally different parties

Yes, not infinite supply. They have been picked up on both gem spawnpoints now and will respawn at block 1402218 (I trust Tia'tha on this)

Dibs range is 5 tiles. Coming closer to the spawn while randomly shuffling around instantly gives the gem.

Looks like everything is running perfectly

It's ready for mainnet now. Newest github or Windows build from today (20160925, linked in github readme) is required.

Works with the same blockchain files as Huntercoin v1.3, but not Huntercore yet. Copy the gamestate file game_sv4.dat to the data folder (where game.dat already is).
And the blockchain must be equally or more up-to-date than the gamestate file (or it may crash)

For the anonymous zombie in the pic, I did "Receive coins"|"New Address", which happened to be "HSoxogPWFQCyApNzcQMQPCMV9c9FBDLWru".
Then I did:

sendtoaddress HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX 250 comment1 comment2 "GEM HSoxogPWFQCyApNzcQMQPCMV9c9FBDLWru"

to create the storage vault at this address.

and then sent 3023.60005501 HUC with the normal "Send coins" tab to HSoxogPWFQCyApNzcQMQPCMV9c9FBDLWru

3023.6000 is actually not a good order, 3025.8000 would make the zombie wait and teleport earlier.

Also there's no point in making lemures until at least 18..20 zombies exist and 1 or 2 are near the spawnpoint, because lemures have only 100 blocks before they must make their first kill.



The big 4-gems prize will spawn for the first time at block 1400976



edit: all stats are now in adventurers.txt, including how successfull a creature was during its lifetime

More like they can do a speedrun if in a group. Then players could just send them at the optimal time, but I want that it requires some strategic thinking to win.

I also thought that probably no one will play this because it's too much hassle to set up a vault when you first need to make a hunter and all.

Then there is this line in the console help:

What tag? Could it be... a transaction message? (it is) So I added another function that allows instant storage vault setup just with coins, no hunter. Readme will read as follows:


New: instant creation of storage vaults (20160923)
enabled on mainnet after block 1400000
======================================

(Cortez's test continues, first part was conversion of gems to coins at a fixed rate, see
https://bitcointalk.org/index.php?topic=435170.msg16312993#msg16312993)

After block 1400000, it will be possible to convert coins to gems at a fixed rate,
instantly, trustless, and with a single (atomic) transaction.

While Cortez's Huntercoin address (HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX) still belongs to the
same user (wiggi), it's also a game entity now, and can act independently
with no need of a specific node being online.


Example use (see also "help sendtoaddress" in the client's console window):

to send gems to the storage vault of "some_huntercoinaddress" (will be created it not already existing):
sendtoaddress HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX coin_amount comment1 comment2 "GEM some_huntercoinaddress"

to donate 1k coins worth of gems:
sendtoaddress HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX 1000.0 comment1 comment2 "GEM HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX"


Notes:
- the coin:gem rate is variable and taken from the in-game auction settlement
- standard fee of 0.02 gems for storage vault generation applies
- this function uses the "transaction comment", aka OP_RETURN
- in Huntercore client and daemon, sendtoaddress command is different.
  They probably can't be used for this right now.

- Each gem bought will result in -1 "immature gems from trade P/L" for Cortez, with a hard limit of -100
- the total amount of gems in existence will be unchanged (but short term spike of gems in circulation is possible)
- The adventurers inventory page (adventurers.txt) will state the available amount,
  recalculated for each block


Thats about it. We'll see if it really works on mainnet. But that's the way to do smart contracts in Huntercoin, by making a modded client. I'd have no problems to run several of them at the same time if my "accounts", perhaps addresses + a hunter in spectator mode for added functionality, will naturally show up in all of them and can interact with all of them.

Cortez's test (https://bitcointalk.org/index.php?topic=435170.msg16080926#msg16080926) is finished.
he had 2.78 gems + 0.11 immature gems (from trading profits) and requested settlement of 2.7 (at 1980 per piece = 5346)

The automatic process went like this:
liquidity fund grabbed 0.5 of his gems
auctioned off 2.2 (sold at 1260 = 2772)
liquidity fund auctioned off 2.0 of it's own coins for Cortez (sold at 1250 = 2500)
Cortez was paid a total of 5272 coins (remaining 74 is 74/1250=0,0592 gems, less than auction minimum of 0.1 gems, refunded 0.05 gems)
he still owns 0.08 + 0.11 + 0.05 = 0.24 gems

This is also the intended behavior, not perfect but it works.


I think these guys don't really like each other, and the map had a balancing problem: it was possible to spawn a group at "lemure spawnpoint #1"
shortly before the "new gem spawn" resets, this pretty much would always succeed.

So the rules are now updated (and a technical description in the readme)

"2 lemures, if in spell range, will pelt each other with a weak lightning attack for (1d8 - 1) damage per chronon." 


It will run together with the normal Huntercoin game in the client, and I think they won't step on each others toes.


There's a strong way and a weak way to enforce gamestate correctness.
The strong way is, when any code is changed, also to put more variables in the gamestate (to make an incompatible new version, currently it's the 4th version) and generate a new gamestate from scratch by replaying the blockchain. If done, everything must look exactly like with the previous version of course.
The weak way is a shelf-life for the client (Use it 1 block longer and it puts a big warning on the Huc:Gem auction page that doesn't go away, because the gamestate has missed data and is no longer correct)



It's usually 1 trade = 1 or 2 transactions.
And 1 creature = 1 tx. (for it's entire lifetime)

Relax, the blockchain is the same, and the coins are also the same.

Fortunately, the blockchain chat messages allow to store "extra data" in the blockchain that has no meaning for the coin.
(transaction messages would serve the same purpose)



You are mistaken about the "custom data to send" part. There is nothing to send.

Both standard clients and betterQt or any other hypothetical "non-standard" client receive standard huntercoin blocks and transactions, and only standard huntercoin blocks and transactions.

If the custom game players are composed by not 1, but 0 players, and the network consists of only standard clients, the custom game would continue normally (even if no one is there to watch, and physically the calculations are done only when a non-standard client catches up with the blockchain)

Please keep doing this. I usually reckon it's better to wait for questions than to write walls of text that no one would read...


Their hunters, yes of course. Would be really bad if you can't see them.


Correct.


Yes. I deliberately don't allow it, so that players with more time on their hands don't have an advantage.



It's not the status of a hunter.

Once, a hunter with this name and this player address (or reward address) acquired a gem (of a fraction of a gem). And because of this, his name address and gem amount was memorized forever, in the gamestate and implicitly in the blockchain.

Thus creating a game entity that is similar to a hunter, but different. It's indestructible (hence the name "storage vault") and more complex than a hunter (has more variables and can hold more information)

The line in the code box shows the status of one of these.

The coin amount gets translated into the initial stats of the creature (e.g. the second digit will set the position to one of the 9 available spawnpoints)

This spawn method (as opposed to, for example, a hunter transferring to the vault address and sending the msg "VAULT:spawn fire dragon, spawnpoint 4, spell range 7" etc), the 1 creature limit, the magic number, is just arbitrary, how I programmed it.

The storage vault system is very flexible. Nothing prevents a vault from playing 10 different games at the same time, having spawned dozens of characters. Well, someone must code these games, and block processing time sets a limit, but it's rather high.

I don't have one. What I meant was that forum readers can send me one of their Huntercoin addresses and I'll set it up to play the zombie vs lemures game right away.

The method to set it up yourself is

- get the betterQt client (link in OP)
- read the 2 readmes, start client in advanced mode
- make an hunter and visit the tile where Tia'tha the dark elf stands (currently on the right side of the map)
  (then the address is the one where the hunter was transferred to, see "Config.." button)
- alternatively, make an hunter, check out "auction.txt" and have the hunter buy some gems (at least 0.1 but feel free to load up, this would also complete this https://bitcointalk.org/index.php?topic=435170.msg16080926#msg16080926 test and really help)
  Then the address is also the one where the hunter is transferred to

Later (after block 1400000) in order to play the 3000+ HUCs have to be sent to this address. I.e. to yourself 

Design of the zombies vs lemures arena, normal obstacle map will be used.



It's almost finished. With 20 critters alive on testnet, it looks rather empty. (and given how stupid they are, interactions are rare)
I guess 50-75 would be a good balance for this small section of the map.

The critters will compete with hunters for the old gem spawn (0.86 gems per day) and they will compete among themselves for the new gew spawn (4.8 gems per day)

A new creature is always spawned if an address in the adventurers.txt list receives >3000 coins. These coins can be immediately recycled to spawn more creatures.
Amount must end with the magic number "5501" but other than that, any amount would result in a valid critter. (offspring and random mutations ahoy!)

this list has also some stats for the critters

Setting the eight numbers in the "order" column is all you can do for a creature. This is the point (to demonstrate how to kill all botting and farming with fire)

The hunters here can be long dead. And for the start on mainnet at block 1400000 I can set up any address so that it's ready to go, and no interaction with hunters in the normal Huntercoin game is needed.
Just send me PM with an address.

I'll also come up with a technical description of what all the numbers actually do

A technically accurat description of 90% of the current rules is in domob's GameLogicChanges.txt.

No, it's not a picture book for beginners.

Was meant literally. Huntercoin has done it already 4 time and changing game rules (as opposed to the basics of the coin itself) regularly is better than leave it in an unfinished state.

When you play a round of the game what are the 5 most simple things that would improve it the most? Everyone must be either perfectly happy with the current state or have such a wish list. I have one...


I always thought it was a darth something but it's not