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

Best way is to probably avoid pvp until we improve game mechanics or until you can out wit the enemy.. may be by using more than 1 hunter.

If you stand on the spawn area or a star, you will bank and despawn .. you will get get your 100 hunter cost back.
You only need to collect more than 1 huc to be profitable per hunter) and not die in pvp.

I spawned by a nice collection fo coins then some yellow fool came and killed me. It seems like it will take forver to get 100huc and I will lose my hero before then so how is this profitable ? Please some advice. Thank you.

perfect timing for the pump ..btc down

This also makes it more difficult to have some kind of "diplomacy feature" in Huntercoin. If 2 hunters would agree to not attack each other and, should one still kill the other,  automatically pay compensation to the victim (must be worth more than a hunter, different technical problem), how can the game engine know who attacked first.

Perhaps a practical solution would divide all hunters into groups (same algo like checking who would get hit by chain lightning with unlimited hops). If an hunter that is is not under contract would get hit then all hunters in the group are in a warzone where collateral damage is to be expected and you could kill anyone without penalty.

There is no malware. Check with virus total.

Installer is acting up. I tried to reverse engineer it and found odd pieces of code that looked like malware. I will look at it closer and post my findings in this thread but bear in mind I cant sit here all day long helping u with fixing and peer reviewing that weird code.

Yes, that might be a possible approach.  But I'm not sure what that would buy you - then you still have to get a miner to include your tx, and tx sent at the "same time" might still not confirm in the same block.  Also making blocks very fast is problematic due to orphan blocks.

The red stars are banks. The coins used to make your Hunter and any coins he/she was carrying are returned to your wallet when you go over it.

I started playing and I have no idea what I am doing I only just figured out I can't collect the clear coins till they have gone solid. I think that means they under respawn ? I saw a red star and walked on to it then made coffee and came back and I disappeared. I assumed I died. Why ? Did the star kill me ? Also how do I sed my coins back to my wallet ? It says I must find a bank that respawns but where ? What do they look like ?

A short guide from anyone would be much appreciated.

@ MithrilMan

mysql all setup for you - tested and working.

I think this could be very interesting if we can fill it with as much data as possible.. and fun.
If it doesn't work too great, we can have a look at giving someone a bounty to modify ABE for us -- or just make some script that parses the json and imports to mysql

I like the installer it is cute when it tells you to go to polo to buy HUC while waiting for the installer.
Also I was expecting the blockchain to take much longer but I am only 5 weeks behind so that is cool. Hopefully I will be playing soon.

What if you made blocks really fast, and then made the gamestate wait for at least 2 confirmations instead of 1? Could it then take the 1-confirmed transactions into account and hold off including others that were issued in the same block but already got to 2 confirmations?

This is unfortunately not very straight-forward to do.  There's no network consensus about unconfirmed transactions (that's precisely why they are still unconfirmed), so one cannot take them into account for consensus-stuff like game-state transitions.  (There might be more complex hacks around this in some way, but I doubt one can find a good solution that fully retains Huntercoin's trustlessness and decentralisation.)

There are other ways to fix it, too. For example, if some players issue transactions in one block, and some confirm in the next block but not all of them, the gamestate could choose not to update until all of the transactions are confirmed, giving each player an equal chance.

It could be done map-wide like that, affecting the base speed of the game. Or it could be done only for players in close proximity such that combat might occur, causing a bit of a time warping effect.

Overall, I don't see it as a huge problem to fix, and I think it will be, soon. Everyone just has to be patient

using just the headers would be a start. we can use that to kick it off to see if we can get it working. With just the header info we can only look at both algos blocktimes/difficulty.

would be good to get more info to play with like block size, and some simple gamestate data (how many on the map), combine that with exchange data etc etc.

once it's parsed all the previous blocks - performance for adding each block should be ok.. but it would need to consider reorgs for real-time..
tbh, Tableau doesn't work too well in real time and the Tableau public version may have some limits for syncing with DB - e.g. may be every 10mins or something.

So real-time doesn't need to be real-time - it could just update the db with new info every few minutes if that is easier. or, once a day - i can set a cronjob if just need to execute your program every now and then.

-
we could just use a blockexplorer like ABE and modify it, but i'd need help. From my side, all i need is a db to connect to.

-

to give DB access i will need an IP from you to allow through the firewall (can send in pm or on skype).

I'll setup tomorrow if i get time, on a vm with lots of diskspace..

I recently rent 2 micro VM to start hack around with linux and VM and I've your same configuration (ubuntu 16.04 server) but i don't have space/ram to host huntercore or mysql anyway i should be able to work on your VM, i already installed on mine the dotnet core needed (it's just a matter to update apt with a new repository url and then apt-get the needed dotnet-core stuff to be able to compile and run .Net Core app

Anyway i can start implementing and testing on my system, maybe you can create mysql db and tables you'd like to be populated, and let my VM run the daemon that get info from your server (getblockinfo, etc...) and write back on your mysql, so once it's ready it's just a matter to deploy it on your server and i don't need access to your machine
I can give you the IP of my VM so you can allow my machine to connect to your huntercore RPC service

-

Ok I'd say you could:
- configure your VM with huntercore
- install MySQL and create the database with tables you'd like to have populated
- open RPC service to my IP
- give me the connection string to reach your MySql db
- (bonus) install dotnetcore on your server, pretty straightforward ( https://www.microsoft.com/net/core#linuxubuntu )


once that's ready, wait some time that i find the time to do the app and test it and then I'll give you the app or i'll install it on your vm

ok so we are talking about 2 components: a realtime one that runs as a daemon that polls the RPC, and an historical one to fill the gaps
note that gathering blocks information is quite fast even on historical data and seems to work even on a pruned node (i need just the header info)

getblockhash 1
> a91daed69a867a560cd68d364889c925c26c6d6f3b985c27b588f108ca72e786

getblockheader a91daed69a867a560cd68d364889c925c26c6d6f3b985c27b588f108ca72e786
> {
  "hash": "a91daed69a867a560cd68d364889c925c26c6d6f3b985c27b588f108ca72e786",
  "confirmations": 1571465,
  "height": 1,
  "version": 131585,
  "versionHex": "00020201",
  "algo": 1,
  "merkleroot": "09b1b907a0b33312822acb00bc3d7441fa4ee4842d6cf16ef090dc48e2eb70c6",
  "time": 1391264537,
  "mediantime": 1391264537,
  "nonce": 57104,
  "bits": "1e0fffff",
  "difficulty": 0.0002441371325370145,
  "chainwork": "0000000000000000000000000000000000000000000000000000000200011001",
  "previousblockhash": "00000000db7eb7a9e1a06cf995363dcdc4c28e8ae04827a961942657db9a1631",
  "nextblockhash": "000000000e14e03fa502dad4b69184c23690bd16455bf0dc7e5ea76ed033c961"
}


and so if that info is enough would be quite fast to populate the historical data, but gamestate is a loooooot slower

Perhaps there's a way to reduce the randomness by reducing the blocktime and make 1 game turn every X blocks (e.g. block time 20 seconds, 1 game turn every 3 blocks)

In a RPG, 3d20 damage is also more uniform than 1d60...



If a sha256 block comes shortly after a scrypt block, then the scrypt block is likely to get orphaned, because in Huntercoin, both add to the total chain work according to a constant ratio sha256 diff/scrypt diff, and in practice this is in favor of the sha256 block

that would be useful, probably for other cryptos as well.

there is some posts etc about doing it with bitcoin, but i've not researched it properly..

to start i'd just install ubuntu 16.04 server on a VM, install current mysql server, huntercore etc..
not sure what you will need - i can give ssh access or tell me what you want installing.. is it just an exe and i use mono to run it?

will it also update the mysql table(s) realtime when i a new block comes in?

-

for data -
probably 1 table with all the variable info for each block (if you can process gamestate as well, that would be a bonus)..
probably fields such as > blockhieght, algo (0 or 1), difficulty, unix time, median time, size, weight(i should google this i guess), and anything else you can think of
If you can do gamestate stuff as well > Total generals and total hunters, and anything else if it is easy for each block.. (can do that later if that's more of a pain)

only need the raw values (no need to calculate unix time, or put the difficulty type etc).

all that can go in one table..

Could also output getchaintips into another table, although it would be more of a live table with no historical data for ach block .. not sure how i would visualize it but could use to see if there is any forking going on.

let me know what you need me to do..

(would of course need to parse all the blocks from block 1 till now too)

It could be a pool switching from mining BTC + some merge-minable coins to mining other non-merge-minable coins based on realtime exchange rates, but not sure how realistic such a scenario is.

what information did you need to be dumped?
what's your VPS configuration?

I can build something in .Net Core (works on linux) if this can help the community
just something as simple as an RCP wrapper around huntercore, to get some data and save it on mysql or wherever, of course it would need a reachable huntercore on your VPS or another location