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

I was once on the receiving end of this too, and kicked the limit out:
https://github.com/wiggi/huntercoin/blob/betterQt-with-storage/src/net.cpp#L36

Must also start the node at least once with
because the old setting of 8 is stored hidden from the user (on windows in the registry iirc)

You just stated what i was thinking about, I think that for the application type (game) masternodes should be the way to go, we should reengineer the architecture to really makes the game playable, enjoyable and more secure.

I was thinking that having some kind of constraint on block generation, that enforce a block to include all transactions that at least 2 or more masternodes aspects to receive, should ensure that clients know if their transaction is received by the net and miners can't cheat during block generation.

Don't know if i made clear my point. I try to explain in a more descriptive way:

Masternode
Masternodes are special kind of nodes that host pending transaction and are linked togheter, in a way that allow them to be redundant and updated.
They apply validation on incomin transactions, to reject invalid ones, and hold a list of pending transaction that they expect to be included in the next block.
They could have a logic to include the transaction that act like "if transaction is valid, and has been received in 30 seconds since last generated block, include in the "next block expected transaction list", otherwise park it for the further block.

Dispatched Messages
- If a masternode accepts a transaction, he sends a packet to the network, communicating that he is expecting tx XXXX being included into block YYYY so that any client is aware of that. (and here a client can know if a transaction he sent will be into the next block or not)
- When the time threshold to include transactions in the next block has elapsed (in my example it's 30 seconds) MasterNode sends a packet that include the list of transactions the next block has to generate (this way every miners node knows what they should work on, and every new generated block have to include that transactions in order to be accepted by the network
- Generated blocks must be accepted by Masternodes


What does this mean practically:

When a player sends a move transaction, the transaction is sent to one of masternode and the client will have an async feedback about the sent transaction ACK (IncludedInBlockXXX/Rejected), this way the clients can shows the transaction status clearly.
At the same time, the player know for sure that his transaction will be included in that specific block, without having bad surprises like i had.


Masternodes should have a sort of consensus algo that exclude masternodes that act strangely and of course there must be some kind of elasticity in accepting transactions on different masternodes, because of latency, but every masternode must have the same UTC time.
Whenever a masternode receive a tx, it have to relay it to other masternodes that must agree on including it on the next block, so a clever syncronization alghoritm has to be thought, i'm just stating the bare logic behind

P.S.
I'm pretty sure this will remain in the limbo of the "cool things to do but there aren't people working on it"

thanks.

i think once huntercore is completed we will fix some static nodes to the client to start with

-

i should have a huntercore / unity client ready for testing today/tomorrow - less then 500mb download (with chain), pretty much instant play for anyone wanting to get into huntercoin. It's a pruned chain so you need to use a fresh wallet, or send coins from your old wallet to a new address in your new wallet.
just run the .bat file and you are good to go.

hopefully we can get this out of the way then start working on game/combat mechanics - maybe get wiggi to put something together?

You can introduce masternode feature to keep network alive and clicking. Or introduce active nodes and maintain it on your own.

i'm doing some testing with huntercore -

i sent myself 1050 hucs to huntercore wallet from old-current-wallet - totally skipped "pending" on huntercore (memory pool) and went straight into the wallet after a min.

I suspect this actually is the issue MM experienced (in my last post).
probably need more connections, or more miners/nodes/better-connected-nodes -

i will keep testing (could be huntercore has issues with memory pool?)

it's possible that when f2pool were mining blocks (sha256 and scrypt - both on the same daemon using a mod they did after some time), most people had their IP/nodes connected to f2pool node(s) and saved in addr.dat.

it's possible you are not directly connected to the current miners node or the other players node (limited by 8 connections?) - could be the tx had not yet been received by you but had been received by the miner (tx needs to get relayed and propagate through  the network - people receive txs at different times)

maybe solution would be to open the port 8988 (i think it's that port, will chekc later if not) and forward port to your daemon/PC, or if upnp is enabled and working properly (on daemon and router) it should open up itself.

This should then increase your maximum of 8 connections and you will maybe get a direct connection to the miner and player - the more connections you have the faster you will receive txs

just a guess and may be wrong.

-

if we had lots more miners (changing algos?) would it be more like that or not?

the fact is that i received the enemy pending tx after more than 30 seconds, so at least i would expect our tx go into the same block and not his tx before mine

The element of chance is now much larger than before. No more neat rules like "if tx is 60 seconds old and a block comes out it will not be in, but after 65 seconds it will".

But it seems to affect everyone evenly matched.

Need to check what happened when f2p scrypt blocks (i.e. HPDTLRqahPPoVx4Vt2HowVGnXEBFp8Ne1m) stopped.

Did a sha block get mined? I received a payment from mining - my second in 6 months! 

#sHUCked!

I'd say you never deleted it. And #9 is only 108k behind #8.

But this is a problem, without using a specific client there's no feedback of whether the vote was recognized, or deleted or not.



Depends. With betterQt on Windows (7, don't know about 10), the risk of hanging goes way down the moment you press middle mouse button in game tab for the first time. But it's never zero, so I prefer to play in a Linux VM.



The future movement given away can also be a feint. But mostly it's just like calling dibs, if you have a hunter walk to some low tier harvest area, rational opponents may avoid it, if you have 4 hunters walk to a crescent shaped harvest area, rational opponents (especially if only one) may retreat.

in past days i lost more than 10 fights because my transaction just got ignored respect others, even if i send it 30 seconds before enemy
this lead me to think that current miner is cheating, ignoring the transaction of players he wants, so i can't relay on the game now
If this isn't cheating, then is even worse because i can't imagine why my destruct didn't goes in at the same time of another one that send the same transaction with same fees, but 30 seconds later!


Is there a way to know if current generated blocks are from the same source?


P.S.
to not add insult to injury, a transaction with a destruct fee should be returned if the hunter is destroyed before his destruct tx being accepted ....

update:
i've added a statistic module to my client (wip) and i see that in the past 23 days i spent ~8700 huc as fee to gamefunds, that's insane

I think I just invalidated my vote by creating a hunter :/ Didn't look like shortest time was gonna win anyway...

Anyway, seems like blocks are coming pretty slowly, maybe one every few minutes, and zero sha blocks still.

I guess if you are trying to program a bot or something, you have to balance giving away your future movement with paying tx fees for each movement. I mean, ideally you would move one square at a time and not let anyone know where you're going, but that will start to add up in terms of tx fees I guess to some extent.

Is the hanging on win10 a known issue? Is it a spinny hd thing? Is there any workaround to kickstart it or something, or just use linux?

You're correct, thanks. It hung a couple times during sync, but I just assumed for whatever reason that once it was synced it wouldn't hang anymore. Clearly not the case. Using win10 here, I'll try it on a linux machine or virtual machine.

stuck client.  https://www.huntercoin.info/blockExplorer shows 20 blocks/40 minutes relatively constant.

I use Mint/Mate in VirtualBox to play, it never hangs. Really not even once in almost a year.

10 chronons in the lead atm. Since we're getting apparently about 2 chronons per hour, that's only 5 hours needed to quit playing the game

And it's counted (and line feed chars do make it into the blockchain, only the client's chat window and the chat view in https://www.huntercoin.info/blockExplorer ignore them)

adv_motion.txt

Voted - 9ee879a7cb66c5be7a57ef171ee37ec844df2c6deafa3a2fcfbd627d0a6a9ad8

Was gonna grab some coins and add some power to my vote, but price is up quite a bit, maybe next week

Edit: Man, blocks are coming in super slow, only like two confirms in 20 min or so.

Edit2: 70 min and still only 2 confirms. I guess game isn't really playable atm?

This would be cool, every extra bit can make the difference between voting being a dud and other voting rounds coming with more and more coins participating and actual influence.

I don't have too many coins, and sync is going really slow, but I vote for the fastest time to logout. I'll try to get synced and make it official.

And another time:  I've just updated the chain download, now it is up-to-date until block 1,295k.