I know I downloaded the chain a few weeks ago but didn't know where to unzip it and exactly which files to delete in the applications folder of MAC.
Can anyone elaborate on how to get my wallet up and running?
"/Library/Application Support/Huntercoin" is Mac equivalent to "username\appdata\roaming\Huntercoin" on Windows and ".huntercoin" on Linux. Just start the executable once, it will put small versions of all files it needs in the exact place it wants, then replace with the big ones from chain.huntercoin.org (and remove any write protection). |
|
|
|
Just got a thought which I think would be nice for the game:
It would be awesome if at some point, the world of Huntercoin would be as immersive as for example in World of Warcraft or other MMORPGs in terms of environmental interaction and game depth.
Is there any storyline so far for Huntercoin? I could help with that.
We could build a Huntercoin universe together where the community votes upon how they would like to shape the Huntercoin world.
The devs are doing a great job on the tech side. The community could do the job of inhaling a spirit into the Huntercoin world.
What do you think?
Huntercoin as a game engine has a few things going for it. One is, the only serious performance concern is "transactions per block", the world can be huge, and it's mostly the amount of micro-management that limits the number of players. Less micro-management, less transactions per block. I like the little RPGmaker sprites. There are so many of them, if the community collect and categorize the 10000 best and most unique looking, loading them all in vram is not a problem. Generally, programming interactions would be as easy as for a single player roguelike (data base and gamestate take care of everything really) if you could do a hardfork every week, but need thinking outside the box if not. The result is then Huntercoin and uses only Huntercoin rules to do things but has evolved somehow... If the gameworld would be somewhere in Planescape what plane would it be?  |
|
|
|
But you could produce a signature which proves that you own the private key associated with a historical hunter for banking its coins, right?
A voting system could even work without such a proof, and be really simple and fast. For example, vote is cast by sending coins to the "historical hunter" player address. The voting must have a closing time (block height), the actual vote (i.e. yes or no, 1 or 0, or perhaps a choice #1, #2 ... #10), and a "weight" in coins. If 2 different polls never have the same closing time, and closing time is always multiple of 100, then to vote "Yes, #4, for the round of voting that closes at block 1358000, with a weight of 50k" can be done by simply adding all these numbers and sending 50000.01358014 coins to yourself. If recipient is not a historical hunter's address (on record in game state), the act of voting can create a new record, with "unknown whale" as hunter name. (*) parsing of all incoming payments https://github.com/wiggi/huntercoin/blob/betterQt-with-storage/src/gamedb.cpp#L94gamestate record, this doesn't interfere with normal huntercoin function, and it's probably easy to include both in daemon https://github.com/wiggi/huntercoin/blob/betterQt-with-storage/src/gamestate.h#L279A vote would be overwritten by one with more coins, and deleted if its tx id (what is the fastest way to get OS independent hash of it?) is seen as "input" of another tx. (*) Min amount can be low or zero but then it's stored only for a few days, to avoid spam. Same if NPCs start to do artificial atmospheric actions, sneak around, or give cosmetic items to hunters (i.e. the facility that can store items forever is an item itself)  |
|
|
|
|
If the critical section implementation is different for each OS, and daemon is more stable than Qt on windows, was the v1.3.01 release daemon cross-compiled?
Imo it can be fixed by only allowing 1 thread at a time to use critical block. CPU is only the bottleneck with very fast SSD and internet, and then it doesn't matter.
domob said this may lead to other issues because it was not anticipated when the code was written.
need more testing, what happens if threads are suspended individually.
|
|
|
|
I've not checked it, but yes, I strongly assume that there are quite some deadlocks and race conditions in the old code.
Updated windows build to fix this https://mega.nz/#!eUMwhK5J!g0aJv1PX6ewWDMsm78BBeQAqWWZ0sZctDrZquUnic90 It includes a hacked ThreadSocketHandler2 function (snippet in readme) to investigate if the thread is still killed by deadlock. I found 1 case: debug.log: ThreadSocketHandler2 stage 10, count 8, loops 17 (3/s)
ThreadSocketHandler2 stage 3, count 3, loops 16 (3/s)
ThreadSocketHandler2 stage 3, count 3, loops 0 (0/s) and it's easy to look up... //
// Find which sockets have data to receive
//
[snip]
#ifdef PMON_DEBUG_WIN32_GUI
pmon_debug_stage(3);
#endif
CRITICAL_BLOCK(cs_vNodes) ...what caused the problem, in combination with CriticalSection implementation on windows. Probably there are some more.  |
|
|
|
tbh, i've not checked recently - but that is probably one difference between the windows and linux compile (boost version). I've used easywinbuilder for huntercoin exe's in the past, i can check the version difference if you think that could be related..
i didn't notice any compile error though?
Latest version that works for me is 1.54, but didn't really look into this. Can easywinbuilder use the newest (1.60)?
I've tried a lot in the past.. the issue now is the blockchain size and sync time
i know we've recently reached out the bittrex - awaiting a response.
i'm hoping once huntercore is good to go we can more easily get it added to more exchanges.
Would be seriously cool if they react to the higher volume now and eat the big chain (exchanges will use an unpruned node anyway imo) |
|
|
|
i keep reading windows daemon in unstable but my experience says that the daemon works fine, i have 1 node running huntercoind.exe 24h without any issue.
I confirm that QT wallet instead have problems.
it';s very rare but there's been quite a few reports. there is/was a bounty for it but atm i wouldn't call it that serious now that huntercore isn't far away from completion. 24h isn't probably enough.. it can run fine for 48 hours but randomly it will stop sync and requires a restart to catch back up. I have actually died because of it in game. It happens with the daemon as well - a test to see it happen is by trying to sync from scratch on windows - it's unlikely to make it fully through the sync without a restart. The threads of a windows Qt client look rather constant. procexp.exe lists 16 (14 if on Tor), always same "start addresse" and activity level. Perhaps it's 1 less when stopped syncing. If not.. hasn't this problem gotten worse (not so good idea to use newest possible boost version that doesn't cause compile error)? |
|
|
|
I've wrote a guide for setting up your own instant play ubuntu openvpn huntercoin server on digital ocean..although it could do with someone going over it for security purposes, it should allow you to play on your android device anywhere anytime instantly. it's a big post but extremely simple to do.. http://forum.huntercoin.org/index.php?topic=22247.msg26488#msg26488isn't ideal and is really just a temp work around for those who want to get their hands dirty and "play". would be good if any linux/security gurus could help make it more secure if required.. I'm confused.. this is for 1 user, but would it be difficult to modify for more users? Speaking of confusion, I hit myself over the head today: heureka, hardlinks  So, the following is IMO the best method to run Huntercoin on Windows only, works even for old notebooks (without VT-x). First, copy the blockchain to a subfolder, in this example "huntercoin-betterQt-20160221-exp\_huc", and "-datadir=_huc". Make a copy of the entire Huntercoin folder, but without blk0001.dat to blk0004.dat. They are full and won't change anymore, and in a few days blk0005.dat will be at maximum size too. Replace them with hardlinks: mklink /H "C:\huntercoin-betterQt-20160221-clone\_huc\blk0001.dat" "C:\huntercoin-betterQt-20160221-exp\_huc\blk0001.dat"
In the clone's config, change port and make it connect through tor browser bundle: #port=8398
port=8397
#Tor Browser Bundle listens on port 9150.
proxy=127.0.0.1:9150 Now both nodes can go online, and if wallet.dat is bloated, send coins to a fresh wallet (that has a backup) at the clone node. If the old wallet is empty, and some hunters are in "adventurers.txt", do for each of them: importprivkey <key> <huntername> false No rescan required, if the old wallet is empty. Backup the clone node wallet, and use it with the first node too. Now both running in sync but connected differently. This is similar to RAID1, unless internet dies completely, they won't stall at the same time. PS trick question: if both nodes are used to send moves (switching at random) will the wallet files remain identical even if old and bloated? PPS this is also an easy way to use different clients at the same time |
|
|
|
P.S.
player is a term in huntercoin that i try always to avoid because it confuses too much with the game concept of player, that's the human playing the game and controlling the hunters
I think "human" or "human player" sounds too clumsy, so "players" are human, hunters are characters (who need more character) and generals and soldiers are both "hunters". (soldiers being dormant)
that's not an account, i mean you can play in a single wallet multiple players and thinking about a gamer that uses simultaneous multiple accounts in a wallet isn't something right imo
moreover, once that player dies, that address is gone (afaik) and you can't reuse that. I'm not sure tho what happen if you transfer every hunter to another address, if the transferred hunters share the same address, but anyway you can't force people use the wallet in that way. Moreover, the address isn't even mnemonic, so you'd end talking to the gamer HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE, etc...
The address is fine (as any "re-used" address). If someone send coins there, it means coins and hunter(s) owned by the same player. And the game also has recorded a bit about the hunter's doings. For example, when it comes to voting what feature to implement next, or anything that need subjective interpretation, it would be better than Nushare's system (only vote + weight in coins) if the motion result page reads like "Foobar, who owns 150 thousand coins, has slain 10 bandits and 300 common hunters, and lived for 90 thousand chronons, votes YES" The ancestors of such an individual hunter used different names, but not always. Players have a habit of reusing names. Of player characters. Gamer HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE is more a demon possessing the characters, perhaps likes talking but is not forced to do anything or to provide anything. Another example. Individual player sprites are a cheap (performance wise) way to make the game look better, and there are many RPG maker sprites done with talent and skill, usually "free to use, no strings attached". If based on popular culture characters, this would be fair use. And probably some players would want their party of hunters look like characters from some anime/game/movie. In practical terms: player would make hunters, transfer each to their usual name addresses, get new look (same in all clients). This is also the most basic "inventory item". If it has no gameplay effect and doesn't cost anything (and saving the data in gamestate is a bit overkill) perhaps it's not too difficult to achieve consensus about the "rules" (how to get one? incentive for player to convert sprites to Huntercoin format? how to eventually move saved stuff to a different address?) |
|
|
|
But you could produce a signature which proves that you own the private key associated with a historical hunter for banking its coins, right? Then if someone starts using your habitual hunter name to mimic you, you can verify yourself as the original. If you switched addresses, just send a trivial amount of HUC from your former one to prove mutual ownership. I imagine a client could be designed to take care of such things automatically.
This would be the way to go if the coin has only transaction messages and otherwise is a vanilly Bitcoin clone. Keep sending coins from your address to itself, and tx message can be game moves or "Hi game, my new addr is ...". The Huntercoin player name address is just more convenient to use. Btw if someone starts using your habitual hunter name to mimic you, you can verify yourself as the original.
sounds horribly, horribly wrong, like someone wants that players go "Papers please" on each other. It should be made absolutely clear that the problem is NOT someone mimicing someone. The problem (actually only a part of it) is this: when hunters die, the game will delete all information about them. And hunters are guaranteed to die, with no place to hide anything. Think Gothic 1, only all prisoners get murdered every few days and the place is carefully stripped of every item that could be of use for the new ones, so that it becomes a proper hard labor camp and instead of an epic adventure. See? |
|
|
|
that's not an account, i mean you can play in a single wallet multiple players and thinking about a gamer that uses simultaneous multiple accounts in a wallet isn't something right imo
moreover, once that player dies, that address is gone (afaik) and you can't reuse that. I'm not sure tho what happen if you transfer every hunter to another address, if the transferred hunters share the same address, but anyway you can't force people use the wallet in that way. Moreover, the address isn't even mnemonic, so you'd end talking to the gamer HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE, etc...
The address is fine (as any "re-used" address). If someone send coins there, it means coins and hunter(s) owned by the same player. And the game also has recorded a bit about the hunter's doings. For example, when it comes to voting what feature to implement next, or anything that need subjective interpretation, it would be better than Nushare's system (only vote + weight in coins) if the motion result page reads like "Foobar, who owns 150 thousand coins, has slain 10 bandits and 300 common hunters, and lived for 90 thousand chronons, votes YES" The ancestors of such an individual hunter used different names, but not always. Players have a habit of reusing names. Of player characters. Gamer HMSCYGYJ5wo9FiniVU4pXWGUu8E8PSmoHE is more a demon possessing the characters, perhaps likes talking but is not forced to do anything or to provide anything. |
|
|
|
another problem (it depend from you POV) is that current implementation doesn't have an "account" concept, so people doesn't have someone to talk with but talk only by hunters (so no identity)
this could be a plus or not, but as a gamer i prefer to have someone to talk with
You can pick the same name for your Hunters every time, but I guess then someone else could use that name and pretend to be you. What about if each private key reserved a name? Hunter names are only flavor, but player name addresses are really "accounts", if your hunter transferres to an address that another hunter used yesterday, and if the hunter can do another move. Then it's the same player (at least know the same privkey). |
|
|
|
well now that bitcoin core .12 was released with block pruning and full wallet access, think its time for a new huntercore qt..
Yep  New Qt versions (5.4+) also have OpenGL support, you can display graphics with normal qt function like painter->paint and it will autodetect hardware and use GPU or fall back to the software renderer. Comes in handy because the old qt is at its limit when rendering 1080p. bitcoin-qt could be the place to start, make an extra tab, display a demo like http://doc.qt.io/qt-5/examples-widgets-opengl.htmlthen let it paint some sprites, then the static Huntercoin map... Current huntercoin-qt has lots ot code and "forms" dealing with UI elements, and Qt is not really into backward compatibility. Lots of work to adapt, and it's tempting to go for a new clean look with hotkeys "spawn one" "spawn my list and keep alive" "transfer selected" "transfer all" etc |
|
|
|
Go for it, I say.
Yep  3rd version of betterQt is almost finished, and not much will change until block 1140000 (if Huntercore is not ready earlier). It's now possible to stop playing from one minute to the next, or temporarily be away from keyboard for a relatively long time, and playing is *much* more relaxing and fun. https://github.com/wiggi/huntercoin/blob/betterQt-with-storage/betterQt_readme.txthas a link for prebuilt executables (1x for windows, 3x for old/new 32bit/64bit ubuntu/mint/debian), it's probably a good idea to take a look at the readme addendum and to understand what the included game.dat can do. The afk functions are not nerfed in any way. notes: The queued path (gray line) is no longer recomputed after a new block, allowing players to update the path without time pressure. Combined with "config:afk_defence" this allows for a rather deadly attack. Selling something in the in-game auction is absolutely riskless (assuming no bugs), with a price limit to catch fat-finger-errors. But buying is 2-step with a 15 block timeout. After that, sending coins is just sending coins. You have been warned. (what's the best way to improve this, within current Huntercoin rules?) Real life calls, need to stop playing right now, but want hunters harvest coins for at least another 10 minutes? config:bank_notice -120
config:afk_leave_map 60 While testing the prebuilts with their respective (Mint, double checked iso md5) version in VMs, there was, as expected, no case of a node stopping to receive blocks. On Windows this is daily routine. Generally huntercoin-qt nodes in VirtualBox VMs are reliable (for me: 100.00% reliable since v1.3 was out) even if the host is a windows machine. |
|
|
|
Go for it, I say. We could easily build an AFK contingency right into the protocol, even; for example, a Hunter could be auto-banked at a higher fee if it doesn't move for X number of blocks.
This, or some kind of safe place where players who *have* to switch off their mobile device (done commuting) can send the hunters. The tile set has pretty villages with tavern, not using these is a waste. But need to be balanced, if risk for hunters is lower, some players (the usual suspects) will spawn more. |
|
|
|
in few days i'll update my client with a new version that expose much better the pending moves and path in general and has an improved automatic behaviour system
along with that I hope to find the time to record some "how to" videos to show how to use automatic behaviours, chain them togheter, etc...
The best we can do is to make the client that is perfect for the respective maintainer's own playing style. Could be farmer, duellist, psycho stalker, stat nerd, grand strategist, probably much more and more complex when the game evolves (currently it slowly does, from only 1vs1 encounters to group tactics) Yeah, it's the biggest gameplay issue IMO.
Definitely the biggest gameplay issue, and the question "should such an afk mode be released with full source" was meant more literally, like in say a wish and be careful etc  There is an updated readme on github, and a replacement huntercoin-qt.exe/huntercoin-qt for windows and "32bit ubuntu 12.04 derivatives". I think the afk mode makes the difference between just "human minable", and enjoyable as a game. |
|
|
|
|
There are a lot of situations where another hunter tries to kill you and a fight is unavoidable, but can happen anywhere from 5 minutes to 15 minutes, or from 10 minutes to 25. Be glued to the screen or lose, which is also the reason why no (as in not a single one) new player will play regularly, until this is fixed.
So the game needs an afk mode with defense that is good enough to discourage a "casual attack if seeing a new name". On the other hand, if someone has an habit of keeping their hunters on the map, day and night, any player should be able to dispatch these (with 2 hunters and at an expense of 40 Huc)
The question is: should such an afk mode be released with full source? If yes, will some players always have something better than what is released for everyone because they apply their own mod for each new release, limiting the number of people who are willing to play? If no, does the copyright even allow it? Is there a middle way with excessive configurability (and lots of "choose 1 of these 10 formulas" in the source). Will devs cooperate to maintain the afk mode? Lots of questions.
It's also not really clear if this (game asks for too much time in an inflexible way, need afk mode asap or eventually back to 1 guy playing and 300 sats) is painfully obvious or minority opinion.
|
|
|
|
I've heard it works better on other operating systems besides Windows. Unfortunately, I don't know Linux, yet  There's no real "getting started with Huntercoin" list. Let's collect some useful notes, assuming little knowledge and no-enthusiast-level hardware. (1 desktop PC or notebook, windows, CPU with VTx, no SSD or no free space on it for blockchain) 1) get blockchain from http://chain.huntercoin.org/ - on Windows, get a program like "wxDownloadFastPortable" to download big files 2) get the newest 1.3.01 client, start and exit a few times while offline, rename the resulting wallet.dat files (e.g. wallet.dat.huc.new.01 to wallet.dat.huc.new.19) and BACKUP them. - this way, it will always be easy to have a fresh (<10MB) wallet, and less lag, when playing 3) Make a reliable node (so that it'll never simply stop receiving blocks again) - get Oracle VirtualBox and Oracle VBox guest additions - get Linux Mint Mate edition (v17.3LTS, the old v13LTS works too) - give the new VM 35...40GB disk space (fixed size), 2 CPUs, 64MB video ram - to install guest additions: open VBOXADDITIONS... folder, "open in terminal", and: sudo ./VBoxLinuxAdditions.run - don't use their stupid Update manager (paste "sudo apt-get update && sudo apt-get dist-upgrade" in console once per day) - on 17.3: use Software manager, search "qt", install Qt-Creator. - source: (get both, put in different folders) - official v1.3.01: https://github.com/chronokings/huntercoin - modded client: https://github.com/wiggi/huntercoin - Dependencies: - formatting in http://huntercoin.org/downloads/compile-guide/ seems broken so that only 1 line is processed - I (also) installed this: sudo apt-get install qt4-qmake libqt4-dev build-essential libboost-dev libboost-system-dev \
libboost-filesystem-dev libboost-program-options-dev libboost-thread-dev \
libssl-dev libdb++-dev - and for good measure, and bitcoin 0.11.2 (only if using Mint v17.3): apt-get install libevent-dev - open huntercoin-qt.pro in Qt-Creator - in official v1.3.01 huntercoin-qt.pro, if miniupnpc is not installed, add the line - and: Build | Build project huntercoin-qt to be continued... |
|
|
|
Auction is open on mainnet. Playing on testnet a bit to understand the details before doing anything for real is probably a good idea - The juicy reward for buyers (by far over)compensate for some risks (example: dead hunters don't exist and don't get anything) - This is regular Huntercoin, no fork. Just extracting some extra data from blockchain and displaying it. - A player could theoretically use Unity3d client, walk over the right tile, type "GEM:HUC set ask 1 at 1000000", and *eventually* that hunters name address *will* receive coins - "Settlement price" is the game's guess of what the collateral value currently is. It moves very slowly. - On testnet, just delete/rename gamestate.dat, a new one is generated on start (safemode uses the "normal" gamestate.dat) - Editors like Qt-creator, Vim or Notepad++ can autoupdate without asking (for generated auction.txt) - there *are* dangerous bugs Don't use an old client version. New windows build: https://mega.nz/#!2BsVhDDR!CulNnVf1Q1M7cKhqpW7GmeEKHRfAJdLwFRbhIcMWS2E the scary "alert for the auction page" warning in the latest commit for https://github.com/wiggi/huntercoinis a canary: 0.5 BTC bounty if someone can trigger it network-wide (on testnet, all tricks allowed). It's easy to screw with your own node of course. |
|
|
|
|
Show Posts
