yes it does, and the reason is not 30s or 60s blocks, but the map layout. It could have been a bunch of small villages
with safe inns to park your hunter and connected with teleportation links. This is technically trivial but after tiring discussions
the layout is as it is. (Btw, that's exactly what I meant with the "let them human miners suffer" mindset which does Huntercoin no good)



There's a testnet where you can learn the rules, it's free to use and CPU minable.

There are advanced clients that can defend your character even if you're not looking, even against sapi, even free to use.

It wasn't an army, it was a single character that killed a clueless noob.

Huntercoin map is not a mine, it's a no holds barred pvp killing field, and this is one of its redeeming features   

Disclaimer: I never used a char named sapi

Given the habit of f2p to always use the same address for their coinbase tx, the pool went down completely several times and Huntercoin can usually muster ~20% of its scrypt hashrate and recuperate to 2 minutes between blocks without f2pool. Which is quite a feat actually.

Voting would be just expressing an opinion, without formal power of enforcement, but still very useful.

I'm playing with an implementation: if you could link
- a number that is the vote
- opening and closing blockheight for the voting
- optionally an hunter
- optionally a comment
- proof of ownership (of coins and 1 address)
then everyone can call for votes by putting the topic in the comment, using a new closing blockheight, and casting the first vote.
This is rather straightforward and could be ready to try on mainnet in a few days.

The spam limiting factor is mostly the total number of available coins, so a call for votes can be free of charge, just asking (and competing) for attention.

Somehow this word has a negative sound to it. Pro gamer could be your favorite occupation, human miner/human guinea pig/human whatever probably not.
The description should confer the meaning that the game is the mining process as opposed to distribution of premined coins,
but humans play games, computers mine coins.

There's a mindset attached to the human mining notion, basically that the disutility of the miner's "work" gives value to the coins.
This is of course not true, and I guess everyone will deny thinking like this. Perhaps it's a semi unconscious thing.


But the risk is the only thing that can prevent everyone from spawning masses of dumb bots.
Playing Huntercoin is not gambling because of the (really huge in % terms) positive expectancy.

All Qt client windows builds are 32bit, don't even know what a GPU is, and allow all CPU threads to idle if idle (so old laptop won't die heat death).

"Biggest" Qt version with extended gamestate need ~680MB memory, and win7 with crap disabled ("foobar diag something service", "windows search") less than 800MB if on a machine with 2GB of physical memory. It will probably take 30+ minutes to get the node up and running though.

Perhaps try a different OS. It's always easy to go back to Windows7 (has this official 120 days demo version, 32bit iso too)

if your opponent is destructed and dies, he will drop 0.9*30 HUC and your hunter value goes from 200 to 400 (and be refunded 400 in case of Disaster)

You can't tell without thinking if woken up at 4am?



I'm actually a big fan of roguelike ascii representation, even if semi transparent fireballs will look better on RockPaperShotgun.

It looks like killing hunters, but perhaps they really use it for steganographic messaging   

Yes, the hunter addr wouldn't give a privilege or more weight per se, and without coins they can't vote at all.
It's a nice gimmick, and convenient to implement (the tx that is "holding" coins cannot store much data, but hunters can send several "messages" using same player addr for example)


edit:
It could be very useful but only if guaranteed to not change.
OPRETURN_MAX_STRLEN is 100 in Huntercoin, but iirc was set lower in Bitcoin from 80 to 40 amid chatter of generally kicking extra data out, like coin eater addresses no longer valid addresses etc.

If a regular tx contains the data for voting, and the tx hash doesn't show up in one of the inputs (txin.prevout.hash) of subsequent transactions,
this is "almost" proof that the voter still owns the coins (theoretically could have sent it to someone else who doesn't move the coins)

Or rather the/one output of a regular tx contains the data for voting. If the recipient address is the same that several hunters used
as player address, the owner of the coins also owned all these hunters.

Each output can have a "tag" (the OP_RETURN tx message that Bitcoin and most other coins have too, subject to OPRETURN_MAX_STRLEN)
If tag is not used for now, and votes can be "anonymous" (without reference to a hunter), this leaves the least significant digits of the amount for data (1 for the actual vote, 7 for voting close block height) so every unspent output can be interpreted as vote. I think such a system is rather easy to implement right now, just need reasonable thresholds (min coin amount, min+max blocks until voting is closed) to keep spam and noise out. Any forum post with desired close/block height and the different choices can be an informal call for a vote.

Votes that use a former player address of "veteran hunters" would assign the coin weight of the vote to the hunter's
wishlist of how to tweak parameters and what features to enable. This would need a standardized way for the hunters to communicate what their players want.

oops, nevermind


In a shareholder democracy the rich should get what they want. (but the one case of crypto that plausibly claimed to be a company...wasn't) And there's a big difference between a vote that can only state an opinion and a vote that automatically enforces itself. Perhaps the whales, if they have a voice, will say that the farming thing was an error and all further coins shall be distributed like in some "most dangerous game" variant.

That's seriously cool. Do we have an official tool to determine the winner? (and the hunters that need kill lest they break the record)

When using multiple hunters it actually is complex. Have 2 hunters of the same color vs 3 with the remaining 3 colors an advantage in an enclosed space like the center? I'd prefer to fight with the two. (but it's slow and difficult to get 2 to same spot, and everyone will see it coming)

Yes


You got that "assign" wrong. No transaction is generated, and no one is managed.

If you want to play a game you have to invent rules, this cannot be helped. Like "Race me, the first to touch that tree wins".

The patched client passively watches and determines who would win something according to the rules (its source code is the rule, per definition).
It does not communicate the results. Only human players communicate by sending valid Huntercoin transactions.

In a way this is similar to what Mastercoin (which would be much cooler if implemented in the Bitcoin-qt wallet) is doing on the Bitcoin blockchain, only the extra information make more sense visually. The inventory items are the Masterhuntercoins.

A small step that is useful right away, could go like this:
- use the same list of "player sprites", if mithril edition gets a new monster, betterQt would load this too, and vice versa
- a daemon (with 2 patches applied) determines a list of important things to display (just "indicative, client side" like the gem spawnpoint in betterQt safemode),
  this can be polled using RPCs or compiled into Qt and displayed in both clients

Any new game element would be designed with this in mind, e.g. 1 of the 2 patches must be able to determine the coordinates of a NPC that will then do complicated things in one client but visually (sprite index, coor, dir, and what it has to say like "5 gems for the ugly head of this annoying hunter") would appear in both.

In this example, players can also do the "quest" with any client, and the reward is kept safe for them. This happens implicitly, without any additional programming, if all input is normal Huntercoin moves and gamestate does all data processing.


Would you need a closed server only for payout?

It's 2D tiles even if it looks 3D and visually several things on top of each other are often optimized to only 1 tile. When Qt is upped to an open-gl supporting version it should be possible to have mountains on a much larger map and zoom out to a realistic looking satellite view, just so with no tricks no LOD and no popping.



As long as it will just trust the data of your wallet and doesn't force full blockchain dl (not just the 800M) on rescan, it's ok to use.

Coordinating this will be a challenge. Perhaps a formal motion/voting system would help, if it gives coin holders the ability to choose
between different gameplay updates or even commission one, and of course the right to veto unwanted changes.

and it shouldn't discourage gameplay updates for different clients. Easier to pack things that exist than vapor, so...


new binary release for betterQt client
(a bit ahead of github concerning the Windows stability bug (I give it 20% chance of being killed for good)
https://mega.nz/#!OdthBC7S!8pptEB7jxdmCp_DVN-Jo6ezq9hKE5J-gDECmrY9gxjE

The inventory/alternative outfits seem to work as intended, and this is of course a fine example of having the network host data and data processing.




If an items is aquired it is stored with the reward address (or, if none exists, the player address),
and items are "equiped" as long as both addresses are the same, and otherwise stored away (if the hunter already owns a storage or the item can create one) or lost forever if not.

This should be done less complicated and more ergonomic, and here is a problem: sending data to the Huntercoin network is too limited.
The waypoints are designed only for walking around (they're integers, but limited to 0-501, no "escape" value that would allow the hunter to *not* start walking).
Then the chat message, good, but will spam the chat window, and finally the reward address. It would be cool if we had something that is not just a hack but future proof and designed with the purpose of inputting general information.

We should band together to extend the standard gameplay, at least in the cases that can be done in a decentralized way. Huntercoin network is pretty good as "server", storing data in decentralized way (the game state) and doing almost arbitrary calculations with it (would be interesting to compare to ethereum, what use cases exist that are possible for one, but impossible for the other).

hunting the deadlock bug in Qt on windows:

The different critical section implementation for windows was probably only needed for an older boost version. Easy (i.e. #ifdef __WXMSW__) to let it use mutexes like on Linux.
Stability is not better or worse than before.

Everything in ThreadSocketHandler2 can randomly...not return, for example "int nSelect = select(...);"
and the only suspect for this is ThreadOpenConnections2. This thread is almost 100% idle, easy to overlook.
Has someone ever seen a node that stopped receiving blocks, but can regenerate lost/manually closed connections,
or update the "active connections" icon?

With procexp: priority set to "realtime", it auto changed to "background", then to "high". (node looks ok after ~14h)




I'll try to update github and binaries over the weekend, then it's not only a screenshot but live on mainnet

in the early times everyone used that 4GB freeware Amd Ramdisk and it was really fast, remember?

(syncing early blocks with daemon on windows is something no exchange will do and no player *should* do,
and back then, the windows daemon was probably not used by anyone)