GrogHeads Forum

Game Forge => 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.