Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Mithril Man

Pages: [1] 2 3 ... 32
Technical / Support / Re: old wallet wont load
« on: January 20, 2017, 09:36:14 PM »
i faced some cases of corrupted wallet that couldn't be recovered without effort on huntercoin-qt so months ago i created an utility to open a wallet with berkeleydb dll and recover private keys to import on a fresh wallet, i sent you a PM if you need help, bye

Development / Re: Gameplay change (hard fork) wish list
« on: October 21, 2016, 02:46:55 PM »
as a side note about increasing hunter costs :

More people were playing the game when 1 huc was 1$, therefore 1 hunter was 1 $ (at the start) (upwards to 3$ at some points).
People stopped playing when the value decreased, not because the hunter cost in HUCs increased. this was long after, when a small handful of players were playing.

Having the high initial costs prevents the map from being saturated and increases risk for the dominator... as previously, he just blocked the entire map with hundreds of hunters

and, don't forget probably one of the main reasons why the price increased - the blockchain was 10gb in 2 months lol.. if we did not increase the fee the blockchain would be 1 TB by now :D

don't cheat :)
when HUC was 1$ it means that COLLECTING 2 coins you were gaining that sum.... it was kinda balanced: "you risk what you are able to try to collect", but incresing the cost to 200+5 +20xdestruct etc... you unbalanced the game, because the collectable coins per day is the same while the time to recover from a loss is order of magnitude harder

previously, when you lost a hunter, you lost 1 HUC. To recover its value we just needed to collect 2 or 3 coins
nowadays, when you lose a hunter, you need to collect 205 HUC  PLUS the times you triggered destruct*20HUC, so if you face an opponent and fight back for 5 times then die, you spend 100 in destruct fee + 200 of lost HUC value + 5 hunter creation fee... and to recover 305 coins you need to collect A LOT (just for 1 hunter lost!!)
if you think in therm of daily coin redistribution, you have on map (excluding crown) 8*1440 coins = 11520 collectable coins
if you now compare that with the lost coins for a lost fight, you have to collect 2.65% of the total daily coin supply, that's huge, compared to the previous version where you'd spent 1HUC and so you needed 0.0087% of total coin supply!

And i considered an average fight, but often you ended up spending more destruct, and this lead to a lose-lose situation if you destruct 10 times, becasuse who lose is losing:
205(huc cost+fee)+200(destruct fee)=405 HUC

and who win goes even:
200 (destruct fee) - 200 (gained hucs) = 0 HUC

if you want to have an high hunter cost, you need a high coin pool available, otherwise this is a pay-to-win game and not a human mineable coin

about skill, nowaday the needed skill is very low, I'm not against a competitive game, but you need a competitive platform before implementing a competitive game, and a big player pool too.
I'm pretty sure i could code a bot that would drain you money always going even in a 1vs1, so ending up without a winner (or a winner just because of lag/connectionproblem or human mistake, so more odds to the bot), and so I'm pretty sure your vision would change


Development / Re: Gameplay change (hard fork) wish list
« on: October 21, 2016, 12:12:55 PM »
I remember you said the same things more than a year alone (let increase price and see what happen) and we saw what happened, almost no one plays and fun is worse
Not blaming you, just exposing facts.
Now we should learn that increasing prices/fees was a bad choice and we should fix that
I know we have completely opposite views about this, you want a more "pay much win more (or lose much!)" attitude while i've the "pay less, win less/lose few (but more players means even more fights/chance to win)

And i didn't talk about distribution but your idea is a big anti-distribution system (like actually it is), where few people have most of the coins and you should consider this in your "cons" list
when a cryptocoin has value and it's worth mining, everyone mines it, when its value drops and it's not profitable, people stop.
Same for huc, if the amount of coins you can get playing huntercoin is worthless (whether looting or pvping), then no one will play (mine)...
there is the arguement about it being a game, but it isn't a fun game yet. There is a long way to go before it's a game for fun.. until then, it's a human mineable coin and therefore follows the above statement

without considering this is a game (but this can't be omitted) you can't really compare standard crypto mining with hunterocoin mining... if you see a valuable coin you mine it but you don't risk to lose already mined coin in the process.

about the fun aspect of the game, i remember lot of people were more than happy to play with hundred of players and even if they were facing bots, it was fun or at least a lot funnier than now)

about bot: with high price, i'm pretty sure that developing a bot would be on the "todo-list" of devs around, it's not a matter of cheap/expensive fees but about HUC price per se (and I'm pretty sure leaving out the HUC vlaue, currently bot aren't running only because of PVP costs (destruct fee) and even humans try to avoid fights if possible, except maybe trying to hit once or twice)

Development / Re: Gameplay change (hard fork) wish list
« on: October 20, 2016, 09:56:10 AM »
wiggi, it sounds like you would prefer a higher cost game with fewer players. did i read correct you would prefer ~50 individuals on the board at one time? is that not orders of magnitude too low for a "successful" global decentralized game? when you have time, i'd like to hear your thoughts on this one?

I had the same concern, but Wiggi and SnailBrain have good points. More expensive Hunters makes the system harder for someone to game. We have a recurring problem called the Dominator, where someone makes hundreds of them and takes over the map.

but this is not what he asked, point he raised was about the low population rather than the Hunter cost

About hunter cost i didn't share the same vision, the dominator(s) (actually i know there are 3 people sharing the map without fighting each other, or at least this were the situation when i stopped playing) and I'm pretty sure that a price increase is not an issue for them, they actually have so many coins that the risk to lose some is less than the potential gain to kill noobs, I'm convinced that the way to stop anyone from dominating is outnumber them, so cheap hunter will cause more player to join (and if they die they lose not much) on the other end the dominator(s) couldn't handle constant fights with many hunters, so they have to controll less hunter and anyway they'll be less efficient and the effort to be "ALWAYS ON" doesn't worth the ROI

Development / Re: Gameplay change (hard fork) wish list
« on: October 18, 2016, 05:28:09 PM »
if i remember the fee change happened after the first disaster after the specified height (not sure tho) anyway you could apply the same logic: after the first disaster with height > xxx apply changes, this way there is no risk that hunters with different value coexists.

Development / Re: Gameplay change (hard fork) wish list
« on: October 16, 2016, 08:33:01 PM »
it's a well known guess that having a low fee game and a prunable chain with an easy setup would bost the game popularity because actually what's prevent people from joining the game is the startup difficult and the cost to play, all other issue are secondary.

while we focus now on lowering the fees (even fixed fees are ok at this stage, we just need to have much lower fees) the other aspect is still unknown to me
did you wiggi code on standard old huntercoin code?
how far did we are about using new one with pruning feature?
I think we should release changes on the new huntercoincore.

Development / Re: Gameplay change (hard fork) wish list
« on: October 15, 2016, 01:56:50 PM »
Note that important state changes (hunter invulnerable, hunter is spectator, coins ghosted) can directly be calculated from
2 gamestate variables, either characterstate.stay_in_spawn_area or gamestate.nHeight, so visualization should be easy for all clients that work by fetching the gamestate from daemon.

3rd party client like mine, or external GUIs that relay on huntercoin/huntercoincore daemon, shouldn't implement any business logic that compute a status, but just reflect the status it reads from the returned JSON of the game_status call

So any new status should be reflected in those JSON returned.
It's not about lazyness, but about good software architecture practices and separation of concerns

Development / Re: [ANN] Huntercoin Core - ready for first testing
« on: October 13, 2016, 04:48:36 PM »
but as you know you won't be able to use a pre-pruned chain with an old wallet unless you synced from scratch with the old wallet attached and pruned along the way (or later on).

this is something i like to understand better
If i have an old wallet, what prevent me use it and -rescan on the pruned chain, if i'm ok with loosing all historical transaction but having an update utxo set?
At the end it's important to have an updated balance with utxo, so why shouldn't be compatible?
Or is this just a technical implementation limit?

Development / Re: [ANN] Huntercoin Core - ready for first testing
« on: October 13, 2016, 03:43:27 PM »
pruned-chain - will need a fresh wallet - 1gb uncompressed, 500mb compressed!UFN3hIbQ!gr14wf0rW5BgJcP7q0QAyJpRaR9v3tdYCpVK0iUnl4s

let me know how you get on testing with 3rd party clients

thanks, will try probably this weekend when you finish testing windows build
is this compatible with old wallets? no i suppose? (I think we need, if possible, an utility to port old to new wallet format)

Development / Re: Gameplay change (hard fork) wish list
« on: October 12, 2016, 05:33:11 PM »
some considerations:

1 - about blocks ghosted
I don't think that is a good idea because it limits at some extents the game for casual players who just want to go in, play some minutes and go out and didn't help about dominator issue, because my direct experience with them says that they are always active even for pvp (at least one of them). I'm always a beliver that the main anti-dominator will be having lots of players to face, so the more the map is populated, the less the dominators can ...dominate

this mode rises even some technical aspect to consider (but not that importants): the GUI should reflect that coins aren't pickable (so remove them from the map or change the aspect) and it should be clear to users, so game_state (thinking to my client extensions or other possible ones) should include that block is in "block ghosted" mode (but I think that at a gameplay level, that features doesn't fit well)
But i'm more concerned on the feature itself that technical aspects

2 - Hunter cost
(Talking about hunter cost, we should consider even other fees, Destruct fee is INSANE and prevent having a fun PVP, it should be set to a 1/100 ratio , so if a hunter costs 10, a destruct costs 0.1)
Hunter cost is not an easy aspect, but I think that's better to have an overcrowded map with lot of human players that an empty one with just few players.
This mean that in the long run I'm for popular fees and the blockchain bloating has to be solved with technical implementations and should not be a limit of the system.
Would be nice to change the cost dynamically but various proposed ideas have pros and cons but I'm not fully convinced by any suggestion.
Let me explain replying to foglight:

A) regular scheduled hard-forks to update the hunter_cost
- ex, if its scheduled once per 100 days, this could be a simple solution to keep the costs within some desired $ range.

B) hard code cost of hunter to usd value
- ie, $1 dollar per hunter. continuously calculated via exchange rate

C) hunter_cost = median(num_players_per_sq) * A; // where A=100 or some other constant.

A) is too invasive. Hard fork is something that should be avoided, it requires exchanges to be updated and legacy system too, with the risk of causing incompatibility, etc...
Personally i'm against this solution.

B) being bound to a FIAT could change constantly the balance between the PVP potential income and the Looting aspect of the game. This could be at some extent positive because the game dynamics change constantly and at a given time, some action my have a better ROI than another. On the other hand this could help the dominators, because if huc price increase, hunter cost decrease and he may build up more hunters to collect. But low price mean even that more player can play, so he would have an hard time fighting in pvp.
This mode can be fun, but the problem i see is that it would be quite tricky to be implemented in a proper way: a player should know in advance how much he will pay for an hunter, so how did he get that value? from where? a decentralized coin shouldn't depend on a centralized asset or resource, so how did you solve that?

Pegged currencies attempts, afaik, have all failed in their implementation, they aren't reliable and as i said we should avoid being dependend on external services
I'm not against the solution idea per se, but technical implementation prevent this solution to be implemented properly

C) the goal should be to stimulate the game adoption, and the formula that "the more players the more it costs" goes to the opposite direction, moreover the dominators could create lot of hunters to increase artificially the price, preventing casual players to join.
Probably a curve is a better choice, because you can chose target areas where the cost increase/decrease, but anyway a cost based on the numbers is something that, without an account system, could be artificially changed to dominate in another way

Another aspect to consider when talking about dynamic hunter cost, is that the cost itself is the PVP value too, so if i spend 1 HUC for a hunter and you spend 100, if i kill you i gain 100 while you gain 1, not sure this is what we want... and could be a possible argument fom players... if using your formula i join a populated map and spend 100, while the dominator had time to create 100 hunters at a very cheap price, i would pissed off to be killed by him... a lot :)

An alternative could be (but i'm not fully convinced from this too), that the price change every XXX blocks, linked maybe to a fixed disaster
e.g. once every 2 days and 2 hour (roughly 3000 blocks) so that no one has advantage on timezone because of the 2 hours offset that happen every disaster (let me call this concept a "game session")

So everytime the map is cleaned, the hunter price change, based on the previous game session.
We could then chose how to change it, It may change:
- randomly in a range of values
- using a formula that takes into account those variables :
   * previous game session population
   * previous game session  fee cost
   * random variation
   * previous game session game_fund amount (the amount collected only during that game_session

note even that the "game session game_fund amount" is a vauable information that can be taken into account to even distribuite all that amount into the map, as bonus coins or other things, so that we don't risk to run out of game_funds!

I wanted to write more but it's late, sorry

Development / Re: gameFund - 2017
« on: October 12, 2016, 02:54:51 PM »
ok back up a second...

Do these gameFund HUCs exist as part of the 48 million total supply?

yes they are parts of the total supply because are the fees collected during the game (not sure about the total suppli, wasn't 42? could be wrong)

Development / Re: gameFund - 2017
« on: October 10, 2016, 05:22:06 PM »
I fear a big part of that gamefund comes from my attempt of pvp during past monts after insane fee increase :|

Anyway about its usage, it's under discussion, imho it shouldn't be used to fund devs or marketing but only for ingame purpose, because that funds was created with that purpose and i'm against changing its goal.

I think that using it to spread money around in random places at specific times during the day ("it's raining coins!") could be a funny (AND SIMPLE) way to start using it.
e.g. like if every 4 hour (240 blocks), for 1 hour (60 blocks), 50 hucs per block are distribuited randomly over the map (roughly 3000 coins per event)

next step could be a little trickier: the gamefunds could be used to create random NPC enemies that carry some, that can be both aggressive (they could kill humans) or passive (they run away) in order to implement a simple ingame AI, that would be more unpredictable than human because it doesn't require to wait the tx confirmation in order to move and human players can't know for sure where the enemy is going the next block (no pending move to see). Of course it will have a predictable AI, but if the next move consider some randomness than it could work, and anyway hunting for NPC could be funny.

Those implementation aren't hard to implement if someone knows QT/C++ (first one would be really easy) but this isn't my duty nor my environment (I haven't a QT environment ready), I wish i had time to dive into it but I haven't and it seems no one really spend time on this.

Hopefully if the price climb up like today for some days (reached 0.00005 BTC today) the dev funds could attract some devs, but we need a fork even before, because with current price, creating a hunter costs ~ 0.00005 * 200 * 615USD = 6.15$.... way too much.... and any destruct attempt cost 0.615$ ... so the more the price rise up, the more the game is for the elite (and currently i see that always the same persons play it)

TBH If I ever found the time, I think I'd fork the coin because the other aspect that's hard to handle is that discussions take too much time to reach any consensus and there are even very few persons involved actively in consensus decision, it's a pity and this causes the project fossilization

Development / Re: Gameplay change (hard fork) wish list
« on: October 03, 2016, 10:48:17 AM »
This is the reason why i wanted to remove color system and introduce the account system, you could then allow "friendly fire" to hunters of the same account, and in future you could add the guild concept where accounts register too (imagine a special name/value that create a named guild/temam, of course that team will have an associated address and an account name/value could subscribe to it, nothing hard to implement, is just an address reference

You mean disable friendly fire between hunters of the same account? That makes sense, yeah, but guilds would ruin things a bit. If friendly fire is the price for not declaring ownership of multiple Hunters, then people who want to avoid paying an increasing fee for buying too many of them will just create their own guild and fill it with pseudonyms of themselves. Friendly fire would thus be avoided, negating the utility of the fee. Can you think of a way to make that unexploitable?

not time to read all now, but about the hunter creation fee cost, as i said here previously in this post
A fix to overpopulation, in the long term, could be the implementation of an Account system, that allow you to create few hunters at a decreasing price each one, but limited
(e.g. 1st hunter in game costs 50, 2nd 40, 3rd 30, 4th 20, 5th 10 and you can't have a 6th in the same account (just throwing random numbers but explaining the rational)

so basically i didn't proposed a progressive incremental price, quite the opposite, but with a limit number of hunter that an account can create
so you pay the higher fee for the first (but lower than now of course, in my example it was 50) then 40 for the second, then 30, etc... until you fill your 6 available slots
so if someone wants to "cheat" and create lot of accounts with a single hunter, they pay the max for each one

numbers aren't significant, just an example and need to be balanced
moreover we could add kind of powers to accounts, so that the hunter performance affect the account status (loyalty)
loyalty could lead to "lower fees" or more hunters that can be added (but always looks for balanced gameplay)
you may argue about the higher fee required for a noob to enter the game (that would work if fee were increasing instead of decreasing like mine) and my idea about this is to allow a player to chose if to enter in the competitive field (so with my fee proposal) or in a "training area" where hunters cost less but collectable coins are less and hunter's can't harm each other

sorry but can't elaborate more (@ work)

Development / Re: Gameplay change (hard fork) wish list
« on: September 30, 2016, 08:46:10 AM »
I just wish there was a way we could effectively make people pay an increasing Hunter creation fee the more Hunters they have... I assume they would just get new private keys to look like different people. One benefit of removing the color system might be that we could remove friendly fire entirely, forcing people to do everything under one key. Friendly fire would become the cost of anonymous gang attacks. But this would also reduce people's incentive to form teams, as ganking will be less effective due to FF

This is the reason why i wanted to remove color system and introduce the account system, you could then allow "friendly fire" to hunters of the same account, and in future you could add the guild concept where accounts register too (imagine a special name/value that create a named guild/temam, of course that team will have an associated address and an account name/value could subscribe to it, nothing hard to implement, is just an address reference

about the idea of random coins, this is already something i asked time ago, using the gamefund coin, but extending it, we could even re-design completly the map, removing (or reducing) the coin spawn areas and dropping random the coins, except few areas (that must be well designed) where most coins are and pvp is incentivated (this remind the old BGB concept of layered map, with a map zone that's for noobs and allow some little reward, a medium area where the risk increse and an high risk area where most of the pvp and $$ are centralized (and extending it too, the map could have different rules based on the map "level", so the "noob" zone could just have the HUC collection aspect implemented, denying the PVP, so no destruct allowed there

I think that, since we need an hard fork, a map chance should be mandatory

Development / Re: Gameplay change (hard fork) wish list
« on: September 20, 2016, 11:42:41 PM »
As i said in the past, a real "open framework" should have a turing complete scripting system that allow to insert validation rules for each custom world so that ANY node could validate each other nodes, just by running the custom transaction ruleset.

Now, currently this is a missing huntercoin feature.

do you mean every huntercoin node validates every gamestate?

Turing completeness ( and i quote "any function whose values can be computed by an algorithm can be computed by a Turing machine, and therefore that if any real-world computer can be simulated by a Turing machine"
now, we don't really need to go that further (Ethereum has it tho) but anyway to validate every custom transaction in any node, we need some custom language to specify the validation rules, and this way ANY huntercoin node can validate ANY transaction.

Imagine my example, in a scenario where huntercoin has a powerful scripting system, basically when i want to register a new game ruleset, I register the ruleset with all specifications like
- name validation
- allowed classes
- which action can be performed by a specific class
everything that's inputable in a name_update, should have a validation rule in the ruleset definition

this way, any transaction can be, at some extent, be validated.
I don't want to push too further saying that all the gamestate could be computed by any node, because it would cause too many computation effort (even if this would be ideal), so it's fine that the gamestate itself is computed by custom nodes that just decode the transaction that are relevant to their ruleset

this is why i'm against having just a name that start with d or X to say that that player uses other rules, because it's too much limited, while having an explicit "ruleset" field sounds more appropriated (and architecturally speaking is a lot "cleaner")
if you are worried about backward compatibility, lat say that if the name_update doesn't contain the ruleset property, it refers to standard protocol

About junk transactions, i were refering to invalid transaction (in the sense that were malformed for the ruleset, or invalid in their content) and that keep space in the blockchain without having value.

Think this way (and reply, because maybe i miss a bit here) what did happen now if i send a malformed transaction that contains invalid json in name_update?
Did i spend (waste) money and tx get added to the blockchain or did i get refunded and tx ignored?
In the past i remember that sending a malformed json caused the wallet to be corrupted (doh!) but what happen on the blockchain side?

fact: a malformed/invalid tx is sent

scenario 1: to prevent ddos/spamming, those txs are saved and fee deducted
result 1: we are filling the blockchain with junk data, causing a ddos to be at least a bit expensive

scenario 2: to save blockchain space, those txs are rejected
result 2: ddos/ing is cheap, but we save blockchain space

in scenario 2, the problem is that custom ruleset cannot be validated, so there isn't a way to say a tx is malformed/invalid, so all possible junks would be stored in blockchain (hope my though is clearer now)

of course if actually what happens is scenario 1, having "junks" is already possible, but the more the games, the more the possible junks

Pages: [1] 2 3 ... 32