Changelog - picture heavy

[Andy ONeill]

Unit Type Best Route Costing

Stable version committed.
Likely needs some more thought and work.
Including checking on memory usage.

[Andy ONeill]

Game

Least cost route colour change to purple.

I made this slightly transparent so you can still make out anything underneath.
When I tried it out I was a bit confused to see the line get darker and darker gradually.
Which was weird.
For a while I couldn't work out what was going on.
I then realised there were multiple calculated route lines being added which appeared on top of one another and hence re-inforced the purple colour to full opacity.

This is due to a bug in the process which handles move input.
Essentially, it recognises a click to commit a move and handles it, handles it again and again never resetting.
I've hacked in a temporary fix which just marks a click as handled.
There are probably other implications to this but I'll have to do a refactor to sort this properly.

[Andy ONeill]

Least Cost Pathing

I've refined the numbers used for this in order to improve results and lower the chance of couriers or pieces resorting to swimming.
The unit type based costing I implemented initially had issues whilst using metres per second.
It works far better when it has integer values as used by the original courier calculation.
For units, I now use the courier integer values or a high number for terrain which is invalid for that unit type.
That solved the pathing issues.
The result is good for best route.
Along the way, I've refined the elevation calculation used for couriers.
Also obviated the possibility of someone breaking pathing by entering fast movement values leading to <1 metre per second costs.

I still need to calculate seconds per pixel using the existing methods used for straight travel.
This was always going to be the case though.

[Andy ONeill]

Game

Move the best path calculation onto a background thread.
Show throbber whilst calculating
Overlay map with translucent grey panel to stop someone clicking again whilst mid calculation.

Background:

Whilst doing a little testing I was reminded just how much processing is now done for best path calculations.
If you choose a short-ish move then one to two or maybe three seconds calculation is likely.
I see no problem there.

If you choose a very long move across complicated terrain which has choke points ( like bridges across rivers ) then that time will increase.
If you choose an "impossible" route then the time it takes will increase considerably as the algorithm only finds many bad routes.

I'm not concerned about the time - a lot is likely to happen on that journey so it seems like something a user is only going to do quite rarely.
The throbber is one of those "spinning" petal things indicates that the app is working at doing things.
The overlay gives some more indication things are happening and stops you clicking repeatedly.

Here's one test routing:



I picked this to see the effect of an impossible route.
Someone is going to pick one.
That took 22 seconds in debug mode.
If I instead pick a location right of that stream where the piece isn't going to have to swim, this is almost as far but takes far less cycles and 5 seconds.
I think that move is still extreme anyhow so that time seems reasonable.

It should be faster with an optimised release compile and my PC has an old-ish i5 processor so it's low end for a gaming PC.

[Andy ONeill]

Game

Added "rubber band" for least cost movement.
A line between the Piece you clicked and cursor prior to clicking to commit your move.
This is a dashed thin line so it's immediately obvious the Piece is not limited to linear movement.



As usual in any first version I write of anything this is not intended to be 100% finished.
I still have to set position to where you click for any further moves and (somehow) calculate facing the Piece will have when it gets there.
The facing will require some sort of average along the last few cells of it's calculated path.

[Andy ONeill]

Game

Set "new" position after costed move.
Calculate new facing after same.
Clear previous rubber band when order is committed.
Previously the dashed line stayed between piece and where you clicked after the costed route appeared.
Although this then disappeared as soon as the mouse was moved it's a bit confusing to see the two lines there at once.

Rationalise least cost path building code so there's now one version rather than duplicated code for courier and unit versions.

In the picture below I've Clicked once to commit a costed move order.
Then I move the mouse and the dashed "rubber band" line is between that point I clicked and where the cursor is rather than Piece and cursor position.



The facing isn't at all obvious from the picture but I've tested the calculation and with debug output.
The way this works is it takes the fourth from last point and third from last point and calculates a bearing for each.
This is then averaged.
This is a simplistic initial version which only works so long as the two bearings do not cross vertical.
I'm still considering what to do about that.
The potential is that one bearing is 0 degrees which is vertical.
If the other is just left of that and say 359 then the average would be way out.
Despite a number of tries, I've not managed to produce this so it's probably quite rare, but possible.

My first thought is "just" to use the bearing for 4th from end to click if the difference is bigger than x degrees.

[Andy ONeill]

Game

Refining the end facing for least cost path.

A bit more testing showed some weird results for using 4th and 5th  from last points.
I get a more reasonable result using 9th and 10th.
If there's over 40 degrees of difference then the bearing from the 10th is used.

[Andy ONeill]

Game

Added focus grabber to busy panel.
This takes focus whilst the panel is visible and eats keyboard input.
Because it's a hungry growing grabber?
Not exactly.
This stops the user inadvertantly inputting whilst the system is busy processing things.
Or at least reduces the chances somewhat.
You can still click on other things outside the map.
At the moment.

PS
This busy panel also shows whilst a game loads which takes a few seconds and doesn't like being interrupted.

[Andy ONeill]

Courier Pathing

Fixed a bug in the scenario editor which was due to slope costs not being pre calculated for everything.
We may well end up removing or changing the way the courier path calculation works in the scenario editor.
It's increased in expense and hence the time it will take to run.
It will interfere with saving if it's till running when you try to save the scenario.
It's still quite easy to mouse over a HQ and start the process inadvertantly.
On the other hand, it's potentially useful to visualise the route that couriers or even units might take as you're building the scenario.

I also took paths generated from "real" moves and tried them in the movement animation proof of concept I built a while back.

[Andy ONeill]

Game

Setting up structure for generic order persistence.

I was about to work out the per pixel cost for least-cost moves when I realised I didn't want to add that costing to what I had.
The current movement allows you to do one move order then another for a piece.
This is not in a shape that could be persisted though.
The classes for orders were just sketched out.
I've revisited these and added some more detail and filled the obvious holes.

[Andy ONeill]

Game

Added Automapper.
Maybe not the sort of mapping you might imagine though.
This  is used to copy data from one class or object to another - the mapping done refers to property X in object A being "mapped" to the property X in object B in order to copy data from A to B.
The reason I've added this is I have quite a few new classes for the data relating to orders.
I want to (or will want to) hold this data in more than one place.
"Flatten" it out for some display purposes.
And persist in game saves.
All of which will be the same data but in slightly or very different shapes.
I don't want to write a stack of code to translate that data so a tool that does most or all of the heavy lifting automagically is quite handy.
A few of the shortcuts I took along the way are now looking a bit like they were mistakes.
I may need to sort out some classes which are already in use.
I'll try and avoid it but this might mean translation app(s).

I also made a couple of changes which improve the perceived load time.
This ensures you get the app window appear that bit faster and a bit more feedback as things happen.
It also reduces the chance a user will immediately start doing stuff with the UI whilst it's still busy loading a game.

[Andy ONeill]

Game

Increase the water costs for least cost
Started refactoring to improve structure of data and display classes

Loader

Fixing missing images

[Andy ONeill]

Army Editor

Mapping unit properties.

Fixed a bug - a new army could have a leader with no accuracies.
At least at the moment, a HQ cannot shoot.
They are still a sort of a unit though and need some nominal values to avoid an error.

[Andy ONeill]

Army Editor

Run time parameters will now make the loader full screen, like the other apps.

Allow editing strength for HQ
Set default to 100 on new HQ.
This will not change the strength on HQ you’ve already defined which will probably be the previous default of 1000.



Whilst doing some work on the mappings refactor I realised that HQ had a strength of 1000 and you couldn't change that.
A fixed value is incorrect - some armies would have substantial bodyguards.
I would imagine wherever Crazy Horse was, there's a lot of other pretty tough guys hanging out.
Other armies will have mainly staff officers.
There would almost certainly be some sort of body guards / reserves.

I've also "done" the mappings refactor for Scenario on the loader, scenario editor and the game.

[Andy ONeill]

All

Sorted out Scenario mapping, along with all it's various pieces like unit targets for victory points.
There's quite a lot of stuff goes into a scenario and several of our apps use it but with different requirements.

Remove the inappropriate dependency I was working towards breaking.
The mapping/objects translation work is now complete.
Which means I'm in a position to do the work I was about to do when I realised "uh oh.... there's a problem here".

It also means I can separate out the various functionality better.
Hence people who do not buy (say) the scenario builder will not end up with libraries containing scenario building functionality.
And the loader can potentially have a simplified slimmed down version of (say) a scenario to work with, as can the game.