Changelog - picture heavy

Started by Andy ONeill, January 02, 2018, 02:08:07 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Andy ONeill

Game
Rationalising the move arrow code.
In the process of doing this I not only improved the code as intended but  also spotted and fixed a bug.
Code quality isn't just some academic thing.
Untidy messy code takes much longer to understand when you try and find problems or change it. Like an overgrown back garden full of weeds, you're best taking a strimmer to it before it gets out of hand.

Started refactoring the rubber band and arrow processes.
These mostly worked but there were still at least 2 bugs and a fundamental change in approach is necessary.

Bug fixes.

Army Editor

The approach stopping the app from closing down was faulted. Replaced it.
Clicking the wiki option crashed. Definitely used to work but I think is a framework difference in net core. I've coded round that.

Crash reported when drawing accuracies.
I can't reproduce this so I added error trapping and that will put up a message if the line drawn results in an error.

Map Editor

The approach stopping the app from closing down was faulted. Replaced it.
Clicking the wiki option crashed. This used to work but I think is a framework difference to net core. I've coded round that.
Greyscale elevations would crash if you click the save button without  a greyscale image to save data from. Added error trapping so it now just gives you a message.

Snapline.
Translate turned whatever you have into a piece of terrain. The term seems to be confusing. Changed to Commit and moved the explanatory tooltip from the containing grid to this button.

Andy ONeill

Scenario Editor BugFix

Saving the scenario could produce very odd pictures in some edge cases. The most obvious being when some things are logically off screen they were included in the picture. That could produce an image with a couple of dots in the top left corner and the actual map squeezed down bottom right.
I now force it to clip to the expected bounds.

Loader Bug Fixes

The last scenario image wasn't being loaded due to a fault in the looping.
When you started up initially it popped up a message box telling you it can't find a file containing paths to the various exe, which you haven't set yet.
Now fails gracefully if there's no file written yet.
The file was written to the folder the exe was run from, which wouldn't work for live users who installed to program files.
Corrected the file location so it goes in a (new) Loader folder in appdata with the rest of the suite's data files.

Game

Mid way through refactoring the movement code.
Quite a substantial refactor.
Once it's split out and neatened up a bit... and I beat the bugs out.
I can then do another refactor so it's ready to be used by Ezra's AI.

Andy ONeill

Unit Icon container

This is the thing contains each of the nato icons. I say each because you can have 4 in one piece if you're playing in "game" mode.
The dropshadow I added rotates so it falls in the same direction no matter the unit facing on the board.

Which is great for units on the board.

However.

That unit is also there in the treeview to the left in the scenario and army editors. Rotating the shadow on the icon there looks a bit odd.
Same container and same piece viewmodel are involved.
The main difference is that the icons are always white black and grey unless they're on the board.
I've therefore used that colour setting to drive code sets the dropshadow direction over-riding facing when a uniticon has colour set to "white" as that's anywhere off the board.

Andy ONeill

Unit Icon Dropshadow.

I forgot that the unit appearing in the scenario editor and game treeview aren't white.
Bit of a tweak to set the dropshadow direction on these.

Game

Move refactor first iteration done.
Fairly stable.
Old bugs are gone.
New - much more interesting ones - added.

Andy ONeill

Game

Move refactor now stabilised.
The worst bugs swatted.
Setting aside those nasty bugs which weren't going away.
This is "just" pretty much back to the state I started the refactor in.
But more stable, easier to extend and closer to something Ezra's AI will be able to use.

Still need to use whether a move is valid or not, check what the unit type and formation is before any wheeling is used et al.

Andy ONeill

Game

Stopped the user choosing to commit an invalid move.
As well as the red part of the rubber band and the message saying "Water cannot be crossed" ( or whatever invalid terrain was first encountered )



You now get a cancel sign appears where you clicked.



The transparent centre of the X will be exactly where you click.
Moving the cursor further on doesn't make that move any better.

In the pictures, I've just got the hypsometric background and that dark green line is a river.

I've still to decide what is best to do then.
If you try and commit an invalid move part of me thinks it's too bad if you have to then go and choose the unit again.
Which is what happens at the moment - largely because I've not got around to allowing a series of moves yet.
OTOH maybe I should just hook up the rubber band handling stuff at the same point I remove the cancel symbol so you can carry on.

Andy ONeill

Unit icon shadow

Couple of fixes to this.

The shadow direction wasn't "quite right" all the time.
I needed to add 315 degrees to the facing for the shadow.
Added that.

Then I took another look at columns and they still weren't right.
I'd forgotten that columns rotate the unit 90 degrees for various arcane internal reasons.
Which in turn was rotating the shadow.
Fixing that was a bit fiddly but done.

Movement Costing

I've started working out how to do this.
I need to stop moves that go through invalid terrain or over a given slope for the unit.
Slope up or down can be bad.
Some of this is trickier than you might think.
EG
Cavalry can't charge down anything but quite a gentle slope.

Slope should increase cost particularly up and particularly as it approaches a unit's limit.

Validity of move needs to use a specific path of some sort.
This will be where the central point of the unit will travel.
At the moment I have this "working" for the straight part of a move but only based on terrain type.

There are some complications to allow for.
Constraints being one.
Where a unit in line or skirmish encounters something blocks part of it.
Like a house or where there's a gap between close terrain narrower than the whole unit could fit through.
There were standard drills for this.
Skirmishers just kind of flowed. Although often organised in lines they were not in a fixed close order.
The companies (or half companies even) of a battalion in line stack behind others when blocked.
They then expand back out at the double to "catch up" and re-form the line which would pause to dress.
The only part of that which would usually slow a unit is the dressing.
The unit is disordered until the lines are dressed.
Should they contact enemy whilst in the process of re-expanding I suppose I could calculate what proportion are ineffective but my inclination is to just go with one disordered minus.

Cost of a wheel will be the highest of central or outer arc movement.
I need to decide on some default cost for blocked outer arc.
Plus dressing the line.

I think I mentioned it previously but it was common practice to try and avoid wheeling within range of the enemy.
Similarly, commanders would try and give the order to form square with plenty of time to spare before any cavalry were likely to be a threat.
Movement directly forward was reasonably predictable.
Fancy stuff like wheeling, formation change et al were tricky things and prone to problems made them unpredictable.
Particularly so "in the face of the enemy".



Andy ONeill

Slope Effects

Researching and starting on slope effects.

Strategos seems like a reasonable starting point since it is the most detailed of the various Kriegsspiel-like systems and was reviewed by experienced military men of the time.
They probably came with their own personal bias but there were a number of reviewers should have evened that out.

Scenario Editor

I was looking in the scenario editor to double check how we hold movement rates and noticed there was a bunch of junk in the source repository.
Removed unused pictures, font and txt files.

Model

Started on the Slope class which will hold all the stuff for maximum elevation change and slope costings.
With a computer to do the calculations I can build in an exponential increase in movement cost for elevation change as a unit approaches slope limit.

My initial plan for elevation change cost is based on dividing max slope by 5.
Square how many fifths you get.
Multiply elevation change by that to give the equivalent flat cost in metres.

Andy ONeill

Game

Added prototype slope checking to the line validity checks.
Looks like it's working, but needs more checking.
The map I've been using has inordinately large differences between pixel which means pretty much everything can't move.
Have to try a different map tomorrow.

Andy ONeill

Game

Added multiplier for diagonal movement for slope calculation.
It's not immediately intuitive, but a cell diagonal to the one you're moving from involves a longer lateral move, which reduces the effective slope a bit.

Map Editor

I tried to load some elevation data for Antietam.
The processed failed because I'd introduced a bug somewhere along the way during the .net core or float elevation refactors. The google data originally relied on a namespace they didn't include in .net core.
Fixed the bugs.
This means, by the way, if you're a beta tester and try the google maps import then it will crash and burn.
Seeing as nobody has reported this bug we're unlikely to do a new distribution just for this specific bug.  The fixes I've just applied will be included with any later release.

Scenario Editor

Removed unused pathing.
This is the thing which finds a best route for couriers.
A modified version will be used as an option for column and skirmisher movement.

The original pathing code had some problems and was a bit slow so I replaced it. This was over 2 years back now.
I kept the original thinking I might find some bugs in the new code and want to revert.  Then I completely forgot the old stuff was still there.

Andy ONeill

Slope Costing

Added unit tests to check slope costing code I just wrote.
Fixed and improved that code.

These are automated tests - code that checks the results of code.
A standard in my usual commercial work but not well suited to most code in the game.
Slope costing is something of an exception because it gives fixed and predictable results meaning automated tests can be written.
It's also very difficult to test a range of cases manually so the time spent writing the tests is worthwhile.
If you're curious you could easily google TDD and learn all about red-green-refactor.

Although the code is working I've still to use those costs in the orders code.
Next step will be to plug the calculations in and check the overall results look right.

Andy ONeill

I used my austerlitz-ish map to build a simple test scenario.
Added costing to the movement process.
At this stage a prototype because I want to see this working with simple stuff before I do anything harder.
There were some problems.

The first was my new map background had a margin round it's picture.
This is something new in code that's been stable for some time.
It seems a problem introduced by net core conversion.
Fixed that.

My pieces didn't turn up in the game when I loaded it.
That's because we have a hierarchical structure to the OOB and if you don't include a parent HQ, then the child unit also isn't included.
Insisting you include a  CO in a scenario for any piece you want in it doesn't seem unreasonable.

I then tried the slope code with real world data.
Even after running the smooth shaper over it a couple of times it is obvious that slopes which will stop something moving completely in Kriegsspiel style rules are all too common from one px to another.
This means the simple approach of calculating difference from one pixel to another is likely to give you results which seem over sensitive.
Bit of a nuisance but a more sophisticated approach is necessary.
Probably best to give this more thought but.
Maybe two fails on the run or over 1.5 * the current limit in one.
The mechanism needs to stop a unit leaping up a cliff or moat so there must be some sort of a limit.
I've previously considered mechanisms like averaging but that isn't going to work because a long move would likely produce different results to a short one.

Andy ONeill

Game

Improved and more sophisticated slope checking algorithm.
As well as a somewhat less sensitive pixel by pixel comparison.
Now also takes into account the change in slope across the move.
( The straight part of it at the moment )
A message tells you the angle calculated, limit and what it's using to decide that limit.
Skirmishing over-rides unit type for this.



Although this is sort of part of antietam you're looking at, this map has artificially high elevation differences for my test purposes.

I still need to take into account any wheeling and whether the unit is skirmishing or not.

The limits I'm using are based on Charles Totten's Strategos.
I've increased his limits slightly by adding 2 degrees.

Andy ONeill

Scenario Editor

The scenario editor maintains speeds for any given scenario.
There is a different speed for a combination per army, unit type, terrain type, formation.
Hence an example value will be held for an example combination: red, light infantry, woods, line
There is no entry for invalid terrain types - those a unit cannot cross.
Not sure if this has been posted before but it's a long time since I worked on this and would have posted about this view.
You can see these values maintained in the "Set Movement Rates"



These values are metres per minute.
( There's a tooltip explains that if you hover over the "Rate" heading in that datagrid ).

In order to work out how long any given piece of movement I've been working towards a value in metres.
This is level movement plus a value representing the effort to change elevation.

If you have a static defender and an attacker moves up to them then this could be a full move.
As the attacker you might be able to see both and order your piece into contact with the enemy.
If it just stands there then the time taken to get there would be your full move you ordered.

That is the simple case and things aren't always going to be be that simple.
Maybe that defender isn't quite so static, you have fog of war turned up so you didn't even see the piece... etc.
We also can't rely on a full move always being completed within a turn.
There's also likely to be different terrain types for different parts of a move.

All of which means I need to calculate based on seconds each pixel "cell" takes.
I could use the values you see above and calculate from them each time.
That would add a set of calculations to every pixel handled.
I can save that by pre-calculating the equivalent seconds per metre.
Which has the added benefit of splitting out that calculation so I can check it's right.
Turns out this is just as well, because I got the first version wrong.

This calculation is now done as you save a scenario and the results saved.
Internally that is - as a player you'll never see these directly.

If you had a saved scenario you'd now need to save it again before it'll work in the game.
That only affects Ezra and I at the moment though.


Andy ONeill

Map Editor

Following the changes of elevations, Ezra re-imported the Antietam greyscale data.
Something odd went wrong with the background picture on saving.
I've spent some time trying to reproduce the problem.
Tricky one this because fixing something that you can't reproduce is quite a challenge.
I've made some changes intended to improve stability in this area.