GrogHeads Forum

Grog Friends and Affiliates => General Staff Support Forum => Topic started by: Andy ONeill on January 02, 2018, 12:08:07 PM

Title: Changelog - picture heavy
Post by: Andy ONeill on January 02, 2018, 12:08:07 PM
Hi all.

The idea of this thread is to list the development work as it's done on the General Staff suite of apps.
This will be fairly low level stuff. I expect parts will not be very easy to follow unless you know the apps well.
Version numbers will eventually start appearing.
This way it should be easier for early adopters and beta testers to see what's in each change and Kickstarter supporters can see things are being done.
Higher level descriptions of work including significant milestones will be posted to Ezra's blog.

The thread is likely to get quite long and demonstrate just how dull most development work is with numerous iterations before you see Ta Daaa.... this bit looks like it's working... oh... well now it looks like it's working.... oh, wait a minute... better fix that bit.  And so on.

Much more of a crawl with occasional detours in the wrong direction than a sprint to the finish.

If you have questions, expressions of admiration  ;D or whatever then please start a separate thread.
Thanks in anticipation.
Title: Re: Changelog
Post by: Andy ONeill on January 02, 2018, 12:18:58 PM
Army Editor

These changes are intended to make it easier to work with the army editor when the window is narrowed. So you can work side by side with reference material, spreadsheets, Netflix or whatever.

Gridsplitter added between left treeview panel and right detail panel. Hover over the divider to see double headed arrow, click and hold to drag width left or right.

Items marked for copying now have saddle brown background and bottom border which is also increased to 2px.
The lime green selected item background overlays this but you can still see the bottom border and make out which are marked to copy without seeing the right part of the item.

Title: Re: Changelog
Post by: Andy ONeill on January 03, 2018, 12:48:29 PM
Scenario Editor

Minor changes to scenario info view.
Increased height of form so stacked controls have more space.
Scenario name textbox will wrap and grow if it fills but still limited to 50 characters so it fits on the main window OK.
Increase height of Scenario Description textbox and allowed it to grow as user types.
Added a little padding to number of turns textbox so victorian font numbers don't look cramped.

Title: Re: Changelog
Post by: Andy ONeill on January 05, 2018, 01:13:39 PM
Scenario Editor

Bug fix
For the victory conditions, you should see a list of target units to destroy under each army with a maximum based on how many are present.
These ought to be based on the enemy army.
Hence, if the red army has 8 light infantry units then under the blue army there should be a line which shows light infantry with a maximum of 8.
If you load just the red army and open the form, then you ought to only see a list of red units on the right side ( blue ).
This was previously the wrong way round - so you saw the blue totals under the blue army targets and the red under the red.
Very obvious once you know what to look for and load just one army, then open the victory conditions form.

Now fixed so the blue list of units appears under the red and vice versa.
Title: Re: Changelog
Post by: Andy ONeill on February 14, 2018, 05:05:06 AM
The current code base is still largely prototypical and some parts are pretty creaky. Bugged even.
There will be a lot of refactoring on existing code before it can be re-used in the game solution.

At the moment I'm working towards enabling re-sizing of the map board.
In doing this I'm also rationalising bits of code in order to simplify them.
Also with a long term eye on re-usability and multi threading for performance.

Scenario Editor

Refactored out all the "magic offsets" so the board, map pieces etc all go in one container within what looks like a frame you see in the right hand pane.
Removed several canvases that aren't needed.
Rationalised map background image loading.

Title: Re: Changelog
Post by: Andy ONeill on February 16, 2018, 01:21:02 PM
Scenario Editor

First iteration.
Refactor to replace drag drop of units.
I've ripped out the old drag drop code which was buggy and pretty nasty stuff.
The old version could not support stopping the user dropping units on invalid terrain or each other, which we want.
Started replacing with a simpler drag approach.
Further work is required.

The cursor isn't offset and unitvm isn't correctly added to the lists it needs to be added to ( I just realised this as I type ).
Maybe fix up with another iteration tomorrow.
Title: Re: Changelog
Post by: bayonetbrant on February 16, 2018, 01:24:20 PM
it's cool to track the development :)

Us non-game-dev IT weenies can appreciate the headache it can be
Title: Re: Changelog
Post by: Andy ONeill on February 17, 2018, 09:28:37 AM
Scenario Editor

Dragging units off the treeview and around the board is stable now.
I spent at least 2 minutes trying to break it and it just worked.
Way faster than the original drag drop and a LOT less code.
Buggy unexpected dropping - gone.
The improved performance is particularly pleasing. I can drag a unity as fast as I can move the mouse and it just copes.

Not quite finished yet.

To do.
Invalid location like off board in swamp or water or another unit still needs handling.
Probably stick a fews seconds red flashing border on the unit and then it's gone if the user doesn't grab it.

Title: Re: Changelog
Post by: Andy ONeill on February 18, 2018, 03:58:46 AM
Scenario Editor

Minor refactor:
Both retreat point and pieces now use their center X and Y for positioning and the same contentpresenter style.
This simplifies/improves some of the code used for positioning and pathing.
Also another minor step towards allowing the user to dynamically scale them.
Title: Re: Changelog
Post by: Andy ONeill on February 18, 2018, 12:03:41 PM
Scenario Editor

Added bad terrain and collision detection for unit locations.
When you stop dragging, it checks what terrain applies and whether that unit type is allowed in that terrain.
It also checks whether another unit is overlapping.
And whether the unit is entirely on the board.
If any of these fail then the border is set to red.
If you don't move it within 4 seconds the unit is removed from the board.
Title: Re: Changelog
Post by: Andy ONeill on February 19, 2018, 03:16:28 AM
Scenario Editor

Bug fix:
If you dragged a piece that was already on the board, it was being added to the PiecesOnBoard collection again.
Anything in there is templated into a piece meaning there were actually 2 pieces where you'd expect one. As they were all stacked on top of one another it looked just like one. But odd things happened.

Dragging a unit already on board seemed a bit sticky to start off with.
This was due to only starting drag when the user moved over 2 so many pixels at a time.
A piece is relatively small though and the tendency is to start slow. Too slow.
Removing the minimum move check fixed the problem and doesn't seem oversensitive if you just click.
Laptop mouse pads might be an issue but designing a scenario without a mouse doesn't seem very practical anyhow.
Title: Re: Changelog
Post by: Andy ONeill on February 19, 2018, 08:13:35 AM
Scenario Editor

I've added scaling of the map board.
There's probably more to do, but it seems stable at the moment.
Anyhow, as you drag the corner or edges of the screen the map "board" will scale to fit.
It retains it's proportions.
In the below, I've dragged the size of the window down, reducing height proportionally more than the width.
This means you'll get a gap either side of the board if you're not careful but gives you total flexibility.


I've also (since taking that screen shot) horizontally centered the elevation and terrain textblocks.
Title: Re: Changelog
Post by: Andy ONeill on February 19, 2018, 01:32:55 PM
Scenario Editor

Minor refactor on piece dragging to reduce overhead.
Narrowed the scope of the piece dragging routed event handlers.

Refactored a load of mapping orientated code out of the mainwindow code behind into
Needs to be re-used in the game exe. Eventually.

Refactored out a number of public variables from mainwindow.
Title: Re: Changelog
Post by: Andy ONeill on February 20, 2018, 04:07:28 AM
Scenario Editor

Added user notification mechanism.
Textblock in menu bar shows a new message which then fades out.
Neatened up the "busy bee" which is used to show a long process is busy - during pathing calculations at moment. Now yellow with fine black outline rather than red.
Moved map scale and size to help menu

Added user messages explaining why drop location of piece is invalid.
Refactored some code around pathing.
Fixed pathing error when you drag HQ which is off board.
Title: Re: Changelog
Post by: Andy ONeill on February 20, 2018, 09:23:47 AM
Scenario Editor

Added Scaling of Pieces and Retreat Points.
There's a new slider in the preferences menu which you can drag. It goes from 20px to 80px, the default size is 35px. A px is a "device independent unit" and in theory 1/96 of an inch. Windows user settings alter that though.

The combination of Window resizing and Piece scaling should mean the game is usable on most sensible set ups.
At the risk of stating the obvious, there is only so much you can do on this.
Scaling units can make them bigger and they could then in theory overlap each other.
Bad things are likely to happen if you played a game like that.
In the below picture, I first reduced the size of the window down so it's pretty small.
That scales everything on the board down, which makes pieces tiny.
I then maxxed out the piece scaling.
The screen shot is just to kind of give you the idea, it's resized to 60% of size in case anyone cares about bandwidth.

Title: Re: Changelog
Post by: Andy ONeill on February 20, 2018, 12:10:02 PM
Map Editor

Marching ants prototype.
This is a proof of concept animating dashes around a polygon.
Title: Re: Changelog
Post by: Andy ONeill on February 21, 2018, 03:09:56 AM
Scenario Editor

Minor adjustments on menu items formatting
Changed piece size slider to use brass pointer template
Removed all allowdrop settings out the UI - dragging things round is now all using non standard approaches ( for performance) rather than "proper" drag drop.
Title: Re: Changelog
Post by: Andy ONeill on February 21, 2018, 05:10:32 AM
ModelLib & Scenario Editor

There are several libraries ( dll ) which are intended to be used in the various exe.
One of these is ModelLib, the "model" in programming terms is the data being represented and this contains a class called Map. Which is (surprise) all about the map. This is where what terrain is where is stored and has methods to read that data.

In order to give orders to units we want the user to choose a unit and drag to a waypoint.
With a "rubber band" showing the line it would take. Just a line from start point to where you're dragging or moving the cursor.

This is gaming stuff ( I'm a business app developer ) so Ezra designs this sort of thing and knows about game specific things like working out what terrain a line crosses.

Maybe this is interesting to someone reading.
There's this thing called a Bresenham line algorithm (
Which Ezra "just knows" about and explained is very fast.

I've been prototyping something to see whether this'll work or not.
I grabbed this guy's code: (
Which is nice and efficient, I particularly like the use of yield.

We don't have a game solution yet so I've temporarily bolted this onto scenario editor.
I needed 2 points. Somewhere to go from and to, so I used a retreat point as starting point.
Turns out that algorithm is very fast and takes less than a millisecond.
My machine has a fairly recent i5 processor so it's reasonably fast but I'm testing this in debug mode so which is slower than optimised code.


I'm using faked terrain checking with woods, water and swamp as invalid for anything.
On the top image you can see the line crosses woods and is an invalid move.
On the bottom image the line crosses nothing invalid and is OK.

You can also see some debug info I've put in top right.
I'm using a stopwatch to check performance and you can see the milliseconds and "ticks" elapsed. ms 0 means less than one ms which is fast.

The experiment shows excellent performance.
I'd expect even an old i3 and maybe atom would be fine with this.
Title: Re: Changelog
Post by: Andy ONeill on February 22, 2018, 03:49:10 AM
Map Editor

I've been looking into the work which needs doing on the Map Editor.
This is very much a prototype stages app.
Some work will see it stabilised, improved and sharing common code.
Short of dedicating my life, this is always going to be a relatively basic sort of a drawing tool.
I think also that drawing the map is by far the hardest part of scenario design.

Which got me thinking.

Some of you may of course be graphics designers so it'd be nice if you could use specialised software.
Others may want more sophisticated functionality but don't want to pay a couple of grand and spend 2 years learning how to use it.
Maybe some are like me - a developer but not so much of a designer.
Some others will be OK learning a little and doing some manual editing for something to work
Maybe some are even wpf designer/developers and already know XAML.

My plan is to try and include all these groups and offer more.
More is always good.

There's a free piece of software called InkScape.
This allows you to produce "vector" graphics by drawing or tracing.
I use it a fair bit for tracing stuff.
You can also convert graphics files to InkScape friendly format.
Once finished you can save the result as a .XAML file.

That can itself be edited and previewed in xamlpad or visual studio.
Xamplpad is a very lightweight self contained exe you just copy onto your machine, it's free.
You text edit in one pane and see the results in another.
Visual studio community is a pretty big install but also free.
I develop using visual studio.

As an experiment I modified the map designer so you can optionally load such a file.
I then fired up my copy of InkScape.
Because someone already expended some years working on InkScape there are a huge number of options available.
I picked a "pen", width and fill colour.
I then drew a wiggly blue line in inkscape.
When I drew this freehand it gives me totally smooth curves.
There's huge flexibility.
I could move, rotate or manipulate that little drawing in almost infinite ways.

I didn't bother with any of that because I'm just experimenting now.
I just saved my wiggly line as xaml.

This gives a bunch of stuff in a text file which I had to eyeball.
From that I picked the "Path" out of my saved file and put it in a canvas tag of a new .xaml file.
I did this in NotePad as a .txt file and then renamed to .xaml.

Ran my modified map editor and clicked the button.
The result was as expected and I get a line on top of my picture.
Because it's a control of sorts I can add some functionality to the map editor to work with it.

You might be thinking "If it's just about editing a picture then can't I just use a scan and be done with it?".
That'd be fine except the map isn't just a picture
Each pixel is a type of terrain - a field / road / woods etc.
Each pixel has an elevation.
With such a path I can write code works out which bits of the map it covers.
Allowing the user to say this area here is water.


This looks to be a good way to offer optional functionality for the power user.
Not everyone will want to bother but those that do will get a very powerful tool with huge flexibility.

Title: Re: Changelog
Post by: Andy ONeill on February 22, 2018, 08:56:13 AM
Scenario Editor

Investigating optimisation of pathing.
Pathing uses spatial A* and is a very expensive operation.
At the moment it's only used for couriers which will be an end of orders calculation.
Hence it doesn't really need to be super fast.
This is just as well because it can take a while.

I have this on a background thread and have experimented with multi threading the process.
The problem with that is it's no faster due to the expense of creating the necessary arrays per search.
I've neatened up the code but it's just on one thread.

Title: Re: Changelog
Post by: Andy ONeill on February 23, 2018, 07:33:19 AM
Scenario Editor

Refactor on place and points labels.
This improves the look, uses a more sophisticated approach for the objects.
Added mouseover effect on these which increases their z-index so they can be overlapped and still readable.
There's an anomaly in the way these were positioned, but this is cosmetic and can be resolved as part of the map designer work.

Now with rounded borders, a faded drop shadow and will respect the size of the text within.
With Victorian fonts:

With plain:
Title: Re: Changelog
Post by: Andy ONeill on February 24, 2018, 12:59:09 PM
Scenario Editor ( but will really only be used in the game ).

Replaced Pathing.
The original approach was a prototype but bugged, slow and could not be multi threaded.
It also only used very simplistic terrain efffects.

After trying several alternatives, Ezra gave me a bunch of links to investigate.
One of them eventually led to this library:
This initially showed some promise.
It turned out to be bugged and prone to running out of memory.
This is a bit of a problem in a live game.

Title: Re: Changelog
Post by: Andy ONeill on February 26, 2018, 08:05:25 AM
Scenario Editor

Some improvements to place labels and points plaques.
Replaced the bitmap images with clearer, easier to read vectors.
Although not implemented at the moment, the new approach would allow us to use different backgrounds or fonts for the numbers on the plaques.
Anyhow, this should make it easier to read for those of us with less than perfect eyesight and or when running on a small display.
Title: Re: Changelog
Post by: Andy ONeill on February 26, 2018, 09:18:11 AM
Map Editor

Improving handling of empty place names.
It's inordinately easy to add one. The whole cannot-fix-mistakes-you-make needs replacing but in the meantime at least don't read empty ones in.
Title: Re: Changelog
Post by: Andy ONeill on February 27, 2018, 06:57:08 AM
Scenario Editor

Stabilising pathing.
Also made some changes to terrain costings, simplified maths for diagonal moves and changed some types to integer for faster maths.

Title: Re: Changelog
Post by: Andy ONeill on February 28, 2018, 09:14:19 AM
Map Editor

Planning new approach to map editing.
When you draw thoings on screen they will be retained as objects which you can then select, move round and probably adjust  points on them.
You'll be able to fix mistakes at any point.

Created new Solution and started.

Title: Re: Changelog
Post by: Andy ONeill on March 02, 2018, 10:23:37 AM
Map Editor

Standardised and optimised grid line drawing.
Styled up the various drawing options.
Added fancy divider control


Ezra and I have been discussing shooting.
And cannons actually, but let's just talk about effectiveness of shooting.
This is pretty good at short range then drops off.
Graphed effectiveness vs range should look something like:


Rather than try and work out an equation representing this, I think the most practical approach is to have an array with a multiplier per percent range.
It's probably a bit different one weapon system to another as well so maybe there's two or three curves to represent.
Since our aim is to make as much as possible user configurable, such an array is likely to be user editable.
Title: Re: Changelog
Post by: Andy ONeill on March 03, 2018, 10:32:44 AM
Map Editor

Experimentation with patterns for a tree fill.
The prototype uses random combinations of png which is kind of limiting and so I've been working on using dynamically constructed objects.
A few of these look like:

The advantage of this approach is flexibility - the user would be able to pick colour and size of what fills a piece of terrain.

Title: Re: Changelog
Post by: Andy ONeill on March 05, 2018, 09:53:07 AM
Map Editor

First iteration: drawing a forest.
The way drawing areas works is you select your tool ( or you will once things are beyond prototype stage ).
You decide where you want your area ( forest ) to start. Click and hold the mouse button, drawing an area as you move the mouse.
When you release the button, the shape completes automatically. It's a polygon.
It's very difficult to "close" a shape precisely, so this approach means you just need to get near the start point and stop rather than absolutely hit it.

After some experimentation, I reckon the most "natural" looking way to do this is to randomly place the trees.
I do this by hit testing, within the area and not on a tree.
The size of trees is varied randomly and I'm using just one of several tree options.
Hit testing is quite a processing expensive process and of course as it progresses, there's less and less area it can drop a tree in.
As a result, it takes a few seconds to fill large areas.
Maybe I'm a bit weird or maybe it's because I wrote the code does this but I find it quite satisfying watching my forest grow.

This isn't going to give you trees perfectly up to the edge so I apply a background.
This is a texture generated at run time. The way this works, we could allow a user to pick the colours and proportions ( or not bother ).
So if your forest floors should be transparent then no problem, if you prefer a mix of browns or greens or everything sepia then this is all do-able.

As you draw an area you get an effect called "marching ants" the dashes animate around the outside. This will be used to denote the "active" selected area when you have multiple pieces of scenery on the map.
Once you finish you'd de-select your last piece and the finished map would have no dashes.
Unless of course you like em ;^)

The complete effect at 60%
A chunk at 100%
Title: Re: Changelog
Post by: Andy ONeill on March 06, 2018, 12:59:50 PM
Map Editing

More work on the algorithm used to place trees. The size is now reduced as the process runs.
Put a panel over the various options whilst the process is busy.
Added a quill-in-ink-pot indicator which shows how far through planting trees the proces is.
This runs quick for small areas but for large complex ones it can take a while.

"Spinner" wait indicator.
This is similar to the fairly common spinning petals used on web apps and appears on the right of the toolbar.

Line optimisation routine.
As you draw any sort of line on screen it generates a bunch of points. These are x y co-ordinates.
The aim of the optimisation is to remove unnecessary points.
It considers sets of three points in the line and uses some rather geometry to decide if they all line up.
It removes the central one if they do.
There's a 2 degree of variation allowed.

Title: Re: Changelog
Post by: Andy ONeill on March 07, 2018, 06:21:28 AM
Map Editing

Experimenting with drawing smoother lines in a separate solution just intended for this purpose.
To some success.
This would just be for "line" drawing such as rivers and roads.

If you take a look at some of the roads in images above you will notice there's a lot of jaggies going on.
This experimental method uses "ink". This is intended for purposes like drawing your signature for the postman. To smooth out drawings this tech uses some very tricky smoothing stuff with Bezier splines.


The above 2 pictures are crops of part of the window and the road/river is 5 px wide, so on my monitor they're magnified in the forum preview compared to the app running.
They're drawn as two lines on top of one another.
The dark wider one is "below" the lighter top one so it looks like an outlined shape.
We could allow selection of colours and width of both.

In an ideal world I'd write a more flexible algorithm, but that looks like it'd take way too long.

Title: Re: Changelog
Post by: Andy ONeill on March 08, 2018, 03:24:04 AM
Map Editor

More work on "line" structures.
The graphics you see on the screen are only part of the map story.
The game "knows" what terrain a unit is in based on a matrix ( a two dimensional array ).
That means once you draw something I have to work out what cells the shape covers so I can mark them as road or river ( forest / fields etc for other tools ).
Once you draw something it's shape is defined by a sort of series of points like join the dots.
With that fancy spline stuff, smoothed out shapes aren't just plain straight lines though.

My first attempt uses a sort of brute force hit testing around each of the points in the line.
Hit testing is quite an expensive action and there are thousands of such points.
The result is a bit slow really and I'm going to try plan B.

Title: Re: Changelog
Post by: Andy ONeill on March 08, 2018, 09:42:51 AM
Map Editor

New shiny improved way to find all the points inside a line.
This uses a different technique which is faster and can also be multi threaded.
Also worked out a couple of bugs in my code.
Still experimental but can be ported into the real app.
With a bit of neatening.

Title: Re: Changelog
Post by: Andy ONeill on March 09, 2018, 10:00:13 AM
Map Editor

Refactoring prototype drawing process towards production ready code.

Title: Re: Changelog
Post by: Andy ONeill on March 10, 2018, 05:33:47 AM
Map Editor Prototype

Many rivers aren't the same width along their length.
Today, I did a quick experiment with making a river widen from start to finish.
This seems pretty effective so I think I'll be adding this as an option.


Title: Re: Changelog
Post by: Andy ONeill on March 19, 2018, 03:01:55 PM
Scenario Editor

Fixed a minor bug with the place names display.
Changed pathing to take into account elevation changes. Climbing is harder except on a road. It's assumed a road takes best path going up and down hills.

Map Editor

I've done a fair bit of experimentation with stylus support for ink - this is definitely a good option and I'll be adding support for a stylus and "pressure".
I've also been iterating towards allowing the user to select terrain already drawn.
Using the prototype, you draw something and commit it. That's it.
My version will allow you to select objects you have drawn and delete or edit them.
There's only a load of code to show for this at the moment.

I've also done some investigation into storage options for the various pieces of map data.
This needs to be made secure for PBEM games in order to stop an opponent cheating.
It'd also be a good idea to drive down the size of files.
I'm thinking of zipping up and encrypting all the files into one.
Title: Re: Changelog
Post by: Andy ONeill on March 20, 2018, 02:19:34 PM
Map Editor

More work towards allowing you to switch between drawing modes.
You can now actually draw a forest and get it to appear.
Terrain objects are now numbered with an Id so the app knows which are what.
"Children" of these eg the trees which appear to go inside a forest are allocated this id so you can tell which trees are associated with a particular forest.

Prototyped a tabcontrol which allows you to arrow through it's tabs ( less intrusive than clicking tabs ) for the left panel.
Added the templates etc for this into the map editor.
Moved the existing drawing list into this.
Second tab which will allow you to pick a terrain object already on the map is as yet just a stub.

In the picture below, Drawing Options is the current tab.
Click the chevron to the right and it switches out to Edit Terrain

Title: Re: Changelog
Post by: Andy ONeill on March 21, 2018, 05:55:03 AM
Map Editor

First cut of the Edit Terrain tab.
In the screen shot you can see I've drawn a bunch of woods and the list to the left refers to these. The number is their ID and incremented as you add each terrain object.
Selecting one of these on the left gives the corresponding terrain on the map a "marching ants" animation. The dashes in the screen shot are moving in the real thing.

Title: Re: Changelog
Post by: bayonetbrant on March 21, 2018, 05:57:32 AM
The marching ants effect is a nice suble way to suit what's selected
Title: Re: Changelog
Post by: Andy ONeill on March 21, 2018, 09:58:01 AM
The marching ants idea was Ezra's. 
He thought it couldn't be done though  :D  ::)

It's obvious which one you're working with, but you can see the content and it doesn't cover other stuff impact image quality like eg a dropshadow would.

I was going to make the animation work in all "modes" but it's quite processor intensive and I want to keep the hardware threshold low. ( Within reason, functionality and time expended developing are also important ).

If the animation is running whilst you're drawing there's a noticeable gap between the pen and the ink appearing following it.
Ink offers smoothing which is huge for anyone isn't some sort of graphics ninja.
Presumably that smoothing is also quite processor intensive.

Rather than spend weeks optimising things nobody cares about, the simple fix is to just do the animation whilst in edit mode.
If you just drew a lake or woods then you know which one you just drew.
The effect is also a bit distracting so I think this is a plus all round.

Title: Re: Changelog
Post by: Andy ONeill on March 21, 2018, 02:15:28 PM
Map Editor

clipping canvas so you don't get weird stuff happening when you draw outside it's bounds.
I found it kind of funny the first time I drew a forest over half the options in the left tab but...

Choose a terrain in edit mode and hit the delete button. The terrain and any children (trees if it's a forest) are removed.

Stop user drawing unless they're in drawing mode

The outline of woods isn't as definite as I'd like.
Added very fine dotted line round them, which seems to work.

Reclassifying some of the drawing types and removing pluralisation

First iteration of drawing Lakes.
Title: Re: Changelog
Post by: Andy ONeill on March 23, 2018, 01:19:00 PM
Map Editing

Shook out some bugs and added waves to Lakes.

Title: Re: Changelog
Post by: Andy ONeill on March 24, 2018, 10:50:48 AM
Map Editor

Setting the colour of the ink you draw with depending on what terrain you've selected to draw.
Water is blue, for example.
Title: Re: Changelog
Post by: Andy ONeill on March 25, 2018, 01:35:28 PM
Map Editor

Added swamp.

Title: Re: Changelog
Post by: Andy ONeill on March 26, 2018, 04:23:53 AM
Map Editor

Added Fields.

The fill on these is randomised using the same mechanism as the woods background. I could potentially allow a user to customise the colours and frequency used for both.
Title: Re: Changelog
Post by: Cyrano on March 26, 2018, 09:22:51 AM

That is all...

Title: Re: Changelog
Post by: Adraeth on March 26, 2018, 09:44:40 AM
It feels like an excellent engine ... i am here wonder how many battles i will edit with this new UMS .... work hard and bring it to us  O0

thanks for every update
Title: Re: Changelog
Post by: Andy ONeill on March 27, 2018, 05:20:14 AM
Hi guys,

Good to see people are keen.
I hope that lasts  :)

I'm still a while off completing the map editor.
This version will have some ( I guess quite big ) files associated with a map that you use just to edit them.
As you draw there are many points define the line you draw. These will be saved to files and of course "many" anything means big.
I plan on zipping these though.

The prototype you may have tried only has the areas you drew until you click that commit button. They're then copied onto a picture and gone.
You make a mistake then you have to live with it or start again.
This is the nature of prototypes.

The new version will retain all the data so you can edit later and retain the quality.
It is planned to allow you to export vector pictures ( probably pdf ) so you can print a high quality map to poster size.
When playing the game, these terrain objects probably won't be used and you'll instead effectively use a picture of the map as a background.
I might think about giving the option to retain those objects instead but the large size would mean we couldn't support transfer from a pbem / live server as is planned. There's also a fair bit of overhead in stuff like arranging all the trees in a forest.

Then there's the actual game to write.
The pace probably looks pretty glacial from an observers point of view but it's pretty quick for development generally.

Another thing worth mentioning is that the apps will also be improved after release.
As we see issues, receive do-able suggestions or I think of stuff then they will be added.
This is a suite which is intended to have a long life time.

Title: Re: Changelog
Post by: Andy ONeill on March 27, 2018, 09:54:49 AM
Map Editor

Added City.

I spent a while thinking about how to draw a convincing looking city.
This works with a sort of vector scan of a real map.
The user will be able to pick from a number of such models but they don't really scale so well.  I have three. I did what I felt was the least convincing first as a proof of concept.


The image I see in preview is about 1.3 x the original. It'd also probably look better if I was more careful about drawing the shape.
If it looks a bit abstract, that's intentional.
Title: Re: Changelog
Post by: Andy ONeill on March 28, 2018, 03:34:43 AM
Map Editor

Here's another option.


I'll do a couple more pre-built ones.
Clearly, it's impossible to offer something for every single sort of city people might want and we want flexibility to encourage people to get creative.

I'm going to allow the user to add specific buildings.
You can't really beat the human brain for working out sensible layouts.
This will offer the flexibility required to place a house next to a road or river and another next to it.
Villages will work better that way and if you have the time and energy for a complete city then you can go wild.
Those that don't care and are happy with an abstract rectangle kinda looks like buildings.... well they're already covered.

There will be another option to import a picture. You would draw an area on the map set it to your picture and allocate a terrain type  to that. City will be one option. This will be necessarilly rather fiddly but is the only realistic way to cover some possibilties. Bear in mind the entire map can also be a picture if you want buildings scattered all over a massive city.
Title: Re: Changelog
Post by: Andy ONeill on March 28, 2018, 09:16:20 AM
Map Editor

First cut of contours ( for hills ).

Not terribly exciting I'm afraid.
I still need some way for the user to say what elevation each contour is to be and decide how to  display that for review. Probably when selected.

When I did this I drew several contours inside one another and found a bug.
Pretty nasty one actually.
The animation which does the marching ants wasn't always stopping and that's very bad because it's a resource hog.
Fixed that.
Title: Re: Changelog
Post by: Andy ONeill on March 30, 2018, 12:57:42 PM

Added Square to formations.
After some discussion we came to the conclusion that Infantry will be able to form square but light infantry will not.

Map Editor

Added setting height to contours.
This is in "units". There's a factor which converts these to metres.
Elevation units vary from 0 to 255.
The reason for this is due to how elevations are held and the way we intend most maps to be built.
Contours are intended as a fallback because drawing a map using these can be pretty tedious and there is no gradation between layers.
The preferred approach is to use a picture with white throug shades of grey to black.
255 shades of grey.
We're the team that just keeps on giving.
More than 5 times the grey of those colourful books  ;)

In case you missed earlier posts.
The contour with the black dashes corresponds to the one selected in the left and it has a "marching ants" animation makes those dashes move round. You will not miss which piece of terrain you selected.


I might hide the id over on the right since it has no particular meaning to the user. That's what internally identifies the piece of terrain but you will never have to actually know that. It should quickly be obvious to any user that the most recent terrain they drew appears at the top of that list and the first at the bottom. It will scroll if you draw a lot.

Title: Re: Changelog
Post by: Andy ONeill on March 31, 2018, 09:19:52 AM
Map Editor

Added roads.
I'm undecided about the colour of the outline and fill.
Because black looked a bit harsh I've made it fairly fine ( 1px ) and dotted.

You will notice that a road always has a line all he way round it. That's because it's not clever, it doesn't know part of it is on top of another road.
I will probably give an option to combine all roads into just one shape for making the map "picture" at the end of the process to avoid that effect.
I'd have to try it and see but I can't think of any bad side effects from doing that.
Doesn't mean there aren't any.


I hope everyone is enjoying Easter.
Title: Re: Changelog
Post by: Andy ONeill on April 01, 2018, 09:55:06 AM
Map Editor

First cut of Rivers.
When you draw them initially they're a line the same width like a road.
On the edit tab there's currently a prototype button with a > on it.
This applies ink "pressure" along the stroke you drew for the selected river.
It does so from the end you started drawing.
There'll be a < button to do from end to start. Although drawing a river that way just seems wrong to me.
I'll do some better symbols for the signs rather than lt and gt signs.
We also need a way to specify width since rivers will vary a fair bit.
If you use a stylus to draw a river then you can alter the pressure yourself manually.
For anyone unfamiliar with stylus - the higher the pressure the thicker the line you draw.


Similar to roads, you'd currently get a line round any bit of water. I'll allow the user to combine lakes and rivers into one compound object which will avoid that line across joins I talked about in the roads above.
Title: Re: Changelog
Post by: Andy ONeill on April 02, 2018, 08:46:31 AM
Map Editor

Finished the buttons for setting widening on rivers programmatically.


The chevron pointing  to the right will make the narrowest part the end you started your ink stroke from.
The one on the right does so from the end ( which seems weird to me but maybe someone will want to draw that way ).
The rectangle makes the width equal all along.
Title: Re: Changelog
Post by: Andy ONeill on April 02, 2018, 11:46:26 AM
Map Editor

Prototyping combined water.





Note that the waves on the lake are in a layer below the combined result. They're still there, you just can't see them. I'll fix that once I've shaken the bugs out of this method.
Title: Re: Changelog
Post by: Andy ONeill on April 03, 2018, 05:48:04 AM
Map Editor

Another iteration on combining water.
You can now combine and split water.
When you combine it hides the separate objects, when you split it will show them again.
Combined water appears in the "correct" layer so waves are on top of a lake once combined.
It's actually a separate object and the process of working out how the various shapes combine is pretty expensive but only takes a couple of seconds on my i5 machine in debug mode. It will be faster in the real thing - debug code is not optimised by the compiler and Visual Studio (the development environment) isn't exactly lightweight.

Title: Re: Changelog
Post by: Andy ONeill on April 04, 2018, 04:13:36 AM
Map Editor

Added roads to combine / split logic.
They go on top of water.
Submerged roads aren't terribly practical.
I reckon some people will want to dash off a quick map as quick as possible and this allows you to not bother with bridges.

Fixed a bug which was eating processing.


Title: Re: Changelog - picture heavy
Post by: Adraeth on April 04, 2018, 06:16:08 AM
Roads (instead of bridge) over troubled water  ;) ... excellent idea; yes i am one of those to make a fast map to play almost immediately
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 05, 2018, 03:28:41 AM
Map Editor

I might have explained this earlier but maybe at the risk of repeating.
Which terrain is on "top" isn't just a visual thing.
There's a 2 dimensional array of terrain type used for spatial A* navigation and for tactical movement.
This will need to be calculated at the end of drawing a map.
Whichever piece of terrain is top wins and that's what the square terrain is.
There are 1155 x805 "squares". They're 1px x 1px  - and very small.
The grid you see on the screen shots is 35x35px.

A road over a river makes the cells it crosses road and a crossing point. Your courier might decide to swim across if the alternative is a very long distance and a river is narrow. Combat units will not.

Development work, largely internal:
Changed background colour of swamp to green (from light blue) so it is more clearly distinct from water.
I've refactored the "marching ants" animation process. This was to avoid repeated storyboards ( the thing that does the animation moves the dashes ). There's a very technical reason why this was worth doing that only wpf developers would be interested in.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 07, 2018, 09:59:43 AM
Map Editor

Added Fortifications.
These are necessarily somewhat abstract.
There are numerous things you might want to classify as fortifications during our period. They come in all sorts of shapes and sizes and it's not practical to give a way to draw any of these dynamically.

If you want something that looks like trenches, breastworks or a star fort then you'd use a different mechanism and import your path or picture, then tell the editor that is fortifications.

Title: Re: Changelog - picture heavy
Post by: Adraeth on April 09, 2018, 02:53:09 AM
About trenches, fortification:

do you think Red is the right color for them? might them be confused with red army units?

However i can't think about a different color, maybe grey?
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 09, 2018, 06:19:31 AM
I don't think you'd confuse this red with units, they're a paler sort of red.

Red is extremely intrusive though.
They are going to be fairly important things but maybe we don't want them to stand out quite that much.

There's actually two parts to this. Probably clearer with a picture.
The dashes and center can be different colours.

If you think in terms of castle wall sort of things then this'd look a bit too much like just a stone wall ( one of the boundary options ).
Dark and light gray

I think I prefer Sandy brown and Sepia.
Title: Re: Changelog - picture heavy
Post by: Adraeth on April 09, 2018, 07:58:03 AM
Sandy Brown and Sepia is excellent, reminds me of old battle maps  ;)
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on April 09, 2018, 08:39:46 AM
FWIW - the obstacles and engineer works appear in green on modern-day US/NATO graphics overlays, with friendlies in blue and enemies in red.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 09, 2018, 10:23:30 AM
Green is an interesting thought.
Another boundary type will be hedge though and that'll involve green of course.

Hedges and walls can be quite substantial things in the European countryside.
Not often quite so substantial as in the bocage but still significant defense against small arms.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 09, 2018, 10:28:14 AM
Scenario Editor, ModelLib and Map Editor

Added new area terrain type, Mud.

At the moment, all unit types can move through mud.
Some do so very slowly.
Since this is new ( I realised we'd want mud a couple of days ago ) we may decide to make it impassable to some units.
As it stands though, you could just use swamp if you want really really bad mud that most unit types can't move through.
Title: Re: Changelog - picture heavy
Post by: Adraeth on April 10, 2018, 08:14:38 AM
Mud is excellent to slow and "disorder" horses and artillery, and can portrait easily  bad weather (rain)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2018, 09:34:12 AM
Mud can be used for any zero height terrain which will impede movement.
You will be able to decide by how much it effects each type of unit on a scenario by scenario basis.

I think mud was quite significant at Waterloo.
There are other similar types of terrain though like moorland or just somewhat marshy ground. Either is very difficult going as anyone who's ever done any hiking walking will tell you.
This can add interest to some battles would otherwise be somewhat featureless.
Maybe Culloden ( I don't know offhand ).
You might consider some "swamps" in French Indian/1812 etc might be more appropriately set to mud.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2018, 09:46:04 AM
Map Editor

Added Boundary as a first iteration.  The first version is intended to be fence.

I'll probably go with red brick walls and of course green hedges.

This particular one led to some discussion about how fence, hedge or wall should work.
These are all slightly different boundaries.

You might think horses can jump fences so they cross them.
It seems they proved too much of an obstacle for some formed units. Maybe the average cavalry nag isn't much of  a jumper and large bodies of men/horse don't do so well with any obstacle.
There is also the issue of the likes of enclosure walls. Often not strong enough to stop a cannon ball so not a fortification really. But if the French could just walk into hougomont then things would have gone rather differently.

At the moment I have fixed "hard coded" settings control who can cross what terrain. This is as well as rates.
It has to be an on off thing because it'll be used real time as you drag a move order "puck" round. No you can't cross one of the pieces of terrain in that direction or yes you can cross all of them.
I'll make this editable per scenario in a new view within scenario editor.
It's then up to you to decide what fences do in a specific scenario stop.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2018, 12:32:59 PM
Map Editor and ModelLib

There are now 3 different boundary terrain types -  fence, hedge and wall.
Boundary is just a logical grouping of these though.
A boundary is drawn as a fence and you can then switch between the three options using 3 buttons in the editor for Boundary:


Drawing boundaries works slightly different from most other drawing objects in that the tendency to smooth to a curve is suppressed.
That's because these are one of the few things in the countryside where you may well really want a straight of wiggly line.

Hedge and wall will block line of sight to a height of 2 metres.
To use these as cover, you put a unit on the piece of terrain.
This represents your unit lining on one side of the wall but using it as cover.
If you are not on it then it blocks los for you, unless you or your target are somehow higher than 2m than the wall.

Fences just block movement. Or not - depending on your preferences.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 12, 2018, 10:38:52 AM
Map Editor

Added Bridge.
Drawing a bridge works somewhat differently from everything else so far in that you're not actually drawing an area or a line. As you mouse down and then up this defines the two ends of a straight bridge between.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 13, 2018, 05:51:04 AM
Map Editor

Added Ford.
Since bridges are way better than a ford (in the real world) they count as mud for speed of travel and whether they block some unit types.

In the above picture I've drawn sort of along the river and back in order to show you can do an irregular shape if you want.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 16, 2018, 04:46:43 AM
Map Editor

Added first iteration of Place.


In order to do this I've moved a bunch of things round such as the view for places which is now in a common library.
I also resolved a number of issues to implement just clicking to add a point differently from everything else with it's Ink support.

I'm still considering whether to allow multi line names for places and a combo box for the points value. At the moment if you typed a number I've not set a geometry up for, you get nothing in the plaque. I will probably just set up paths for 0-9, force only numeric input and leave it up to the user if they feel 99 is really a sensible VP for a place.
I still have to allow the user to pick which side the place is currently associated with.

In the picture, you will notice that the "marching ants" rather mysteriously continues some distance below the plaque rather than just under it. By default, you get the place name above a plaque. If you position a place close to the top of the  map then of course there is no space for the name above, so it appears below instead.  There are two of the labels in the control. I hide the bottom or top one depending on position. The control positions itself so the centre of the plaque is where you click. In order to do that reasonably easily I divide the width and height by 2 as part of the position calculation. Hence there are always the two labels there in the control, it's just one is hidden but still contributing it's height to the calculation.

For this one, "Top Place", I've clicked close to the top of the map. The label you see is the one below the plaque and hence those ants are marching off the top of the board. 
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 16, 2018, 10:15:05 AM
Map Editor

Another iteration on Place.
You can now have multiple line place names.
VP are limited to 0-100
You can't type anything but numbers in the vp box.
There's a combobox allows you to pick which side initially "owns" a place that's worth points.
You just get the text (no plaque) if a place is worth zero points.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 17, 2018, 10:11:30 AM
Map Editor

First iteration of Building. 
I've gone with terracotta tiling because it looks nice and bright, it's appropriate to most of Europe and it's not the same colour as units.
No buildings will have little arrows on them so even if the viewer is colour blind it should be pretty clear a building is not a unit.
Red vs orange colour blindness is also pretty rare.

Functionality still outstanding includes:
Rotate ( a bit ) *
Add a number of alternative styles to pick from.


Like all the other visuals, this is built using vectors and will scale.  Should you want to print a huge version of the map (once I write something allows you to export to pdf ) you will get a high quality picture.  I've not made the shadow and outline of shapes scale yet but at a larger size, that looks like:


I'm thinking of doing some building parts as sort of components. You add a basic kind of cross shaped church then you pick a spire or dome and stick that on top.
This is one of those things I could pretty much spend forever on and still come up with new options styles and things to do. 

Rotation will probably have to be rather limited because these aren't going to be lightsourced 3d meshes. 
Certainly as it stands, the gradients aren't going to change as you rotate. I can rotate the shadow so they point in the same direction, but if you rotate a house 90 degrees it'll look like it has a lightsource in a different direction to everything else. You'll get away with 20 odd degrees but anything more than that would mean a different building option.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 18, 2018, 10:10:26 AM
Map Converter and Scenario Editor

For various reasons, we need a new format for the map data.
That meant that the old maps we have already would of course be incompatible.
I've put together a utility which converts these.
The new format will come as two zip files. There will be:

From the user's perspective you get one or two zip files rather than several per map.

I have the first cut of the utility working.
The scenario editor now uses the new format and loads the data OK.
Still some work to do on that as I've not yet done some things like place names and the px to metres scale. 

The utility is just for our internal use and the ui is what you might call minimalist.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 19, 2018, 04:32:58 AM
New Map Format

This is now firmed up and the converter produces a new format zip file.
Scenario editor now shows places.
The converter is stable.
Stable enough for one map at a time internal use, anyhow.

The map editor is not yet saving state at all, so that's probably next up.
I'll get this end to end working before returning to mere details like rotating houses and different options for terrain and...
There's still a fair bit of work to do on the map editor.

Title: Re: Changelog - picture heavy
Post by: union square on April 19, 2018, 12:22:02 PM
Thanks for the Changelog, Andy.  It continues to be fascinating stuff for those of us interested in the project!
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 20, 2018, 04:31:57 AM
Thanks, I appreciate that.

Like Ezra says, watching software development is usually on a par with watching paint dry.
Hopefully this is slightly more interesting but it's a slow process.
Quality takes time.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 21, 2018, 09:16:23 AM
Map Editor

Started on save map process.

First part of this to do is to work out what terrain type is where in terms the game understands. There's a cell per px in a 2 dimensional array 1155 x 805.
To do that I need to hit test a point for each of these.
That's a lot of points.
Since hit testing is fairly slow, this takes a while.

I started with a proof of concept doing one point where I click. That meant a bit of jury rigging since clicking usually does other things but enabled me to prove what I was getting for a point was what I expected.
As it turns out there was a bit of a complication.
The piece of framework I'm using is bugged and stuff that shouldn't be returned from a hit test was.
I worked out how to filter these out and got the proof of concept to work.
Refactored that into something more re-usable.
I can now fill a 2d array.
This takes some time - around a minute whilst in debug mode.
Should be faster in an optimised compilation release but you're never really going to want to sit there watching it work.

I think I'll do a separate game map and design map save so you can save the design faster and then do the game save once you're totally happy with your master piece.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 22, 2018, 10:04:06 AM
Map Editor

Map saving - applying contour elevation.
This is kind of tricky because a contour can be under some other terrain object and you still need it's effect.  If I'd included contours in the hittesting for every single px that would not be able to stop at the top object hit, it'd need to get any and all objects under that point. That would have slowed down something which is already pretty slow.
The approach I took converts each contour to a new geometry which can then be processed on a background thread whilst the hit testing takes place.
Not only is this on a separate thread so it can be done at the same time as hit testing, it's inherently faster.
The reason I use hit testing at all is because it's the simplest way to work out what is the topmost terrain.
I could impose an explicit z-order and do everything that way. That's a possibility for a later refactor.

Note that contours are all one level. They're like those weird warhammer hills where someone just cuts an oval out of polystyrene and the top is horizontal, the slope vertical.
OK for a casual game where you want to dash off a quick map.
You will want one or more of the alternatives for anything more sophisticated.
The choice will be either or. You use contours or you use the alternative options.
I'll explain these at a later stage.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 23, 2018, 12:05:30 PM
Map Editor

Further experimentation with the hit testing approach uncovered a rather strange issue.
It appears that microsoft's hit testing component is more bugged than I realised.
It becomes ridiculously slow under some circumstances.
Unacceptably slow.

This is one of those un-fun situations that happen every once in a while in development.
I'm now exploring whether there's a practical work round retaining hit testing.
If not then I move to a similar approach I use with contours.
That has some complications but could well be a more elegant solution.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 24, 2018, 12:43:02 PM
Map Editor

I've replaced the way hit testing is done. It now runs for each piece of terrain on a background thread as you finish drawing it.
This still takes some time for some complicated drawings but you can carry on drawing other things.
Proof of concept is now sort of working.
I can save maps and open them in the scenario editor and it doesn't take all day.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 25, 2018, 06:24:29 AM
Map Editor

Various improvements to the terrain detection process which is now stable.
You can keep on drawing pieces of terrain whilst the app works out exactly which area your previous pieces cover.
I've added a visual indication to show this is still going on. It appears top right in the toolbar and you get an icon per terrain being processed. Most recent left to right.
I drew a river and then a road for this:

Small pieces of terrain process very quickly.
What's called the "bounding box" is used to decide where to look. This is the rectangle a piece of terrain fits in. A building is therefore a teeny tiny bounding box and almost instant.  A road stretching from one corner to the opposite diagonal corner has the whole map as it's bounding box and is the slowest.
I should think few people will often want to draw roads like a giant X on a map but if you do then it's going to take a while to process and you should do them first.
When I did the screen shot above, this is what I did with a road and river.  Both took 30 seconds to process.
Your experience will vary so this is ballpark indication only. The time it'll take to run will depend on machine, processor other processes running etc. This is running alongside my development environment and in debug mode.  Visual studio is memory and processor hungry itself and the final deliverable compile optimised code will run faster.
In the vast majority of "normal" use I expect all this means usually no wait at all.

The actual game map save to disk is a couple of seconds on my machine.
This has an SSD and your experience may be a little slower but the game map save is not a particularly large file by the standards of today.

If you look closely at the above picture you will see there's a bit of an odd anomaly like a circle on the end of the road.
These are noticeable initially on any "line" type of terrain. They disappear a while after you draw one and i've deliberately took a screen shot before that happened.
I use one geometry type initially for speed optimisation.
I then later replace it with a nicer looking but more process intensive one which is (again) created on a background thread.

Title: Re: Changelog - picture heavy
Post by: Adraeth on April 26, 2018, 02:21:06 AM
This is going to be a Masterpiece

an usual italian would scream : "Mamma mia!!"  :notworthy:
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 26, 2018, 01:15:31 PM
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 26, 2018, 01:23:49 PM
Map Editor

Added option to choose colour for the text of places.  This is because a place name on a dark background like a forest just disappears if it's black.
The two mysterious little squares on the right of the place are combo boxes.  The top one does which side "owns" the place and the bottom one the text colour.


New "Tab" in left panel ( which will be shown initially ) for map details. You can now enter name, description and pick the DPI the map png will be generated at. 96 dpi is likely to be enough, 300 dpi more than enough but if you wanted to print at high resolution there are higher options. These produce bigger files of course.


I also changed the way the terrains are held internally which improved performance a little but also introduced a bug.  Almost nothing works first time when you develop. Even if you tried to, perfection is way too time consuming so we go for kind of working and see what needs fixing.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 27, 2018, 12:04:35 PM
Map Editor

Hide left chevron when first tab selected and right chevron when last selected in the left panel tabcontrol.

First iteration of saving and reloading design.
Save design.
When you choose load map you see a new view which lists maps and their descriptions. You pick one and then it's reloaded so you can carry on editing it.
It all kind of works but losing ink at the moment which would be limiting on "line" terrain. Just needs some more coding to handle ink.

Avoid terrain adding extra children (trees for forest, waves for lake) when reloading.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 28, 2018, 11:46:20 AM
Map Editor

First iteration of save and load designer data. 
This includes the "ink" for line objects such as rivers meaning you can reload a map and still change the width of rivers.
Stable but still needs a refactor or two to neaten up the code.

Added "Work" folder within Maps folder and Ink folder within that.
This now holds all the files which will be zipped up into the current <yourname>.zip and <yourname>
They are deleted each time you "save" a file to be replaced with the new files.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 29, 2018, 12:41:27 PM
Map Editor

Disable input on map until drawing option is selected.
Refactor of map save and reload.
This is both to improve code quality and a step towards enabling separate save of design map and game maps.
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on April 29, 2018, 02:44:23 PM
Are there options to change the font if someone's got hard time reading some of the period-appropriate fonts?

I'm a big fan of them b/c of the atmosphere they provide, but I'm just thinking of accessibility issues.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 30, 2018, 02:44:56 AM
There will be.
You'll be able to change font in all the modules.
You can already in the scenario editor, I've just not done that in the map editor yet.
If you don't install the font files then it won't fall over or anything, it'll fall back to segoe ui.

I think this is one of those user preferences you probably have for all modules. 
I'll probably let the user set this in the menu module. 
When I get round to writing it :^)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 01, 2018, 03:23:12 AM
Map Editor

Added load map background option.
This gives you a file picker which is looking in the appdatalocal/GeneralStaff/Backgrounds folder.
At the moment, this background will be included in the png created by saving the map and so would be used in scenario edtor. And the game if I'd written it. 
This will be changed so the user can pick background in any of the suite.
One option will be a hypsometric representation of elevation.

Google Maps API

I am currently writing a proof of concept which gets elevation data from google maps. 
I get the data and I'm exploring the practicality of filling the 2 dimensional array which is used for our maps.
Looks like it'll work. So far.

You will input the two co-ordinates ( lattitude and longitude ) for the top left and right corners of your map area.
These can be obtained externally by any means you like but you can just use google maps. Right click the map and choosing "what's here" gives you the data.
Current elevation will of course include some "anomalies" like eg the mound at waterloo but some battlefields remain pretty much like they were during our time of interest.
Users will need to register for a key. The map API is free for up to 2,500 calls a day. 
Since it's limited to a certain size of data returned you will use this up with two calls. 
It is also throttled and will block your IP if too many calls are made in a second.
So it's a bit slow.

Anyone with a google account will find the process of registration almost trivial. You just click and it gives you a key which looks rather like a GUID to me.

This is just an option and you will still be able to translate the grey scale of a graphics file.
Once you have the data you will then still be able to edit it later.
Even if you're not doing a specific historical battle you could pick some random bit of the world and use the data from there to get you started.
Title: Re: Changelog - picture heavy
Post by: Cyrano on May 01, 2018, 09:44:07 AM
The Google Maps option is very exciting.

There's a great thread somewhere here on the fora pointing to a bunch of GMaps battlefields.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 01, 2018, 01:31:23 PM
Google Maps proof of concept

Gets data successfully.   
In order to cut down on the number of web calls I get every other px elevation. 
Hence the map is 1155x805 and I get elevation data for  578 x 403.
This is 578 calls which return the data for a line on the Y or "vertical" axis. 90 degrees relative to your two co-ordinates.
I will be able to use these to set the metres per pixel as well so you don't need to go measuring points against a legend.

Since you can rotate a google map and put persistent "favourite" pins in it you can potentially use a screen dump to trace from.
That would then give you consistent scaling which I think can be an issue in historical sketch maps.

I will show the  co-ordinates for the "bottom" left and right corners so you can put pins in for those as well.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 02, 2018, 12:38:05 PM
Map Editor

Rotating buildings. 
There are now two buttons in the edit tab which allow you to rotate a building by 5 degrees each click clockwise or counter clockwise.
This is limited to 30 degrees because the shading would look weird if you rotated more.
The drop shadow also rotates as the building does.

Google maps integration.
I started the first iteration adding this to the map editor.
This is quite fiddly because if you push too many requests through google's elevation api it does weird stuff first and then locks your ip for a while.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 03, 2018, 03:32:55 AM
Google Map Data

I have the first iteration working. 
Beat several bugs out of it and it seems stable. 
It has to be throttled back to wait between each call to the API and there are 578 calls to make so it takes a while.
I'll give some thought to how I could let a user carry on working in the map editor whilst it trundles along.   
We need some UI for the user to input co-ordinates, initiate the calls and see progress.   
I will probably put that into another tab in the left panel.
The calls are threaded, so you will be able to carry on working whilst this does it's thing. 

Currently, the hills and valleys can be checked in the scenario editor because it shows you the elevation where the cursor is. 
What's needed is some sort of visualisation background or layer that shows you the "big picture".
This will be a hypsometric background.
That's a fancy name for those colours you see on larger scale maps or atlasses where they work up from green valleys through browns, greys and eventually white on mountain tops. 
This is more readily understandable and prettier than contours which would in any case be harder to automate.

That in turn should make it easier to understand which bits you want to do some more work on. 
For a "quick" game ironing out a motorway is probably not worth the effort. 
For a more serious game you may want to flatten those out. 
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 03, 2018, 01:08:35 PM
Google Map Data

The new panel is now there and working, with a couple of superficial issues. 
The green rectangle is a progress bar which creeps along... fairly slowly.
Maybe not slowly enough since the api will still occasionally decide you're not getting anything and you then have to leave it a while or you've had it for 24 hours.  I have no idea what criteria they use but it's inconsistent.
You're best advised being quite careful about where you want your two points to be as the first run will almost always work whilst a second is more likely to crash and burn.


Font size needs reducing on the bottom locations and the number of decimal places rounded to 6.
The average variance needs rounding.

I think I'll probably also add a button to calculate the two bottom corners without doing a "run".
That way you can put pins in the (google) map, take a screen shot and compare to another map or whatever.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 04, 2018, 08:04:57 AM
Map Editor

First iteration of Hypsometric background. 
In case you're thinking Hippo what? 
This is using colour to denote elevation, an approach which is more usual in large scale maps like atlasses.
Green is low, working up through brown to sort of sandy.

And this is a chunk of France.


How this works is I take the minimum and maximum elevation.
Any value will be between them and I translate this into a colour somewhere on a gradient where 0 is the left hand value and minimum and 1 the right and maximum.
The colours used are fixed at the moment but could in theory be made configurable.
The gradient looks like this:

The whole process of first grabbing elevations and processing them needs a good bit of testing to ensure what I get makes real world sense.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 07, 2018, 03:04:35 AM
Map Editor

Tidying up the google maps elevation api process.
If you don't have the file set up when you navigate to the obtain elevation panel you will just see the message:

In order to use the Google map data API you need to provide a key for Google.
Register with Google for the maps API key.
Put the key provided in a file called googlekey.txt in %localappdata%/GeneralStaff/
Close and re-start the GeneralStaff Map Editor.

Registration with Google is entirely separate from the GeneralStaff suite. 
Creation of the file to place your key in is intentionally manual as a reminder to emphasise this.

Although the process is as smooth as I can make it, calls to their elevation data API are subject to whatever drives Google's decisions.
If you run the process more than once in a day then you're likely to see a message saying:

Google rejected call.
You can probably save and resume later.

Presumably to stop denial of service attacks, they have a mechanism which will block an IP for several hours if they decide it's being used to "automate calls".  Quite why anyone would want to use that API in any way that wasn't automated I don't really know.  In any case, despite having to register to use the api they still have this mechanism in place. 
There's absolutely nothing I can do about that other than work round it.

If you get this message but you can see the process has got some data you can save what you have.   
When you reload the save file you'll see a "Resume" button appears.
Don't just try this again straight away.   
I get the impression this increases the time you can't use it for.
All this could change because the registration process just got rather more involved and logically you might imagine they're way less likely to suffer DoS attacks from people who registered with credit card details.


If you leave it long enough then the process will complete and you've got a full map's worth of data.

Despite the hoops you need to jump though I think most people who want more than a few manually drawn contours will find this way easier than the alternatives. 

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 07, 2018, 01:06:16 PM
Obtain Elevation Data

Option to set 0 as minimum elevation.
Google returns negative values for seabed which you're probably not going to want.
On the other hand.... Some areas of the world have land which is below sea level.
Hence you can switch this on or off.

Scenario & Map Editor
Allow toggle visibilty of elevation map
Optimised generation of elevation map to avoid it freezing the UI.
Title: Re: Changelog - picture heavy
Post by: Grecco on May 10, 2018, 04:53:38 PM
There are several sources of elevation data out there that are free and allow bulk downloading. You might want to take a look at USGS's earth explorer website ( for bulk downloading 1 arcsec elevation data (around 30m resolution) with nearly world-wide coverage.

Another website with good free elevation data is this one: Here you can find a full earth-covering elevation dataset at 3 arcsec resolution (around 90m at temperate latitudes).

I would suggest processing these and shipping the battlefield elevation with your game, the google API's sound a bit too restrictive to me (I don't like waiting)  :) .
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 13, 2018, 04:32:57 AM
Thanks, I'm aware of the alternatives.

The google api is fairly easy to use and flexible.
You can pick any two co-ordinates and it "just copes" with any angle between them and reconciles whatever scale the elevation is held at internally.
Of course, buying a pre built scenario will be even easier.
These will also have excellent graphics.

We won't be using google's elevation data for our scenarios. Partly because of their terms of use.
Any utilities which I build in order to handle satellite data are likely to be passed on in one form or another. That could be either as a separate utility or within the map editor.
Since doing the same thing several different ways is inherently inefficient I'll probably add the facility to upload a file with the data in to the map editor.  That is then ready to take data from any external source you want to use.

It's much more likely any such utilities would require a user to download data from source rather than us re-packaging data already publicly available.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 14, 2018, 12:27:32 PM
Map Editor

Menu toggle visibility for grid and places.

Allow stylus pressure to affect width of rivers.
It's only rivers where a different width on a "line" terrain is considered to be a plus.

Collapse point canvas unless drawing options selected
This is to allow user interaction with terrain objects already on the map.
First of which is:

Mouse scroll to rotate a building ( so long as drawing options aren't selected ).
This is limited to 30 degrees like the arrows in the terrain edit as the shading of the rooves would look very odd if you rotate like 90 degrees.
Making buildings 3d objects would be more elegant but they'd then take way longer to design and be way too expensive to render in numbers. 3d objects are very expensive to render.

Started re-templating menu items.
The default WPF template is very complicated and has space for things like a checkbox and icon.  It doesn't suit anything but quite simple items.
As I have sliders in menu items this needs some work.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 15, 2018, 07:00:50 AM
All modules
New Menu item template

Review and add/fix Shortcut/"hot" keys

Map Editor

Visibility toggle and opacity slider for


In the screen shot both the elevation map and terrain opacity are dialed down a little.
You can see the shortcut keys underlined because I've pressed the alt key.

Experienced Windows users will be used to seeing underlines like these showing shortcut or "hot" keys.
This is standard windows behaviour.
Pressing Alt, holding it and pressing another key matching one of the shortcuts invokes it.
Hence Alt+L then Alt+B would toggle the visiblity of any Background you have loaded.
You can also press Alt, L, B.
Again, this is standard windows behaviour for a menu.
You can use Notepad or office apps in this way.
Recent versions of Office give you a little black square with a white letter on it when you press alt to make these shortcuts clearer.
I may implement that later.

You can't see where the mouse is on that screen shot but it's over Elevation Map which makes it's sub menu "pop out" showing the opacity slider.

Rationalising geometry resources.
Geometries are used to define all the vectors used in the iconography.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 16, 2018, 05:20:51 AM
Map Editor

Added groundscale.
You set this in an overlay which is toggled from the layers menu.


The two sort of rifle sights can be dragged around over two points you know the distance between.
You enter that distance in meters and click the save button.
The meters per pixel and overall size of the map are then calculated.


When you save the design of a map, the position of those two points and the amount you entered are saved.
Re-load such a map and toggle the overlay and you'll see the sights in the saved position.

When you use the google elevation data there is a known distance between your two map co-ordinates.
This is used to calculate the scale.
If you calculate the bottom co-ordinates or load the elevation data then this new data will be used for groundscale.
The positions of the sights will then be calculated.
This will over-write any data you already entered.
Meaning if you wanted to use real world elevation data but at a different scale then you would first load the elevation data and then later change the scale.
Don't reload the elevation data or re-calculate the corners (if you forget then don't save your changes).

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 16, 2018, 01:04:56 PM
Map Editor

Working towards allowing the user to "shape" elevation using drawing-app-like tooling.
This is not intended to be the primary way for anyone to input elevation but rather to "fix up" imported elevation data, for simplistic use in a "quick" scenario or as a back stop for someone who really doesn't want to use an image editor.

The original way of drawing the hypsometric elevation image takes a couple of seconds to run. This is OK for a one-off load but would require the whole image redrawing again in order to show any change.
It cannot be made more efficient without using a different approach.

I've added a new method which is a bit more efficient and will allow writing to parts of the image.
This is rather lower level stuff and hence tricky.
If necessary there's the potential to use pointers and "unsafe code" to make it faster again.
You might be thinking "Well just make it faster then!".
There would be a trade off though.
Such techniques come with an inherent higher risk of nastier bugs.
These might be necessary to get acceptable speed but a risk is a risk and best avoided.

Title: Re: Changelog - picture heavy
Post by: bayonetbrant on May 16, 2018, 03:11:57 PM
OK, so the important question - WHEN DO WE GET TO PLAY WITH IT?!?

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 17, 2018, 02:07:21 AM
My guess is December.
Still quite a bit of work to do.

I've started a separate thread.
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on May 17, 2018, 04:09:14 AM
I've started a separate thread.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 19, 2018, 10:15:41 AM
Map Editor

I've added a quick n dirty prototype method to view and change the size of the area you paint with in the map editor.
Choose Drawing options and hover over one.
You will see a tooltip with the current size and a representation of that.
There are two rectangles.
The upper one is at 0.5 pressure which is what you get from a mouse.
The bottom one is at 1 pressure which you get if you press hard with a stylus or use the widening option on river.
Scroll the mouse wheel up or down in increase or decrease the size by 1 px.
This currently "works" for all of the options but is only meaningful for line.

Researching options to improve contour drawn elevations - so they give a gradual slope rather than a step.

Minor improvement to bevelled frame.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 22, 2018, 04:14:52 AM
Map Editor

Fixed Bug failed to reset isbusy flag/indicator on re-opening saved map

Prototype greyscale calculation.

This uses the data from contours.
You need to set low and high so it "knows" the expected range of black through to white.
Set all the parameters, click the calculate button and you get a grey layered effect initially.

Checking the blurred box adds a gaussian blur effect which will then result in a slope rather than cliff when converted to elevation values
Note that the contour line will be towards the edge of the gradient rather than the "top" and hence the expected elevation will be somewhat inside it.
Often the exact elevation at a point isn't really going to matter so much so that few metres won't have any noticeable effect.
If this will be an issue for a map you're drawing, you can either draw your contours slightly further out or give them a higher value.

Hiding the terrain ( which is just contour lines in this case ):

I then have some code which grabs the pixels and translates the grey scale into metres.
Then redoes the hypsometric elevation picture

This is still very much a prototype and needs more work.
The results look pretty good. Certainly way better than cliff edges.

This is never going to be as sophisticated as you can do using the likes of photoshop. On the other hand, probably good enough for most purposes with an almost zero learning curve.
And... this is just one option. 
You'll still be able to import an image created externally.
Or at least you will once I write that part.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 23, 2018, 04:30:56 AM
Map Editor

Remove "old" code which set elevation based purely on contour height when saving a map.
Save new generated elevations
Respect default height
Limit input of (GreyScale elevation) values to numbers

Bug fixing and refactoring greyscale code.

Greyscale image import.
You now select between using Contours or Picture to generate a greyscale based set of elevations.
You can do both but whichever values you save last will be used.

Although a greyscale picture of the right proportion is advisable, this should handle any image you have.
That includes coloured ones.  These will be translated to greyscale based on tone.
If the picture is the wrong sort of shape it will be stretched.


Note that no particular validation is done on what you enter in this view.
If you set a low higher than the high then bad things are going to happen.

The interval is not used for anything yet.
The plan is to speed up allocating a value to contour height.
I may instead move this to the contours option settings.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 24, 2018, 03:21:19 AM
Hypsometric Elevation Image

Optimising algorithm which creates the bitmap.
Exactly how this works is pretty technical stuff involving building a huge array of bytes with 4 per pixel holding blue, green, red and alpha values.

Rather than working out each colour to use for an elevation dynamically I've built a collection of 255 colours.
I then work out which of those 255 "bands" any elevation would be in and use that colour.
The downside of this is that I can't now easily make this user configurable.
OTOH the processing savings are significant.

This may read as pretty dry stuff but it's huge.
Overall, the changes cut building one example picture down from a rather stately 2.68 seconds to 4 milliseconds.
That makes rebuilding the entire image as someone "shapes" a hill or valley practical and should just be a brief flicker rather than noticeable wait.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 26, 2018, 04:11:37 AM
Scenario Editor
Use new optimised hypsometric routine

Map Editor
Improving background file picker selection filter
Changed font used for drawing options to reduce number of different fonts on screen
Ephinol font as default for the left panel (tabcontrol) 

Rationalised elevation storage ( it was stored in both designer and map data ).

Started Shapers.
These are intended for a bit of "fixing up" rather than drawing an entire map.
That's the plan at the moment anyhow.
Having said that.
Due to the optimisation work, I can redraw the entire map very quickly.
That has removed one of the obstacles to somewhat more ambitious shaping.

The tooling needs more styling work but the idea is you pick one of the shapers from a list.
The various attributes of that shaper can then be set in the area above the list.
These will vary from one shaper to another.
There will (obviously) be more than one once I write them.

What I've done is the first iteration of flatten.
This allows you to set the same elevation for an elliptical area.
The two sliders allow you to adjust the size vertically and horizontally.
If they both have the same value then the ellipse is a circle.

In these pictures I'll remove the lion's mound from the waterloo battlefield.


You then drag the ellipse over the area you want to set.
Right click somewhere on the map to "pick up" the elevation from there
Over type in the set elevation textbox.


Either right click the ellipse, press return or click the apply button.
The elevation is applied to all the points under the ellipse and the map redrawn.


In the final picture, I've then dragged the ellipse back off the map.
The mound is no more.
You can't see the redrawing happen immediately because the ellipse is on top of the area changed.
The processing and redrawing the map is so fast it appears to be pretty much instant.

I then changed the ellipse so it's transparent with a white outline.
You can then see the bit of terrain you're about to change.
Counter - intuitively it seemed to me to be a bit harder to work out exactly where the edges of what I was about to change were.
Having said that, you can easily drag the marker round a bit and right click to do a bit more.
This was part of the idea of the right click to apply.

I could potentially allow the user to pick fill and outline.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 28, 2018, 08:11:08 AM
Map Editor

Added small brass slider templates

Started work on Hill shaper
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 29, 2018, 07:54:44 AM
Map Editor

Hill shaper, first iteration.

You define an ellipse and drag it round like flatten but hills are assumed to be bigger.
I did this with an otherwise totally empty map.

Enter an elevation for the peak of the hill

Clicking apply gives:

I'm smoothing the values from high to low using a formula called smootherstep.
You can read more about that:
The idea is to give the top and edges a curve rather than straight line trend.
Like a real hill.

All Shapers ( other than flatten ) will be additive.
The calculated values for the hill are added to whatever elevation each qualifying "cell" already has.
Hit apply twice and you'd get double the set height.

You can enter a negative number to scoop out a hollow.

I also need to allow the user to rotate the hill, the current approach only gives you vertical or horizontal ellipses.
Or a circle.

Refactoring flatten code to make it more generic and re-usable
Fixed a couple of bugs in flatten
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 30, 2018, 12:41:09 PM
Map Editor

Allow rotation of hill shaper.
This turned out to be much harder than I expected.
The problem is that the grid of elevations I need to work with is integer based for x and y co-ordinates.
However, when you rotate a point it gives you a non integer result.
When you round to an integer this leaves gaps
Plan B turned out to be an extremely expensive process which I then had to multi thread to reduce the time it takes.


Note the effect of adding an overlapping hill.

There are a couple of issues including speed ( ~4 seconds ).
More to do.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 31, 2018, 03:34:24 AM
Hill shaper.

Avoid rotation interfering with dragging.

Speed optimisation ( via threading and reducing lists used ).
Now roughly 2 seconds on my machine for the hill you see above.

Bigger hills take longer because there are more calculations.
Title: Indiegogo half off about to end
Post by: Dr D Ezra Sidran on May 31, 2018, 03:41:53 PM
Our Indiegogo half off pre-release sale is about to end. To take advantage of reserving the General Staff Wargaming System (Army Editor, Map Editor, Scenario Editor + Game) for half off the retail price (i. e. the Steam price) please see: (
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 01, 2018, 08:20:35 AM
Hill Shaper

Fix ( rather nasty ) bug in calculations when X dimension was bigger than Y.
Avoid error when part of hill is off map.
Give a warning the hill process can take a while to process.

Experimental work on drawing ridges / valleys.
Assuming I can get a practical version working...
The idea is you would define a width for the ridge and where the ridge line is in relation to that.
And a peak height.
You then draw a ridge line.


Added Compass Rose.

As usual, this is a first cut.
It's in one of the shared libraries but as yet only used in MapEditor.
The google process now also calculates the angle to north.
Still need to allow the user to rotate in map editor, use in scenario editor and decide when it's appropriate to be shown.
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on June 01, 2018, 08:46:29 AM
Hills look nice.  Not necessarily the most realistic, but appropriate for the game :)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 01, 2018, 11:48:41 AM

You raise a good point there.
It's worth bearing in mind there are different audiences with different expectations.
We want to support all of them as well as we can.
These hills will not be for everyone.
There again, real hills won't be for everyone.
These aren't the droids hills you're looking for?
Then there are other options.

Shapers... most of them... aren't really intended to be used for complicated "realistic" maps.
If you just want a big valley and or 3 or 4 simple hills for a quick game then wham bam they'll do that fairly painlessly.
If you want to "fix up" slightly a set of elevations you have already drawn or imported then they'll do that.

The only shaper I think I'm personally likely to use would be the flatten.
Erasing motorways and lions mounds.
I think I'd rather pick a random piece of the real world rather than draw stuff.
But that's just my personal preference.

The "best" way to get a realistic map elevation-wise is google data.
There will also be an interface allows you to import data you obtain from any other source.
At best that is likely to be way less convenient than google.

Different people have different expectations or real though.
If you want maps that match historical maps you see in books then you will find some of these are sketch maps and don't match reality so well.
People have probably been "making stuff up" about battles ever since someone tied a sharp rock on the end of a stick.
Reality changed as well - some battle sites are now heavily urbanised, drained and developed or whatever and the landscape has changed a fair bit.
If current reality doesn't match expectations then photoshop and a greyscale image are your best bet.
You need skillz to use that stuff properly though.
Not my thing.
Ed-the-graphics-guy is a whizz at that sort of stuff though.

If you don't do photoshop then there's drawing contours.
I should think most people will only be using contours for fairly simple requirements.
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on June 01, 2018, 12:57:31 PM
I was just commenting on how they looked on the screen, which I think will make them imminently playable.

I'm totally fine getting detailed with maps

(see attached sample from one of my older games :) )
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 02, 2018, 09:30:13 AM
Compass Rose

Now fully implemented in both map editor and scenario editor

The angle defaults to straight up.
Angle to north is calculated for you when you use google data.
You can (also) rotate it using the mouse scroll wheel (only) when the edit terrain tab is selected.
Uncheck the menu option and it's gone.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 03, 2018, 01:25:38 PM

Proof of concept. This is in a totally separate experimental solution.
This works using greyscale which will then be interpreted into elevation to add ( a negative peak will give valleys ).

You draw a line which is then processed to add progressively bigger layers of the same shape.
You can choose to have just a rounded end or "pointy" and narrowing from where you start drawing to the end.
Pointy ones also need to have the narrow lines shortened. This is because ink draws using numerous circles, whose diameter is the width of the line.  Reduce the width and you increase how steep the narrow end would be.

The layers's z index is adjusted so later lines don't have "lower" layers on top of higher ones.
In this way you can draw a set of connected ridges or river valleys.
The layers will then be blurred like they are in the contours processing.
That would also even out some of my wobbly drawing.

The sliders in my proof of concept control how blurred everything is ( zero for this screen shot so you can see the layers ).
Also how wide the line is drawn.
I had to reduce the width to draw the two pointy ridges connected to the bigger main one.


When you draw in the map editor, there will be no visible black background. That'll be added very briefly as you commit.  It's black in the proof of concept so I can see what it'll look like.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 03, 2018, 01:49:23 PM
Improving smoothness of drawn ridges.

Ink is a bit strange.
There's a two stage process. If you watch closely your line is initially drawn with whatever squiggles and jiggles you draw.
Once you finish a line it is then redrawn with any smoothing.
If you watch closely you can see it seems to move.
In order to grab that smoother ink I need to defer processing input until after that smoothing is finished.
Which I've now done.
I deliberately tried to add jiggly awkward bits when drawing those ridges and they're still smoothed out.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 06, 2018, 09:06:23 AM

First iteration of ridges in map editor.
You draw a ridge line.
The settings you have are then used to build ten layers in greyscale black ( for low ) through to white ( for the peak ) for a ridge.
One of the sliders lets you control how blurred the picture you're drawing is.
You adjust that until you can't see any steps in the greys.
This has to be manual because there are way too many variables to attempt to do it automagically.

You can choose to have just a rounded end on a ridge.
Which would probably do for simple stylised hills.
Alternatively, you can make it tapered - much more natural.

If you choose a negative value for the peak then it'll gouge out a valley.
You'd want to raise the base level first of course...  coming soon.... you'll be able to do that with another shaper.

I've not been particularly careful with these, you can easily do more natural looking shapes.
You can draw any number of shapes you like.
There's an undo button which will remove them last first.
Meaning you can try something and see what it looks like, undo, give it another go.
You'll definitely want that when drawing a ridge attached to another in order to get it looking good.

The sliders have tooltips that say what they do.
I left off headings to save space but I may add small headings as well.



Once you commit by clicking Apply then the hypsometric representation is recalculated.
Note that these hills valleys and the like don't have any "look" other than this hypsometric representation.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 07, 2018, 02:26:36 AM
Bug Fix Scenario Editor
Close button on edit movement rates was left justified.
I have no idea how that crept in.

Map Editor
Added labels on ridge shaper sliders

Raise Shaper.
This applies the value across the whole map.
If you check the checkbox, it will add to all cell values.
If you un check the checkbox it will set all cell values.

You can therefore reset the elevations completely if you've made some sort of a mistake.
You need some elevation before you can "gouge" anything out of it.
Negative elevations are not supported and something to be avoided.
You would therefore want to use this before using any shapers with negative values for dips or valleys.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 08, 2018, 08:27:05 AM
Map Editor

Cone shaper.

This is an ellipse shape rather like a hill, but way faster.

The downside being it's kind of cone shaped rather than the more natural rounded shape of the hill shaper.
By maxing out the blur you can effectively alter that shape by blending everything in and get a more rounded effect.

You can alter height and width, the mouse scroll wheel rotates the ellipse.
You click and hold - drag the ellipse to where you want it and right click to add one.
You can add any number.
Apply then uses greyscale manipulation and the value you set as usual to add the various elevations to the relevant cells.


Because these are additive, you can use shapers together to give more complicated results.
Several connected ridges are best done in one go but you will have the same height along them, tapering off towards the end.
If you draw several connected.

Here I've drawn tapered ridges from the center out.

I then position a large sized cone in the middle and add that.

I now have a mountain with reasonably realistic ridges.

I can then refine that by gouging out valleys or do another one.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 11, 2018, 04:05:53 AM
Map Editor

Bug Fix.
Avoid error if you try and drag a shaper you can't drag

Gradient Shaper

This applies a linear gradient in the direction of the arrow.
By linear  -  this would be a straight line in cross section.
This shaper is intended for fairly gradual changes in elevation across the entire map.  For natural results you should probably only use it the once on a given map.
If you used this from the top down and then from the bottom up, you'd get a rather unnatural sort of V shaped valley across the map.
If the values added were relatively low and or you then did a bit more land sculpting you may not particularly notice how unnatural that was.

You can rotate the gradient using the scroll on your mouse, whilst over the gradient on the map.
White is always highest so in this picture I've rotated through 130 degrees or thereabouts.
The highest part is the white and bottom right corner.
Lowest is top left.


When you click apply the gradient still covers the map so you can't really see it's done anything much.
The hypsometric representation for this looks like:


This is additive so you could draw a river valley and apply a gradient to that before or after so the water is flowing downhill.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 11, 2018, 09:27:18 AM
Brow Shaper

This is intended to give you a long hill brow which can extend at any angle across the map.
You can use two of these to give you a valley.
The Breadth of the brow is how far it is between the bottom and top of the brow.  If that's a low amount it's steep, larger distances mean a more gradual slope.
The slope itself is calculated using smootherstep as explained in a previous shaper. It eases off the slope at the top and bottom.
You can rotate using the mousewheel and drag using click and hold.
It's possible to position the brow in a way doesn't cover the whole map - it's up to you to ensure that doesn't happen.

Let's create a brow across the north part of the map.
Drag the brow up.
Click apply.

Rotate it and drag down.
Apply that.



Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 12, 2018, 08:22:42 AM
Custom Shaper

This works using a picture file you create. Since this is converted to greyscale internally you could theoretically use a coloured picture but I'd recommend drawing in grey and white.
It can be any size you like.
Clicking the open file button lets you select your file.
The Scale slider lets you scale it up or down.
You can rotate your loaded picture using the scroll wheel and drag it around.

For demonstration purposes I created a file in MS Paint.
I started by flood filling in black.
I then used the spray can to draw an interesting sort of ridge in white, outlined that in grey and then dark grey.
I then opened the file in and flood filled the background black as transparent.
Saved the file as png.

This is the result:

Because the spray can sprays loads of dots this is fairly heavily textured.

Opening it in the map editor , I can then set blur on it which smooths out that texture:

Blur is effectively optional since you can set it to zero but I'd want a cleaner picture if I was doing that.
This way I can work quick and dirty.

I then clicked apply, moved the shape off to one side and scaled it down a bit.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 12, 2018, 08:45:53 AM
In seconds you can knock together a picture with some small hilly bits in it.

Applying these a few times, you can rough up the map for a bit of interest.


You'd maybe want bigger hills or lower values - there's a lot of valleys to hide in there.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 13, 2018, 12:10:50 PM

Overhauling the font preferences mechanism.
Changed some fonts and views to make them fit (better) with the different options.
Added font preferences to map editor.

Persisting ( and read on run ) user preferences,
If you pick plain style then next time you run one of the apps, you get plain style.

The Army Editor also has a preferences menu item and will respect the settings.

Rationalised the shapers internals.

Added min and max to shapers panel.


Replaced the button template.
The old one looks too much like a mirror frame and it was a nightmare getting it to look OK with different font formats in all the different views.
The new version's fancy bits are less distracting and now cannot impinge on the text.
Reducing the space necessary to left and right of the text also makes this version a lot more flexible.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 15, 2018, 12:08:14 PM

Terrain and elevations visualisation.

(First iteration)
This is a sort of vertical slice through the map showing both elevation and terrain type.
The terrain type is represented by colour - but you need to save a map before this is actually set.

Showing this is controlled via a checkbox on the layers menu.
When checked you get an overlay with two sights defining start and end points
You can drag these around

Another window appears showing the visualisation.
This is a regular window so it can disappear behind the main window if you let it.
As a result you're best dragging it to one side or your second monitor.

Black is the default colour, I've no terrain other than elevation on this map.

This is constructed from a number of rectangles.
Each rectangle is a cell between your two chosen points.
As you mouse over each of thes rectangles, there's a spot which moves to the appropriate position on the map.
You can see that on the top picture.

Although only used in the map editor at the moment this is designed for re-usability.
I can potentially show it whilst you're issuing move orders for the terrain you're moving over, when you're checking for sightings etc etc.

Currently stable, but still some more to add.

Shapers - evaluate min and max elevations on map load.

Bug Fix
One of the shapers layers was interfering with drawing anything.

Standardising storage of elevations and terrains across modules.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 16, 2018, 10:00:17 AM
Terrain Visualiser

Fixing bugs and improving the behaviour.
Close the menu as the terrainvisualiser is shown.
Usually you want a menu to be on top of anything and the fact that's how they work is great.
In this case something on top of our new window is a bad thing.
Persuading the new window to stay on top of the main one.
Retaining previous positions and data when you re-open.

The sights overlay now initially appears with it's "spot" off map.
Spot is also moved off the map when you drag a sight so it's not left hanging about in the middle of nowhere.

Added elevation and terrain type in text to visualiser.

In the below screen shot I've done a screen capture using windows problem steps recorder.
This captures the mouse so you can see where it is at the time of capture but has adds that rather interesting green border to the window.
I've added a hill and two cones plus some other terrain.
These are pretty steep hills.
The left one is a hill which is a relatively natural shape but slow.
The middle (cone) demonstrates why a cone is called a cone.
The right one  is a cone with a lot of blur applied.
Quick to generate but blurring reduces the effective overall height.
If you can live with that though, it's way quicker than a big hill.


Notice also the colouring showing terrain types.

I wasn't terribly careful with placement of my river and road so they're not in particularly logical places.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 17, 2018, 08:09:03 AM
Map Editor

Styled up the Elevation Shapers options so it's similar to the drawing options.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 18, 2018, 11:52:40 AM
Map Editor

Building options.

I've added a mechanism which allows me to define different buildings.
A Building row has a combobox in edit terrains which allows you to pick from the defined buildings.
I've added another building. 2 so far.
You click a building picture in the combo to pick it and the building on the map changes.


You can still only rotate a maximum of 30 degrees either way.
That is because of the shading, which could look weird otherwise with the shadow on the wrong side and different to everything else on the map.
These are not light sourced 3d objects, because they get very graphics expensive very quickly AND they are harder to build.
They're built from shapes which have a gradient on them.
Although the shadow outside the building can be rotated the shading on the roof panels is fixed like a picture.

This limitation isn't necessarilly going to apply to all building so I'm thinking of making each define how far it can be rotated.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 19, 2018, 08:50:18 AM
Map Editor

List of terrain in terrain edit:
Removed display of id ( this uniquely identifies the piece of terrain but is only internally meaningful ).
Standardised font used.


Added another house and courtyard to building templates.
The templates now have a value for default height and width they set as they're chosen.
Hence the latest house can have a bigger height than width and the courtyard is much bigger.

You can now use the mousewheel in combination with a modifier key to alter the size of a building.
You need to have edit terrain selected ( like with rotating a building ).
Mousewheel scroll + Ctrl alters width
Mousewheel scroll + Shift alters height
Once you alter the size, the building will remain that size even if you change to a different template.
( This is necessary so when a saved design for a map is reloaded any altered sizes will be respected ).
Title: Re: Changelog - picture heavy
Post by: Dr D Ezra Sidran on June 19, 2018, 10:21:26 AM
I would just like to point out that that is an accurate Order of Battle Table for the Continental Army at Trenton and, yes, there really was a Colonel Sargent.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 20, 2018, 02:40:20 AM

There are now several different tree shapes.
Each tree randomly picks which shape it will be as it's created.

Change drop shadow to sepia ( was saddlebrown ).

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 20, 2018, 09:02:51 AM

Added 3 more building types.
You can use these separately of course but I built a church with these as an example of combining buildings.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 21, 2018, 07:16:18 AM
Terrain Visualiser

Added minimum and maximum elevation to the left of the terrain graph.
This is min and max for the whole maps for context - so you get an idea how whatever slice you're looking at fits in.

You now get a pink line above the part your mouse is over.
I considered adding some sort of a scale but that'd be very complicated because the user can pick whatever elevations they like.
I'm also not so sure about how useful that would be without a load of horizontal lines across the whole thing.
I may come back to that later but.... shelved until and unless I can think of a good way to do it.


The window tries to size itself to fit what you pick. If you pick a very long slice then the window could be quite wide.

My experimental map which has some terrain on it only has those three hill/cones on it.
This is with a map of the northern lake district.

And Isandlwana

A friend of mine has South African links and has visited the battefield on several occasions.
It's well looked after and pretty much as it was back in 1879.
Other than the things like the memorial, cairns, fence round the site and the car park.
I was surprised when he mentioned the car park.
There are now a couple of zulu villages nearby.,30.6442408,14.93z/data=!4m5!3m4!1s0x1ef1bbc774f6dc39:0xf740fe2436bd3a34!8m2!3d-28.3586111!4d30.6513889!5m1!1e4 (,30.6442408,14.93z/data=!4m5!3m4!1s0x1ef1bbc774f6dc39:0xf740fe2436bd3a34!8m2!3d-28.3586111!4d30.6513889!5m1!1e4)

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 22, 2018, 02:36:08 AM
Map Editor

Alter line width.
As the heading suggests, this is only applies to line types.  Even then it's probably then only really useful for rivers.

You alter the size using the scroll wheel when over a particular drawing option.
There is also a tooltip appears with a representation of the width.
The upper rectangle is what you'll get when drawing with a mouse ( this becomes 0.5 pressure ).
The lower rectangle is  the maximum width which you'll get at the widest if you click one of the widening buttons for a river ( 1 pressure).
In this picture you can see the tooltip and a few rather random bits of river I've scribbled just to prove you can do the different widths.
It works this way because you can set it prior to drawing and it's relatively quick to set rather than adding extra post processing via a context menu.
The tooltip only appears for line type drawing options.


Terrain Visualiser
When you drag the start "sight" you'll see the (X,Y) location appears as a user message.
This is intended for advanced user customisation scenarios and debugging.
As a sort of side effect, if you somehow got the two sights mixed up then moving the "end" one gives no message.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 22, 2018, 06:46:35 AM
Map Editor

Added support for custom resources.
This is a first cut at the moment.
This is a thing called a resource dictionary which is in plain text. You can edit it in notepad and it's then read at run time.
It's located in your user appdata / generalstaff/maps/CustomResources.xaml

Always find you want more?
Then this might be for you.
You can override many of the resources used within the map editor using this functionality.
What do resources do?
They define pictures, shapes, and colours used through the app.
Want a different background to woods?
You could do that.
The various building colours and shapes are all resources.

There is a teeny tiny catch in that you will probably need some help from me to know what to change.
I'll put guides together on how to do some stuff - eventually.

There is also a new layer - "CustomCanvas" which you can add anything you can define to.

Basic stuff is pretty simple once you get past the fact you're doing mark-up.

Say you want a star fort kind of a thing and of course there are no star fort buildings in the editor.
You could potentially "just" incorporate a picture in your background image in one way or another and go with that.
Maybe that doesn't suit though.

You find a suitable picture in a book or online and start with a picture.
You can then convert that to xaml using Inkscape. This is a little fiddly but not far from rocket science.
As a flavour:

You paste your picture into inkscape.
Choose trace bitmap.
Click the button and it generates vectors for you.
It just looks like another layer.
In this case I clicked the "simplify" button which loses a load of fiddly bits. Some of which you might have kind of wanted.
Drag that aside. delete the original layer and save as xaml.
Go grab the data from the path (or paths) in there and you can use that as a Geometry in the custom resource dictionary.
A geometry is a long string of co--ordinates which looks kind of weird but you're just cutting and pasting it.
The longest part of this process is likely to be finding a suitable image.
In my case I pasted in, surrounded that in a geometry tag and I could then use it


To get the above, I filled in some of the walls and erased some twiddly bits from an online picture.
I just used Paint for that step.
I wasn't terribly careful but the import process smooths bits out a little anyhow.
It will also probably lose some detail but maybe that doe

The custom dictionary has angle brackets in it, so I can't post the content.
It looks like:


The string in the geometry tags defines the shape of the fort. It is way bigger than that, I've substituted ... for most of it for clarity here.
The Canvas.Left and Canvas.Top define where the fort goes on the canvas - which fills the board.
If you want precision, you can use the measurements from the start terrain visualiser as described in the last post.

I intend processing paths using their "Tag" in order to apply terrain types to them.
Assuming I get that working, this would be a significant advantage to the approach.
Still probably not everyone's cup of tea but if you really really wanted a specific shaped fortification then you can do it.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 24, 2018, 09:37:49 AM
Map Editor

Custom Path tags
If you add a Tag which matches a terrain type to a path in your custom layer, this will be recognised as that terrain type.
Fortifications are "Fort" so if I add Tag="Fort" to the path I described above, this is then recognised as a fortification when the map is saved.


Note that this result is probably not ideal with that particular path because there are parts which are not fortification.
More work on the original picture would probably have been better.
You could alternatively use the path without a tag and trace over those specific bits you want in the map editor.
Or, you can split the thing into several vectors withing inkscape and use a number of paths rather than just the one.
Tag those parts which are defensive walls.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 25, 2018, 05:24:21 AM
Map Editor

Testing and neatening up the custom paths code.

Context menu on terrains.
You need to have the Edit Terrain tab selected.
A context menu opens when you right click something and hence with this you right click the background of a piece of terrain.
It must be the background - not one of the trees in a forest for example. A tree is a separate thing  - a child of that woods terrain.

There are three options.
Transparent - makes the "fill" of the terrain transparent so you just see the trees in a woods and a fine dashed line for the outline.
Remove Children - all the trees of a woods will disappear, similarly waves in a lake and swamp grass in a swamp.
Redo children - removes the ones you have and re-adds them. The process is random so it will be different every time you click redo.

Scenario Editor

Use the "new" open map window.

All Apps

Command line argument for full screen.
If you add -full after the run command on a shortcut to any of our apps, it will open full screen.
This is intended for low resolution monitors, where the app would open bigger than the monitor otherwise.

Began speed testing.
At this stage this is just a sort of reality-check to make sure things run and do so with acceptable performance on a low powered machine.
I'll put more detail in a separate thread.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 28, 2018, 02:28:37 AM

Replaced the paper background. The new one is a "cleaner" looking picture.
The old one had blotches on it which tended to look like marks on my monitor.
This still new version has "texture", but less noticeable blotches.

Army Editor

Added "Walden" typography window.
Walden is the the supplier of the "Victorian" style fonts if you were wondering.

Started Accuracies

This is a multiplier which will be applied to effect for range.
Each unit has a 100 values, one per percentage range.
Hence range up to 1% would be the first value and that would be high and maybe 1.000.
The last entry is for very long range shots and almost always going to be very low - maybe 0.001.
There's a maximum 3 decimal places used.

You'll pick from a set of curves for this and or edit each value.
Obviously, editing a 100 values is a bit tedious and many weapon systems are pretty similar in effect.

For example, study after study shows the vast majority of regular riflemen perform extremely badly in battle.
Whether this is down to reluctance to kill, battle stress or whatever is still discussed amongst experts.
Differences between one rifle and another are far less significant than those between the people pulling the trigger.
But I digress.

It will be up to you, the users to interpret reality as you see fit.
We'll be giving you a set of curves but you can changed them.
You can set what values you want for your defaults and what values each unit has.

These curves are loaded from txt files.
Any located in the local appdata /GeneralStaff/Armies/Accuracies will be loaded to the combo box.
I'm going to write editors for these but you could just edit in notepad or paste in from excel.
The reverse is also true, so you could paste the data into an excel spreadsheet and graph it if you say wanted a giant print out of each.

At the moment, this is just preliminary test data and the curves are a bit wobbly.

Title: Re: Changelog - picture heavy
Post by: bayonetbrant on June 28, 2018, 04:41:30 AM
Santa and his Elves, huh?

Seen at Origins this year ;D

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 28, 2018, 07:00:41 AM
They can be very dangerous them elves.
It's the little fellers you have to watch.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 29, 2018, 06:45:09 AM
Army Editor

Added user message mechanism.

Added base Accuracies editor.
This is available off the Preferences menu.
You click "open" to pick which file you want to work with.
You're then presented with a sort of graph of the values.
This is 100 vertical sliders, one per percentage range.
0% range is the left origin and 100 the right.
As you mouseover each, the relevant data is displayed to the right of the graph.
You can alter the values for any you like using their slider.

If you use a pc, you will have used sliders. Just maybe not realised you've been using them.
Because sliders are used to scroll browser windows.
There are sort of 3 obvious parts to any slider.
There are two repeat buttons and a thing called a thumb which is the value pointer.
The thumb on a desktop browser is usually quite a big rectangle.
They also mostly have extra repeatbuttons at each end ( with a chevron on them ).

For those unfamiliar:
You can click, hold and drag the thumb up or down.
Once a slider is focussed (click or tab ) you can alternatively use the keyboard and the arrow keys will make it go up or down.
Alternatively you can press one of the repeatbuttons.
These are the parts you see on either side of the thumb.
One click moves a bit.
Click and hold repeatedly click ( hence the name ).

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 30, 2018, 08:03:27 AM
Army Editor

Added name of accuracy file being edited to title bar.
Clicking on the slider above or below each of the crosses now moves it 0.001 per click.
This makes smoothing a curve a lot easier than trying to drag the thumb by teeny amounts.
You can click and hold to do this repeatedly.


Added tooltip to each of the accuracy curves in the combobox telling you which they are.

Added edit unit accuracies.
This changes just the accuracies for that one unit - not the base files or other units.

It's accessed by clicking the button with the pencil icon on it.
And... looks remarkably similar to how you edit the base accuracies.

Any changes made are only copied over to the unit when you click save.
Even then, if you made a mistake the values are not saved to disk until you save the army you're editing.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 02, 2018, 03:43:09 AM
Army Editor

Changing positioning of unit stats so more will fit.
Adding Swords Reload Time and Range.


Bug fix: Part of the ui wasn't responding to change of font preferences.
Title: Re: Changelog - picture heavy
Post by: Sitnam on July 13, 2018, 09:32:04 AM
The updates are great, Andy.  How close is this project to completion?
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 14, 2018, 02:48:53 AM
The idea of a changelog in software development generally is so you can track changes between versions.
Obviously, people don't have a working product to track any changes on yet.
At the moment the idea is partly to re-assure people we're doing something.
But mainly... to explain decisions, show how stuff works, provide a basis for documentation and to entertain.
If you've been following along it should be easier to get started when you install the finished thing.

It's guesswork when I'll finish the game module.
Not actually started it yet.
Maybe December.
Future plans and wild guesses have a different thread.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 14, 2018, 04:11:29 AM
Scenario Editor

Looking at the distance things shoot and where units would be, it became obvious that one piece would be on top of another when they are at musket ranges let alone in close combat.
Previously, the icons in a piece kind of fill the entire circle that is a piece.
This is problematic because the frontage of a line battalion should be a straight line.
To address this, we decided to move the symbols down inside the piece so their front is across the central line.
That then means some will stick out the back of the circle.
That depth is a bit of a problem so reducing that would be good.
Of course regular nato symbols don't have any arrows indicating facing.
Removing those thus reduces the depth of the symbols and reduces our depth problem.
What about indicating facing?
Facing is often reasonably obvious - but I have a plan to indicate facing separately as well but that's for later.
The first step was to take those arrows off and clean the mess up when it all then fell apart.


I was then surprised to notice you can't set the formation on a unit you drag onto the map.
Add combo to set formation to piece contextmenu
Added "Small" unit formation for HQ so it has a valid formation.

When testing that I found Formation wasn't being persisted when saving a scenario.
Probably not so surprising since you couldn't set it I suppose.
Fixed that.

Still need to sort out column square and make sure all symbols end up in the right place.

Once done units will look OK in common battlefield positions.
There will still be a bit of an oddity if one unit moves into close combat with another from it's rear - because one will be on top of another.
The defender is probably done for in that situation anyhow.

Actual frontage for shooting and close combat stuff will be calculated rather than depending on the pieces you see on the board representing units, so any weirdness should just be cosmetic.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 16, 2018, 04:26:10 AM
Bug Fixing

Fixed points of "triangles" for light infantry and cavalry projecting slightly beyond their rectangle.
Army editor fix problem due to null accuracies when adding a HQ
Set default accuracies for new unit.
Fixed extra underline indicating two shortcut keys on load blue.

Scenario Editor

Completing changes to allow pieces to face each other in close combat without the icons on one being on top of the other's.

Added facing "triangle" to piece.
This is rather like the triangle you get indicating facing for an individual figure in combat games.
It appears only when the unit "lights up" due to mouseover of it or a piece in the same command.
This triangle will probably become different shapes in the game to indicate status.
Details of that as yet to be firmed up decided.

Moved the units down within the piece so the front face is across the center.
This involves changing a number of things rather than just one due to kriegsspiel showing multiple icons for strength. And column.

Icons can now extend past the circular edge of a piece which is particularly necessary for kriegsspiel units strength 2+ in column.

I still need to decide a good way to represent square.

Just to repeat something I think I mentioned earlier.
The icon is just a representation of the piece on the board.
Calculations deciding range, who can see and shooting will be completely abstracted from the visual representation.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 16, 2018, 01:52:55 PM
Scenario Editor

Added Square formation representation.

In Simulation mode, there's an empty square

In Kriegsspiel mode the strength is shown by the number of bands.
The pieces below are KS 2 and 3

Although these have a smaller frontage than a line formation this is still over scale.
Squares were actually relatively small formations since there are 4 sides and they'd usually be 4 deep with command and a reserve in the centre ready to plug any gaps.
They also tended to be closer order than line since the whole idea was to discourage horses from seeing a gap to get through and to ensure there were many more infantrymen than cavalrymen in any contact in order to drive them off.

Involved in this work for various arcane technical reasons was a refactor of how several attributes are handed down the layers of a piece.
This refactor is also a move towards making this more generic which will be necessary for the game.
There are probably still a few things broken in the process though.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 17, 2018, 01:42:44 AM
Scenario Editor

Test - fix cycle turned up less problems than I was expecting. Maybe I just missed some :^)

Minor fixes on unit icon.

Increase height (length) of column when in Simulation

Only show formations combobox on unit context menu when it has more than one option.
EG HQ can only have formation of "Small" and supply wagons are always column.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 18, 2018, 03:54:05 AM
Army editor

Various minor changes to improve look and readability.
Vertically centering edit textboxes so the numbers sort of line up with the label.
It's impossible to guarantee exactly lining up, partly due to the two different controls of textbox and textblock involved but also due to fonts.
Cursive fonts and our Victorian ones measure differently to what the viewer might expect and their centre isn't always where you might expect it to be.
Added tooltips explaining some of the fields.

Bug fixes
Avoid error closing unit accuracy window
Without any preferences chosen, no fonts were loaded and therefore the fonts used default windows ones.
( I hadn't noticed this because personally I prefer readable over fancy ).
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 20, 2018, 01:54:03 AM
Army Editor

Removed the "Swords" which was just a Boolean on-off switch and added.
These are measures of lethality and hence a multiplier on effect.  A full 12pdr battery can now be more effective than a 6pdr battery. *
We can now differentiate between a unit which has no bayonets and one that does. ( AWI ). Or gunners with pokey sticks and hussars with sabres or lances.

( Exactly what weapon these are and weapon reach is a step too far at this level of representation though. )


EG at Isandlwana the British forces had a third of the unit of 7Pdr  - 2 out of 6.
This will allow you to try finer grained what-ifs.
Chelmsford leaves all his 7pdr at Isandlwana.
Reno doesn't wrap his one gatling gun round a rock on the way to Little Big Horn.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 23, 2018, 05:38:27 AM
Added Skirmishing.
A unit has serveral options regarding skirmishing which are set in army editor
These SkirmishOptions are:
Never is the default.


If you select optional then "Skirmish" appears as another formation in the context menu for pieces once dragged onto the map in scenario editor.
Selecting skirmish in the scenario editor or the default when Skirmishing Always is set on a unit then the icon is 0.6 of the height as you see below.

Skirmishing is an infanty sort of thing and a unit is more dispersed.  The unit will take less casualties when shot at BUT will be worse in close combat and when charged. Rallying skirmishers is harder.
Particularly in the ACW, some cavalry would dismount and act as a skirmish screen to slow down advances and the like. I've therefore not limited which unit types can skirmish.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 30, 2018, 08:25:34 AM
Army Editor
When choosing save of a new army there was no default name so it errored. Set name to "default".
Changed menu File > Quit to Exit ( windows standard ).


Changed the folders and standardised internal methods to access these.
In localappdata there is now a /GeneralStaff/Blackowder folder which contains all the files and folders.
This is because we intend releasing general staff for different periods as well.

Renamed the exe.
The various exe are now prefixed GSBP which stands for GeneralStaff Black Powder.
There will be different versions of the editor and game for each period and hence each module should have a unique name.
This won't be noticed by the vast majority of steam users but early supporters will be getting installers before I do steam integration. There are also some people prefer to control where steam installs apps and run them just from links rather than via steam.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 06, 2018, 02:22:09 AM
Army Editor

I've built a prototype installer for the Army Editor.
This needs testing and we also need an icon for the army editor before we can distribute.

This will also probably be an interim solution and only used for beta testers.
Steam will be our main distribution platform and hence we will have to conform to their requirements.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 08, 2018, 09:20:31 AM
Substituted the new ico files.
The 3 apps now have arrow with different colours so they're immediately identifiable separately but of the same suite.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 15, 2018, 01:15:58 AM
Army Editor Installer

There are a couple of bugs with this.
I think they're fixed now.
Ezra found a bug in the army editor to do with deleting a unit.
I can't replicate that.
Once I do and that is fixed, the army editor will be made available for beta testing.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 16, 2018, 05:46:07 AM
Army Editor Big Fixes

Fixed a number of delete and insert bugs related to the lost of all units getting out of step with what you added.
Changed way attributes are copied when you paste.
This should now copy everything but those marked ( internally ) not to copy.

That way when I add another attribute to a unit then this won't recur.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 16, 2018, 07:32:29 AM
Army Editor Improvements

Added metres distance for each percentage in army editor edit accuracies.
This is of course dependent on setting the range.

Show file name that will be used for save in sub menuitem from save.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 17, 2018, 03:50:39 AM
Scenario editor
Remove default debug map and army load.

Map Editor
Added Exit to File menu
Completed installer project

Army Editor
Added date to version on exe.
This is in case someone finds a problem I think I fixed - so we know which version they're running.
I now have to remember to change the version each day I build the app though. :-\

Army Editor installer
Try and make the net framework requirement more sophisticated.
Not sure why it wasn't detecting .Net 4.7 wasn't installed but maybe this change will address that.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 17, 2018, 06:56:09 AM
Army Editor

Added two paste options to preferences.
These give you control of whether to copy the unit name for HQ and combat units when you paste.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 18, 2018, 06:30:30 AM
Army Editor

Fixed issue where unit Name was blank after save. This was a bug I introduced that fixing something else.
Attempted to cope with full stop for decimal place whilst user's machine language would usually expect a comma.


Added message when saving army
Added f4 for "quick" save which saves back to whichever file you loaded or Default.xml. This is the same as File > Save
Changed the way the current file name is displayed in the file save menu
Simplified the save as - it's a given that you're saving an army file when you're in the army editor.
Set the default name of file in the menu after you choose Save As.
Put the two columns of editing controls in the edit panel in scrollviewers.
These will give scroll bars if the content cannot fit.
Admittedly, this is a somewhat quick and dirty fix but should enable the main window to at least be usable on lower res monitors.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 21, 2018, 02:34:10 AM
Army Editor

Fixed a bug in ID save.
This problem was particularly apparent on delete.
When you save an army file and reloaded it, the HQ and units would load fine and it'd look all good.
Then when you delete a subordinate you'd get an error.
This was because multiple units qualified as the unit's CO.
Any armies saved prior to version 0.2018.8.21 are likely to display this problem.
You can likely fix them temporarily using renumber ID since this iterates through the unit tree and renumbers everything.
Until using the new version it will recur every time you save though.

As suggested, I've added the version number to the standard About Window so you can easily see which version you have installed.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 23, 2018, 03:00:03 AM
Army Editor

Add default HQ on start up.
This avoids the possibility that the user will choose to save a totally empty army file and then later get an error when they load it.
It also saves an extra key press to start a new army when you're just getting started

Prompt for Save if data is dirty.
When you close the app.
It keeps whatever you started with or loaded or last saved as an origininal version.
It then compares with what you currently have in memory.
If these are different then it shows a message box prompting you
If you choose OK then your changes are gone with the app, cancel stops the app closing and you can then save or whatever.

Ctrl+S invokes save army ( in addition to existing key combinations).
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 25, 2018, 05:37:46 AM
Map Editor

Next up for beta testing will be the Map Editor.
This is much more complicated than the Army Editor with a lot of fiddly bits.
I've added on functionality which was added to the Army Editor as a result of beta.

Ctrl+S & f4 save

Show default name in menu
Added Save as ( Could have sworn that was in there already ).
Rationalised code used for saving.

Investigated prompt for save if dirty.
This would be extremely involved for the map editor for various tedious technical reasons.
In brief - there are many different complex objects involved.
This would be quite hard to implement and likely to have many edge cases where you get false positive or negatives on differences.
Will not implement.
Until and  unless I can think of a practical way to do so.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 26, 2018, 08:21:13 AM
Map Editor

Prompt user for save if closing when there are unsaved edits.
This is using an approach which isn't as reliable ( or elegant ) as the army editor.
It seems stable but the most likely failure will be over sensitivity.
Erring towards prompting unecessarilly is better than erring towards failure to spot changes.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 27, 2018, 02:15:39 AM
Army Editor

Following feedback on accuracies files, I've made a couple of changes which should make the app handle accuracy txt files with less than 100 lines rather more gracefully.

If you have such a file then you will see a message on running the app.
At the risk of stating the obvious - you should fix the problem rather than ignore it and carry on.

The part which draws the little graph for the accuracies combobox now gets a default value for any missing entries and should not crash.
Other parts might, but that part of the code shouldn't :^)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 03, 2018, 05:17:12 AM
All - Global error handler

I've added code which attempts to capture the details of any error.
The idea being to make it easier for beta testers to report errors with a stack trace.
You don't see any difference from the current behaviour, there's no extra form shown.
The error description and stacktrace are copied to the clipboard.
You can then just paste that into notepad or a forum post.
Testing this is kind of tricky since I needed to simulate an error.
An example of the result from this is below.

Note that this isn't always anywhere near enough to diagnose a problem and a description of what you were doing at the time you saw a problem is still invaluable.

Parameter cannot be null
Parameter name: original
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at GalaSoft.MvvmLight.Helpers.WeakAction.Execute() in C:\Users\lbugn\Documents\MVVMLight\GalaSoft.MvvmLight\GalaSoft.MvvmLight (PCL)\Helpers\WeakAction.cs:line 357
   at GalaSoft.MvvmLight.CommandWpf.RelayCommand.Execute(Object parameter) in C:\Users\lbugn\Documents\MVVMLight\GalaSoft.MvvmLight\GalaSoft.MvvmLight (PCL)\Command\RelayCommand.cs:line 230
   at MS.Internal.Commands.CommandHelpers.CriticalExecuteCommandSource(ICommandSource commandSource, Boolean userInitiated)
   at System.Windows.Controls.Primitives.ButtonBase.OnClick()
   at System.Windows.Controls.Button.OnClick()
   at System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs e)
   at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent)
   at System.Windows.UIElement.OnMouseUpThunk(Object sender, MouseButtonEventArgs e)
   at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
   at System.Windows.Input.InputManager.ProcessStagingArea()
   at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
   at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
   at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
   at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   at System.Windows.Application.RunDispatcher(Object ignore)
   at System.Windows.Application.RunInternal(Window window)
   at ArmyEditor.App.Main()

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 05, 2018, 03:43:31 AM
Army Editor

Smoothed out the values in the accuracy .txt files.

Reload accuracies when saving a change to a file.
When you use the preferences > Accuracies to edit files and save changes.
Previously, you would have needed to close the app and re-open to pick up changes to an accuracy file.
Having said that.
Extensive changes to accuracy files should not be necessary.

Change the accuracy drop down combo to include the name of the file.
(Ezra felt a tooltip wasn't obvious enough.)
Also added a border round the little graphs.
Note that picking a curve is a one off process.
You pick the curve out the combobox and it's values are applied to the unit.
You're not setting the unit to have Muskets or Pistols, you're just copying the values.
This then allows you to edit the values for a specific unit if you really wanted to.
It also means units and accuracy files are totally separate.
Someone else you give an army file does not need the various accuracy files you used to create it.
If you wanted to, you could have a different set of files you use for different periods and switch out which you have in the Accuracies folder as you work on armies for each period.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 05, 2018, 07:21:00 AM
Army Editor

Added a message which says which file name you just selected when you set the accuracy values.
This includes the initial set when you add a new unit.
This is because the values are initially set to the default - whichever file name contains "Musket" in the name.
As mentioned previously, if you have either none or more than one such file qualifies then strange things might happen.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 06, 2018, 01:34:22 PM
Army Editor

Several changes to the Accuracy editing. This is for both editing values of a unit and a txt file.
The x and Y axis are now labelled.
You're working with proportions and a percentage per slice for both.
If you have entered a range for a unit then that will be used when you're editing a unit's values.

There is also the facility to draw a curve.
You click the "Draw" button and a low opacity overlay is added on top of whatever curve you have.
Draw a line and when you finish it will be interpreted into values and those will replace whatever you had for that unit/file in memory.
You can then choose to save, close the window and abandon your changes or redo.
I can't manage to draw a smooth curve with a mouse despite multiple tries.
You may be better at this but my approach is to get near-enough and then edit the values.

You must left mouse ( or stylus ) down, draw continuously and then left mouse up.
You can't draw a bit, stop then draw a bit more.
The process is per continuous drawn line.

This picture is snagged mid-draw.


You can see the original curve behind the line I'm drawing.
Pretty much as soon as I mouse up, the old curve is replaced by a new one.
The screen capture approach I used doesn't capture the cursor.
It's a pen.
You're drawing with ink here so the curve can be a bit smoother than you'd get otherwise.

The process works by dividing the line into 100 vertical slices and working out where you drew in each of these.
If you don't start from near enough to the left axis then there will be nothing in "missed" slices and 1.0 is substituted.
Towards the right hand side, similarly 0.01 will be substituted.
In the below picture I stopped part way.
On this pc there is no noticeable lag between drawing the line and the processed result.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 26, 2018, 10:00:02 AM
Map Editor Grey Scale

Removed interval ( unused ).
Removed entry of high and low values from contours.
Calculating same instead.
Avoid calculating if there are no contours.


Note that a certain amount of artistry is necessary to get a nice curve when using contours. You need to fiddle with the blur, spacing and interval.
Probably my last choice if I was building a map myself.
OTOH you can trace contours off a real map and not sign up to google or think about how to reproduce something with shapers... So I expect some people will still want to use the approach.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 27, 2018, 08:30:57 AM
Army Editor

Switch default font size for the window when changing between styles. This is a simple fix to cope with the Victorian fonts being non standard sizes.
Fancy and plain font sizes are a bit smaller than victorian since they're inherently easier to read.
This ought to suit people with lower resolution displays.

Edit panel:
Move range above accuracy so a user is more likely to have entered it before clicking the pencil to edit accuracies.
( You should relatively rarely be clicking that pencil though. The intention is that you should almost always pick a different curve and or edit range rather than edit the accuracy curve for a unit. )

Textboxes will now grow as you enter more numbers.
Defaults are set Range 150, Ammunition 30, Reload 30 Shooting 1 Close combat 1.
These are more likely defaults than the previous values.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 28, 2018, 09:29:50 AM
About window

Added description of module.
Rationalised over long menu items (all modules ).
Added About to Map editor
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 08, 2018, 05:20:44 AM

Created solution
Created CombatLib.
This will hold the two sets of solvers used to work out combat results.

Created solution
Initial draft of main ui

Scenario Editor
Minor rationalising changes of stuff I noticed as I was essentially copying bits into the sandbox.
Moved some stuff around into common libraries so I can reference it in sandbox and game
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 08, 2018, 09:33:42 AM
Scenario Editor
Include centerville on map selection list even though it doesn't have a description.
This will mean the map editor will show Centerville.
If you try and edit that you will see a message saying "No design file" and you won't be able to edit it.
Centerville was created using the old map editor and though it works fine with scenario editor or the game it is not compatible with the new map editor.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 08, 2018, 02:02:58 PM
Sand Box

Load Scenario
Add armies to treeviews in tab control

These treeviews have more or less the default treeview template rather than the styled ones you see in other modules.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 09, 2018, 10:12:30 AM
Now loading the map and showing pieces
Mostly cut and pasted from Scenario Editor.
Needs more work to stabilise even what you see there...
But I'm fairly pleased with progress so far.


The really hard part will come when I start turning our ideas on combat and morale into code.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 10, 2018, 07:45:08 AM

Added tooltip showing unit data to treeview
In the image below, the cursor is over Colborne's brigade.
Removed same from piece - I found it gets in the way a bit when trying to drag.

Drag and rotate pieces.
The piece view started off as a copy of that in ScenarioEditor.
There are now quite a few changes to the sandbox version.
The sandbox version now has:

.5 opacity by default and 1 when selected.
Only the unit symbol hit tests - this is necessary so you can rotate and drag two units when close.
Their borders are likely to overlap which meant you couldn't rotate the one with a lower Z-Order.
A different way of doing Z-Order of it's parts.
A smaller subtle triangle denoting facing.
The grey outline and facing triangle are only visible on the (two) selected pieces.
Frontage is the diameter - matched by rather than defined by the front of the unit symbol.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 11, 2018, 08:39:03 AM

Bear in mind that the sandbox is intended as a utility and hence styling is only a priority if it interferes with readability.

Allow selection of red or blue piece as firing / target.
Calculate distance scaled to metres between unit centres.
This will be necessary to work out whether a unit is within effective range or not and which range band.
It also allows us to double check what units will look like at firing distances on the board.

Started on the bearing relative to facing calculations.
Mainly prove the code which will work out whether an enemy unit is within a unit's firing arc.

This is shown in the first of several tabs.
I've not even finished the first tab yet though

Internal interest only:
Change to how common libraries are referenced so it's easier to ensure they're compiled.
Moving numerous bearing calculations into ModelLib from MapEditor so they're common across the suite.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 12, 2018, 04:16:14 AM

Bug fixes on places:
Initial visibility - places were never visible in a loaded map.
The numbers showing points were repeated in the plaque when a saved map was reloaded.
Initially this bug looked totally weird - when debugging I could see the points were correct and the geometries initially correct.
Why on earth were they then changing?
These are interpreted into a collection of geometries.
The property holding these was being serialised/deserialised when it is intended to be purely calculated.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 12, 2018, 09:33:54 AM
Choose Map

Added ability to delete map files.
This will eventually need to distinguish between paid content and ones designed by the user.
These may go in different folders though - Steam has it's own expectations for the folder structure of one of it's apps.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 13, 2018, 09:18:07 AM

Recalculate position etc when rotating pieces.
Working on bearing and relative angle of target piece to shooting piece.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 15, 2018, 12:14:21 PM

Enfilade multiplier calculation.
Enfilade is sometimes called flanking fire.
When a unit shoots at an angle acute to an advancing line of enemy then each bullet has more soldiers it can potentially hit. That makes such fire particularly effective.

This is one of the reasons commanders would try and advance their battalion straight on towards an enemy unit and avoid crossing the face of any other.
The multiplier varies between x3 when the target is directly in line with shooting and x1 (none) when it's at 60 or more degrees.

Here red is shooting at blue.
The unit blue represents is facing directly down and the point of measure is centre to centre.
There is only 1 degree offset of the blue unit's line considered to be where the men would be and hence this is almost an ideal angle for red.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 16, 2018, 12:28:57 PM

Cycle through formations with right click of piece.
Handle column in enfilade calculation.
A column is effectively rotated 90 degrees for purposes of calculating it's edge.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 18, 2018, 09:50:37 AM

Bind formation of selected target so it's obvious which it's in.

Working out if a target unit is in arc of fire.
This involves calculating the offset between facing of a unit that is shooting and the bearing to the target.
At the moment I'm using 30 degrees but I may go for as much as 45.
Some designers (of other games and sims ) suggest arc of fire of close order infantry should be very limited.
I don't really follow that.
Napoleonics units drilled for front line(s) kneeling and firing line shooting over them.
Back ranks didn't shoot inbetween those in front - they shot over them.
Even the narrowest standard frontage per man allows for plenty of rotation of each.
And of course each soldier is side on to the direction they shoot in.
Yet some people reckon a unit should only shoot directly to it's front.

I think this is a convention adopted for some tabletop games as convenient.
Then propagated into computer games.
I suspect partly because it simplifies the calculations a lot if a unit only shoots directly ahead.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 22, 2018, 05:34:52 AM

The suite now shares and persists most of the values set under Layers.
If you lower the opacity of the elevation map or hide the grid in one of the apps then open it in any of the apps it will use that setting.
Some properties don't really have the same meaning.
In map editor the map background could be rather transient and a picture you open temporarily to trace or whatever.
For a Scenario, the background is the picture of the map with terrain etc that you built in the map editor.
The setting for Background is therefore not persisted.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 24, 2018, 08:48:32 AM
Piece Size

I've moved this from Settings to Scenario.
A Piece is a representation of a unit on the map.
This needs to be consistent for both players playing a game by pbem ( or maybe online eventually ).
Any difference in piece size from what the game is internally working with in it's calculations could otherwise potentially look very odd. With pieces overlapping visually but logically still being out of effective musket or close combat range.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 24, 2018, 09:57:23 AM
Map Editor

Description wasn't saving if you chose to save whilst focus still in the description.
Ensure Description persisted to viewmodel from view as user types.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 27, 2018, 05:47:18 AM
Map Editor

Improved the method of avoiding saving whilst a previous save is still processing.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 29, 2018, 01:48:45 PM
Map Editor
Change outline of symbols on river edit to dark blue in order to increase contrast.


Added experimental elevation based line of sight ( bresenham 3d ).
Which runs really quickly but seems to have problems.
Added display of terrain and elevation at cursor.
Necessary so results from 3d los can be checked.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 30, 2018, 01:27:14 PM
Map Editor

Change outline of river shapes in edit terrain to dark blue. Increasing their contrast for readability.
Reversed the icons for river widening in edit terrain
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 31, 2018, 07:12:38 AM

Routine to generate a grey overlay showing areas of the map which are out of line of sight using the 3d algorithm.
This allows us to visualise the results of the routine and check speed.
The calculations for the results below took 2.3 seconds which is blazingly quick when you consider it's checking 1155 * 805 cells. Less one.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 02, 2018, 05:46:17 AM

Stop users drawing more terrain whilst the app is still busy processing the one just drawn. This is particularly noticeable with large complicated woods where it takes significant ( maybe 3-10 seconds ) time to "plant" trees.

The map editor is quite resource intensive.
Not only is it processing "ink" to smooth it but it also works out all the points each terrain piece contains. The latter is  particularly costly on large areas.
A 4 core processor with hyper threading is advisable if you want to draw stuff quickly.

On particularly old or low spec 2 core pcs you won't have enough processing for some of the multi threading and you need to draw any area piece of terrain fairly slowly so it can keep up.

The game itself is likely to be less demanding.
I'll only know for sure once I write it though :^)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 06, 2018, 08:52:07 AM
Army Editor

Added first shot bonus mechanism.
Externally all you see at the moment is a checkbox.
Obviously, we will internally need some way for units with this bonus to track whether a unit has shot previously and return a higher factor if not.
This has been implemented using an extensible architecture. 
Of course this is as usual a first cut and therefore a prototype at this stage.
Smoke, notorious jamming and anything else we decide is a good idea will all be done this way.
They can all be called in the same way to give a shooting effect modifier. 
Once I write them.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 07, 2018, 06:52:10 AM
Model Library

Extended the list of "postures" this is what a unit is ordered to do - move, attack etc are obvious. Perhaps less obvious is Demonstrate which orders them to hang about outside range of an enemy but be in a position to potentially attack in order to pin. Probe would be move forward tentatively and avoid engaging.
Delay is try and slow the enemy without being caught and wiped out.

Working on shooting.
Rationalised code used to find width factors for units.
I will need to know exactly where units are when they are shooting or being shot.
There's a lot to do for shooting and hence I will be breaking this up into more digestible chunks.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 25, 2012, 10:24:47 PM

Point visualisation mechanism.

I need a mechanism to work out 5 points on a unit to use shooting from and to.
Just calculating these is all very well but you then just have co-ordinates X and Y for a point.

In order to check these are where I want I need some way to visualise that.
Which is where this thing comes in.
I can add co-ordinates found and it places a spot where they are.
Hence centre front of this red unit has a little spot on it.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 09, 2018, 08:25:47 AM

Calculating all 5 points on the front of a line.
The routine matches the NATO symbol size in an abstract manner.
Meaning it's calculated and not reliant on the graphic or objects on screen.
It allows for variable size of piece and unit type multipliers.

So far this is line only ie not column.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 09, 2018, 11:38:02 AM
Map Editor
Map Save bug fix.
Retain initial preference for grid visibility after capturing picture for map.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 10, 2018, 06:40:06 AM
Map Editor
Bug fix
De-select any terrain which is selected whilst saving. Then re-select it after.
Previously if you had a terrain selected the "marching ants" were visible as black dashes on the picture saved.
Which was not ideal.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 29, 2012, 09:17:42 PM

Shooting points for column formation.
If you look very closely you may notice spots are very slightly out of line.
Each location needs to be defined by integers for x and y - they're used to match a cell in the terrains and elevations matrices.
The graphics and hence those spots are, however,  located using doubles.
There's a conversion to integer and back to double which makes their location approximate and that of the spot even more so.
The pictures I post also tend to look bigger than they will on a monitor.
In any case, this won't be a problem in the game. Sub pixel accuracy is more than sufficient.

What could look a bit odd is if you have unit A in column and it is contacted in the flank by unit B.
B will overlap A partially.
This should be a rare event.
I may give some thought on how to avoid the anomaly but my thinking at the moment is this is not worth the complications it would introduce.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 12, 2018, 09:34:08 AM
Scenario Editor

Allow units to be placed overlapping.

This change is necessary to allow someone designing a scenario to have several units in close proximity eg the british units in hougomont.
 It's up to you to avoid bad things happening with this.
Various parts of the game will assume that units will not literally occupy the same space.
EG if you stack then a player will not be able to give any orders to the bottom units until the top one moves.

Avoided a null reference error under obscure circumstances whilst dragging a piece onto the board.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 17, 2018, 06:48:09 AM
Map Editor

Bug Fix
A while ago I changed the way terrains were presented to the UI.
The order of these matters because they go on top of any previous ones as you add a terrain.
What I hadn't noticed was that combining terrains needed to change.
They were being inserted and ended up bottom of the collection and below everything else.
When you click combine two new things are created. Technically these are geometries.
One defines the shape of the combined water and the other roads.
First water and then roads are added to the collection at the point you click the combine button.
The separate roads, lakes and rivers are hidden.
The implication is that if you combine and then add some terrain it could go over your water and roads.
Which you might want. Or you might not.
If that's not what you want you can redo the process by clicking split and then combine again.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 18, 2018, 04:23:33 AM

Working out which enemy units are in range to shoot at.

The first iteration finds enemy units within range + half piece width measured centre to centre.
The final version has to be rather more sophisticated.
Those that are found are "lit up" with a yellow radialgradient background which then fades out in a similar manner to the scenario editor mouse over.
As you can see from the below picture, it's possible that you might expect one unit to shoot at multiple enemy with split firepower.
I also need some way to work out whether a unit is masked by another.
This is an example of the value this prototyping adds -  it's easy to drag pieces around and see what happens which then makes things obvious one might not have considered.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 20, 2018, 06:41:36 AM
Map Editor

Bug Fix avoid re-selecting a terrain causing error when none selected.
Experimented with changing zindex of terrain. This is problematic so I shelved it.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 21, 2018, 07:42:09 AM
Map Editor

Move the zindex of a terrain up or down.
This will raise or lower a terrain object ( and children ) compared to other terrains.
Usually, as you add new terrains they appear on the map on top of previous ones.
The new terrain also appears at the end of the list of terrains in edit terrains.
If you drew something in the "wrong" order then you couldn't change that order short of deleting something and drawing it again.

You move a terrain by clicking one of the chevrons on the right of the terrain in Edit Terrain.
The lower the terrain in this list the "higher" it appears on the map.
Here we start with a river which is on top of the rest of the terrains.


If I click the top button of that river then it moves up the list and now appears below the woods and it's trees.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 27, 2018, 04:14:13 AM
Map Editor

Replaced line processing in order to ameliorate "anomalies".
Whilst drawing roads Ezra has found you can get some "artifacts" appear.
When you select such a road the animated dashes can be seen crossing the line.

This seems to be when drawing very slowly.
I replicated the problem but had to draw very slowly and wiggle the mouse to reproduce it.
My machine, however, is win 10 and just 3 years old whilst Ezra's is way older and win 7 with only 2 cores.
The issue might be worse on machines with just 2 cores because they're under powered for the multi threading.

My replacement routine is less likely to produce these.
If you get a lot then try drawing slightly faster with less wiggling.
Do not go back over a line as you are drawing it.
You can force it to try and recalculate a road.
In edit terrain, select the problem road.
Check you're seeing dashes animating across it and make sure you know which road you're about to re-process.
Right click the entry for your road in the left panel.
When I do this it fixes any problems I've managed to introduce.
On one of Ezra's test maps I found a couple of roads just disappeared.
If that happens to you then it's somehow corrupt - delete that road ( select in left panel and press delete ).

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 29, 2018, 09:50:00 AM
Map Editor

River anomalies fix.
All line drawing other than rivers now processes using a constant width line.
You are very unlikely to really want a road or fence to have variable width so that's pretty safe.
Rivers tend to get wider as they go, so this is the one line terrain you might not want constant width.
Avoiding the odd line you sometimes get with slow wiggly lines drawn with a radius close to width is a bit tricky.
If you right click the word "River" in the list of terrains then that river will be recalculated.
This usually removes anomalies.
Sometimes two or three clicks are necessary.
If you have the problem river selected and the black dashes animating around it, then any oddities are much more obvious.

Since rivers are outlined in a low contrast colour, any extra little line inside the river isn't particularly noticeable.
A fairly simple way to avoid these anomalies completely is to draw slightly faster and avoid wiggling the mouse.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 30, 2018, 04:31:18 AM

Centralising Places text.

Map Editor

Optimising river outline process so that the longer "fix" process that slightly widens the river is only used when you right click and not initially.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 06, 2018, 12:20:45 PM
Map Editor

Visualising terrain which has been set.
This allows you to see a red overlay where a given type of terrain has been set. You can thus double check the terrain has been processed as you expected and those cells which you wanted to be water are marked as water.
This is particularly useful if you happen to have a low end or old and low end PC which only has 2 cores.

A new panel in the left tabcontrol allows you to select a terrain type. Notice that terrains which have no meaningful area or do not play a part in marking terrain are not options. A place is a special sort of a label and no terrain cell is marked as type place. Similarly contours are used to calculate elevation rather than set terrain type.  You can put a woods over a contour and still process that contour for elevation.
The cells are then translated into a red overlay.

Bug Fix

The way the area of buildings was worked out had several problems.
I've refactored this to improve the process.
seems stable to me.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 11, 2018, 10:29:57 AM
Army editor
Add army description
This is in an expander you drop down using a round button next to the army name.

Map Editor
Improved calculation of points contained in a terrain.
This morning I drew a river from top left corner to bottom right on a map and it took 9 minutes to calculate.
Not many maps will have this sort of thing but it got me thinking.
I tried another approach - I didn't think it would be particularly efficient but 9 minutes is pretty easy to beat.
Now under a second.
I thought it might be faster.... but that's ridiculous.
 :D :D :D :D
This is going to make a massive difference on lower end PC's like those which only have 2 cores... for example.

Persist compass rose visibility as a preference
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 12, 2018, 12:29:22 PM
Map Editor
Improve feedback on load and save by ensuring isbusy if visible and only hidden once complete.
Avoid excessive recalculation of area for buildings.

File open dialogues are now replaced with a standardised view similar to the open map view.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 14, 2018, 11:51:27 AM

Working out which enemy units might be in range.
This works centre to centre and is the first stage will be used for shooting.
I'm using the "light up" mechanism which is used for mouse over in scenario editor to highlight units might qualify.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 15, 2018, 06:15:54 AM

Changed from using sdk Behaviors over to Nuget package.
The Nuget package is open source and likely to get new functionality.
This is also a step towards using .net core 3.0
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 17, 2018, 09:42:27 AM

I'm currently prototyping effect of arc of fire on which units are in range.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 19, 2018, 09:43:29 AM

Working out the points defining a unit's position.
This is part of which unit can shoot at which.
Turns out there are a lot of complicated edge cases when you mix in the angle and formation of each unit, angle of facing and multiple potential targets.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 21, 2018, 08:56:52 AM

Import custom paths.
On the file menu there's a new option which allows you to import tagged paths out the custom resource dictionary into your map.
This means you then don't need to distribute your custom resource dictionary to anyone else who wants to edit your map.
You can largely work with these paths like you drew them in the editor.
( Although in this initial version there are some caveats and probably the odd bug lurking there ).
For our internal purposes this will make it easier for Ed the graphics guy to draw using his fancy tooling and for Ezra to then import into the Map Editor.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 22, 2018, 09:59:55 AM

Stabilising work on new path import process.
Removed old obsolete custom path processing.
Only imported paths will now contribute to what terrain is in a given map cell.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 27, 2018, 09:34:30 AM
Several fixes
Scenario editor hadn't been changed to use:
The persisted compass rose visibility
The standardised dialogue for map open.

Scenario Editor
Storing Places data in the scenario.
Moving the Kriegsspiel / Simulation button
Adding tabcontrol in left panel
Move current left panel content into first item of tab.
New tab to allow editing of places data for a scenario
Save edited places to scenario.

Still needs a bit more work - eg the panel says what terrain the mouse is over probably now belongs in a different tab
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 28, 2018, 08:54:00 AM
Scenario Editor

Bit more work on places.
Needed to clear places when another scenario or map loaded to ensure that version's places used.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 28, 2018, 01:05:19 PM
Map Editor

Added New Map option.
Reset map data for new map and when loading a different map.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 30, 2018, 09:06:58 AM
Map Editor

Added json attribute so the terrain type of a terrain should be serialised as string.
Ezra somehow has a map where all the terrain types are wrong.
I can't reproduce this issue.
Maybe it's win 7 related somehow but the data is serialised to json and back again when you save/load a map.
Maybe this is somehow failing on his win 7 machine.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 30, 2018, 01:20:16 PM
Map Editor

Bug Fix.

Changing the zindex of terrain was leading to terrains having the wrong set of points associated.

The Id of the two objects was out of step.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 31, 2018, 08:16:03 AM
Map Editor

More testing and minor changes for re-ordering terrains.
I experimented with changing the hypsometric colours in order to try and give a more consistent tonal gradient between brown and cream.
Doing that resulted in a washed-out cooler look which is less attractive.... so I then backed the change out.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 02, 2019, 03:26:47 AM
Army Editor

I couldn't reproduce the issue reported with errors whilst deleting.
The current version of the map editor seems to work fine no matter whether I open a file, save, paste, edit.
I tried everything I can think of - no error.

The army file name should probably match the army name though and you can easily edit the army name.
I've changed file saving so it copes with changes to army name.
Hence if you open army XXX and change it's name to YYY when you save, the original XXX file will now be deleted and your army saved as YYY.
If you wanted to email an army to someone else, it should now be obvious in file manager which file is what.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 02, 2019, 12:58:12 PM
Map Editor


Line (only) stable, still got to do area terrain types.
This new process allows you to define terrain using straight lines rather than the "ink" curved lines.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 03, 2019, 09:52:36 AM
Map Editor

Redid the bridge area calculation.

This was marking an area equal to the line drawn but bridges are drawn from the start point to the end.


Some refinement of the line terrains process.
Added areas.

Like when you're drawing these freehand, areas are self closing and to draw a square you draw a U.

For example:
Translated to a Field gives:

The dashed line is from the last point clicked to the cursor.
That screen grab doesn't include the cursor.

Not everything can work with this - removed those terrains which will not from the combo
Seems stable now.


I wasn't particularly careful drawing the lines there.
If you draw a line doesn't look right you can reset.
Drawing a line precisely around a field or next to another is a bit fiddly.

Since these are translated into regular terrains you can of course also delete one after you translate.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 04, 2019, 01:57:32 PM
Army Editor

Blank out description for new army.


Calculating the points for a unit in square formation.

Map Editor

In order to try and improve overall performance of the map editor when a complex map is being edited I experimented with virtualising the left tabs.
This does not noticeably improve performance and introduces a number of complications.
I've parked this work in a separate branch.
It'd be nice if switching  tabs was instant, but it seems likely saving the user that second would take an inordinate amount of work.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 05, 2019, 10:05:29 AM
Scenario Editor

Fix the mechanism handles routed validation failures.
The nuget xaml behaviors are subtly incompatible with part of MVVMLight.
I expect Laurent Bugnion will change the reference in eventtocommand eventually but I need a workround for now.

Reduce size of the infantry square formation.
A "real" battalion square would maybe be 50 yards or so square making it under a quarter of a battalion frontage.
That would be tiny if I did that though so half the frontage square will have to do.
It's still going to be too big but this now as small as I can make it and you can still make out the kriegsspiel strength bands.

More work making get the "target" points for a piece into a generic method that varies based on formation.
This is the points on a line for all but square when it's 4 lines.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 06, 2019, 08:05:37 AM

Removed Limbered and Unlimbered from formations.
Artillery in column will be limbered and hauled by horses.
Artillery in Line is not limbered and will move slower.

In real world for our period a cannon could be prolonged and moved by it's team of horses without being limbered.  If you feel the need you can alter scenario movement speeds and how long it takes to change from line to column to take this into account.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 09, 2019, 03:31:17 AM
Scenario Editor

Added formation change time to edit movement rates
This is per side so one can be better drilled than the other.
This will be used as a base value.
Changing formation will be harder when close to the enemy and harder again when under fire.

Show piece size in px on menu
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 11, 2019, 06:10:20 AM
Choose file view - increased width of column for name


Best visible target calculation.
This takes several points representing a shooting unit and work out what enemy units are in range and within arc of fire.
It then looks at the distance between each shooting point and each visible point representing the position of qualifying target units.
The closest (or none) is chosen for each shooting point.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 11, 2019, 12:05:26 PM
Choose file view, added user confirmation before deleting.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 12, 2019, 07:45:07 AM

Shooting - another iteration on best target points.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 12, 2019, 09:59:50 AM
Scenario editor
Bug fix
Set turn time.
The width of each rectangle representing movement was calculated incorrectly.

Army Editor
Increase ammo max to 999
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 15, 2019, 05:11:55 AM

Moving some code around so shooting and target points are only calculated once per unit ( in a time slice ).


This is the standardised view which is used to open a file -  map, army or scenario.
Avoiding opening any selected file if you close the window using the x top right.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 16, 2019, 06:26:03 AM
Combat Lib & SandBox

Started shooting prototype.
There are a lot of factors go into deciding how many casualties are inflicted by a volley.
Amongst other things, a unit might not be shooting at just one enemy.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 19, 2019, 10:20:43 AM

Shooting weighted random and modifiers.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 21, 2019, 03:41:43 AM

Moved randomisation routine and weighted it.
This is used for shooting and the previous version was a bit too slow and producing too many casualties.
The routine now produces a "bell curve" similar to rolling 3 dice - or normal distribution.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 21, 2019, 06:16:29 AM
Sandbox & CombatLib

Calculating the zone shooting is from - front, flank or rear.
A unit in line has 5 "shooting points" and fire is calculated for each.
The "zone" that point falls in is calculated for each of these.

The zone will be used for morale.
Being attacked from the rear doesn't particularly cause any more casualties than from the front.
It's particularly bad for morale though.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 22, 2019, 09:47:02 AM

Added horse holders multiplier
A quarter of skirmishing cavalry are allocated as horse holders so they shoot at 0.75 effect.

Minor refactor of combat code.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 23, 2019, 04:34:44 AM
SandBox & ModelLib

Added Current stats for piece
This allows me to track losses from shooting.
Will allow me to track changes in status such as morale, fatigue etc.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 25, 2019, 10:01:56 AM
Sandbox & CombatLib

Added Morale prototype.
Still incomplete but I now have a set of morale states and a mechanism which will degrade these as a unit is shot.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 26, 2019, 09:51:36 AM

Degrading morale from being shot at.
And more work on morale generally.
All this is still prototype stage.

There are two measures of morale.
The stat which is 1-99. ( A 1 stat morale unit would be extremely brittle and 99 would be equally silly).
The level ( I might change the name for that ) which is the unit's current state and can reduce effectiveness, limit what they will do or make them run away completely.

The various morale levels are:


Most, maybe all units, will start Steady.
How a unit gets to be Enthusiastic is TBD.

Hence (at present) if a unit fails morale tests badly enough it can be irrecoverably broken.
I might make that only if attacked whilst routed.

Each usually has 5 shots.
A unit shot at takes morale tests.
These are a straight percent roll vs the unit's current morale stat.
Failure reduces the morale level to the next one - eg Steady to Slowed.
It takes 1 test + another per 5% casualties taken.
Just being fired at can be bad.
Taking a lot of casualties is likely to be really bad.
For each test the current morale stat is always reduced by 1.

Say unit X takes fire from unit A.
Unit A has 5 firing points which fire is resolved for.
For each of these.
Casualties are resolved.
Morale is then tested.

At the end of a period... which is yet to be decided....
The unit will recover morale if it wasn't shot at during that period.
At the end of a period.... again which is yet to be decided...
The unit may be rallied to recover level.
Winning a combat will probably increase morale level.

There will also be some sort of rallying mechanism.
Self rallying will be possible but leaders in proximity will be better.
You can't just send a note telling a unit to rally.

This attempts to model how real world unit morale works.
Studies looking for a morale losses based "break point" have found there is no guaranteed percentage.
An assaulting unit will probably break at around 30% losses but there are instances where attacks have still carried on with higher or stopped with far lower.
"Just" 10% losses can often stop an assault.
What these studies found was how fast a unit took losses was usually a decider.
This is what reducing the morale stat and then increasing it when not under fire is about.
If a unit comes under sustained attack then it will become brittle.
If it comes under attack from numerous attackers then that will happen quicker.
The longer it goes without being attacked the more such a unit will recover morale.

Below is debug output for some shooting.
I'm using this to check my process gives good results and it's not really for public consumption but probably clear enough.
If you find it confusing, don't worry.
Combat reports you see in the game will be more user friendly, albeit with less internal detail.
When I write em.

The 5 sets of hits (casualties) are one each per firing point.
The unit shooting is strength 2390.
It has first shot bonus making modifier 1.2
Each musket is rated as killing 1 person per hit.
This is very short range so accuracy is high.
The morale of the firing unit is indifferent -  40
The quality of the firing unit is indifferent -  42
The target unit is face on and both are in line so no enfilade multiplier
The random factor used is weighted -  It's currently three randoms between 0.01 and 1 added together and divided by 9.
Note that the casualties are maybe still too high - morale is and was far more significant than pure casualties.

Hits 91 -- Strength: 2390 Modifier 1.2 Lethality 1 Accuracy 0.993 Morale 0.4 Quality 42 Enfilade 1 Random 0.191271533347327
Hits 51 -- Strength: 2390 Modifier 1.2 Lethality 1 Accuracy 0.993 Morale 0.4 Quality 42 Enfilade 1 Random 0.108229782068795
Hits 110 -- Strength: 2390 Modifier 1.2 Lethality 1 Accuracy 0.993 Morale 0.4 Quality 42 Enfilade 1 Random 0.231340596404861
Hits 101 -- Strength: 2390 Modifier 1.2 Lethality 1 Accuracy 0.993 Morale 0.4 Quality 42 Enfilade 1 Random 0.212642983942902
Hits 122 -- Strength: 2390 Modifier 1.2 Lethality 1 Accuracy 0.993 Morale 0.4 Quality 42 Enfilade 1 Random 0.255582311102719

The morale tests for these:
Fives +1 is five-percent-losses plus one.
Rolled is the percentage "rolled" as a test.
Morale is the current morale of the unit which started at 72 and drops 1 each test.
Strength is the number of men left alive in the unit being shot
When it says "Reduced Morale state" that means the level drops from Steady > Slowed > Shaken > Halted
This is a relatively large unit shooting at a smaller one at point blank and 475 casualties would be a LOT from a real napoleonic era volley.

Rolled 20 Morale 71
Rolled 38 Morale 70
New Morale Steady Casualties 91 Fives+1 2 Strength 1560
Rolled 19 Morale 69
New Morale Steady Casualties 51 Fives+1 1 Strength 1509
Rolled 20 Morale 68
Rolled 15 Morale 67
New Morale Steady Casualties 110 Fives+1 2 Strength 1399
Rolled 92 Morale 66
Reduced morale state
Rolled 82 Morale 65
Reduced morale state
New Morale Shaken Casualties 101 Fives+1 2 Strength 1298
Rolled 61 Morale 64
Rolled 16 Morale 63
Rolled 70 Morale 62
Reduced morale state
New Morale Halted Casualties 122 Fives+1 3 Strength 1176
RunTime 0 s 10 ms
Total casualties: 475
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 27, 2019, 07:52:10 AM

Halve shooting casualties.
As I mentioned above, the number of casualties was coming out far too high.

Morale cannot now drop straight through to dispersed from one unit's volley.
It needs to already be at routed before an attack can drop it to dispersed.
Meaning at least two volleys ( or a volley then close combat).
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 28, 2019, 04:32:59 AM

Rationalise naming of army files.
Previously the full path was retained in scenario files.
Since that is in appdata and includes user name, only the army name will match from one user's machine to another.
Since we've not yet delivered the scenario editor it's only Ezra and I really need to worry about this for now.
Best to neaten things up as I notice potential future issues though.

Show messagebox when army file handed to ReadArmy cannot be found.
Previously it just crashed and burnt.
Now it'll still crash and burn but you'll at least get a messagebox telling you what it is looking for.
Why might you not have an army file?
This could happen if you change an army name after adding it to a scenario or you just don't have an army a scenario is relying on.

Note that all files must be in your user's appdata in the correct folders.
You can't use  an army file you put on a usb or from just anywhere on disk.
Exactly where files go will have to change when we deliver the live version via steam.
Steam has it's own delivery mechanisms and game folder structure that we will need to conform to.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 01, 2019, 04:11:24 AM

Force focussed element bindings to transfer to viewmodels so their values are committed prior to saving.
By default, wpf bindings transfer data from the UI to their viewmodel when focus is lost.
Clicking on a menu item or using a keychord like Ctrl+s doesn't make a control lose focus.
Hence you could potentially lose a change to the last field you edited when saving.

Force sliders to "snap" or increment/decrement in integer intervals ( no decimal places ).
None of the values make any sense to numerous decimal places as you could previously set when dragging.

Scenario Editor
Change file naming so it uses the scenario name.
Remove full url from scenario.  This couldn't work cross machines and it's a bad idea to allow saves outside the expected file structure anyhow.
If wanted to back up files then you can use file manager at the moment. Steam has cloud back ups built in.

Move scenario name / description army names and turn length into a new first tab.

Both changes are for consistency with other apps.
Moving the scenario name etc makes it far clearer what scenario you have in case you're unfamiliar with it.

Title: Re: Changelog - picture heavy
Post by: Dr D Ezra Sidran on February 02, 2019, 08:48:01 AM
"Unimaginative description blah blah..."  ;D
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 06, 2019, 07:51:16 AM
Scenario Editor

Added start time and a new control that allows you to edit that time.
You can type in hours and minutes.
And or use the mouse scroll wheel to increase/decrease either.
There are also up-down repeat buttons if you prefer clicking to scrolling.
A repeat button keeps on clicking when you hold it down ( like the up and down arrows on a browser scroll ).

Hours "clock" so as you scroll up it will go from 23 to zero and scrolling down from 0 takes you to 23.
Minutes work similarly except obviously 0-59.
As you scroll over 59 and the minutes reset to zero an hour is added, as you go the other way it is subtracted.
The mousewheel scroll can  be much faster, especially if you have one of those mice whose wheel will free wheel quickly.  I use a Logitech mx master 2s and I can just spin the mouse wheel. Hours or minutes will then change like a blur.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 10, 2019, 08:49:51 AM
Map Editor

Added right click piece of terrain in Edit Terrain mode selects that terrain.
This allows you to identify which terrain you want to work with in the left panel from what you're seeing in the right.
The selected terrain is outlined in blue and given a light blue background in the left panel list.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 11, 2019, 04:18:16 AM

Yes, I've actually started to do some work on the game itself.

Started to build out the main containers and tabs.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 11, 2019, 12:51:21 PM
Menu Sliders

Bug Fix
When I made piece size snap to integer numbers, I also broke the other menu sliders used for opacity.
Fixed these so they snap to 0.1 change and use large change of 0.1.
Large change is used when you click the button on either side of the slider.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 12, 2019, 02:30:06 AM
Scenario Editor

Bug Fixes:

Commit start time values when typed.
As part of this change I've improved the process which commits bound data when the user clicks a menu item or uses  a key chord to save a scenario.
By default, bindings transfer data from a textbox to the viewmodel ( which is where data is saved from ) on lost focus. Clicking a menu item or using a key chord does not make a textbox lose focus.

Force reload of map when loading another scenario with same map.
Only clear scenario when a new scenario chosen in open scenario
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 13, 2019, 06:39:12 AM
Scenario Editor

Minor changes to how courier distance is calculated.
This is still a prototype because - when finalised - it will be used in the game rather than scenario editor.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 14, 2019, 02:50:12 AM

Some more work on menu and infrastructure

Army and Map Editors

Fixing wiki links.
The url have moved since I set these up.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 19, 2019, 08:18:02 AM

Working on the start new game process.
Not much I can actually show you yet though.

Added icon.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 20, 2019, 05:04:13 AM

Sketching out the new game view.
Still early days.
Largely because there's a lot of structure associated with creating something which will encapsulate a game / game save.

You pick a scenario from a dropdownlist.
That then has two sides in it.
You pick which of these you will be playing.

You then pick who or what you will play against.
That will be the AI or a person, via PBeM

The textbox for email address appears when you choose PBeM.

Disappears when you pick AI. You're not emailing your computer.

This specific aspect will almost certainly change significantly.
For example.
It could well be most people only play one or two friends - so inputting a (short) list of name and email address separately would suit better.
Eventually, we could build a web site allows you to find opponents and arrange games. Which would of course have a cost associated that we'd have to cover somehow. Maybe google ads would be enough.

There are also other options to add to this screen.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 22, 2019, 04:13:39 AM

Added Fog of war selection.
This is a drop down, defaulting to unit based view.

The options are:


All means no fog of war.
Unit is like pretty much every other game works and you see all your own stuff plus any enemy which is in LoS of your units.
Commmanders is units your commander or HQ can draw LoS to. That applies to your own combat units as well.
HQ means you only see units your General/HQ can draw LoS to.

Personally, I think Commanders or HQ based visibility will not work.
You need to be able to see your own units to give them orders.
You will of course need to be able to see enemy units to react to them.
If both your unit and one it somehow ends up fighting are out of sight all you would see as a player is a report some time later.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 24, 2019, 08:56:07 AM
Scenario Editor

Added checkbox in layers menu to toggle retreat point visibility.

Fixed up the clear scenario process which wasn't clearing hardly anything.
Now when you choose new scenario the old map and army are cleared.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 26, 2019, 03:48:10 AM

Increased movement costs of BUA and Fortification.
The former is to make couriers move along roads inside BUA.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 27, 2019, 04:44:56 AM

Sketching out game objects- this is the set of objects used to hold pretty much everything makes up a "game".
There are a lot of these so I'm currently kind of chipping away at the mountain roughing out rock for my statue.
Lots of pieces of rock are flying around and it's a huge mess.
But you need to start from somewhere.

Picking a scenario for a new game now actually has some noticeable effect.
Probably way less than you're thinking though :^)


Click the button and you get to see the scenario name and description set, so far.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 02, 2019, 08:27:43 AM

Added more infrastructure.
Most noticeable effect is that new game now loads the map.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 04, 2019, 12:46:29 PM

Added prototype PieceView.
A unit "on the board" and in action becomes a Piece which additional properties such as location.
A PieceView is the piece of UI which has the circle that can "light up", the triangle indicates facing and the symbols representing unit formation and type.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 05, 2019, 06:59:25 AM
Scenario Editor
Adding message to indicate the ui is busy if the user ignores the spinner and tries to save.
Warning when saving scenario to tell you if there's an orphaned unit - one whose CO is not in the scenario.
This doesn't stop you saving the scenario - you might only be part way through building the thing and want to head off out or something.


More work on Pieces.
Which turned out to be rather more complicated than I was thinking.
I can't "just" re-use code out the scenario editor.
Partly because you don't have to use all of an army in a scenario.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 06, 2019, 03:45:53 AM

There are two labels, one above and one below the plaque for a place.
The plaque is hidden when the points are 0.
The bottom one is usually hidden.
When the place is within a certain distance of the top of the map, the top label is hidden and the bottom one shown instead.
This is the simple mechanism used to stop labels running off the map.
Upped from 30px to 60px.


More work on Pieces - something to show you.
Now visible on map.
Added OOB structure to Units tab.

This first iteration is still very much a prototype EG which army is the player's is still hard coded.
I need to implement the player0 = which army and player1 = other army and a way to switch which is the current player.
Along with pretty much everything like everything to be input and saved per turn like orders and results. 

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 06, 2019, 08:57:16 AM
Scenario Editor

Warn user when closing app with unsaved changes.
Similar to the army and map editors.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 06, 2019, 01:26:23 PM
All Menus

Refining look.
Refactor of user message and busy indicator into re-usable common control.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 16, 2019, 09:22:00 AM

Fix piecesize bug.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 19, 2019, 01:13:41 PM
Kriegsspiel piece

Fix width of 3rd kstrength displayed
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 27, 2019, 02:27:30 PM
Kriegsspiel pieces

Made the line formation icons square.
Unit type width multipliers are now no longer applied to kriegsspiel line icons.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 16, 2019, 07:43:12 AM

Added mechanism tracks which the "current" side is.
Because ( naturally ) as you play the game you should only be able to order your own units about, see what your entire army contains etc etc.
Add "second" army's pieces to board.
Clear old pieces when starting a new game.
Title: Re: Changelog - picture heavy
Post by: Sitnam on May 16, 2019, 08:28:45 AM
It's gone quiet here and still no word on a release date.  Should backers be worried?
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 18, 2019, 12:20:56 PM
Ezra is working on the ai but posts on his blog.
The pause in my development work is due to several factors.
It's a pause rather than end though.
Title: Ai & the Sand Box
Post by: Dr D Ezra Sidran on May 20, 2019, 03:16:42 PM
For the last six weeks or so I've been working on porting the AI code that I wrote for my  PhD dissertation ( ( and the MATE project code that I did for DARPA into the General Staff Sand Box which was created for testing AI, combat, etc.

The thing about AI is that I like it's often like being a submarine commander: it's all happening below the surface and often there's nothing much going on visually. AI - especially tactical AI - requires numerous 'building blocks'. For example, one of the most important is being able to identify battle lines. Here is a screen shot from the Sand Box showing how the AI perceives battle lines: (
This scenario uses a restored map from the original 1882 American Kriegsspiel.

I've written at more length about what's going with the battle lines calculating AI on our development blog here: (

As always, please feel free to contact me directly if you have any questions or comments (or just reply to this post). I'll be glad to respond.
Title: Fixed bug in the way battle lines are calculated
Post by: Dr D Ezra Sidran on May 23, 2019, 10:00:49 AM
Wow! This was the worst case worst bug I've hunted down and killed in my 30+ years of coding. I noticed an error in a picture I posted in this article on our development blog: (

It's been driving me crazy for two weeks. But, it's fixed now.  I'll write a bit more about this in a blog post shortly.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 26, 2019, 06:52:30 AM

I've started prototyping the mechanism you will use to give move orders.
The idea is:

When in order mode, there will be a chevron appears when you mouse over one of your units.
You drag that to where you want your unit to go.
As you drag, the game will calculate whether you're ordering your men through invalid terrain like a swamp, river or whatever.
There will be an indication this would be an invalid move.
Which is why it's light green.
I'll probably use light green if OK, red if not.
Not sure about using colours matching your side whilst ordering.
You're not going to see enemy orders. ( Obviously ).

A line will be drawn to where you're moving and combined with the chevron this will of course look like an arrow.
When you mouse up you will see an arrow ( in order mode ) showing where you ordered them to go.
You can then issue another move and drag a new chevron.
Some limits to the number of arrows are likely but tbd.
As is exactly how road movement will apply.
Logically, this would be outside of threat from enemy since units would likely be deployed into line for combat and hence out of column and "off" any road by their CO.

The chevron is somewhat tricky because it's point is where you're going to and it needs to drag smoothly.

I've therefore been experimenting in a scratch solution.


The blue rectangle is there so I can easily tell where a specific point is.
Both that and the chevron are positioned at 100, 100
So "usually" you'd expect the chevron's left point to be on the left edge of that rectangle.

Although that's tricky to show, the chevron also rotates around the point.  As you'd expect with something showing where you're going.

Title: Range of Influence
Post by: Dr D Ezra Sidran on May 29, 2019, 06:53:41 AM
Added Range of Influence calculations. These factor in 3D Line of Sight and Range of weapons. Below is a screen shot of the ROI mapped for the battle of Antietam at dawn.


Note: visual display of ROI is for AI debugging purposes and probably won't be available in the game (it's not really necessary). It shows what every unit can hit and the cumulative firepower of all units.

This is an ROI map from the American Kriegsspiel 1882 scenario:


Notice the range and accuracy of 19th century artillery; it's accuracy falls off quickly.

I will be writing a longer and more detailed blog post about ROI at our development site: (
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 09, 2019, 09:40:58 AM

Prototyping move chevrons.
First step is to prove a chevron will position correctly and point in the correct direction.
This is very quick and dirty, adding a chevron for all units.
There will be a panel for orders eventually and you'll need to be in giving-orders mode before you see any.
The final version will only show your own side's orders of course.
I'll also need some mechanism to hold the data.
The chevrons are also fixed size and I need to work out whether to scale or recalculate the chevron shape.
One step at a time though.


The chevrons point in the direction of facing - some units are in column.
The very point of the chevron is positioned at the centre of the front of each unit.
Which is a sort of logical position for movement.
Some of movement will necessarily be somewhat abstracted in that it's that point which will count for what terrain a unit moves through rather than each point of it's face.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 16, 2019, 08:12:38 AM
Army Editor

Increased range to 9000 m.
Note that this is not maximum theoretical weapon range - don't just look up the claimed range of an artillery piece and input that.

For example
Theoretically, a musket would maybe have 300m or so range.
There were a number of Napoleonic war engagements where battalions exchanged musket volleys at 100 yards.
To negligible effect.

Similarly with artillery.
Even if you could make out a unit at 9000m away, you'd probably not be able to work out where your shot landed with
Guns of this period were almost always direct fire.
The exceptions where indirect fire happened were rare and involved rather unusual circumstances.
Which of course contrasts completely with ww1 onwards where artillery fire would usually be indirect.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 18, 2019, 01:00:23 PM
Map Editor

Bug Fix
If you checked the minimum zero box, the elevation values were set on the wrong collection which were then overwritten.
At the moment you can work round this with the current version by unchecking that box.

Since Google decided to force everyone to register a credit card in order to use the elevation api, they have been able to remove a number of the safeguards they used to have in order to stop abuse.
As a result of this I've been able to reduce the throttling on the service calls.
Which means a map worth of data is about twice as quick.
This, by the way, is fairly  connectivity sensitive.
It's making a service call every 40 milliseconds to get data.
The data returned is not massive by today's standards but non trivial.
A broadband connection will easily handle bandwidth.
Poor wifi connections might not.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 21, 2019, 12:25:00 PM
Scenario Editor

Scenario Editor

Bug fixes:

Set victory conditions had both values bound to the red side's text box.
Set turn time wasn't notifying value changed when you re-read a scenario so you didn't see the value change to that in the file.

Considering the range of values led me to a realisation.

You could set scenario minutes per turn to between 1 and 60 minutes.
Higher minutes per turn would be very frustrating for players and allow way too much to happen with units out of control.
I've reduced the maximum to 20 but I think maybe anything over 5 or so is a bad idea and could see weird things like units just walking past each other without players being able to give more appropriate orders.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 22, 2019, 08:08:05 AM
Scenario Editor

There were still issues around setting turn time.

I refactored this.
The viewmodel is now dynamically created and the view templated out from it.
This seems to have stabilised behaviour.

I still think we may have to either reduce the possible range of turn times or fix it at 1 minute.
We'll need one of those actual working game things to prove that theory and that is still quite some time distant.
Title: Re: Changelog - picture heavy
Post by: Adraeth on June 24, 2019, 09:59:14 AM
"You could set scenario minutes per turn to between 1 and 60 minutes.
Higher minutes per turn would be very frustrating for players and allow way too much to happen with units out of control.
I've reduced the maximum to 20 but I think maybe anything over 5 or so is a bad idea and could see weird things like units just walking past each other without players being able to give more appropriate orders."

Maybe a 15 minutes might be an interesting choice for fast games but without those problems, an hour would be 4 turns so a whole battle might around 32 to an average of 40 turns i believe.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 30, 2019, 08:17:58 AM

Reviewing and changing a number of classes related to orders.
This is a pretty complicated part of the game.
Although I sketched out some classes a while ago, it turns out these were way off what I need.
Not 100% "correct" yet but I think near enough so I can start using it.

Title: Re: Changelog - picture heavy
Post by: Dr D Ezra Sidran on June 30, 2019, 08:26:23 AM
I'm doing the same thing with the AI.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 02, 2019, 08:48:50 AM

Only the "current" side - ie you own side - will now show the move chevrons.
Make chevrons match scenario piece scale.

Setting the scale particularly high or small has potential downsides.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 02, 2019, 10:05:37 AM
Refactor Move Chevron into a control.
This is a step towards the drag drop process necessary for move orders.

Scenario editor
Confirmation message when scenario saved OK.
Could have sworn I added that a while ago... but it's in there now anyhow.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 03, 2019, 10:23:28 AM

Reduce size of move chevrons by a quarter
Added last order location to piece.
Set that initially to the piece location on load and deserialisation.
Bind move chevron location to that rather than the piece location.
The net result being no noticeable difference in the UI.
I'm now closer to being able to record where the order is to go to.

Prototype dragging
Calculate facing so chevron points in direction unit will face as you drag.
That looks a bit weird with the cross over the point.
Fix that.
Hide cursor so it's more obvious the chevron point is where the unit is going.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 04, 2019, 09:46:14 AM

Prototype order dragging and terrain checking.

Working out whether all of a move would be across valid terrain or not.
As you drag the chevron a calculation is performed which works out which cells the centre of the unit would cross.
The terrain in each cell is compared to terrain types the unit may cross.
If all the cells are valid terrain you get a green line.
If any cell is not valid terrain then you get a red line from that cell to the end.
These are on top of the chevron, because of course you might have an invalid point underneath where it is


The above unit is artillery which may not cross woods terrain.
That dashed line on the map is the outline of a woods and hence the red line starts at the woods.
Between the far side of the woods and the chevron point would otherwise be valid terrain, but it can't get that far.
The red line starts at any invalid terrain onwards, partly because there could just be one or two invalid cells and a player could well find it difficult to spot where the invalid terrain was if the red line was only 2 pixels long.

Notice the chevron indicates facing of the unit which is in the direction it moves.

Of course, this is rather simplifying things.
For example.
If a 200 metre long unit in line is ordered to go 100 metres in the direction 90 degrees to it's right then in reality things are much more complicated than just a 200 metre move.
It would wheel 90 degrees around the right corner before advancing.
This is trickier than you might think because it would likely become disordered on a real world battlefield.
The wheel would be followed by a pause to dress ranks before it advanced.
The whole process could take quite some time for poorly trained troops.
A unit such of French revolutionary volunteers would probably struggle to pull the whole thing off.

I'll have to give some consideration to how movement should be constrained.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 11, 2019, 09:23:54 AM
Bug Fix

Map Editor

The binding was failing for description so it was never saved.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 07, 2019, 09:57:27 AM

I've upgraded the target framework from "regular" .Net 4.7.2 to .Net Core 3.1
This is rather a fiddly process for any substantial code base and particularly for ours which contains things I don't use in business app development.
And some stuff is probably quite unusual in any wpf app.
I've only had enough time to do a quick smoke test through the suite.
Not much more than spin it up and try a couple of options.
It seems stable.
Usually the problem is simply failing to compile at all.

Some particularly expensive process like the pathing seem faster.
One "free" improvement to expect is in the garbage collector.
OK, garbage isn't usually associated with instant excitement and this probably sounds pretty dull to non developers.
The garbage collector runs all the time in the background of a .Net app and re-cycles unused objects which are in memory.
In .Net core 3.1 this runs faster and uses less memory.
Meaning the app your running runs faster and uses less memory.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 02, 2020, 08:46:14 AM

I've removed dependencies on mvvm light from the app since there's no WPF friendly .Net core version available at the moment.
This may well change and I'd rather use the standard library but that's not practical. Yet.
The framework introduced a dependency on .Net old so some parts used core and some the old dll, which would have meant mysterious failures to run and error reports from some users whilst others would have been fine if we had delivered.
Anyhow, bug squashed.
Everything should be OK with .Net core only now.


This is Ezra's menu / launcher which you can see on his blog
When you choose to start a game it now writes a file to disk containing the parameters you chose.
This will in turn be read by the game when it starts.
The file represents a PlayState object.
This contains enough data so the game can "just know" what you were doing last time you ran it, what turn you're up to when you've  restored a game save as well as what scenario you're beginning when you start a game from the menu.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 08, 2020, 09:51:17 AM

Now looks for that PlayState object the launcher writes to disk.
If there's one there where it's expected to be.
It loads that
The scenario
The armies
And selects the appropriate side as the current one.

This would also allow you to resume your last game.
Potentially anyhow.
There'd have to be some actual game in the game to change anything and some code to do a save.
One thing at a time though.


As part of my last change, I refactored so that a generic approach was used to serialising and deserialising objects to disk.
( Serialisation is the term for a process turns an in memory object into a string that can be saved to disk. )
I broke that.
This became apparent when I tried to deserialise my playstate into an object and it didn't work.
Fixed that now.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 09, 2020, 10:05:36 AM
Scenario Editor

When saving scenario, capture image of map as byte array to scenario file.
This can then be used in the launcher to give a preview picture of the scenario map with all pieces visible.
This is the first iteration and I've yet to do any testing on it so there are likely bugs and changes.

I think I also fixed a bug whilst rationalising some code.
You only want one piece of code for any sort of operation because when you change anything or have some sort of problem there is then only the one place to make changes.
I had duplicated code in scenario save and scenario save as.
Almost duplicated.
Save as didn't have all the code save had and I think would have missed copying "Places" into the scenario.
Both now use common code in a new method to do a bunch of things including this.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 12, 2020, 01:39:51 PM
Scenario Editor

Improve generation of scenario "thumbnail".
There are complications to capturing an image from this view.
One of which being some pieces of UI such as Retreat Points can extend out of the logical frame.


Use standard method to load scenario data.
Show this thumbnail in select scenario.
Title: Re: Changelog - picture heavy
Post by: zu Pferd on February 28, 2020, 05:13:12 PM
Watched the latest video. Very impressed with it, the process to get into a game is friendly, the maps are superb.
I can only ask when ?  Cheers !
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 29, 2020, 02:49:41 PM
Tricky one to answer, that.
I've changed jobs and my new one is pretty much all consuming so i don't have much time to spare on this.
I get to eat and still have a roof over my head though.

Ezra is working on the game now.
I think if you read his blog you will find some numbers.
You'll also find a post he explains how he's always been known for extreme optimism in his estimations.
Personally, i think there's still a lot of work to do.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 07, 2020, 09:52:27 AM

Although I'd upgraded the dotnet version the apps depend on to Net core 3.1, the installers still had a pre requisite of Net 4.6.1 ( which is older ).
I've un-checked that box and the installers don't think any dotnet is a pre-requisote any more.

There is a complication to adding a pre requisite of net core 3.1 in the installer projects.
MS, in their infinite wisdom, have greatly complicated net core framework installs by having numerous separate smaller exe. You need to pick desktop and the appopriate 32 or 64 bit version. To spread the joy further, installer projects don't easily support adding net core as a pre requisite.
Spending a disproportionate amount of time on these installs is not a great plan.
For now, if you're installing something targets net core then please download the desktop install from:
Currently 3.1.2


On my machine the scenario and picture is and was an instant load. This isn't a particularly powerful machine but it does have ssd.
Ezra's machine is very old and I think probably below the minimum spec we should give as necessary to run the game.
He experiences a delay.
I've multi threaded the code that sets up these pictures which will hopefully address this.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 10, 2020, 09:54:15 AM
Save As

This is a new dialogue used across the app suite.
Previously, I took a short cut and "just" used a standard windows file save dialogue.
The problem with that is you could decide to navigate to some other folder and pick a location could never work.
A standardised file structure is necessary for a game to find a scenario which can find it's armies and map.

The new dialogue "just" shows you file names and stops you saving elsewhere.
This first iteration is not fully styled up yet.
As usual... it's probably also not completely stable.
I'll show you pictures once I've done some more testing and styling.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2020, 07:54:17 AM
Save As

Fairly stable and styled.
Still needs a bit more testing.
I know there's at least one minor bug lurking in there.

Since you could potentially change the name to something already exists - intentionally or unintentionally - there is a "Replace" button appears if your name matches something already there.
In which case, the "Save" button disappears.
Otherwise, the Save button saves as whatever you have in the textbox.

If you've used the open screen you might have noticed the listbox styling there is default win 10.
I've put together a more suite-suitable styling for this which I will probably use across the suite.
Instead of the light blue gradient for a selected entry and blue border I've got brown ( saddle brown ) with white text for contrast and a sepia border.
These are colours used throughout our suite.

Here I'm using Save As in scenario editor and have antietam open.
Initially I had File Name "Antietam".
I type "not " in front of that.


I then hit save.


Tech talk:

I know there are one or two devs read this so some aspects of making a generic save as...
The viewmodel takes an an anonymous Action delegate via it's constructor which is built in the parent and captures variables from there.
This then allows it to generically run something which does quite different things.
EG "Saving" a map is pretty complicated stuff since there are components like ink "strokes" persisted, a picture of the map needs to be grabbed and everything is then zipped up.
Army saving is simple by comparison with an army object serialised to xml ( using datacontractserialiser ).

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 17, 2020, 02:41:16 AM

Rename to Engine.
The idea here is to make it clear you're supposed to run this via the loader which lets you pick settings and options.
Those are passed indirectly via a file written to disk.
As you run the game it reads this file and loads whichever scenario you chose with whatever settings.
Running the game directly continues whatever you were playing last time.

Prototyping unit wheels.
A battalion in close order didn't just spin on the spot to turn.
It pivots around one corner until it faces the direction it is to move in and then moves forward.
I am therefore using some maths to work out where a unit has to turn to in order to face a given point.
Not something a commercial developer does usually - so this led to a bit of head scratching.
Looks like I have a left wheel calculation is working though.
I "just" need to:
Get right wheel working.
Prove it's really really working ( in programming if something works first time you probably spent too much time on it ).
Then refactor to make it maintainable when I come back in a week or two and can't recall where the atan2 of the wossname came from.

As a historical note:
Pretty much all maneouvers and changes in formation were done by company.
Wheeling was no  exception and is non trivial.
A battlefield was rarely a completely flat expanse so one or more companies might well encounter some obstacle like a tree or rocks and have to break up and then reform once past it.
Cavalry formed up quite close to each other and a horse is a sort of long rounded rectangle or ellipse so as each turns they risk bumping into the horse on either side.
It took a fair bit of training for a close order cavalry unit to be able to turn at all.
Title: Re: Changelog - picture heavy
Post by: Adraeth on April 17, 2020, 05:11:26 AM
thank you for the updates
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 18, 2020, 06:05:30 AM

Got the formula working generically so it works with left or right wheels.
I've done a minimal conversion ( AKA bodged ) of the visualisation code I had already.


Here you can see the unit will wheel to the right.
You click the unit to select it for move and then the line follows your mouse move.
You currently get a red line from the first invalid point.
I think I'm going to change that so it's one line that turns red if you're crossing invalid terrain.

When you click, more checks will be done and it'll become an arrow with it's point where you clicked.
At the moment it's a bit of a nuisance if you decide you don't want to move the unit you just clicked.
A bit like chess maybe.
You touched it so you've got to move that piece  :)
You can click it again to de-select but I think I'll add another way - maybe press esc or right click also abandons the move order.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 20, 2020, 09:38:06 AM
Beating the bugs out my angle calculations.

Output user message indicating what terrain makes a move invalid.
This is just the first invalid terrain.
Only terrain type is used.
Hence slope is currently ignored for this and whilst you’re dragging just the line directly from start to finish is used. A more sophisticated and hence time consuming routine will be applied once you click.

Avoiding running the calculations every time the mouse move event fires. The process is reasonably efficient and is “only” done for the one piece but this change should reduce the stress on lower powered machines.

Multi threading the calculations and terrain testing.
This will improve UI responsiveness.

Together with the above, calculating the rotated “start” point and drawing the line from that to the cursor point is now smooth and totally responsive.
This is on a dev  machine which is not particularly powerful for a gaming machine and running in debug mode at the same time as visual studio so I’d expect it to run fine on even fairly low powered machines.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 22, 2020, 07:30:50 AM


Finding the points the unit will pass through as it rotates.
I've started with the central point.
We will also - at least - need the outer point.
There are two potential complications:

Some awkward terrain might be somewhere part way but not in the arc either centre or outer points describe.
The unit wheeling will be considered disordered anyhow as it wheels and for a while after.
I might make that last longer depending on the extent of a wheel.
And it was standard practice for wheeling by company to allow for this.

The other possibility is  a wheel grazes impassable terrain.
I'm undecided on what to do about that.
I might count the number of impassable px crossed and allow a small number like less than 6 or something.


The dots and the output in the Orders panel are for my information.
They look a bit wiggly because they're integer based and the output is a temporary hack.
Why do we care?
This is because I need to look up the terrain and elevation for each pixel that rotation crosses.
The data for these are held in two arrays in the map. Each is two dimensional. Hence there's an array for each pixel in our map width of 0 through 1154.
In each element of that is another array representing the Y co-ordinate 0 through 804.
A cell = a px value is looked up using x and y co-ordinates of each array.
Y being the second, vertical dimension and 0,0 being the top left cell or px.

The co-ordinates used for a cell is therefore an integer.

To provide the values for each relative px in a circle I pre-calculate for a given radius and cache that so I only calculate it the once.
This circle of relative-points ( vectors ) is calculated using something called the Bresenham circle algorithm.
That's actually the easy bit.
I then calculate what bearing each will have to it's theoretical centre and this is used to decide if a given point falls within the rotation a unit would do whilst wheeling.
This is quite tricky.
Left rotation seems to be working for a simple case at the moment.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 23, 2020, 05:13:20 AM

De-selecting current selected piece when you press Esc.
The “rubber band” following your cursor from the piece you click gets annoying pretty quick if you click the "wrong" one.

Fixing the checks for multi-running wheeling calculations.
The wheeling points calculation seemed to be slower than I expected.
And there were some bugs.
I added some debugging output to the calculation and realised the whole thing was being run many times more than I expected.
Performance and bug fixed by one change.

Added wheeling clockwise and beat the bugs out of this.

I put a stopwatch in to check performance.
Takes 9 – 12 milliseconds as it stands.
So far this includes:
Calculating the rotation points for the centre.
Calculating the points from that rotation to end point.
Validating those are ok for the piece.

I also need:
Outer edge rotation points.
Check all these rotation points are valid terrain.
Check slope is valid between all points.

And of course the debugging panel and dots I put together to show the points will need removing.

Wheeling is also currently applied to any unit you click and it's only appropriate for a close order unit in line.
Skirmishers and a unit in column won’t need to wheel and will need a slightly different ( but much simpler ) mechanism to work out the points they will move through.

You’re probably bored reading this but my dev pc is a not-new i5 and I’m running debug mode ( non optimised ) within visual studio. It’d be faster if I ran a deliverable version.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 23, 2020, 09:43:28 AM

Calculating the outer arc points.
Set the width of the "rubber band" line to the frontage of the chosen unit type rather than the previously hard coded value.


I mentioned it earlier but those bobbly spots are an approximate representation of the points to show me they're not some random point over the other end of the map and I got em all.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 25, 2020, 08:11:52 AM
Map Editor

The next step in valid moves is to check slope.

That got me thinking about how slope is held internally.
The implications of that.
But also how it's represented.

Slope is the metres difference in elevation between cells (px) divided by the scale distance a cell represents.
And the difference in elevation is always going to be a minimum of 1 metre because elevation is an integer.
One of those squares on the map is 35 px across.
It must therefore be over 38 scale metres across or slope will always be at least 45 degrees from one pixel to the next when there’s an elevation change.
A scale of 70+ metres per square is preferable.
Having said that, as scale goes up you are likely to find engagement ranges between units mean they’re quite close together before they are in effective range.
Added a user message warning when a loaded map has map scale set too low.
Map scale under help will also turn red and bold
The map scale is a bit tricky to read with the fancy font because the decimal place disappears. I’ve made the metres per square appear rounded to an integer since 2 decimal places on a metre is a bit academic.

I also built another layer to show fake highlight and shading.
This compares elevation per pixel to the one above and to it's left.
If this pixel is lower you get a dark pixel, higher gives a light pixel.
This itself is set to a fairly low opacity.
There is then options to match the other layers.
You can check/uncheck to switch this on/off.
A slider sets the layer opacity.

There is also a blur applied to this to smooth it a little.

With just the hypsometric representation:


Setting the Slope opacity to about 80% - probably more than you'd want as a background

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 30, 2020, 07:50:52 AM
Map Scale and Slope

On further investigation this is tricky and (quite frankly) a complication the project could do without.
Originally, we had integer values for elevation.
The minimum step value of 1 metre is a problem for slope calculations since it's all too easy to have huge steps in the landscape our little men are going to have trouble climbing over.

Changing integer to float allows decimal places and was an obvious first step.
That's the easy bit.
A bunch of code in the map editor uses greyscale values.
Whether that's importing a base set of elevations or smoothing contours into rounded hills.
As it turns out, you're not going to get more than 256 steps out of greyscale no matter what you do.
Making the greyscale value a proportion of the difference between minimum and maximum can only mitigate that so much. If you want a map with a fair set of elevation changes and don't particularly want it to be 5km across then you're going to need help to smooth things out a bit.
And you're going to need help spotting potential problems.
This is what I'm working on now.

Map Editor.
Numerous changes associated with slope issues.
Changing elevations to float for decimal places.
Proportional calculation of elevation from greyscale.
This divides the difference between minimum and maximum to calculate what each step change in greyscale represents.
Hence if you have 0 - 256 that's a 1m step. And you're likely to see slope problems unless you have quite a big map scale.
0-128 would be a 0.5m step.

Note that the shapers are additive.
Hence you could potentially build a map using say a 0-50m range import initially.
Then add a sticky-up bit like the big rock at Isandlwana using a custom shaper which represented just the rocks additional elevation.
This isn't the whole solution but rather an option.

Change message on map scaling to more of a warning.
"Map scale is low, watch out for elevation differences giving a high slope between cells"
Base slope shader difference threshold on map scale

Terrain Visualiser
Make this window “topmost” initially and every time the user ceases dragging one of the sights.
This makes it pop up on top of the main window and reduces the (rather annoying) tendency for it to disappear behind that when you drag a sight around.
Added Slope to data for the point you have mouse-overed ( at top )
Added list of elevation differences with count.
Improved sizing so it gives a bit of a better impression of the terrain relative elevations.
Added a datagrid showing elevation differences between each point and the previous one and the count of each. This is in a tooltip and hence appears on mouseover of the updown grey arrow you can see top right. The idea of this is you can see if there are many big jumps or everything is smooth small nought point something changes.

You can't see it in the picture below but my cursor is over the grey up down arrow of the terrain visualiser window.
That means the datagrid appears.
Showing that 119 of the points along that line have an elevation difference of 0.2 metres.
There are several have differences of over 2 metres.
That's OK if we intend some parts to be too steep to cross.
It's not OK if we thought that big peak was just going to be a slight rise.
By definition, I don't have my mouse over the graph of elevations forms the black shape.
If I did, you'd seen details of that specific point in the heading.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 30, 2020, 12:02:01 PM
Map Editor

This is a work round for a bug which I think has probably been fixed but is still in some of the versions of the map editor that early adopters have.
When you draw a piece of terrain it is translated into an object.
Various things are calculated.
One of these is the list of points within the terrain.
This is used for things like telling what area a given contour covers.
We had a bug report off someone with a corrupt map.
This has no list of points for a couple of the terrain objects in it.
Under some circumstance, using an old version of the map editor, you could find the process working out the points contained in a piece of terrain had not finished before you saved the file or suchlike.
In this case you could end up with no list of points at all.
When you then try and do certain things with that file later the app crashes because it's expecting that list to work with and it ain't there.

My fix is to re-calculate the contained points for any object doesn't have such a list when you load any map file in the map editor.
This is transparent to the user.
Or largely so anyhow.
That recalculation is a change and you might find you unexpectedly get a message pops up saying you have unsaved changes in your map file.
You can just save it.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 01, 2020, 12:51:14 AM
Map Editor

Added new shaper:

The idea behind this is that should you find yourself with a map has impassable steps all over it you can "just" squash it and flatten things out so your teeny tiny little soldiers don't need ladders to move around.

This applies a factor to all elevations to sort of flatten or squash it down.
You could potentially input 1.5 and stretch elevations up.

The calculation applied allows for the minimum elevation:

((elevation - lowest) * factor ) + lowest original elevation * factor

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 01, 2020, 08:30:23 AM
Map Editor

Do your maps look like they're built from leggo?
Need to give em a good rub down with some sandpaper?
Here's the answer.

New Shaper: Smooth.

This applies a Gaussian filter to the elevations.
A Gaussian filter is often used to process images - the greyscale contour process relies on a Gaussian filter to round off what would otherwise be a cliff edge per contour.
The algorithm works by doing a sort of an average for each cell across those around it.
It's a weighted average so the cell you are changing is influenced by those around it but the data in the cell isn't radically changed.
This essentially blurs a picture so it's often known as Gaussian blur.

Why would we want this gaussian stuff if we can do it using the greyscale processing?
An image greyscale render based approach is flexible and convenient but can only offer 256 levels because that's all windows will display.
This smoothing method applies the algorithm mathematically and therefore has no such limitations.
It should reduce slope and smooth out awkward transitions.

You can apply the effect several times - but anomalies are likely to creep in due to various things like rounding.

Like all shapers, it's best to try it out first on a scratch map you don't care about and familiarise yourself with strengths and weaknesses.
Even then I would advise you to save your file between processes and back up your work if you spent a while making a map.

Here I import the same greyscale image I used above.
I've chosen 0 - 256 so we would expect integer steps.
Which is fairly easy to confirm using the terrain visualiser.


A fair few of those steps are more than 1 metre so I've got some chunky steps and huge slopes in there unless my groundscale was pretty massive.

Applying Smooth twice I get:


Looking at the outline, this looks pretty much the same profile I started with.
Just that it's a bit more rounded out.
( Bit like myself )
You can immediately see from the list of differences that they're no longer all integer steps.
There are many non integer steps and lot of the "sharp edges" have been reduced.
It will also reduce any odd spiky bits somehow creep into a map's elevations.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 02, 2020, 09:08:18 AM
Map Editor

We'll be doing another version of the map editor for distribution.
With that in mind I started doing some testing.

Entropy is a law of the universe.
Software development is a particularly fine demonstration of this.
The universe tends towards disorder.
Software tends to break.
As soon as you touch anything, things you forgot had anything to do with that code will break.
As soon as you let anyone else touch something you wrote, it breaks.
It's the law.

Fixed some small issues where data related to elevations hadn't been changed to float.

Add Floor to raise shaper.
This allows you to specify a minimum elevation for any and all cells in a map.
This is particularly useful if you want to remove any inadvertent “noise” out areas which should be flat – like water.
If your “set” value is a negative number when you apply an additive raise it will actually lower everything.

Redo Hypsometric image after any shaper is applied.
I found it confusing seeing no change after I did something.

Add Blue Minimum property for a Map.
If true, blue is used for the minimum level on the hypsometric representation.
Meaning sea or a lake doesn’t have to be green.
This is also useful set temporarily to check you have sensible levels for the sea or lake.

Still need to do some more testing and build the distributable.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 03, 2020, 05:26:12 AM
Gaussian blur

Bug fixes:
Change to use original value for cell where weighted values would be based on cells which are out of bounds or "over" the edge and for cells don’t exist.
Previously, if your edge level was above zero you’d get a chamfer on the edge.

There was a potential memory leak in the way I was using my gaussian method.
Now obviating by copying the content of the array returned rather than setting map elevations directly to it.

Terrain visualiser.
I found the “sights” disappear when the background is dark or black.
Outlined the circle and arrow with a very narrow white line.
This now looks somewhat bitty - because your monitor dots don't exactly map to circular things.
But you don't just lose the things.

Added a dropshadow to the nato symbol. 
This is something Ezra asked me about some time ago.
Back then the "wheels" on a supply symbol protruded out the bottom of it's symbol and would have made the approach I've used impractical.
Everything is now in a neat rectangle so I can work with what that is presented by.
Might not sound like much but those map symbols are tricky stuff.

In order to make the map symbols crisp, they're built in quite a complicated way using vectors.
This change is applied to the thing which contains all the fiddly bits.
It therefore could now be one relatively simple change.
As a plus it effects pretty much everywhere you see such an icon.

As well as:


Something which might not be too obvious is that the drop shadow has to rotate as the piece it's inside rotates.
If those blue units above were rotated so they face "up" then the dropshadow would still be pointing off in the same direction as it is now.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 05, 2020, 08:35:40 AM
About window
Put the copyright notice onto 2 lines and changed the font.

Map and Army editors.
Change version numbers and rebuild ready for distribution.
Ezra should be putting these up on his site soon.

Improving the rubber-band throttling process.
As you move a mouse there’s an event fires. This is used to drive the rubber band calculations.  Those calculations are quite complicated and expensive. Which means running this for every mouse move event would mean several could overlap and cause problems.
I get round that using a mechanism avoids running that process many times.

That throttling (aka de-bouncing) process had a subtle fault.
Previously, you could sometimes end up with your mouse in a different position to where it decided to calculate to.

Started prototyping a move arrow and it’s mechanism.
After you click to select a piece to move you see the line “rubber band” following your mouse position which gives you an indication whether that move is valid and what terrain the piece will travel across.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 06, 2020, 03:26:16 AM

As it turned out the installers that had been working previously mysteriously failed to work.
Why could that be?
Net core introduces a number of extra options for builds and to cope with that the authors of the "installer project" I use introduced different functionality.
An installer project previously targetting the "old" dot net frameworks is now incompatible.
Fixed that.

These installers are not what we're going live with.
We'll be partnering Steam and a software house - to deliver disk based media.
Both have their own ideas on installation.
Steam is a "file copy" based approach which ends up in the user's app data folders and has a mechanism which will automatically detect and copy upgrades.
Any established software house has their own installers with standardised delivery mechanisms.
Our current installers are therefore "just" beta delivery methods and spending time on making them super-polished would be a waste.

I don't think the current versions will prompt you if you don't have net core 3.1 runtime installed.
You will therefore have to install it from (right column ):

3.1. anything
Should be compatible.
Currently 3.1.3 but 3.1.4 will probably be published eventually and that will be an in place framework install over previous 3.n frameworks and compatible.

Apologies in advance if this seems inconvenient.
If I put time into the installers I could probably work out how to direct you there from the installer.
But there's only me and it's a case of do that or work on the game.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 06, 2020, 09:47:49 AM
Army Editor

Bug fix.
In the accuracies editor.
When I clicked on one of them I couldn't set it to anything but 0 or 100.
I suspect this is due to a subtle difference between .net old and .net core.
I've not changed anything in this area for quite some time.

I can now drag one of the X around up or down and clicking on the repeat button above or below sets it +- 0.01 each click.
What looks like white or pink track above or below each X is actually a repeat button like you have on a browser slider.... very likely to the right of this.
If you click and hold a repeat button it repeatedly fires the click event.
Or you can drag the "thumb" up/down.
In the accuracies editor that's the X.
For a browser, the thumb is that darker rectangle.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 08, 2020, 01:04:50 AM

More work prototyping move arrows.
I now have the "rubber band" line disappearing and an arrow appearing once I click.


That's actually crossing a river and hence an invalid move.
You won't be able to commit that move in the finished version.
I need to add more checking - including slope - to the rubber band code and then stop the arrow process if the move is invalid.
Remove those debug wheel spots.

And.... a bunch of other things including the odd bug is probably lurking in that code.

The wheel itself will take time and temporarily disorder the unit.
If it gets into combat part way through then that will have an effect.
That needs to be translated into one of the steps which will appear in the list of orders and the like.
Maybe a circle segment indicates it's a wheel rather than turn.

Like commanders of this period, players will want to get their units into a position so any assault onto target involves a straight forward move.
All part of the period simulation, flavour and skill the player will apply.


Win 10 templates for wpf have mouse over effects for buttons built in.
You see a light blue rectangle appear, similar to mouse over effects in ms office, paint etc.
This appears on top of the pictures used as the fancy bits around the loader buttons so you instead see a light blue rectangle.
I've built a replacement template which doesn't have that mouse over effect.
The loader now behaves on win10 the same as win7.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 11, 2020, 10:00:49 AM

There were some side effects to my first go at button templating on this.
Think these are now fixed.


I've been trying to fix a couple of bugs in the move rubber band and arrow code.
They are resilient little rascals and I've spent some time chasing them round and round.
Time to reach for the BIG bug swatter.
I think I will need to change the technique I'm using fundamentally so there is one piece of code deciding what to do about user input and calculating where the unit is to go, whether that's ok and adding the arrow... removing the rubber band.

Along the way, I added a line around the move arrows.  Now units have a drop shadow the arrows looked very flat by comparison.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 13, 2020, 07:52:18 AM
Rationalising the move arrow code.
In the process of doing this I not only improved the code as intended but  also spotted and fixed a bug.
Code quality isn’t just some academic thing.
Untidy messy code takes much longer to understand when you try and find problems or change it. Like an overgrown back garden full of weeds, you’re best taking a strimmer to it before it gets out of hand.

Started refactoring the rubber band and arrow processes.
These mostly worked but there were still at least 2 bugs and a fundamental change in approach is necessary.

Bug fixes.

Army Editor

The approach stopping the app from closing down was faulted. Replaced it.
Clicking the wiki option crashed. Definitely used to work but I think is a framework difference in net core. I’ve coded round that.

Crash reported when drawing accuracies.
I can’t reproduce this so I added error trapping and that will put up a message if the line drawn results in an error.

Map Editor

The approach stopping the app from closing down was faulted. Replaced it.
Clicking the wiki option crashed. This used to work but I think is a framework difference to net core. I’ve coded round that.
Greyscale elevations would crash if you click the save button without  a greyscale image to save data from. Added error trapping so it now just gives you a message.

Translate turned whatever you have into a piece of terrain. The term seems to be confusing. Changed to Commit and moved the explanatory tooltip from the containing grid to this button.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 15, 2020, 03:31:38 AM
Scenario Editor BugFix

Saving the scenario could produce very odd pictures in some edge cases. The most obvious being when some things are logically off screen they were included in the picture. That could produce an image with a couple of dots in the top left corner and the actual map squeezed down bottom right.
I now force it to clip to the expected bounds.

Loader Bug Fixes

The last scenario image wasn’t being loaded due to a fault in the looping.
When you started up initially it popped up a message box telling you it can’t find a file containing paths to the various exe, which you haven’t set yet.
Now fails gracefully if there’s no file written yet.
The file was written to the folder the exe was run from, which wouldn’t work for live users who installed to program files.
Corrected the file location so it goes in a (new) Loader folder in appdata with the rest of the suite’s data files.


Mid way through refactoring the movement code.
Quite a substantial refactor.
Once it's split out and neatened up a bit... and I beat the bugs out.
I can then do another refactor so it's ready to be used by Ezra's AI.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 15, 2020, 09:56:14 AM
Unit Icon container

This is the thing contains each of the nato icons. I say each because you can have 4 in one piece if you're playing in "game" mode.
The dropshadow I added rotates so it falls in the same direction no matter the unit facing on the board.

Which is great for units on the board.


That unit is also there in the treeview to the left in the scenario and army editors. Rotating the shadow on the icon there looks a bit odd.
Same container and same piece viewmodel are involved.
The main difference is that the icons are always white black and grey unless they're on the board.
I've therefore used that colour setting to drive code sets the dropshadow direction over-riding facing when a uniticon has colour set to "white" as that's anywhere off the board.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 17, 2020, 09:40:02 AM
Unit Icon Dropshadow.

I forgot that the unit appearing in the scenario editor and game treeview aren't white.
Bit of a tweak to set the dropshadow direction on these.


Move refactor first iteration done.
Fairly stable.
Old bugs are gone.
New - much more interesting ones - added.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 18, 2020, 05:14:25 AM

Move refactor now stabilised.
The worst bugs swatted.
Setting aside those nasty bugs which weren't going away.
This is "just" pretty much back to the state I started the refactor in.
But more stable, easier to extend and closer to something Ezra's AI will be able to use.

Still need to use whether a move is valid or not, check what the unit type and formation is before any wheeling is used et al.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 18, 2020, 09:02:31 AM

Stopped the user choosing to commit an invalid move.
As well as the red part of the rubber band and the message saying "Water cannot be crossed" ( or whatever invalid terrain was first encountered )


You now get a cancel sign appears where you clicked.


The transparent centre of the X will be exactly where you click.
Moving the cursor further on doesn't make that move any better.

In the pictures, I've just got the hypsometric background and that dark green line is a river.

I've still to decide what is best to do then.
If you try and commit an invalid move part of me thinks it's too bad if you have to then go and choose the unit again.
Which is what happens at the moment - largely because I've not got around to allowing a series of moves yet.
OTOH maybe I should just hook up the rubber band handling stuff at the same point I remove the cancel symbol so you can carry on.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 19, 2020, 10:15:31 AM
Unit icon shadow

Couple of fixes to this.

The shadow direction wasn't "quite right" all the time.
I needed to add 315 degrees to the facing for the shadow.
Added that.

Then I took another look at columns and they still weren't right.
I'd forgotten that columns rotate the unit 90 degrees for various arcane internal reasons.
Which in turn was rotating the shadow.
Fixing that was a bit fiddly but done.

Movement Costing

I've started working out how to do this.
I need to stop moves that go through invalid terrain or over a given slope for the unit.
Slope up or down can be bad.
Some of this is trickier than you might think.
Cavalry can't charge down anything but quite a gentle slope.

Slope should increase cost particularly up and particularly as it approaches a unit's limit.

Validity of move needs to use a specific path of some sort.
This will be where the central point of the unit will travel.
At the moment I have this "working" for the straight part of a move but only based on terrain type.

There are some complications to allow for.
Constraints being one.
Where a unit in line or skirmish encounters something blocks part of it.
Like a house or where there's a gap between close terrain narrower than the whole unit could fit through.
There were standard drills for this.
Skirmishers just kind of flowed. Although often organised in lines they were not in a fixed close order.
The companies (or half companies even) of a battalion in line stack behind others when blocked.
They then expand back out at the double to "catch up" and re-form the line which would pause to dress.
The only part of that which would usually slow a unit is the dressing.
The unit is disordered until the lines are dressed.
Should they contact enemy whilst in the process of re-expanding I suppose I could calculate what proportion are ineffective but my inclination is to just go with one disordered minus.

Cost of a wheel will be the highest of central or outer arc movement.
I need to decide on some default cost for blocked outer arc.
Plus dressing the line.

I think I mentioned it previously but it was common practice to try and avoid wheeling within range of the enemy.
Similarly, commanders would try and give the order to form square with plenty of time to spare before any cavalry were likely to be a threat.
Movement directly forward was reasonably predictable.
Fancy stuff like wheeling, formation change et al were tricky things and prone to problems made them unpredictable.
Particularly so "in the face of the enemy".

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 20, 2020, 05:31:56 AM
Slope Effects

Researching and starting on slope effects.

Strategos seems like a reasonable starting point since it is the most detailed of the various Kriegsspiel-like systems and was reviewed by experienced military men of the time.
They probably came with their own personal bias but there were a number of reviewers should have evened that out.

Scenario Editor

I was looking in the scenario editor to double check how we hold movement rates and noticed there was a bunch of junk in the source repository.
Removed unused pictures, font and txt files.


Started on the Slope class which will hold all the stuff for maximum elevation change and slope costings.
With a computer to do the calculations I can build in an exponential increase in movement cost for elevation change as a unit approaches slope limit.

My initial plan for elevation change cost is based on dividing max slope by 5.
Square how many fifths you get.
Multiply elevation change by that to give the equivalent flat cost in metres.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 20, 2020, 10:32:50 AM

Added prototype slope checking to the line validity checks.
Looks like it's working, but needs more checking.
The map I've been using has inordinately large differences between pixel which means pretty much everything can't move.
Have to try a different map tomorrow.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 22, 2020, 01:46:12 AM

Added multiplier for diagonal movement for slope calculation.
It's not immediately intuitive, but a cell diagonal to the one you're moving from involves a longer lateral move, which reduces the effective slope a bit.

Map Editor

I tried to load some elevation data for Antietam.
The processed failed because I'd introduced a bug somewhere along the way during the .net core or float elevation refactors. The google data originally relied on a namespace they didn't include in .net core.
Fixed the bugs.
This means, by the way, if you're a beta tester and try the google maps import then it will crash and burn.
Seeing as nobody has reported this bug we're unlikely to do a new distribution just for this specific bug.  The fixes I've just applied will be included with any later release.

Scenario Editor

Removed unused pathing.
This is the thing which finds a best route for couriers.
A modified version will be used as an option for column and skirmisher movement.

The original pathing code had some problems and was a bit slow so I replaced it. This was over 2 years back now.
I kept the original thinking I might find some bugs in the new code and want to revert.  Then I completely forgot the old stuff was still there.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 25, 2020, 05:14:34 AM
Slope Costing

Added unit tests to check slope costing code I just wrote.
Fixed and improved that code.

These are automated tests - code that checks the results of code.
A standard in my usual commercial work but not well suited to most code in the game.
Slope costing is something of an exception because it gives fixed and predictable results meaning automated tests can be written.
It's also very difficult to test a range of cases manually so the time spent writing the tests is worthwhile.
If you're curious you could easily google TDD and learn all about red-green-refactor.

Although the code is working I've still to use those costs in the orders code.
Next step will be to plug the calculations in and check the overall results look right.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 26, 2020, 08:40:41 AM
I used my austerlitz-ish map to build a simple test scenario.
Added costing to the movement process.
At this stage a prototype because I want to see this working with simple stuff before I do anything harder.
There were some problems.

The first was my new map background had a margin round it's picture.
This is something new in code that's been stable for some time.
It seems a problem introduced by net core conversion.
Fixed that.

My pieces didn't turn up in the game when I loaded it.
That's because we have a hierarchical structure to the OOB and if you don't include a parent HQ, then the child unit also isn't included.
Insisting you include a  CO in a scenario for any piece you want in it doesn't seem unreasonable.

I then tried the slope code with real world data.
Even after running the smooth shaper over it a couple of times it is obvious that slopes which will stop something moving completely in Kriegsspiel style rules are all too common from one px to another.
This means the simple approach of calculating difference from one pixel to another is likely to give you results which seem over sensitive.
Bit of a nuisance but a more sophisticated approach is necessary.
Probably best to give this more thought but.
Maybe two fails on the run or over 1.5 * the current limit in one.
The mechanism needs to stop a unit leaping up a cliff or moat so there must be some sort of a limit.
I've previously considered mechanisms like averaging but that isn't going to work because a long move would likely produce different results to a short one.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 27, 2020, 03:31:15 AM

Improved and more sophisticated slope checking algorithm.
As well as a somewhat less sensitive pixel by pixel comparison.
Now also takes into account the change in slope across the move.
( The straight part of it at the moment )
A message tells you the angle calculated, limit and what it's using to decide that limit.
Skirmishing over-rides unit type for this.


Although this is sort of part of antietam you're looking at, this map has artificially high elevation differences for my test purposes.

I still need to take into account any wheeling and whether the unit is skirmishing or not.

The limits I'm using are based on Charles Totten's Strategos.
I've increased his limits slightly by adding 2 degrees.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 27, 2020, 07:32:04 AM
Scenario Editor

The scenario editor maintains speeds for any given scenario.
There is a different speed for a combination per army, unit type, terrain type, formation.
Hence an example value will be held for an example combination: red, light infantry, woods, line
There is no entry for invalid terrain types - those a unit cannot cross.
Not sure if this has been posted before but it's a long time since I worked on this and would have posted about this view.
You can see these values maintained in the "Set Movement Rates"


These values are metres per minute.
( There's a tooltip explains that if you hover over the "Rate" heading in that datagrid ).

In order to work out how long any given piece of movement I've been working towards a value in metres.
This is level movement plus a value representing the effort to change elevation.

If you have a static defender and an attacker moves up to them then this could be a full move.
As the attacker you might be able to see both and order your piece into contact with the enemy.
If it just stands there then the time taken to get there would be your full move you ordered.

That is the simple case and things aren't always going to be be that simple.
Maybe that defender isn't quite so static, you have fog of war turned up so you didn't even see the piece... etc.
We also can't rely on a full move always being completed within a turn.
There's also likely to be different terrain types for different parts of a move.

All of which means I need to calculate based on seconds each pixel "cell" takes.
I could use the values you see above and calculate from them each time.
That would add a set of calculations to every pixel handled.
I can save that by pre-calculating the equivalent seconds per metre.
Which has the added benefit of splitting out that calculation so I can check it's right.
Turns out this is just as well, because I got the first version wrong.

This calculation is now done as you save a scenario and the results saved.
Internally that is - as a player you'll never see these directly.

If you had a saved scenario you'd now need to save it again before it'll work in the game.
That only affects Ezra and I at the moment though.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 28, 2020, 08:55:03 AM
Map Editor

Following the changes of elevations, Ezra re-imported the Antietam greyscale data.
Something odd went wrong with the background picture on saving.
I've spent some time trying to reproduce the problem.
Tricky one this because fixing something that you can't reproduce is quite a challenge.
I've made some changes intended to improve stability in this area.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 29, 2020, 03:16:42 AM

I've added a small line to the front of pieces.
This is similar to those you see on maps of this period, within the limits of practicality of the code base.

Whilst doing the slope work I found it's fairly easy to forget some of those pieces are in column formation.
The line makes it a bit easier.
I chose a line because a more complicated or bigger symbol would introduce problems.
This will also still appear in "game" mode where it might be between two symbols.
( Have to consider that, it might be best to hide this thing in "game" mode.)
It will also still be visible when two pieces are in close combat and could well overlay an opposing piece.
It's not hugely intrusive so I don't see that as a problem.

I tried various options starting with a plain black line.
What seems to work best is a gradient white to black or black to white.
I switch between these depending on the facing of the unit to try and give best contrast against the dropshadow.
And because it's white-black-grey some part of the line will always contrast with whatever it's on top of.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 02, 2020, 02:20:04 AM
Scenario Editor and Model

Skirmish fix up.

Skirmish formation was a relatively late addition to the suite and it turns out I missed some stuff out.
This wasn't added to the default movement rates and you can only edit values already exist for these.
They were also missing off turn time visualisation.
The way that view works is you mouse over the area with the graph like bars on the right for a unit type and it shows you text and numbers in the left panel.
The section you mouse over is selected so it changes style a bit - so it's clear what matches.
Adding another formation made the content of that left panel too big, so I re-organised the buttons from a vertical stack to a horizontal row.
I considered moving the close button somewhere else but I don't see a better option.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 04, 2020, 03:30:25 AM
Terrain Type Checking

On further consideration, not all the terrain types we need are covered by costs.
At least the default "Empty" needs to be costed for everything.
Part of the code assumes it will be costed as field.
This is incorrect and pretty much removes the value of having fields.
Fields are often particularly difficult going if ploughed or full of big/tough crops such as maize or grape vines.
OTOH some of the great outdoors is particularly rough and some scenarios might have better going in cleared areas around BUA.
This means more entries which means more space in that right hand column.
They're probably not all going to fit.
I need a different approach to displaying that data in the turn time view and times for more terrains.

AI Editor
I've been helping Ezra with hiding Pieces.
This is to do with fog of war.
Two players will will have a different subset of Pieces they should be able to see on the board and we need a way to drive hiding those not in LoS.

Elevation Costing
I've made downhill use half the elevation difference for costing.
This is arguably a simplification but similar enough to the Langmuir additions to Naismith which ramblers use.
And these rambling estimation methods are the closest I've found to military.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 05, 2020, 03:28:23 AM
AI Editor:

Added a method Ezra can use to show / hide a Piece for fog of war.


I'm part way through prototyping move costing in seconds.
The move and elevation change calculation itself need bringing together.
That's the easy part.
I'll do this initially as a prototype.
This will require substantial refactoring but enable me to check the results look OK before I start complicating things.

Why will it require so much re-factoring?
There are a lot of complications in this area which need resolving.
Such as hedges and walls should take longer to cross.
A close order formed unit should be dis-ordered and require time to dress lines.
A unit can't just instantly stack and un-stack when crossing a narrow constraint such as a bridge.
Just forcing into column to cross a bridge or ford is too simplistic though.
There are very similar situations possible with a gap between two lakes or woods etc.
At the moment, only the elevation checks stop a piece just moving straight into a fort.
Some thought needs to be given to what to do about the like of frontier "forts".
If your fort is just a wall then that's not even an elevation change.
Maybe this is OK though and an undefended wall should be cross-able.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 08, 2020, 03:18:14 AM
Provide default gradient for the facing line.
Initial prototype for move costing in seconds.
Baby steps are necessary for this due to the many complications.

A number of changes to the default move values
Add move values for empty
Add default move values for artillery in line – this would be manual handling or prolonging. Although the latter is arguably as fast as limbered there’d be little point taking the time to limber and form into column if move in line is anywhere near as fast as column.  Dragging cannon by hand was fairly common and the only way 7yw battalion guns moved.
Change Supplies formation for move from none to column.

Enable equality check by implementing iequality interface on movementkey.
This class is used as a key for the seconds per metre movement values.
The change is necessary to be able to look up values in that dictionary at all. Without it, the app doesn’t know how to compare an entry and none match.

Map editor
More investigation on background “slip” bug.
I’ve never been able to reproduce this behaviour so it’s guesswork what’s happening.
I’ve made several changes might fix this.
One being to tighten up how the sub tasks process. The message saying it’s saved should now only appear once that task has completed.
My advice would be not to shut down the app the instant after you click save.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 09, 2020, 07:17:06 AM
Make the front indicator appear on top of the unit icon.
There was a subtle difference between the the piece in scenario designer and game.
That made the new line I added appear below the icon.
Putting the white part behind the drop shadow made it harder to see on “downward” facing pieces.

Fixing some of the calculations in move costing.
Since this is complicated the inevitable bugs are quite tricky to detect and trace. 
Fixing each is fairly easy once you know there’s a problem and where it is.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 10, 2020, 04:33:04 AM
Efficiency Improvements

As we creep slowly towards a working game, the time things take needs to be considered.
If opening a map in the map editor takes say 5 seconds rather than 2....
This is no big deal.
This is a relatively rare thing and you expect it to take a while.

If working out how long it takes to move from A to B takes 0.5 seconds rather than 0.2.
This is a problem.
Certain things need to be as fast reasonably possible.
As always with software development this is a sort of a balancing act.
If it took 10 days work to shave 0.1 seconds off a process then that process would have to happen a lot to be worth the time spent.

Sandbox and ai editor
Add size property with default value to viewmodel for piece.
This size property is now used to drive the size of a parts of the icon in a piece as well as the obvious size of it. All the pieces are proportioned based on the size.
Size has been moved into the piece viewmodel for efficiency in the game.
You might think.... "this isn't the game."  but pieces of UI come from a shared library.

Started location refactor

Piece calculations such as move and sighting are done based on a Point struct which has double ( non integer ) values for X and Y.
Terrain and elevation, however, live in 2 dimensional arrays.
If you imagine a very fine grid laid over the map.
A given cell in that grid can be defined by X and Y where X is an integer offset right from the left-most column and Y is an integer offset down from the top row.
Any and all look ups for terrain and elevation values use integer values.
The 3d sighting code similarly relies on integer based locations.
Currently, those numbers are converted every time anything is done.
Each of those conversions costs a bit of processor time.
Not very much.
But there are lots of these and it’s an avoidable overhead.
The plan with this refactor is to reduce down the number of times this happens.
This is something I would ideally have done this some time ago but we're where we are.
As it is, best to get this done before I write more movement code and firm up what I've got already.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 15, 2020, 08:04:27 AM
Movement Costing

Translating some terrains such as wall to field.
Without this the movement cost lookup would fail to find any value and error.
Walls, hedge and Fences now add 3 metres to vertical cost.

Costed Move per PX refactor

Previously, a list of points and the total costs was returned.
Now returning a list with an entry per pixel, each has a cost for that specific pixel.
Also rationalised the code so wheeling can share the same approach and code.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 16, 2020, 08:40:47 AM
Wheel Costing

Initial version calculating points and cost passed through for both mid and outer edge.
There's a bug lurking in there somewhere.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 17, 2020, 04:05:42 AM
Wheel costing

Fixed bug, now getting values for both inner and valid values.

The background is explained in previous posts but in case you missed it or the significance wasn’t clear:
When a unit wheels there were two lists of points calculated.
One for those the mid point of the unit passes through and another for the  outer edge.
You can see these visually represented (for debug and development only) by those dots in pictures above.
There were drills a unit would use to avoid problems due to "constraints" such as terrain blocking part of a wheel.
I still have to decide what to do about invalid terrain but it should not be as simple as bad terrain = stop.
But we don't want to allow wheeling to be used to cross a river or something.
That's something for another day though.
To minimise the opportunity for costing weirdness, I will use whichever total costs the most between mid and outer arcs.
This is likely to be the outer arc, because it's (obviously) going to be twice the radius of the middle and longer.

Reduced the cost multipliers for elevation change.
These previously scaled up. An exponential progression towards the maximum slope a unit can move seemed logical.
My progression scaled up less than exponentially.
Which seemed ( and still does really ) logical.
As you reach your limit it seems pretty obvious you'll slow disproportionately.
The cost curve should be sort of concave and maybe even an exponential progression.
In practice I was getting some quite high values for moves which didn’t seem right.

Avoid costing any move which is invalid due to crossing invalid terrain.
This was producing a spurious error.
There is no cost for terrain a unit may not cross.
This is, of course, quite correct. No point in maintaining a cost that can’t be incurred.
Because the costing code was always running during “rubber band” calculations this was trying to look up costs for all terrain. Including invalid terrain.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 18, 2020, 12:49:19 AM
Scenario Editor

Add and set piecewidth property on the piece viewmodel as it's loaded.
Thought I did this previously.... but it seems not.
As previously explained.
In order to speed up rendering of each piece, components now uses this property rather than the more complicated way it previously found piece size.

Changed the slider mechanism so it now also updates that property in each piece viewmodel.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 19, 2020, 05:14:55 AM

Apply Unit Type frontage multiplier to pieces in Game mode line formation.
This was previously not applied because scaling the pieces down doesn't leave much space in the icons when you have more than one.

The Simulation mode icons have always had a 0.7 multiplier for artillery.

Now the Game mode icons also have this applied.

If you've used the army editor or you "just know" the symbols used you'll be familiar with what each of these represents.
Just in case though...
Top to bottom the rows are Horse Artillery, Artillery and Infantry.

If you take a look at that little line middle top of each piece.
This is the "front" indicator I added.
On this light background the top end is almost invisible.
That's because it' a gradient white through grey to black.
On a light background, the black stands out best.
On darker backgrounds, the white will stand out more than the black.
Which means I don't need some "clever" code to work out what sort of background the line is against, whatever you have there will be some part of it gives reasonable contrast.
It's small because effective musketry range was very low.
In addition, the likes of zulu and cavalry were melee only and will move to contact.
Which means you can expect to see pieces very close or in contact with one another.
When that happens, the indicator overlaps the enemy piece.
A small indicator is then less intrusive.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 23, 2020, 08:02:39 AM

Next up is to allow multiple moves.
I started this thinking it shouldn't be too hard.
Just make the start point to the last end point.
It seems there's rather more work to do than this though.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 24, 2020, 04:55:38 AM
Model library

Added PieceLocation class
This will be used to work out the shooting and target points of pieces.
This has to work in the abstract rather than related to a piece’s current position so it can cope with moves and encountering enemy part way through a move.
One of the bugs I found was related to calculating the two “ends” of a piece when it’s going to wheel.
I took a short cut with that and this class is part of the refactor necessary to address that problem.


Fixed (the obvious) bugs with multiple move input.
Seems reasonably stable now but could do with more test and maybe a bit more refactoring.

Below, I’ve clicked to commit two moves and the rubber band is shown for a third.

This is still prototype stuff.
Everything currently wheels, for example.
The “moves” are also not persisted in any way and we’re going to need some standardised way to keep a list of orders:
Wheel 30 degrees, 120metres forward, wheel -24 degrees, wait until 4pm.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 26, 2020, 04:08:47 AM

A test-fix cycle following the multiple move changes.
Which seems remarkably close to stable in that I only found one immediate problem.

Avoid error when looking up invalid pixel costing.
This now returns a default cost which shouldn't ever end up being used but guarantees no crash.
There's a flag for valid move which is also set false.
Meaning you can't commit such a move.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 29, 2020, 03:06:05 AM

Direct movement.

Or movement without wheeling.

The piece spins around it's front central point and heads towards where your cursor is.

This is for pieces in formations Skirmish, Column, Small or none

HQ essentially do not have a formation and there is allowance internally for some sort of a unit which isn't HQ and also isn't a full sized unit.
Although not implemented (yet) this could be used for scouts, messengers etc.

This piece is in column formation and hence it will have the option to take the most efficient route or move direct.


It's perhaps worth mentioning that there are parts of the code which aren't fully implemented but are there with future change or expansion in mind.
Hence a unit type which doesn't currently exist is partly supported so it would be relatively easy to implement.
Sometimes this is because of a change of direction in design.

EG ADC or messengers were originally to be visible moving across the map with the potential for enemy to intercept them.
On further consideration we realised this would be a bad idea as it risked turning the game into chase the messenger. Which might be an interesting game of itself, but not really what we're aiming for.
The complications of messengers travelling to where a piece was when it set out and then trying to find where it had moved to in the mean time also seemed just an over complicated distraction.
Hence messenger time will be calculated at outset rather than having to calculate a series of moves as the adc tries to find his moving recipient.

Sometimes it's just something which was easy to add

Another example is the number of sides in a scenario.
There are 3 armies in a scenario internally.
You can't set the third one at the moment but this could potentially be used for neutrals or a third player ( Blucher at Waterloo eg ).

I've also started planning for order persistence and implementation.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 30, 2020, 04:47:58 AM
Movement Animation Experiments

At the moment I have some raw data that's used to add arrows to the map.
I also have some raw costing data for these.
What I want is some way to persist these.
This is, however,  linked to how it will be used.
One purpose will be animating pieces around on the map as a turn is played out or re-played.
I already have a rough plan in mind for this but it's very detail light.
Best to experiment with this and see what happens with the various options.
Which is what I'm currently doing.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 06, 2020, 02:38:45 AM
UI library

I've added a custom facing animation to the UI library.

Whilst exploring the various animation options, it became obvious there is no "straight out the box" framework animation which would maintain facing in the direction a piece moves.
As a result I built this class.
The animations will all use one standardised mechanism.
All animate the x and y co-ordinates and the facing angle.
They will all rely on using a "path" supplied.
This will be an arc for wheeling, a straight line for direct moves and a wiggly line for fastest move.
The x and y co-ordinates are fairly straightforward and work in a similar way to graphing or standard maths definition of position.
x is horizontal position and how far from the left
y is vertical position and ( somewhat unusually ) how far from the top
These are relative to whatever container the point you're defining goes in.

The custom code I've written essentially works out the direction of travel so a piece can be rotated to face the way it's headed.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 08, 2020, 02:18:58 AM

More work on sketching out turn and move persistence classes.
An order will translate into a series of things the piece should do.
Each will need timings, details of exactly where it moves when, what direction it is to face in and what posture it should adopt.
All these things for all pieces need to be such that they can be saved to disk as a save game.
When the game reads that save game back into memory, it must give the same result you expected.

The opposition probably have different plans in mind and will likely interfere with your carefully considered moves.
Things will happen part way through carrying out that move from a to b.
The timing of your moves vs the enemy will be important.
The game loop will need to work out if and when moving opponents see one another.
When they do so their posture will define what they do.
Or attempt to do.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 09, 2020, 08:24:07 AM
Wheeling cost roll up

I have two sets of costings for a wheel.
One for the cells the mid point will move through.
Another for the cells the outer point will move through.
Usually the outer arc will be more expensive.
When that is the case we need the cost of the outer point totalled into the appropriate mid.

Initially I thought I'd just divide one by the other giving say 2.
Add up each pair of outer point costs and set the next mid point to that.
Add any over to the last.

This is too simplistic though.
My first try at this gave odd results.
When I took a look at what was happening this was because you get numbers like 89 mid and 177 outer.
177/89 = 1.988.
Just less than 2.
Meaning 88 outer points cost end up totalled in the last mid one.

I need a plan B.
Work with the amount of relative rotation for each from the starting angle.
Which is more complicated but will give a much more sensible distribution.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 27, 2020, 08:35:01 AM
Fixing bugs associated with these.
This is the thing which is used to hold X Y integer co-ordinates.
There were problems working with these in collections and with adding the values to use them in a similar way to a vector.

Bresenham circle fix, removing duplicates
A bloke called Bresenham invented several algorithms. These find the cells crossed by line or circle in a grid.
The original purpose being so you could print lines or circles on a dot matrix printer or old style monitor.
As it turns out, all the "standard" implementations of Bresenham circle returns duplicates.
This had some unfortunate effects in wheeling because I wrote code which relied on each point being unique.

These changes seem fairly stable.
With one exception.
After the first move, further moves with a significant wheel go wrong and start using the wrong start point.
That's either because.
Something was relying on a broken version of the above.
There was a bug there already and I just hadn't noticed it.

Wheeling cost: Rolling up the outer point cost into mid points when the total is greater.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 03, 2020, 02:20:04 AM

Whilst trying to fix a bug where the wheeling decides the wrong direction and heads off clockwise rather than clockwise I introduced a new bug.
The move handler stopped doing anything after the first move was committed.
This was because the timer wasn't being restarted after committing the move.
One line change but quite difficult to track down.
This is the problem with complicated code, and why I usually spend time trying to simplify what I've got after I get it working.
That's quite difficult to do with the move - it's inherently quite complicated.

Back to tracking the original bug.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 04, 2020, 01:48:20 AM

Wheeling direction fix.
Quite a relief to work out what was happening and fix this.

Wheeling calculates the cells in an arc between the piece's initial point and that which would be a tangent to where the piece should move.
In order to do this it uses a list of points for the whole circle and iterates through until it gets to an angle it's calculated as being correct.
If it goes the "wrong way" round the circle it will use the points outside of the best arc instead.
This is what was happening.
The problem was I'd written this initially and "just to get it working" used the original facing of the piece.
Which worked fine for one move.
Add in more moves and those looked ok, so long as you were always rotating in generally the correct direction.
I now use the original move or facing of the last committed move.

Which will break if I add undo or go back and select an arrow to add more moves.
We'll need a list of move (orders) anyhow.
I should probably refactor that implementation, ensure (end) facing is one of the properties and work with the last off that list.

Title: Re: Changelog - picture heavy
Post by: zu Pferd on August 09, 2020, 08:39:21 AM
Hello Andy,
                I pray you are doing better healthwise.
I just got caught up with all the posts about the work you've done and doing.
Best Regards
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 10, 2020, 02:35:12 AM

Thanks for your concern. I appreciate it.

My health is pretty much 100% now.
It's a weird thing BPPV / Labyrinthitis. And a right nuisance.
Initially it was just totally disabling.
Now I'm pretty much ok but it comes and goes as you're getting better.
I think "Hey... I'm fine." then one or two days later I wake up with the nausea back.
Doctor says this is usual and a slow recovery is expected.

The lack of game development progress is because I'm on a job search at the moment.
Between searching, applying and dealing with agencies ( who of course all have a fabulous requirement I am perfectly suited to ).
Revising for technical tests.
Doing those.
Company research, interview prep and the actual interviews.
There's not much time and energy left for much else.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 14, 2020, 07:21:38 AM
UI Library

Converter optimisations.
This library has things commonly used across the suite in it.
There's a piece of code which is used to position things on the map.
I've changed the way this works and made it a single instance rather than one per usage.
That reduces memory usage and improves performance a tiny bit per usage.
There are, however, a fair number of usages so what would be a negligible effect on one thing is more significant with many.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 19, 2020, 04:58:26 AM
Scenario Editor

Deferring the route calculation process.

In the scenario editor there is a "best route" calculation for couriers.
This is done for all subordinates when you mouse over a HQ.
This process is quite expensive since it's using a spatial A* algorithm to calculate the cost of each cell to the next in the possible routes from HQ to subordinate.
Although this is multi threaded a low powered machine can max out on concurrent threads.
Your full on i7 gaming machines will get through this rather faster but we want to allow for lower powered devices.

The real down side of this process is that it kicks in as soon as you mouse over a HQ.
That's convenient but it's quite easy to inadvertantly move your mouse over one.
Which'd be fine if this was sub second but you're talking more like 10 for complicated maps.
This is not so fine because you'll decide you want to save your scenario... Ooops....
You mouse over a HQ on the way to that menu.
And then those busy indicator petals are spinning and you're burning up cpu calculating routes you didn't want to.

There's more work to do on routing.
This needs to work for units other than just messengers.
In the mean time though I've applied the simplest fix which mitigates inadvertant mouse over.
I've deferred execution of the route calculation ( for 0.6 seconds ).
It then checks whether the mouse is still over the piece before processing.
This means if you're just moving on past a piece then it won't start up.
If you stop your mouse on the piece, it'll be there longer than the threshold time and the process still works.
Trying this out, the delay isn't particularly obvious so this feels like a reasonable fix.
At least for now.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 20, 2020, 09:30:12 AM

I've started work on least cost pathing for pieces moving in column.
Column is inherently a more flexible formation than line and a unit in column takes an optimum route rather than a straight line.
Our columns abstract the several different real world options of column of attack / division / march.

This was written and working for messengers and called from scenario editor.
I need to be able to call the same code from the game as well so it can't live in the scenario editor.
I've refactored the code and moved into the UI library which is referenced by all other front end projects.
Maybe it's just my imagination but it seems to run a bit faster.

This needs more work to cope with different unit types because it was designed to work purely for messengers.
There is only one set of costing and a messenger is assumed to be able to cross any terrain.
The cost is just very high for some terrain.
The same concept might be retained for other units.
A river would be a very time consuming thing for a battalion to cross.
They would do it eventually though if there was simply no alternative.

My Dad was in the Chindits in ww2.
Jungle river crossing was a routine necessity.
One lucky fellow swam with a rope and recce'd the far bank whilst some of the force covered from the friendly bank.
Once "clear" he would secure the rope and the covering force remained whilst part crossed.
Then the remains were covered by the majority.
In case an enemy force was on their trail, a "tail end charlie" remained behind on the new friendly bank covering the far one with a Bren gun for a while.

Dad's top tips:
Don't get picked to swim across first or stay behind.
Put your pack on up-side-down ( or you can't get out because you have a pack full of water on the far side ).

Back to game building world.

I also noticed there's no gap between the "HQ" in a HQ icon and the outline.
Which makes it a little harder to read than it could be.
Since a piece is of course of variable size and you can't easily scale text these are actually a vector representation path.
Added 1px margin round HQ path.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 06, 2020, 08:01:38 AM

Added prototype least cost move for units which aren't in line.
HQ and column will by default take whichever route looks to be the easiest and fastest to where you want to move them to.
In the picture below you can see some of these moves represented by the bright red lines.


The process of calculating which is the best path is quick for simple moves like down a road where it's pretty obvious the road is your best option. When you are heading off into the weeds and hills the calculation becomes quite expensive and time consuming.
As I mentioned, this is currently a prototype version and I've pretty taken the code was in the scenario editor for and couriers slammed it in here.

The road routes were quick enough I didn't feel I needed any more feedback.
That route heading north around hills, took 2 seconds which is time to start thinking "did it do anything?".
This movement type doesn't have the "rubber band" effect that direct movement uses because that code path does a bunch of validation and calculations on the path. Least cost will try and go round invalid terrain so might be a valid route even if the direct line crosses a big river or something.

We need some other similar but visually different rubber band to show this is where you're headed.
Maybe also to flash or something as calculations are performed.

Additionally, the unit type should be taken into account for terrain costs.
There's just one set of costs at the moment.

In order to avoid terrain paralysing couriers, the current algorithm doesn't have absolute blocks. A river or cliff is "just" a very high cost per pixel.
That 1 pixel wide trickle of water will not totally block couriers.
A similar approach is probably best for units.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 19, 2020, 08:32:56 AM
Unit Type Best Route Costing

I've started working out the best way to implement this.
At the moment, we have something which is designed just for couriers and one fixed set of costings.
What we need is something that will work with the movement rates specified by unit type and side in the scenario.
Long story short.... this is not easy.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 19, 2020, 09:40:58 AM
Unit Type Best Route Costing

Stable version committed.
Likely needs some more thought and work.
Including checking on memory usage.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 26, 2020, 10:42:17 AM

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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 28, 2020, 08:41:03 AM
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.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 29, 2020, 08:51:44 AM

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.


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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 30, 2020, 04:18:39 AM

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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 01, 2020, 04:33:46 AM

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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 01, 2020, 08:46:39 AM

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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 01, 2020, 09:46:05 AM

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.

This busy panel also shows whilst a game loads which takes a few seconds and doesn't like being interrupted.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 02, 2020, 06:02:50 AM
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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 05, 2020, 09:26:41 AM

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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 07, 2020, 01:00:12 PM

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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 08, 2020, 04:09:59 AM

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


Fixing missing images
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 10, 2020, 09:28:38 AM
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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 12, 2020, 01:56:03 PM
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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 17, 2020, 09:52:09 AM

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.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 19, 2020, 10:14:37 AM

Started on SaveGame structure.
This is the class which will be constructed and saved to disk when you choose to... save a game.
When you load a game after the first turn orders are committed, this is the thing will be read from disk and translated into objects in memory.
Since this will be a fundamental driver for pretty much everything I want to refine my ideas on what this will look like and how that translates into a working game.

Not that players need to understand all this but FYI this will look roughly like:

      VP Loss / gains at start of turn
      Orders ( the plan may cross turns)
      Orders this turn
      Piece state changes ( the results )
           Change- movement; morale; ammo; strength; Posture etc

Indentation indicates properties of parents, hence a piece state change is an event which happens at a specific time and  contains stuff about what is changing.

Resolving a turn is done in memory and the results can then be reviewed.
You don't see a turn resolved as it happens because a player could potentially interrupt and replay a result they didn't like the look at, hoping they were luckier the second time round. Or perhaps worse.

My current thinking for a pbem game.
The last person inputting orders only sees results after his opponent.

Both players will input their orders.
If A inputs their orders and then B inputs theirs, the turn will be resolved on machine A.
The results will then first be seen on machine B.
Which means extra emailing over just resolving on whoever inputs orders last.
Which is unattractive.

There are several options I can think of to avoid that.

The simplest would be to give a setting allows you to "trust" your opponent when you start a game.
That alters things so A inputs orders, they email to B.
B inputs orders, the result is resolved and he watches this.
He then sends the savegame back to A to watch the result.
Processing always happens on machine B.

Another is rather more involved but could be rather slicker.
The two players PCs would communicate directly to each other.
Both could input the next turn's orders at the same time,  commit and send.
The turn would be resolved on one of these.
The results could then be transferred in a similar way and viewed simultaneously.
This is rather more like the sort of thing I do commercially but running on a regular PC rather than a web server.
You'd need to open ports - another machine sending your stuff is pretty much what firewalls are designed to stop.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 20, 2020, 04:13:49 AM
Bug Fix:

I noticed the HQ icon in the game and scenario editor treeviews had a white background.
This bug was introduced when I added the dropshadow to pieces.


Now fixed.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 21, 2020, 09:24:50 AM
Scenario Editor

Format elevation to 1 decimal place
BugFix: Total maximum pieces in a force was not reset to zero on load so increased every load.


More SaveGame classes.
This takes longer than just add a new class here and there because I'm working out how to best represent things.
I add something and then realise later that won't cover some other circumstance so I go back and change it.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 23, 2020, 05:02:59 AM

Defining events.
Here's the list I have at the moment:


StateChange allows update of stats on a piece.
As a piece shoots, it becomes unloaded.
When it reloads it uses ammo and ammo is reduced.
It's then reloading for a while.
When they are shot, a piece loses strength and probably morale.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 23, 2020, 06:28:23 AM

Changed the styling and what data is used for the piece strength in the treeview.
Cursive writing doesn't "measure" so well. This is the process that windows uses to work out what space the text takes up.
If you therefore put cursive font next to another font it's very difficult to make them line up neatly.
If you look above on the changelog at the picture with white HQs, you'll see what I mean.

I've therefore removed the "Strength:" textblock - it's pretty obvious what that number is going to be anyhow.
Replaced this with a tooltip to explain what it is.
I changed what data it uses so it shows the current strength.


That then got me thinking.
Always dangerous.

Considering fog of war and the realities of a battle.
There you are mid battle and you're general whoever.
Your second battalion gets shot up.
You would only know exact losses once a post battle roll call was done.

I then changed it back to using the starting strength:

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 23, 2020, 08:36:57 AM

Improving the look of a unit's entry in the treeview.
The design was copied in from the scenario editor.
In the scenario editor, greying the text of pieces once they were added to the board for a scenario was useful because the dark more obvious ones were those still available to be dragged onto the board and into a scenario.
Grey vague looking ones were "used" and deployed somewhere.
Part of the suite's design is that you can build an army but not use all of it in a given scenario.

In the game, making all the text grey just makes it harder to read.
The lime green background of a selected item is also out of step with the theming elsewhere.
Probably a matter of taste but I'm not so fond of lime green outside of pop art or the 1970s.

Made the text black.
Removed the greying of text off pieces which are in the game ( everything ).
When selected the text is now changed to white on a brown background.
Unit names are now far easier to read.
I also rationalised or removed several parts of the templating which also aren't appropriate in the game app.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 01, 2020, 10:02:50 AM
Fixing library reference.


I showed our ui to a couple of friends ( socially distanced via ms teams screen share of course ).
Something they both noticed particularly was you can’t read all the unit names in the treeview.
This is something I’d noticed myself.
Hence I've started on a set of changes to reduce the width used by the entries in the treeview.

You’re more likely to be able to see more / all of the unit names.
If you go with long names then these still aren’t going to help and many players will have wide monitors or higher resolution displays.
Previously, you max out the game you were still “stuck” with a narrow left panel and maybe a chunk of useless space.
Fixed that:
Added width resizing on width of left and right panels.
When you mouse-over the space between the two panels you will see a double headed arrow appears.
You may hold and drag left or right to adjust the widths.
(This is similar behaviour to apps such as excel for column resizing )

Moved the general out the treeview.
This is currently just a prototype piece of text - still needs more styling TBD.

The commander icons now act as the expand/contract button which toggles visibility of their subordinates.
Shifted the subordinates over further to the left so their indentation is actually a bit less than their parent's icon.

I also made a number of internal changes which are less visible and to do with rationalising how data is held for the army pieces.
One thing is visible - the oob you see now corresponds to the current player ( previously hard coded to red ).


Ezra particularly likes those pointy fingers.
( Sorry Ezra - they were too wide ).
I may re-introduce one in a rollover effect as you expand a HQ.
Not sure about that.
There are huge pointy fingers in the loader though.

I'm also thinking about the strength again.
This is the original strength.
If I moved that out into a tooltip I could save some height on every combat unit and reduce the chance of a vertical slider appearing.
No vertical slider means more width for the treeview items.
I could also re-template and reduce the width of those sliders.
I thought about using something similar to the small brass slider I built for menus.
Not sure about that one.
It'd perhaps have to be a different shape to be big enough to get your mouse on but narrow enough it didn't take more room.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 04, 2020, 01:02:18 PM

Changed the symbol used to navigate through tabs.
This was previously similar to the material design chevron which is a triangle with a cut out.
Now a fancier victorian style thingummy if you choose victorian styling or a triangle.

Victorian style:



Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 08, 2020, 05:50:46 AM
A number of changes intended to give more space for the content of those left panels and to make scrollbars styling match the suite pallette.
If you’re a user of android, ios or apps like Slack on windows you are likely to find the new look and behaviour of scrollbars very familiar.

Made the scrollviewer content fit the entire scrollviewer.
This means when there are scrollbars appear on a control, the content which would normally stop at the scrollbar extends under it.
Hence the content always fills the bounds of the control rather than stop at the scrollbar track.

Re-templated scrollbars so the track is now totally transparent and there’s a narrower “thumb”. On windows a thumb is usually a grey rectangle. The idea of scrollbars work is you can have a panel bigger than will fit in an area and you move the viewport on that panel to see a different area. To move the viewport up or down you have two options. You can click, hold and drag the thumb up and down. Alternately, you can click above or below the thumb on the track and it’ll page up or down. Similarly with horizontal scrollbars except of course the movement is lateral rather than vertical.
Less dead space.
More content.
Less grey.
More theme-brown.

This picture shows the treeview now.  There are both a vertical and horizontal scrollbars here, each is transparent until you mouse over it
When I mouse-over the vertical one you now see a rounded rectangle appears.

Moved the strength value for units out the treeview and into the tooltip.
We’ll want a lot more info about units than just strength and that is probably best moved into a floating window you can drag round and some sort of unit tooltip or popup.

I don't think I posted a picture showing what happens if you drag the width of that left panel.
Below, I've done this and made the left panel just a little wider so all unit names fit.
The "(Kanawha Div." is now fully visible.

Notice that the map panel is smaller but retains the same proportions so it contracts vertically proportional to the reduction in it's width.
On my monitor I could drag the width of the parent window and make everything bigger but fit vertically.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 08, 2020, 10:01:55 AM

Some optimising on the spatial A* pathfinder.
Avoid backtracking - don't include the cell you previously came from in the options to check.
Reduce iterator usage - for index o to n is slightly more efficient than foreach. Which is usually so marginal you wouldn't bother but pathfinding can do many of those loops.

Setting water to higher cost for units.
This makes it a bit less likely that a column of infantry will decide to try and cross a river.
There is a potential downside to this if you build a map with an island and a whole lot of sea between it and land.... then try and move a unit across that sea.
You may well find that crashes the app.
But you built something could never work.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 09, 2020, 12:53:18 PM
Fixed the problems with my initial version of the scrollviewer/bars.
More pathfinding optimisation.

Make up and down arrow navigate up and down the oob treeview with one click per node.
Title: Re: Changelog - picture heavy
Post by: Adraeth on November 10, 2020, 02:10:47 AM
Thanks for everyday updates, the more i see the more i love this engine O0
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 10, 2020, 11:24:36 AM
You're welcome.

I wish i could work on this every day.
As it is, my day job means that's not practical.
Each little piece done is another bit closer to a working game.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 13, 2020, 01:23:13 PM

Upgraded target framework from net core 3.1 to the shiny new Net 5.0.
Which is a bit faster.
Every new framework version, they optimise things here and there.
Something called garbage collection optimisation might not sound so glamourous but faster speaks for itself.

If you're technically minded or just curious you might find the detailed analysis and benchmarks interesting.
Obviously, if a process takes about 18ns in net core 3.1 ( previous target ) and about 15ns in net 5.0 that's roughly 3 ns or a sixth faster.
And whatever weird and obscure that might seem, a sixth faster for free is obviously a good thing.

Time to drink beer, I think.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 21, 2020, 07:28:28 AM

Started replacing spatial A*.
For least cost path finding ( couriers and columns ) I use an algorithm called spatial A*.
The version we have ( had ) is too slow and not suited to with multi threading to carry out pathfinding for multiple units at once.

The original started off life as the fastest of several implementations I found on the interwebz.
It was acceptably fast.
Then I modified it for slope, different units and the user set movement costs.
Each of these changes made it less efficient.
I shaved an eighth of the processing off by tweaking it a bit.
Not enough though.
Time for to reach for the big hammer.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 22, 2020, 10:06:16 AM

I changed a number of fundamentals in the spatial A* code and it now runs rather faster.
Processor and memory cost of running multiple calls at once is also substantially reduced.

If you choose a route which is logically unreachable due to water or cliffs or something then it can still be a little slow as it finds bad route after bad route.

There are still a couple of optimisations I could still try but I'm now out of time.
Might see if I can fit those in over an evening or two through the week.

For example.
Currently I ignore a possible cell if it's the one I just came from.
I could ignore that and ones to each side.
So if travelling north east, I'm ignoring SW but S and W are probably not going to be good directions to head in anyhow.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 23, 2020, 10:23:53 AM

Improved the algorithm working out addition to add for slope.
This is one of the more expensive parts of costing a cell so anything that makes this work any faster is worth while.
I have now reduced the cost of the calculation by pre-calculating a tenth of the metres per pixel.
An increasing cost is applied by looping up to ten times subtracting that from the difference and adding a cost each time until the difference is less than zero.
If it loops ten times and what's left is still over the metres per pixel then this is a big jump and a cliff or something so add a bigger value to cost.

Downhill is halved by * -.5 first.
A road cell ignores this process entirely.
Roads should always be best.

This pathfinding process is used purely to find a route.
Scenario based costs will then be applied.
These are more costly to process and that was a large part of the problem with the old version.
There is the potential someone chooses to make mud easier to traverse than roads or something.
The fix for that atm - just don't do that.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 05, 2020, 10:13:22 AM
Spatial A*
Removed some code and data which is now unused.

I've been experimenting with some options to make the wiggly line you get for best path look a bit more interesting.
First couple of things I tried didn't give good results.
But that's kind of the point in trying stuff.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 06, 2020, 09:30:58 AM

Arrowed best route paths.
Previously, you just got a line for best path moves.
You now get an arrow on the end.
I've outlined everything in black like the direct move arrows.
I also changed from purple to red or blue matching the piece's side.
Ezra didn't like purple.


This is still somewhat experimental.
Internally, the arrowhead makes this trickier than you might think as the whole thing is now a shape.
When you fatten up a line to give it breadth, it also adds similar length.
I needed to chop that extra bit off the end, calculate and combine a triangle.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 13, 2020, 08:18:34 AM

Now prefers to keep heading in the same direction.
This reduces the tendency for kinks, particularly in road movement.
If you look closely at the paths in the above post you'll notice the direction of travel can wander a bit at road junctions.
The algorithm didn't particularly care about moving in a straight line previously but now does.


Which doesn't completely remove the possibility of kinks, just reduces them.
Might have to consider a different algorithm.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 18, 2020, 05:51:03 AM
Scenario Editor

Changed heading on edit move rates to make it clearer it's metres per minute.
Neatened up the view.
This has the same style scrollviewer as everything else which means it's narrower and there's still room for the original wider scrollviewer track.
That's still there but I've hidden the border that's around the containing control so it's less obvious.

Below you can see some of my development environment behind the scenario editor.
I've used psr to capture the cursor as the tooltip for the heading is shown.

When I just mouse over the area immediately to the right of the datagrid, the scrollviewer "thumb" appears.


Think I explained this elsewhere but you can drag that rounded rectangle up or down to scroll.
You can alternatively click the area above or below it on the "track" and that'll scroll.
With your mouse over the datagrid you can scroll up and down using the wheel on your mouse.
Or you could click a cell and arrow up / down.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 18, 2020, 08:55:26 AM

I've added two steps of post processing applied to least cost paths in order to smooth them out.
Not sure I've explained why kinks are bad.
Why bother with all this stuff?
Any kink in a path will be particularly noticeable for a piece moving in column because they'd wiggle noticeably as they animate.

First step.
Something called a "string pulling" algorithm.
Not a name I made up but the intimation is you pull on a wiggly piece of string and it tends to straighten.
This goes through the list of cells and looks for one which is at least as good but more directly towards the target.
It has quite a subtle effect.
Although it's doing some expensive maths it's processing far fewer cells than spatial A* so is low cost.
Sample routes took 6 or 7 milliseconds extra.
Which you're never going to notice.

Second step
I built something which looks for straight lines in road movement.
Straight roads are one of those things you'd particularly notice kinks on because you've got a straight line to compare the move to.
And why would you weave around on a road anyhow?
Drunk Colonel?

This loops through the list of cells.
If it has a road cell it looks ahead 17 cells ( roughly half one of those squares on a map ) and sees if that's road as well.
If they both are then maybe this is a straight piece of road here.
It sees if it can draw a straight line between them which is all through road cells.
If it can then it uses those cells.
This process is very lightweight and even faster - took under a millisecond on most routes I tried.


Maybe stating the obvious.
I'm still part way through developing this thing so I can do things won't happen in the finished thing.
Here I have done moves for both sides.
In the completed game, you won't be able to see the enemy orders or tell them where to move.
Hence you'll only see red move arrows if you are red and blue if you're blue.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 19, 2020, 09:04:16 AM
Map Editor

Improvements to terrain visualiser.
To recap how this works.
This gives you a view on a slice through your map between the two scope sight points.
Each pixel of the map is represented by a narrow band intended to give you an idea of what terrain and elevation each has.
The outline this gives will not give a true scale impression of elevation differences and is intended to emphasise these so unintentional steps or cliffs stand out.
Each band is colour coded.
If you mouse over this selects whatever band is under your mouse and you see more information, including what terrain type that band is.
One particular usage is to see whether your river is at the lowest point in a valley.
You will also see a "spot" appear on the map which shows you where that band corresponds to.

Last time I was working on this thing I ran out of time and never quite got back to fixing up some things.

I moved the terrain band description over to the left.


The up-down arrow over on the right top is there to allow you to see the distribution of height-difference-steps along the line.
If a lot of these are your scale or more then you have cliffs and you need to do something or your little men won't be able to climb round your map.
The shaper smooth tool is a fairly easy option.
Click that up down arrow and a datagrid appears in a popup.


The counts are of elevation differences between cells along your chosen line.
These are rounded to 1 decimal place and totalled.
0 means the cells are the same height.
High numbers of high numbers are bad.

If you have a lot of elevations then this datagrid will be scrollable.
You close that popup by clicking somewhere else other than the popup.
Until you do that the popup is the thing you're expected to interact with and there will be side effects - eg mouseover effects outside the datagrid will not work.

I also increased the base opacity of the slope layer.
This is the white and black layer intended to allow you to make elevation difference look a bit more interesting.
Reminiscent of the terrain layer in google maps.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 21, 2020, 06:52:27 AM
Validation Prototype

The idea of this is to tell you when the thing you're building has fundamental issues.
This is just a reminder so it doesn't try and tell you what to do to "fix" anything and doesn't stop you carrying on with whatever you want to do.
Usage is therefore entirely optional.

It works by using a set of fairly basic generic tests which (when run) return a true = ok = tick or false = not ok = cross.
Each has a description.

The process is necessarilly "dumb" in that it always runs all checks and always just returns that true/false.
It doesn't do anything as well as it's check.
So doesn't care if you have a totally empty scenario or whatever.
Everything is run every time.
The approach itself is generic so it can be used in any app within the suite by "just" building a set of checks specific to that.
At the moment I have just 3 prototype checks.

If I explain exactly what one of these is doing.

Blue pieces is a header grouping checks.
There will be other ones, eg red pieces.

"All pieces on board".
Looks at all the blue pieces you have.
A piece has a flag "IsOnboard" which will be true if you've dragged it onto the board ( map ) to a valid position.
If none of these are false then that check passed and is ok.
No blue army?
There won't be any blue pieces to not be on the board.
It's going to pass.


Checks are run when you load a scenario or click the button in the header with the refresh icon.

Does it matter if a commander isn't on the board?
You will have a broken game.
A combat unit needs it's commander to be on the board because loading units into pieces follows that hierarchy.
When you load a game, a combat unit "orphaned" will not appear in your game.
How do you work out which to fix?
Most scenarios will use most or all units and they're reduced to half opacity once dragged onto the board.
If you look at your oob treeview there will be that CO fairly obvious because it's full opacity and those on the board are half.

If I remove hooker off the map and take a look at the oob:


It's fairly obvious where the problem is once I know to go look for it.

You might think "hey... why don't you do other stuff like tell me which piece is the problem?".
I could have done that.
But each of the problems has the potential to be different.
I'd have to inject some extra generic functionality which could do different stuff for each.
Which would take longer.

As I review that screenshot.
I'm reminded that the treeview in the scenario editor is still the original style with pointy fingers eating up space.
I probably ought to take a look at that.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 21, 2020, 09:37:50 AM
Scenario Validation

More checks.
I've refined the initial ones I added a bit so they fail if there's no pieces.
Added dropshadows to the tick so they look a bit more interesting.
Made the checking more reliable by rebuilding things each time you click the button.


I noticed that the meters per square was shown to two decimal places, which is rather excessive.
Changed that to zero decimal places and standard numeric display which will show thousand separators.

The bright green box is added by problem steps recorder.
If I instead used my more usual alt + print screen to capture the display the help menu would collapse and you couldn't see it.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 22, 2020, 07:17:26 AM
Scenario Editor

More validations.
Looks like this is done now.
Usually, this is when I notice that thing I just finished is bugged.  ;D


Bug Fix
Scenario start time wasn't working quite right.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 22, 2020, 07:34:07 AM
Bug Fix

The path smoother was occasionally raising an error.
This was because it was a single instance ( static ) class with a single swap list.
In the scenario editor when you mouse over a CO, it works out the courier routes to all sub ordinates.
This is something which will be removed before distribution but allows me to easily test multi threaded pathing.
Glossing over the intricacies of threads this spins up multiple processes path finding processes at once.
Each of which will then get a bit of smoothing.
If two of them happened to try smoothing at once then they both grabbed the one collection and bad things happened.

In the game, I'll want to be able to process multiple pathfinding at once for things like calculating when AI orders arrive at units.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 23, 2020, 07:26:40 AM
Map Editor

Added data checks.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 23, 2020, 09:14:16 AM
Scenario Editor

Changed the oob treeview to the same style as used in the game.
As there, unit names are much more likely to fit without you needing to slide left on the control.
You toggle expanded or collapsed for nodes by clicking the unit icon.
Except combat unit icons, of course, which have no children.


In the above, I temporarilly removed a few pieces from the board.
Their nodes are full opacity whilst the rest are half opacity because those pieces have been dragged onto the board.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 02, 2021, 08:02:46 AM
Scenario Editor

Changed default internal start time to 9 am.
This in turn means the check for time change is more reliable.

Fixed a checking bug relating to victory kills requirements.
This was a "classic" cut and paste error.
Both the red and blue checks (previously) used blue data.
I wrote one, copied it and failed to change the variable used.

Also removed the automatic runs of the checks.
You need to click the button to run them.
This makes it more obvious they're not somehow dynamic.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 02, 2021, 09:31:43 AM

Direct move arrows are now red or blue depending on side of piece.
Fixed a bug which left a "rubber band" possible move line visible after you pressed Esc to stop inputting moves.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 03, 2021, 10:17:08 AM

Added places in.
These need more work though - the current style is far too big and clunky.
They get in the way and you can't really tell what point they refer to.

Moved show places into appsettings.
Appsettings is persisted and this setting is now used for both scenario editor and game.
Not the map editor.
Since you're likely to want to see the places in that by default whilst building a map.

Improved averaging of bearing for least cost path arrow.
This is used for the final facing of the piece and to rotate the end triangle around.
This being the arrow head.
Because a least cost path is necessarilly kind of wiggly, the arrow can still sometimes look like it's pointing in a strange direction.
That's unavoidable without smoothing out the path.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 04, 2021, 12:15:30 PM

refactor least cost path arrow building into a separate class.

Ignore last 4 points in least cost path for purposes of calculating averaged end facing.
This is because the angle is calculated from one point to the last.
The angle between points very close together is prone to anomalies.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 16, 2021, 09:35:28 AM
Kriegsspiel pieces in line now all have the same frontage.
Simulation pieces have different frontage depending on their unit type and previously game pieces also did.

Scenario editor in Game mode:
Simulation mode:

To highlight differences, here's a chunk of each. Notice how the Infantry unit is wider than the artillery whilst in simulation mode.

The game now respects game/simulation setting in a similar manner to scenario editor.
One difference being, no HeadQuarters pieces in game  mode.
Here's the game in game mode.

If you're thinking "Why does he keep on calling units pieces?"
We developers are forced to be pedantic and specific about names of things.
Code doesn't do kinda-right.
It's either precisely right or it doesn't compile at all.
When I mention a "Unit" this is an abstract thing in the army editor.
The clerk's notes on a Battalion whilst in it's barracks.
A "Piece" represents that battalion on the battlefield (or game board).
It is a different thing entirely because it has a load of other properties - eg location, facing, current stats, orders
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 24, 2021, 06:23:15 AM

Added the option to choose a direct move for pieces which would usually use best path.
In the unlikely event you need a piece that would usually move using a least cost move, you may now do so by holding the ctrl key down.
I would imagine this will be very rarely used but it's there if you need it.

In the picture above, an infantry column would by default choose best path. Here it's using a direct (straight line) move.
The blue HQ has two move orders - the first to move least cost and then another direct.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on January 28, 2021, 01:01:50 PM

Fixed an oddity.
One of the changes I made to avoid wiggly lines had an unintended side effect.
A piece would be a bit too keen to keep on going in a straight line.
Hence sometimes ignore a road it should turn onto and end up choosing a bit of an odd route.
I removed the couple of lines of code reduced cost straight ahead and that problem seems to have gone.

Probably find pieces wiggle down some roads now or something but I'll worry about that when I see it.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on February 14, 2021, 09:45:27 AM
New Pathing mechanism

I've replaced the pathing I was using for best path completely with a different implementation of spatial A*.
Like the previous version, this now relies on pre-calculated slopes within a map.
This is now done when you save a map - with the current version of the map editor.
This is a breaking change but easily "fixed".
You just open a map you created with a previous version of the map editor and save it again.
The calculations are done on save.

There is now another check in the scenario editor.
In the current version when you mouse over a HQ on the map it will try and calculate courier routes.
This uses the best path method and will error.
That courier route functionality might not be there in the final version, this is still TBD.


I have done some work on this to reduce memory overhead but this is a prototype version of pathing.
One of the things I've done is use a reduced set of nodes for a route.
This works out the centre point between start and end and uses a square around that which is sized to the largest difference in X or Y plus a third.
That means short "moves" are now much lighter weight since they're handed say a 200 x 200 array rather than 1155 x 805.
It's possible this could have introduced some oddity for some situations so I might have to reconsider.
But as it stands, if you have a piece on one side of a river and want to get to somewhere just on the other side then it's advisable to give orders in multiple steps. Choose the piece, click on a bridge or crossing and tell the piece to use that rather than try and swim.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 06, 2021, 09:46:33 AM

I've changed the way the calculated slope "slots" are held in memory.
This is a breaking change but we already had one of those so the fix is the same.
Open a map and save it before using it in scenario editor or the game.

For each Pixel (px) this is a measure of how steep the movement to an adjacent px is.
There are 8 adjacent px for each and a map is 1155 x 805 px.
The number of values held in memory is therefore 1155 x 805 x 8.
I've reduced the memory required by storing two values in each byte rather than one per byte.
Previously, I had a class holding an array of 8 values per px.
I now use "just" a plain and slightly more efficient 3 dimensional array of bytes.
This reduces memory pressure a little and speeds up spatial A* in my benchmarking process.
I'll probably soon mess that up by using up that memory on something else.
But I'll take that win whilst it's there.
The pre calculated supercell data will take up a chunk of that memory BUT greatly reduce the memory required by that greedy old spatial A*.
That thing just loves eating memory up.

And what else...
Oh yes.

I started on the new supercell precalc app.
Shiny new... what's it look like?
Nothing much to see actually.

The way this is going to work is you launch it from the map editor for your map.
Like one of those services - OneDrive or suchlike.
It'll grind away doing the calculations giving your RAM and processors a work out.
And save them to disk.
This will have no window of it's own.
That's so it has more memory available to do it's thing and because it's not something you're really going to want to sit and watch.
You'll see it running in the system tray.
I plan on it sort of transmitting progress data.
The map editor will receive that data and give you some indication of progress.
I'll probably need to add a wind down and save option so you can do a bit of a map and persist to disk. Then another bit another day.

Remains to be seen how long this thing will take but I'm thinking probably hours per map.
There are 759 supercells in a map and I wouldn't be pre calculating them if route calculation was quick.
I "cheat" and most routes are ok to reverse one you find for the return route.
If they weren't though this would be 759 * 759 routes.
It depends on your map as to how long would be an average sort of time for a route.
A fair few of my test cases are .3 to .5 seconds apiece but 1 to 3 seconds is not unusual and there's the odd 4 second one I see.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 07, 2021, 11:55:38 AM
Super Cell Calculator

The prototype is now calculating routes.
It spins up a number of threads which simultaneously do pathing but from a different supercell each.
This is fixed at 8 at the moment.
As modern machines can have numerous cores I will let the user choose how many threads they want to run with.
On a fast 64 bit machine with many cores like a ryzen (and lots of RAM) then you could maybe crank this thing up to 30.

The calculator communicates back to the map editor on what it's doing.
This is then displayed as number of target cells pathed in each of the starting cells.
These numbers creep up until all possibilities are pathed for all of the set of 8 starting cells.
It then does the next batch of 8.
As it goes it will find more and more routes already calculated and it should speed up.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 13, 2021, 10:11:33 AM
As I refined this prototype I broke something.
This is a particularly un fun sort of bug in that I can see my old version multi threads OK.
I can see my new version does just one thread of work at a time.

The calculator is now an odd sort of an app which is called a system tray app.
Not quite a service - which are totally invisible and run in the background on your pc.
No window - you "just" see an icon in the system tray.
Feedback is via the map editor or log file.
These things have some subtleties regarding threading which I rarely have to deal with.
And I think it's some aspect of that suddenly made a thing runs with 7 or 8 threads run just the one thread.

Not sure I mentioned this previously.
One of the reasons to make this a separate app is that it gets it's own memory allocation.
That would not be an issue if we only distributed a 64 bit app but that's not the case.
Some of you will have 32bit machines.
For a 32bit windows app there's a 2Gb ram limit.
By having low minimal resource  requirements of it's own, the calculator gets more ram to play with.

Since it takes hours to process a file I also intend building a console app version of this thing.
That can then be run from a batch file or command line on a secondary pc.
EG I have a media pc in the living room I can run this thing on.

But first things first.
I best get this initial version back on the rails first.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 14, 2021, 08:00:17 AM
SuperCell Calculator

Tracked down the threading issue and this is now stable.
For a prototype anyhow.
The proof of concept calculates one cell at a time and the path is shown in the map editor as a dot in each cell the route passes through.
That was great for checking things were working but one at a time would take a very long time to complete.
You could keep your pet amused all day with the ever changing pattern maybe but otherwise it's not how you'd want this to work.
This version works out the paths from a given cell to all others but can do a number at once.
Rather than showing you the path it just worked out for each it shows you how many it's done.
To do that maths again for you there are 33 by 23 supercells which means 759.
Less the starting cell and up to 8 which are directly adjacent ( and probably pointless to pre calc ).
That makes 750.
Less super cells with a water or swamp px at their centre.

Personally, I need to do other things on my development PC.
I will want to run this thing on a different pc than I work on and dial down the number of threads a bit since my "spare" is an i3.
Hence I'll build a stand alone console version and add an import file option onto the map editor so I/you can copy the output file and load it separately.

Here's one of my test runs will give you an idea.
The supercell calculator itself is only visible by a little grid appears in the system tray.
Currently, if you click that icon it kills the app.

Here's what the map editor looks like with this running.
The window on top is debug output which you might find interesting.
It's set to do 6 at a time and is on the third batch of 6 after 35 minutes.


This is the debug version running.
The release version will run a bit faster.
As it runs, it will speed up.
It will find more and more paths are already calculated so each cell's calculations will decrease from that 750 down and down until pretty much all are calculated already whilst doing the final column.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 21, 2021, 06:14:52 AM

Yesterday I had a brainwave. Or a bad idea. I'm not sure which yet.
How about if...
Instead of calculating from each supercell to every other one.
How about calculate to it's 8 neighbours.
Then run spatial A* on a 33 x 23 grid.
Way less nodes and pre-calculation means that would be very very fast.
The pre calculation would be far quicker and way less datal.
I thought it worth a try.

It is very fast.
I can dynamically mark the supercells a route will pass through as I move the mouse.
There is no perceptible delay.

I think there are some bugs in my calculation routine.
Some of the calculated costs I've looked at seem very strange.
Some routes it'll pick are good. My hopes were raised quite high.


Some are less good. Oh... dear.

I think it's worth trying to thrash the bugs out this thing though.
I'm currently including diagonal neighbours and probably should not.
Which would be 4 neighbours rather than 8 for each supercell and even faster to pre calc.

Pretty sure I've explained this previously.
But just to recap.
The purpose of this is to show you the rough route your unit will take before you click and commit the order.
I can work with that and highlight a bad route eg one that's going to mean your unit marches past enemy.

This will also allow me to greatly reduce the nodes the detailed spatial A* works with.
That will both reduce memory cost and make the detailed calculation far faster.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 21, 2021, 01:48:21 PM
Map Editor

I've prototyped a 3d mesh representation of a map's elevations.
Conversion to a mesh takes in the order of 16 seconds and the idea is to give you a better idea of what the slopes look like.
It's quite difficult to make out where there might be particularly steep bits.

I've used the more common "rainbow" colours for this which are used to highlight height differences.
I'll also try with my hypsometric version and see which is clearer.
First-try prototype gives this for antietam:

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 24, 2021, 02:07:48 PM
Map Mesh

I changed the mesh overlay to use the hypsometric image.
Sorted out the camera positioning and lighting.
And added a slider so you can rotate the whole thing 359 degrees.



First Bull Run is very dramatic.
Maybe I should add a vertical scaling mechanism.
But the whole purpose of this is to visualise how steep everything is rather than to give a 3d playing area.
Exaggeration is arguably a plus.
It does look like it could probably do with a "smooth" or two run on it though.
Those visible contours are the sort of things likely to make some parts inordinately steep.


These are "proper" 3d meshes composed of many triangles.
I could probably export so you could 3d print or something.
eg Bull Run
929775 points
1855632 triangles
Which is why they take a while to build.
Totally smooth rotating though.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 26, 2021, 01:57:54 PM
3d map

Divide elevation by groundscale so they're both to the same scale.
That then makes the maps look a lot less dramatic and much more sensible.
Also added controls to move light source up and down.
These are the triangular buttons above and below the sun.

I could maybe add a spotlight to make it easier to see particular parts.
But I'll change back to other stuff for now.


The area around Austerlitz - this is google maps data.

I've made no effort to remove the modern structures which are the blocky lumpy bits in some of the valleys.
Which raises an interesting point.
What would you do if you wanted to use google elevations as the basis for a scenario map?
Two obvious options:
Work round that stuff: set initial dispositions to avoid them.
Only really viable if they're not going to interfere.
Level them out.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on March 27, 2021, 09:33:18 AM
Map Editor

I've changed the way custom resource dictionary loading works.
There's a new folder within the maps folder called CustomResources.
Only the extension of a custom resource file name in that folder matters.
It must be .xaml.

If the file is not a properly formed resource dictionary the app previously did not handle this well.
It will now tell you it couldn't load the file.

Other aspects remain unchanged.
The content must be a valid custom resource file with a canvas x:Key CustomCanvas containing any paths you want to use.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 17, 2021, 09:12:40 AM
Map and Scenario Editors

I've added a "validation" check for groundscale.
The default groundscale is 1m per px.
Along the way the elevation measure has changed from integer to float.
Originally integer elevation meant any change between px would be 1+m elevation difference.
1m change over 1m lateral movement is 45 degrees which is very steep and would stop movement.
Changing to float means you can now have decimal places in elevation so for example 0.001m elevation change per px is possible.

Meaning you don't absolutely need groundscale of 3+m per px to ensure units aren't constantly blocked by 45+ degree slope.
Having said that, the game is not trying to be skirmish so 1m per px might work but odd things could happen.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 18, 2021, 06:58:58 AM
Map Editor

Added a file picker for custom resources.
You first load and a resource dictionary.
Then once loaded you may choose to import paths from it.
This isn't all one step because you may want to use the content of the resource dictionary to over ride styling or provide some background to a map.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 15, 2021, 10:20:02 AM
Scenario Editor

In the Scenario Editor you can set different ownership on Places.
You might have two or more scenarios on the same map and different starting positions mean a different side could hold a bridge, hill or town.
In order to accommodate this, scenario has it's own copy of Places.
This copying is done once, when you pick the map.
If you then later go back and change Places in your map then this could cause a problem.
In order to highlight this I've added a couple more validity checks in scenario editor.
These check you have the same number of places as in the map and the same total victory points.
I've also added a menu option under File which allows you to re-import places.

The list of checks in scenario editor now looks like this:

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 31, 2021, 09:30:43 AM
Places Prototyping

The first step to changing places is to break them.
What do you mean that doesn't sound so good?

I need to turn the existing working styling into something else which is quite different.
I want a piece of text for the label and a marker for the exact location.
That means some big changes from what we have now.
The first step is to get something basic kind of working.
I've started out with a spot for the location with the text underneath and starting from the same x co-ordinate.
Maybe that text should be offset to the left by half it's width so you can have a place right over on the right and still click the text to move it round.

Below, I've not set the background of antietam.


You'll be able to move that text round in the map editor and the spot will be something else.
Maybe a star if the location is worth points and a cross otherwise.
I've not decided yet.
The points will be moved into a separate panel.
And the colour of the marker will indicate ownership.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 05, 2021, 10:29:51 AM
Places Step 2

Offset the place name text to the left by half it's width - to centralise it below the spot.
When the place is close to the bottom of the map, offset the place name upwards by 30 pixels so the first line is above the spot.
This is applied to both existing places as you load and new ones as you add them in the map editor.

The next step will be to let you drag the name round to position it as you like.
These changes ensure you will definitely have something visible on the map to click and drag.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 12, 2021, 10:12:03 AM

Making the marker fancy.
Colour is hard coded red at the moment.
The idea is that this should be noticeable but not overwhelming,
The aim of the change is to avoid covering things up like the previous version.
You should be able to see enough to play the game without hiding places.

Not sure about the circle.
What do you think - keep it or lose it?
Or maybe a map pin instead.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 13, 2021, 08:54:40 AM

I wasn't happy with the star so I've changed it to a pin.
This is flipped vertically so the point of the pin is the pixel where the place is.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 13, 2021, 09:53:42 AM

Drag and rotate place name.
You click hold and drag the text as you might expect.
Don't try this whilst clicking has some other meaning though.
You can use the mousewheel to rotate the text.
Due to some fiddly dull technical stuff the rotation of the text is not always round it's centre.

Testing this, I just went with the default unknown rather than changing anything.
I moved the text on all these and rotated two.

The places save successfully and this picture is after I tried it out and reloaded the saved map.


This should probably only work whilst you're in edit terrains mode with the list of terrains in the left panel.
The colour should change.
Still need to add panels to the game and review the one in scenario editor so you can see what's going on.
And decide on any mouse over animation
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 18, 2021, 01:19:13 PM
Place Map Pin

Quite a minor change.
Make pin fill colour the same as the place's "owner" colour.
This was previously used as the fill on the background behind the place name so it's gold, blue or red.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 20, 2021, 06:42:50 AM

Animations highlighting place when selected.
The rectangle surrounding the name of a place is now gone and the text might not be right next to the pin.
The marching ants animation now goes in a circle round the place' point.
As you select a place there's a coloured ring animates from nothing to fill that and back.
This is of the same colour as the pin fill, indicating the owner.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 27, 2021, 09:27:24 AM

Fix two omissions.
Place name colour now matches the selected one.
0 point Places use Amaltea or the style based substitute for the name font.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 27, 2021, 10:19:18 AM

Animated circle now grows and shrinks 3 times rather than once when you select a place.


Prototype list of places.
This is a new panel in the left narrow column.
Places are ordered by owner then name.
Each has name and value with a coloured background matching owner.
If you click one you select it and that starts the circle animation so you can easily see which place is what.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 02, 2021, 09:46:10 AM
Neatened up list of places
Fixed sorting of these

In the picture I've selected Ford and you can see a blue ring round it.
That ring is animated, expanding and contracting 3 times when you select the place.

The primary aim of these changes was to make Places less intrusive and make it practical to play the game with them visible.
Secondary was to make it clearer exactly which point was a place.
I think these aims have clearly been achieved.
It is clear where the exact point of each pin is.
The big plaques and solid rectangles are gone but you can still easily see who owns what place and what VP it is.


Think I may still make the points a bit bigger and fancier.
But otherwise this looks like it'll work to me.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 04, 2021, 05:14:50 AM

I styled up the places panel in the game.
There are now 2 flags denoting owner.
The text of the name uses the Dark colour associated with the owning side - black, dark red or dark blue.
The victory points now have a gold effect with a black dropshadow.

Title: Re: Changelog - picture heavy
Post by: Adraeth on July 05, 2021, 02:13:49 AM
Excellent, i love it
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 05, 2021, 10:19:46 AM
Back to orders next, I think.

In very broad terms:
Take input.
Queue up the instructions.
Suport saving these
Work out what happens
Record the results in repeatable form.
Support saving these.
Show the results.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 10, 2021, 05:39:39 AM
Place Selection Animation

I increased the size of the ring and outlined it in the dark colour for owner.
Fixed a bug where the ring was getting "stuck" part way through an animation and left visible forever if you quickly selected different selected items.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 17, 2021, 09:40:16 AM
Final Place improvements

In the scenario editor whilst working with the list of places you had to click the area between the textboxes and dropdowns in order to select it.
This is because clicking these controls has meaning and they sort of eat that click in order to act on it.
I've changed this so if any of the controls for a given place take focus then that place is selected.
Hence click on either textbox and the animation starts up.

Made the selection circle several circles so it's easier to see.
This makes it cover things but the animation is temporary.

I also neatened up the spacing a little between the textboxes.

Below,  I clicked the textbox and you can see the multiple rings frozen part way through their animation.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 25, 2021, 08:10:36 AM
Light up selected unit. This is similar to the scenario editor but selecting a unit using the army treeview lights up the corresponding piece on the map.
The is a light yellow background in the circle surrounds a  piece.

The triangle in front of the piece will be a variable icon used to indicate "posture".
Posture is intent. What those guys are supposed to be doing.
Moving, assaulting, withdrawing or holding a position for example.
We'll probably want to make that a bit bigger and maybe it should go outside the circle.
Have to think about that.

I've also been thinking about orders, friction and command ability.
This is a game so we don't want to totally frustrate players.
On the other hand we want to model reality and on battle the simplest thing becomes difficult.
More difficult for bad commanders.

As they give orders a commander will be limited in the amount they may issue depending on their capability.
As orders are issued a commander may hit a limit and be able to issue no more for that turn.
Essentially, there will be a roll off vs command skill per stage as an order is put together.
Fail so many times in a row and you can give no more orders ( that turn ) to the unit you're ordering.
Fail more and the HQ for that unit can give no more orders that turn.
This is a similar mechanism to those used in some tabletop games.

You won't know exactly when you're going to run out so that adds suspense.
Complicated orders are higher risk - which models reality.
Even terrible commanders should be able to give simple orders successfully.
If you can plan far enough ahead then you should be able to work round the limitations of dunderheads.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on July 31, 2021, 08:34:17 AM

Bugfix:  Correct initial red/blue side selection.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 01, 2021, 08:50:33 AM

I've started refining the structure of classes used to store orders.
I sketched these out a while back and then of course moved on to do other things so I'd forgotten how rough of a sketch that was.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 08, 2021, 08:34:24 AM

I've started on persisting a move instruction into an order.
I've only just sketched out the structure of classes make up an order and ( as expected ) that still needs a fair bit of work.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 09, 2021, 09:44:16 AM

Now uses the same preferences appsettings file as the rest of the suite.
When you switch between victorian and modern style this is the equivalent of victorian and plain in the rest of the suite.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 15, 2021, 08:38:20 AM

Refining how to persist a move order.
I need to shake out several classes - the sort of refactor you have to do all at once.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 21, 2021, 05:34:38 AM
Map Editor

I've made a minor change which copies the terrain type from the pixel next to the edge to the edge px.
Why? You might wonder.
Ezra found something weird happened with the routing where a unit found a way past a river along the outermost pixel of the map.
This was still marked as terrain empty when he expected it to be part of a big river.
As it turned out this was a mistake in usage rather than a software bug.
But this is an easy thing to overlook.
They kind of look like they go to the edge until you turn the grid off, screen grab and increase the size of the picture in paint.
I've applied a fairly quick and dirty fix.
I can't imagine anyone will have a piece of terrain on the very edge of the map so you can only see 1px of it so I can't think of a downside.
It doesn't change the original source shapes though so if it turns out we see a problem I can easy rip the change back out and just saving a map would give you those edge pixels back.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on August 22, 2021, 04:45:44 AM

Better final direction for piece at end of best path move.
Previously I was averaging the bearing between a number of points on the move and the final point.
That averaging seems to be bugged and was giving some strange results.
As a result the triangle used for the arrow head would point in strange directions.
Just using the bearing between 8 px back along the path from finish and the finish seems to give better results.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 05, 2021, 09:28:48 AM

More work on orders persistence.
In the scenario editor I have calculations for the time a courier will take travelling between a piece's co to them.
That code is invoked when you mouse over a HQ and you can see the various paths the couriers will take appear briefly.
There was previously no equivalent in the game.
I've added a prototype implementation.

Technically, this uses somewhat tricky multi threading because it has to do a "best path" for the courier.
That's an expensive operation but it's "only" to work out when the order starts.
Meaning the player will want to continue to give orders and that courier calculation should not stop them.

Since this is a brigade commander which will be sending these orders out this is one of the subtleties of the system where player skill will show.
You want combat pieces to be covering each other's flanks and approaches etc.
Brigade HQ should be near enough to all that orders do not take forever to arrive and yet "safe" from enemy.
And the HQ may want to be able to see as much as possible but maybe not be seen by some enemy.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 22, 2021, 10:41:24 AM
Map Editor

There was a problem importing complex area terrain types as custom resources.
This produced quite strange effects since it was connecting up the wrong dots and filling in areas it shouldn't, excluding areas it should have included.
I've changed the way these shapes are handled to obviate this issue.
There are some rather obscure technical side benefits which I won't bore you with.

The reason we noticed this bug is Ezra is building a map for Ligny.
Since the "rivers" across the battlefield didn't stop the French then they we can't make them rivers.
Any water stops direct moves.
Those rivers in question were a couple of meters wide and easily crossed.
With some mud either side.
So the whole translates in game terms into mud.
Mud is an area type terrain whilst the rivers and roads Ezra routinely imports as custom resources are line.
This was therefore the first time we tried importing complex shaped area type terrain.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on September 26, 2021, 09:20:50 AM
Map Editor

alt + Page up or Page Down now moves the selected terrain to top or bottom of list.
Disable the river manipulation keys when there's no ink to manipulate.
This avoids an error if you've used custom resources to import a river.
Fixed a bug in templating which gave you unusable rows in the edit terrain list.
That was introduced by my refactor of area terrain.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 17, 2021, 08:33:32 AM

Calculating and storing distance from co to unit when an order is placed and it has not already been calculated for that piece for it's current position.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 24, 2021, 09:14:50 AM

When you select a piece now shows the path the courier will take from it's HQ with orders.
You ideally want that to be short but the hq to be safe from enemy,


The driver for which piece you're giving order is you click to choose it.
You may then click esc to de select or click on another piece.
Whichever way you do this, the previous courier path will be removed.
That choosing a piece also sets up the container for orders.
Currently, if you go back to a piece you already input orders for you lose those.
Final behaviour is still TBD. 
I'll likely allow clicking a previous move arrow to allow additions to this turns orders.
Once a piece is underway though, you're likely to have to issue a halt order first and get a known location before you can issue further move orders.
A move has to be from a given location ( point ) to another in order to carry out calculations.
We can't do "just go to X, from wherever you are".
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on October 31, 2021, 10:07:02 AM

Started organising a Turn object which will be used to hold the orders players give.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 13, 2021, 09:51:53 AM

I've upgraded the suite to .Net 6 ( and Visual Studio 2022 ).
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on November 21, 2021, 09:13:27 AM

Tracked down and fixed a bug in selecting a piece for orders.
Unless the piece is the army commander, always calculate the courier distance to it's CO.

The time taken for that courier is still the original calculation purely based on distance.
I need to make that more sophisticated and use a similar calculation to light cavalry.
We'll need fallback values because there are edge cases where there will be none.
An army might not have any light cavalry.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 05, 2021, 09:15:54 AM

Initial refactor adding timing for direct move order.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on December 10, 2021, 01:49:39 AM
Map Editor

Importing a particular type of area terrain resulted in an error.
Bit strange because seemingly very similar geometries worked fine.
I refactored the code manipulates an imported geometry to make it more flexible.
When I then tried the fixed version it gave a patchwork of woods across the entire map.
That made the process which "plants" trees very slow because I didn't have a bounding box filling the entire map in mind when I built it.
I therefore refactored this.
Another thing I changed since I did that original tree planting code was a mechanism for finding all the cells in a geometry.
I used that collection to ensure every point tested would at least be inside the woods area.
It's not quite as simple as that as all of each tree must be inside but it greatly reduces the cost of the process.
That change also speeds up planting trees in a woods you draw.
Unless you draw a perfect rectangle, some of the bounding box won't have woods in it.

In case you're wondering.
A bounding box is a (sort of imaginary) rectangle you would draw which just fits all of a given shape in it.