posted details here too, could be useful
download link:
http://www.mithrilman.com/Huntercoin/Download# released a new version of Huntercoin: Mithril Edition (HUC:ME) : V 1.1.2 (339)#
This new version add a lot of new features, some of them was already announced in the past in some forums but never released till now. But now they are ready to be used, so here the list:
##
Pending Moves - The Hourglass icon is the key! ##
pending status 
That spinning (when enabled) icon, shows you which pending moves mode you are using. Clicking on it, you can chose your mode.
Enabling the pending moves (orange icon) allow you to monitor your targes hunter pending moves.
Note: because of performance reason, the clients shows only your current Targets pending moves, so if you are interested in following someone's move, you have just to add that hunter in your target window.
Pending Moves: Disabled 
If you ever need to hide all pending moves, this is the mode you have to choose.
This could be useful if you have many targets and wants to take a look on the map without all that black lines
Pending Moves: Enabled 
The "Enable" option is the basic pending feature that consider that the pending move will be added to the blockchain on the next generated block.
Unlucky often this is not the case and the move will be accepted a block later, this is why there is the Enanched pending mode, see next.
Pending Moves: Enhanced 
The "Enhanced" pending moves mode, consider that a just sent transaction takes 2 blocks to be added to the blockchain, so the probable enemy path have to consider, as the starting coordinate, not the current hunter coordinate but the next. So, to have a better idea where and when a hunter is going, this feature should be the preferred choice.
The only reason to pick the basic mode is when you see that your moves take only 1 block to be accepted.
This isn't very common but could happen, so it's up to you to choose the best mode in a specific situation
##
Automatic Behaviours and Actions ##
Behaviour Actions configurations 
I've introduced the concept of behaviours actions, but to explain this, let me take a step back... what's a *Behaviour*?
As i said I wanted to reduce at minumum the advantage that bots have over humans, so while it's not possible to exclude bots from the game, why not implementing a framework that allow anyone to create his own bot using my client and then maybe share/sold/rent it on a market?
This is the core idea I had and I'm planning to implement it, including the market thing.
This is a big challenge but I've already done a lot toward that direction, because my framework is pretty stable now, and I've created some behaviour using it (and more will follow) and if the game will be successfull, I'll dive into sharing the SDK with anyone to code and put on a future marketplace their creations.
Anyway at the moment what a player can do is to use one of my implemented behaviours, and this image shows an example about how you can expose Behaviour Actions throught a Generic Behaviour (a generic behaviour is a behaviour that's not bound to a single hunter, but coordinate actions from an higher level, think of it as a god behaviour, he can create hunters, transfer them, expose generic/troop/target actions, etc...
In this image you can see how actually the "Commander" behaviour configuration looks: actually any of the shown options is a Behaviour Action, that could be triggered, depending on the context (your hunter, an enemy hunter, or generically) by a button in the Behaviour Actions window (furter explainations below)
Behaviour Actions window 
This is how the Behaviour Actions window looks like.
It has 3 tabs (excluding the last "?" tab that just shows a little window description)
- Generic tab is where you can trigger generic actions (not linked to a specific hunter) like the "Show Enemy List" or "Show Bank List" actions.
- Troop Tab contains the list of actions that can be triggered when you have an active hunter in your "My Troop" window. those actions are more powerful than others because they can add to your hunters some automatic behaviours and configure easily other complex Behaviours (see the Collector behaviour)
- Target tab contains a list of actions that can be triggered when you have an active target (Target window). An example is the "Estimate Loot" action
let me show you some behaviours actions examples:
Bank list (available in the Generic tab) 
This is a sample result of the "Show Bank list" action, here you can see a sortable grid with informations about current spawned banks, with current remaining life and coordinate.
Clicking on a bank will center the map on that coordinate.
Enemy hunters (available in the Generic tab) 
This is a sample result of the "Show Enemy List" action, here you can see a sortable grid with info about current enemies on map.
The last column (Recycle) shows if the hunter is going over a bank (probably to recover himself).
Clicking on a hunter will center the map on its position.
Estimate Loot (Troop hunter) 
This is a sample of the "Estimate Loot" action used in the Troop panel of the Behaviour Actions.
You can see in gray the queued path (not yet commited) of one of my hunters and in the right upper corner you can see the result of the action that says that going there i can collect about 39.6 HUC.
When the hunter has already an active path, this feature can be useful to see the estimated difference between actual and queued/pending path estimated income.
The computation doesn't take into consideration other hunters that are collecting on the same area.
Estimate Loot (Target hunter) 
This is a sample of the "Estimate Loot" action used in the Target panel of the Behaviour Actions.
This is similar to the "Troop" version but it can't show you queued paths of enemies, but in future i could show the estimated pending path value.
Actually you can see how many coins your target is going to collect going on his actual path (30.25 in the sample image)
The computation doesn't take into consideration other hunters that are collecting on the same area.
Collector automatic behaviour !!! (Troop hunter) 1/3 - Intro 
This actions can easily configure an improved version of the previous "Simple Collector" behaviours i released on previous versions.
This is an example about how using an action you can bound an automatic behaviour to one of your hunters, without the need of configure the behaviour like before (it's very easy!!)
The Collector Behaviour is useful to collect money while you are afk or you can't keep staring at the monitor constantly.
It's highly configurable and it's compatible with other (planned for the future) behaviours that can try to keep you safe from enemies, or be aggressive, and so on.
Collector automatic behaviour !!! (Troop hunter) 2/3 - When Coins End
In this image you can see the available choices available for the collector configuration "When Coins end" parameter.
This is useful to choose what to do when there are no more coins on the area you are harvesting (area = Target Area coordinate expanded by Sight Range parameter).
- If you choose "*Keep Looting*" your hunter will stay on that area until he has collected the amount specified in the "Max Loot" parameter, then will return to the bank.
- If you choose "*Remove Behaviour*", when coins end the collector behaviour will be removed from the hunter, so the next (eventual) configured behaviour can run, or your hunter will stand still there undefinitely waiting for your inputs.
Advanced tip: you can chain several Collector behaviour togheter because only one of them can run at a time on a specific hunter, so adding multiple cascade collector with the action "Remove Behaviour" is useful to harvest multiple areas - If you choose "*Go To Bank*" well... when the coins end your hunter will find the nearest bank (or stand still waiting for a bank to spawn near him).
In any case, to find a bank the Max Bank Distance parameter is used, so you can chose if you want to go only to banks near you, or take a long journey, anyway if a new bank spawn near you when you are already going to a bank, the nearest one is chosen (so it's optimized to go as fast as you can to the nearest bank)
Collector automatic behaviour !!! (Troop hunter) 3/3 - When Arrived at Bank 
In this image you can see the available choices available for the collector configuration "When Coins end" parameter.
When the behaviour decide that you need to go to a bank, the alghoritm to find a suitable bank is the same: find an available bank that can be reached at most in "Max Bank Distance" blocks.
But what to do next, depend on the choice you make here:
-
ReturnToTargetArea: when you deposit your coins to the bank, then you'll go back to your Collector target area to keep doing the harvester.
-
Recycle: when you chose to Recycle, then you stand on the bank for 3 blocks in order to be removed from the game and have your hunter cost refunded.
Note that if you chose this option, then the alghoritm to pick up a bank take into account the need of having to wait 3 blocks on the bank, so if you chose e.g. 60 as maximum bank distance, than only banks at 57 blocks (60-3) are taking into account. Of course only bank that have at least that amount as remaining life are considered ##
closing notes about Behaviour Actions ##
Active behaviours 
To see the active behaviours running on a hunter you can right click on your hunter in the My Troop window to see a contextual menu that shows at the end a sorted (by priority) list of active Behaviours, each one with its own visualizing style to recap the main parameters you've chosen.
In this example you can easily see that my mmtest hunter has an active Collector behaviour, with a target area set at coordinate 281;94 and is harvesting an area of 5x5 cells around that coordinate, with a maximum loot of 100Huc and that when no coins are available at that area the hunter will go to the bank and whenever he goes to a bank (because of 100 huc reached or because no more coins available) then he will recycle!
Configure Behaviours 
Like in the previous versions of the client, you can setup some of your behaviours with preconfigured parameters and pick them from the list of available configurations, clicking the "Configure Behaviours" contextual menu on a hunter in the "My Troop" window.
However I consider this an obsolete way to apply behaviours on hunters (but still useful for some kind of behaviours), anyway this window is still useful because now you can drag and drop your active behaviours chosing their priority (they are sorted in priority order).
Priority is important because it can impact on operations: the wrong order can lead to unpredicted results.
There isn't a generic order valid for any mix of behaviours, it all depends on behaviours that are chained togheter, so refer to specific behaviour documentation to understand the consequences.
There are other behaviours ready to be used, but will talk about that another time because, even if they are usable, they need some tweak, anyway you would want to try to configure your own Scary behaviour, that will allow you to automatically
try to run away from incoming enemies, while at the same time warning players that are using my client about staying away (a fun way to interact more with players). I will talk more about this in another post!
##
Path Visibility Enhancement ##
Often there are moments during a fight where you need to see clearly where seeing paths is important to plan carefully our next moves, but when a hunter sets a complex path seeing it clearly is difficult, this is why I've implemented some nice features.
- There is a new way to see paths now, numbers on blocks are more visible and animated in succession to see how the path progress.
- If you zoom out enough, numbers are replaced by an animation that progressively highlights a single segment following the segments path succession
Those two features are nice but not enough, so I implemented another feature that let you easily trim out the path at your desidered lenght, here some screenshots to show you how:
normal path (look to the left, the menu to pick the path size)
this one is the same (pending) path, that has been trimmed at the 8th point as per Max Visible Path Lenght settings
this one shows that the queued path aren't affected by the Max Visible Path Lenght limit
I created a short video to see this in action, here the link
here the link Let me know your thoughts!
Enjoy!
) and the server can barely run a daemon that check new blocks incoming and a "simple" game server implementation for realtime chat and something more, so need to understand costs, etc... ...
