snailbrain (OP)
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2016, 07:21:11 PM |
|
Huntercore for testing is here (for a while) http://forum.huntercoin.org/index.php/topic,22255.msg26622.html#msg26622for it to be released we need more people to test. my current findings are that name_list causes crashes - at least with a pruned chain, i don't think I've tested with an unpruned chain so this could be related. this isn't unity related as it happens in the huntercore QT console window, at least on windows. It seems intermittent but happens a lot - i noticed first using the unity clent and huntercore debug.log the last rpc is always name_list.. further testing in the console window repeated the issue (intermittently, but enough for it to happen over a few minutes - doing game_getstate and other commands mixed in between seemed to speed up the crash) I will check the latest release, and build for windows, along with linux and test some more. If people could help test and report their findings then that would speed things up.
|
|
|
|
Icon
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 22, 2016, 01:03:31 AM Last edit: August 22, 2016, 03:31:27 PM by Icon |
|
Thanks snail but the links you provided are for the pruned blockchain, not the actual new Qt version ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Didn't know if that is what you meant to link too anyways ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Icon PS that name_call thingy might be a bug/problem due to not having a complete blockchain to index the older names/whatever, prune blockchains only have ~ 2 weeks of data, and when accessing something older then whats in the blockchain it was sync to could cause a d/c.. IMO ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
OSYA
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 647
Merit: 255
DATABLOCKCHAIN.IO SALE IS LIVE | MVP @ DBC.IO
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 22, 2016, 06:19:55 AM |
|
Huntercore for testing is here (for a while) http://forum.huntercoin.org/index.php/topic,22255.msg26622.html#msg26622for it to be released we need more people to test. my current findings are that name_list causes crashes - at least with a pruned chain, i don't think I've tested with an unpruned chain so this could be related. this isn't unity related as it happens in the huntercore QT console window, at least on windows. It seems intermittent but happens a lot - i noticed first using the unity clent and huntercore debug.log the last rpc is always name_list.. further testing in the console window repeated the issue (intermittently, but enough for it to happen over a few minutes - doing game_getstate and other commands mixed in between seemed to speed up the crash) I will check the latest release, and build for windows, along with linux and test some more. If people could help test and report their findings then that would speed things up. A link to download here can not be put? Why does the network stop?
|
|
|
|
wiggi
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 22, 2016, 12:21:50 PM |
|
A link to download here can not be put?
I think you'll have to build latest version from source https://github.com/domob1812/huntercore(can be done exactly the same way as with latest Bitcoin-Qt)
|
|
|
|
wiggi
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 22, 2016, 12:33:19 PM |
|
I was waiting to publicize Huntercore until the name_list issue was fixed, with the understanding that the beta would be pretty much over with that done. I'm hoping you guys testing it now don't find any new bugs, but we have to encourage you to look, anyways. ![Embarrassed](https://bitcointalk.org/Smileys/default/embarrassed.gif) I'll bother snailbrain to get ITT, because I don't know how to get on Huntercore, either... managing too many cryptocurrency projects, already. Apologies! Perhaps it's better to also wait until next update of game rules. Currently new players would just have a bad experience and they won't come back. (and tell everyone they know how much the game sucks) 3 or 2 month ago the "game doesn't allow to stop playing" was the main issue, but now there's a worse one: the 20HUC destruct fee will drive every new player into "playing at a loss" territory. Specifically, noobs will not be able to avoid combat with a group of players that has always 60...80 hunters, and it's too easy to deliberately abuse the destruct fee to make everyone else not coming back next day, so they get really all the coins. These 2 issues need to be fixed asap, and before that, anything to promote Huntercoin, or to make playing easier with a lite client, would only backfire.
|
|
|
|
The Bitcoin Co-op
Legendary
Offline
Activity: 1268
Merit: 1006
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 22, 2016, 02:38:06 PM |
|
I was waiting to publicize Huntercore until the name_list issue was fixed, with the understanding that the beta would be pretty much over with that done. I'm hoping you guys testing it now don't find any new bugs, but we have to encourage you to look, anyways. ![Embarrassed](https://bitcointalk.org/Smileys/default/embarrassed.gif) I'll bother snailbrain to get ITT, because I don't know how to get on Huntercore, either... managing too many cryptocurrency projects, already. Apologies! Perhaps it's better to also wait until next update of game rules. Currently new players would just have a bad experience and they won't come back. (and tell everyone they know how much the game sucks) 3 or 2 month ago the "game doesn't allow to stop playing" was the main issue, but now there's a worse one: the 20HUC destruct fee will drive every new player into "playing at a loss" territory. Specifically, noobs will not be able to avoid combat with a group of players that has always 60...80 hunters, and it's too easy to deliberately abuse the destruct fee to make everyone else not coming back next day, so they get really all the coins. These 2 issues need to be fixed asap, and before that, anything to promote Huntercoin, or to make playing easier with a lite client, would only backfire. We can promote all the time if we do it to different audiences. For now I would imply that gameplay is experimental, but state that development has been proceeding and that the client is now more stable. We need people to buy HUC to sustain our community and development momentum, and speculators need to know that our dreams of an autonomous MMO are not vaporware. This can be accomplished via channels like NewsBTC... I won't be talking to any video game critics, yet ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
|
We work hard to promote Bitcoin adoption and the decentralization of society. You can support our efforts by donating BTC to 35wDNxFhDB6Ss8fgijUUpn2Yx6sggDgGqS
|
|
|
domob
Legendary
Offline
Activity: 1135
Merit: 1170
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 22, 2016, 06:24:27 PM |
|
that name_call thingy might be a bug/problem due to not having a complete blockchain to index the older names/whatever, prune blockchains only have ~ 2 weeks of data, and when accessing something older then whats in the blockchain it was sync to could cause a d/c..
I wasn't aware that the crash happens with a pruned chain until recently, and am not using pruning myself - so that could indeed be a good hint. In theory, the data for name_list is from your wallet and not the blockchain - but maybe some parts of the code (which was written before pruning existed) fails for a pruned chain. I'll look into that, but need to sync a pruned chain first for that.
|
Use your Namecoin identity as OpenID: https://nameid.org/Donations: 1 domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NC domobcmcmVdxC5yxMitojQ4tvAtv99pY BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
|
|
|
snailbrain (OP)
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2016, 10:34:16 AM Last edit: August 23, 2016, 06:24:27 PM by snailbrain |
|
that name_call thingy might be a bug/problem due to not having a complete blockchain to index the older names/whatever, prune blockchains only have ~ 2 weeks of data, and when accessing something older then whats in the blockchain it was sync to could cause a d/c..
I wasn't aware that the crash happens with a pruned chain until recently, and am not using pruning myself - so that could indeed be a good hint. In theory, the data for name_list is from your wallet and not the blockchain - but maybe some parts of the code (which was written before pruning existed) fails for a pruned chain. I'll look into that, but need to sync a pruned chain first for that. looks like the issue happens with unpruned as well - it seems i may have tested both previously but just in case i have tested with a fresh unpruned chain and fresh wallet. I sent 450 coins to the wallet, created a character and the next name_list caused a crash of the QT on windows. Restarting the QT, the hunter seems playable.. I created an additional hunter and when it comes out of pending state, the next name_list caused a crash again. 2016-08-23 10:28:27 ThreadRPCServer method=name_pending 2016-08-23 10:28:30 ThreadRPCServer method=getblockcount 2016-08-23 10:28:30 ThreadRPCServer method=getblockcount 2016-08-23 10:28:30 ThreadRPCServer method=game_getstate 2016-08-23 10:28:30 ThreadRPCServer method=getbalance 2016-08-23 10:28:30 ThreadRPCServer method=name_list 2016-08-23 10:28:31 ThreadRPCServer method=name_pending 2016-08-23 10:28:31 ThreadRPCServer method=getblockcount 2016-08-23 10:28:31 ThreadRPCServer method=game_waitforchange 2016-08-23 10:28:45 UpdateTip: new best=2c7ef67b69e411457fdbf069ee5af854d3855850526debe861dcd655b1037eb7 height=1350630 version=0x00060101 log2_work=81.654947 tx=24468836 date='2016-08-23 10:28:27' progress=1.000000 cache=0.0MiB(66tx) 2016-08-23 10:28:46 ThreadRPCServer method=getbalance 2016-08-23 10:28:46 ThreadRPCServer method=name_list 2016-08-23 10:28:46 ThreadRPCServer method=name_pending 2016-08-23 10:28:46 ThreadRPCServer method=getblockcount 2016-08-23 10:28:46 ThreadRPCServer method=getblockcount 2016-08-23 10:28:46 ThreadRPCServer method=game_waitforchange 2016-08-23 10:29:01 ThreadRPCServer method=getblockcount 2016-08-23 10:29:05 ThreadRPCServer method=name_register 2016-08-23 10:29:05 keypool added key 109, size=101 2016-08-23 10:29:05 keypool reserve 9 2016-08-23 10:29:05 keypool added key 110, size=101 2016-08-23 10:29:05 keypool reserve 10 2016-08-23 10:29:05 CommitTransaction: CTransaction(hash=1e8d6ead66, ver=28928, vin.size=1, vout.size=2, nLockTime=1350630) CTxIn(COutPoint(c61188bfc7, 1), scriptSig=47304402204af833252c966d, nSequence=4294967294) CTxOut(nValue=205.00000000, scriptPubKey=520574657474740b7b22636f6c6f72) CTxOut(nValue=39.97951000, scriptPubKey=76a914e82cfef22cecfa492ad03ee6) 2016-08-23 10:29:05 keypool keep 10 2016-08-23 10:29:05 AddToWallet 1e8d6ead66ef1655c2e860339a2d84092dda23a276ae575f993570d80d5cc617 new 2016-08-23 10:29:05 AddToWallet 1e8d6ead66ef1655c2e860339a2d84092dda23a276ae575f993570d80d5cc617 2016-08-23 10:29:05 Relaying wtx 1e8d6ead66ef1655c2e860339a2d84092dda23a276ae575f993570d80d5cc617 2016-08-23 10:29:05 keypool keep 9 2016-08-23 10:29:05 ThreadRPCServer method=name_pending 2016-08-23 10:29:16 ThreadRPCServer method=getblockcount 2016-08-23 10:29:31 ThreadRPCServer method=getblockcount 2016-08-23 10:29:46 ThreadRPCServer method=getblockcount 2016-08-23 10:29:46 ThreadRPCServer method=getblockcount 2016-08-23 10:29:46 ThreadRPCServer method=game_getstate 2016-08-23 10:29:46 ThreadRPCServer method=getbalance 2016-08-23 10:29:46 ThreadRPCServer method=name_list
I notice the unity client is doing a double getblockcount which i will fix - but note that you can cause the crash by doing name_list sometimes in the console window..
|
|
|
|
snailbrain (OP)
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2016, 10:46:06 AM |
|
sorry Icon, i'm building the latest one now.. i've made a simple to use semi build environment where you can build for windows and for ubuntu if you want to have a go yourself you can install vmware or virtualbox and add the ovf template. works perfect. http://forum.huntercoin.org/index.php/topic,22255.msg26613.html#msg26613otherwise i'll post the binaries in a bit
|
|
|
|
snailbrain (OP)
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2016, 12:20:35 PM Last edit: August 23, 2016, 01:35:03 PM by snailbrain |
|
Here is windows - latest huntercore build untested but no errors with building. always backup your wallet https://mega.nz/#!4EFjnKyL!gu-TfHFtrlG23bcE9itUcx8EHQbRxYGidyIEpoaus6Q- note - did a quick a test - could be an issue with some coin spending RPCs unless my wallet is corrupt from the previous crashing - i will test more later. for now, it would be good if other people could test syncing from scratch, syncing with -prune=500 and any other tests you can think of.
|
|
|
|
domob
Legendary
Offline
Activity: 1135
Merit: 1170
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2016, 06:05:11 PM |
|
Thanks for the input! Have you (or anyone else) also experienced the crashes already on GNU/Linux? I'm unable so far to get any crash with various combinations of name_list and other commands. Also, if anyone is able to reproduce the crash, it would be cool to get a stacktrace or something from GDB (I can provide instructions for GNU/Linux).
|
Use your Namecoin identity as OpenID: https://nameid.org/Donations: 1 domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NC domobcmcmVdxC5yxMitojQ4tvAtv99pY BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
|
|
|
wiggi
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 29, 2016, 08:00:39 PM |
|
I started a test: the task is to convert 50 USD worth of HUC into a fiat-pegged form aka chronoDollar, hold it for 2 weeks, then convert it back, avoiding all fees or slippage if possible. Let's see if a Huntercoin add-on can do this better than the big inspiring example, which in this case would be Bitshares, and where the bugs and shortcomings are. (also updated readme.md for www.github.com/wiggi/huntercoin and did my best to explain what the advanced mode is and how to get it) I'll post and comment on every step here. Part 1 We don't have a slick, stylisch black UI, only plain text files. (I guess it's not too difficult to have some NPCs project the order books over dark water, in-game) On the bright side, no spreads to pay between settlement prices and lowest ask. For the test I used a new hunter ("Cortez"), and a new name address. The first 2 of the orders (they also show up in www.huntercoin.info/blockExplorer Recent Block Chat) were sent with the auction bot (the auction bot also sent the correct amount of coins), the third manually copied from adv_chrono.txt. It's a 2 step process, first gems, then chronoDollar. Cortez CRD:GEM set bid 50 at settlement 1359987 Cortez GEM:HUC set bid 1.60 at 1980.00 1359984 Cortez GEM:HUC set bid 1.00 at 1980.00 1359975 The order to buy 50 chronoDollar "at settlement" was filled at chronon 1360001 at a rate of 0.0505 chronoDollar per gem, with the AI market maker acting as counterparty. (it's an altruistic market maker, giving buyers and sellers exactly the same quote, once per 10000 blocks) Cortez got a "liquidity reward" because the standing sell order at 1980 was in need of buying ("old" and at settlement). Weird rule... adventurers.txt HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX Cortez 2.84 - Adventurers who own something are what would be called "delegates" elsewhere, and can do price feed (once per 10000 blocks) Cortez HUC:USD feed price 0.01 1359991 This was also the "median feed", and the rate of 0.0505 was calculated from this and the gem / HUC settlement of 1980. adv_chrono.txt CRD:GEM trader positions (chronon 1360112, mainnet) ---------------------------------------------------
hunter chronoDollar trade trade gems, not long bid bid ask ask short storage vault key name gems position price P/L at risk risk size price price size risk flags
HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX Cortez 2.94 50.00 0.0505 0.00 0.40 2.54 50.00 0.0505 0.00 0.00 0.00 bid: rollover ok Reward for feed was paid at block 1360050. Currently, Cortez is long 50 chronoDollar (which is a futures contract) and owns 2.94 gems (an asset). Sadly, in Huntercoin, hunters cannot own Huntercoins. This would make things so much simpler ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
|
|
|
|
The Bitcoin Co-op
Legendary
Offline
Activity: 1268
Merit: 1006
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 30, 2016, 11:35:43 AM Last edit: August 30, 2016, 07:53:46 PM by The Bitcoin Co-op |
|
I started a test: the task is to convert 50 USD worth of HUC into a fiat-pegged form aka chronoDollar, hold it for 2 weeks, then convert it back, avoiding all fees or slippage if possible. Let's see if a Huntercoin add-on can do this better than the big inspiring example, which in this case would be Bitshares, and where the bugs and shortcomings are. (also updated readme.md for www.github.com/wiggi/huntercoin and did my best to explain what the advanced mode is and how to get it) I'll post and comment on every step here. Part 1 We don't have a slick, stylisch black UI, only plain text files. (I guess it's not too difficult to have some NPCs project the order books over dark water, in-game) On the bright side, no spreads to pay between settlement prices and lowest ask. For the test I used a new hunter ("Cortez"), and a new name address. The first 2 of the orders (they also show up in www.huntercoin.info/blockExplorer Recent Block Chat) were sent with the auction bot (the auction bot also sent the correct amount of coins), the third manually copied from adv_chrono.txt. It's a 2 step process, first gems, then chronoDollar. Cortez CRD:GEM set bid 50 at settlement 1359987 Cortez GEM:HUC set bid 1.60 at 1980.00 1359984 Cortez GEM:HUC set bid 1.00 at 1980.00 1359975 The order to buy 50 chronoDollar "at settlement" was filled at chronon 1360001 at a rate of 0.0505 chronoDollar per gem, with the AI market maker acting as counterparty. (it's an altruistic market maker, giving buyers and sellers exactly the same quote, once per 10000 blocks) Cortez got a "liquidity reward" because the standing sell order at 1980 was in need of buying ("old" and at settlement). Weird rule... adventurers.txt HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX Cortez 2.84 - Adventurers who own something are what would be called "delegates" elsewhere, and can do price feed (once per 10000 blocks) Cortez HUC:USD feed price 0.01 1359991 This was also the "median feed", and the rate of 0.0505 was calculated from this and the gem / HUC settlement of 1980. adv_chrono.txt CRD:GEM trader positions (chronon 1360112, mainnet) ---------------------------------------------------
hunter chronoDollar trade trade gems, not long bid bid ask ask short storage vault key name gems position price P/L at risk risk size price price size risk flags
HMFESBYnkoTHYVtyMyFVDFXQG5R1nkAzZX Cortez 2.94 50.00 0.0505 0.00 0.40 2.54 50.00 0.0505 0.00 0.00 0.00 bid: rollover ok Reward for feed was paid at block 1360050. Currently, Cortez is long 50 chronoDollar (which is a futures contract) and owns 2.94 gems (an asset). Sadly, in Huntercoin, hunters cannot own Huntercoins. This would make things so much simpler ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) Cool, where are you pulling the price data from? Poloniex, or something? I don't really understand how you are keeping the price pegged. I'm actually more curious about the asset ownership dichotomy between players and their hunters. I can understand why we need a token associated with a user (or rather, his or her public/private key pair) in order to issue transactions. But I think it should be trivial to allow Hunters to hold HUC, because they already do, in a way: the coins they pick up around the map, before banking them. Conversely, I would assume that gems and chronoDollars could be made to be banked and redeemed to the player's wallet. I think we'd basically then be looking at the banks as portals between the Huntercoin world and the real world. Assets leave it that way. Theoretically, we could also make it so Hunters can pick up assets at a bank, so then they can enter the world that way, too. Or correct me if I'm wrong...
|
We work hard to promote Bitcoin adoption and the decentralization of society. You can support our efforts by donating BTC to 35wDNxFhDB6Ss8fgijUUpn2Yx6sggDgGqS
|
|
|
snailbrain (OP)
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 30, 2016, 01:35:30 PM Last edit: August 30, 2016, 05:08:18 PM by snailbrain |
|
Thanks for the input! Have you (or anyone else) also experienced the crashes already on GNU/Linux? I'm unable so far to get any crash with various combinations of name_list and other commands. Also, if anyone is able to reproduce the crash, it would be cool to get a stacktrace or something from GDB (I can provide instructions for GNU/Linux).
on ubuntu, i got a seg fault after creating 2 hunters and then the next block coming in (but i dont' see any rpc's) restarting the daemon seems fine, until i do do a name_list. seems same issue on ubuntu, I think domob is travelling for the next 2 weeks or so. If someone can fix the issue, we can provide 5k HUC bounty from the dev fund..
|
|
|
|
wiggi
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2016, 02:30:36 PM |
|
Cool, where are you pulling the price data from? Poloniex, or something? I don't really understand how you are keeping the price pegged.
The principle is similar to Bitshares really, including the 3:1 initial margin requirement for shorts. (*) Main difference is probably, pegged asset and collateral is not conflated into one thing (bitUSD) but longs own both (like ES futures, you buy stock futures and keep the dollars, they only get "frozen") Then, price data is only needed (and rewarded) every 10k blocks, so that feed can be done manually by players without cost or special expertise. This also means settlement (getting in or out at a fixed price) is only possible every 10k blocks. And I included a "free insurance" against drop of gem price while getting out (would not be needed if the in-game markets had lots of liquidity) The entire system is too complex to describe in a single post, just watch it in motion, it's fascinating ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) (*) the short in this case is a NPC (one with no visual representation in-game yet) CRD:GEM trader positions (chronon 1363027, mainnet) ---------------------------------------------------
hunter chronoDollar trade trade gems, not long bid bid ask ask short storage vault key name gems position price P/L at risk risk size price price size risk flags
npc.marketmaker.zeSoKxK3rp3dX3it1Y Sox'xiti 490.293 -210.00 0.0505 -1.296 458.187 0.00 205.00 0.0494 0.0515 94.00 30.60 bid: ok ask: ok If you think about it, this could be the first AI in history who (and not just it's human masters) owns something, assuming code changes to steal his stuff are generally unacceptable, and Ether didn't have a bunch of these guys earlier. I'm actually more curious about the asset ownership dichotomy between players and their hunters. I can understand why we need a token associated with a user (or rather, his or her public/private key pair) in order to issue transactions. But I think it should be trivial to allow Hunters to hold HUC, because they already do, in a way: the coins they pick up around the map, before banking them.
If a player (and their hunter) can enter contracts involving "loot" (i.e. the coins they pick up around the map, before banking them) it must not be allowed to just walk the hunters to bank and take it away. And impossible for the hunter to die and lose the loot. This would require a hardfork that must also specify exactly what can be done with the loot. Conversely, I would assume that gems and chronoDollars could be made to be banked and redeemed to the player's wallet.
In a way, currently they instantly autobank. It's the privkeys in the player's wallet that decide who can do stuff, like sending to other addresses, or trade. I think we'd basically then be looking at the banks as portals between the Huntercoin world and the real world. Assets leave it that way. Theoretically, we could also make it so Hunters can pick up assets at a bank, so then they can enter the world that way, too. Or correct me if I'm wrong...
Theoretically, I would do the "bring coins already banked back into the game as loot" thing in the way that you can send coins to a coin-eater address that is associated with a hunter's name address, and the coins get re-issued to that hunter as "loot2_deathtax_already_paid". Naturally, this hunter wouldn't want to walk around on the battlefield.
|
|
|
|
merlin0113
Newbie
Offline
Activity: 60
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 01, 2016, 02:20:51 AM |
|
Thanks for the input! Have you (or anyone else) also experienced the crashes already on GNU/Linux? I'm unable so far to get any crash with various combinations of name_list and other commands. Also, if anyone is able to reproduce the crash, it would be cool to get a stacktrace or something from GDB (I can provide instructions for GNU/Linux).
on ubuntu, i got a seg fault after creating 2 hunters and then the next block coming in (but i dont' see any rpc's) restarting the daemon seems fine, until i do do a name_list. seems same issue on ubuntu, I think domob is travelling for the next 2 weeks or so. If someone can fix the issue, we can provide 5k HUC bounty from the dev fund.. https://bitcointalk.org/index.php?topic=1377121.0just for your information
|
|
|
|
wiggi
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 02, 2016, 03:48:50 PM |
|
I won't be talking to any video game critics, yet ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) The antithesis to Huntercoin's gameplay is perhaps a game that does require (and allow) player input only at time of character creation. This would be a programmable alife predator-prey simulation. Once the (totally stupid, hence almost no memory or cpu footprint) critters are sent into battle, players can only watch. (but don't have to, in case of players with jobs) It could run alongside Huntercoin, no player input also means almost no UI programming (not my thing) A challenge is to make it so that no "hunter" is necessary to play (i.e. to communicate with the Huntercoin blockchain without a hunter)
|
|
|
|
crackfoo
Legendary
Offline
Activity: 3528
Merit: 1126
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 04, 2016, 12:02:55 AM |
|
Guys,
when I try to start stratum with huntercoind I get this error:
2014-02-03 10:26:09,764 ERROR mining # CoinD does not support getblocktemplate!!! (time to upgrade.)
Can you support getblocktemplate, or is something else wrong?
namecoin/huntercoin does not have getblocktemplate but, maybe there is some trick or patch - possibly some big btc pools have some idea - (with merged mining btc + nmc) for now will have to wait - maybe will add in the future There is... NMC I just installed has getblocktemplate... maybe you can check it out and update HUC? https://github.com/UNOMP/namecoin-corebeen 2 years now after all ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
ZPOOL - the miners multipool! Support We pay 10 FLUX Parallel Assets (PA) directly to block rewards! Get paid more and faster. No PA fee's or waiting around for them, paid instantly on every block found!
|
|
|
jwinterm
Legendary
Offline
Activity: 3122
Merit: 1116
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 04, 2016, 12:50:00 AM |
|
I won't be talking to any video game critics, yet ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) The antithesis to Huntercoin's gameplay is perhaps a game that does require (and allow) player input only at time of character creation. This would be a programmable alife predator-prey simulation. Once the (totally stupid, hence almost no memory or cpu footprint) critters are sent into battle, players can only watch. (but don't have to, in case of players with jobs) It could run alongside Huntercoin, no player input also means almost no UI programming (not my thing) A challenge is to make it so that no "hunter" is necessary to play (i.e. to communicate with the Huntercoin blockchain without a hunter) This is a very interesting idea. Kind of like a game of life coin or something. Is it possible this could be implemented alongside HUC, or does it make more sense to launch a separate chain?
|
|
|
|
domob
Legendary
Offline
Activity: 1135
Merit: 1170
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 04, 2016, 04:40:29 PM |
|
Guys,
when I try to start stratum with huntercoind I get this error:
2014-02-03 10:26:09,764 ERROR mining # CoinD does not support getblocktemplate!!! (time to upgrade.)
Can you support getblocktemplate, or is something else wrong?
namecoin/huntercoin does not have getblocktemplate but, maybe there is some trick or patch - possibly some big btc pools have some idea - (with merged mining btc + nmc) for now will have to wait - maybe will add in the future There is... NMC I just installed has getblocktemplate... maybe you can check it out and update HUC? https://github.com/UNOMP/namecoin-corebeen 2 years now after all ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Not sure what you are talking about - Namecoin Core (whose official repository is not the one you linked) has getblocktemplate disabled, although we are thinking about re-enabling it. We also already have an updated version of HUC, called Huntercoin Core. Check out my posts a bit up in the thread about that.
|
Use your Namecoin identity as OpenID: https://nameid.org/Donations: 1 domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NC domobcmcmVdxC5yxMitojQ4tvAtv99pY BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
|
|
|
|