Changelog - picture heavy

[Andy ONeill]

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  or whatever then please start a separate thread.
Thanks in anticipation.

[Andy ONeill]

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.

[Andy ONeill]

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.

[Andy ONeill]

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.

[Andy ONeill]

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.

[Andy ONeill]

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.

[bayonetbrant]

it's cool to track the development


Us non-game-dev IT weenies can appreciate the headache it can be

[Andy ONeill]

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.

[Andy ONeill]

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.

[Andy ONeill]

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.

[Andy ONeill]

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.

[Andy ONeill]

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.

[Andy ONeill]

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 modellib.map.
Needs to be re-used in the game exe. Eventually.

Refactored out a number of public variables from mainwindow.

[Andy ONeill]

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.

[Andy ONeill]

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.