Recent Posts

Pages: [1] 2 3 ... 10
1
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on Today at 02:20:04 AM »
Scenario Editor and Model

Skirmish fix up.

Skirmish formation was a relatively late addition to the suite and it turns out I missed some stuff out.
This wasn't added to the default movement rates and you can only edit values already exist for these.
They were also missing off turn time visualisation.
The way that view works is you mouse over the area with the graph like bars on the right for a unit type and it shows you text and numbers in the left panel.
The section you mouse over is selected so it changes style a bit - so it's clear what matches.
Adding another formation made the content of that left panel too big, so I re-organised the buttons from a vertical stack to a horizontal row.
I considered moving the close button somewhere else but I don't see a better option.

2
General Staff Support Forum / Re: Slope costing
« Last post by Andy ONeill on Yesterday at 04:05:50 AM »
I just realise I didn't cover some points there.

The elevations are now held as float.
Float is scientifically approximate - but that'd be less than a mm variation so it's effectively more accurate than we need.
It has decimal places and can hold a maximum way beyond what we'd need
340282346638528859811704183484516925440

The limit you're a lot more likely to notice is inherent to greyscale import.
There are only 256 levels of grey possible.
In theory there are 16bit greyscale but parts of windows will scale that to 256 levels.
Most battlefields aren't going to come near 256m of variation from lowest to highest but if you want to build one that does then the greyscale import will produce big steps between levels and just using a greyscale import will probably not give great results. You would need to smooth or use a different approach.

I have a costed best path algorithm you might have seen shown way back in the scenario editor.
A piece in close order line moves straight forward of wheels.
Or changes formation.
If a straight line happens to take a piece in line exactly down a road then it's base move will use road because it's the central point of a unit that counts.
This is arguable I suppose but working out what the entire frontage of a piece crosses, calculate the slowest etc is also arguably wrong.

Skirmish order and column can move straight or best path.
A best path move could be along road or totally road based.
That path calculation prefers roads.
It currently ignores elevation change.
Logically, a road should offer significant advantages over rough so that's good for couriers ( what it's used for currently ).
I've not decided exactly to do with full size units.
A reduced elevation change cost seems appropriate.



3
General Staff Support Forum / Re: Slope costing
« Last post by Andy ONeill on Yesterday at 02:05:55 AM »
Hi,

That story with the 20 minutes quote now seems highly doubtful to me.
Something is wrong.
Comparing to the numbers from Nafziger's Imperial Bayonets it seems to be maximum speed you could expect on a perfect road.
And it's a whole corps rather than some small super fit light infantry unit.
It can't all be on an excellent road unless one huge column.
Which would then have taken time to Ploy Deploy.

It also turns out that as a costings test this route is not great.
It's unlikely to have more than a 30m "climb" in it.

This is what you find when you compare stories - history - to reality though.
History is often written by people who make stuff up.
Who interviewed people that mis-recalled or made stuff up.
Or simply have an inherent bias.

On map building generally.
The google maps download gets you elevation data.
You register and create a txt file with your unique key in it.
Google gives you a $200 a month allowance - I wouldn't expect "normal" usage to come anywhere close to that.
To reduce the effect of any anomalies this gets the data for every other pixel and then averages for values between them.

I looked into sources other than Google.
To generalise, these give you a thing called a geo tiff. Which sounds like a picture but is using the tagging mechanisms in tiff files to hold data.
The problem with these things is it's very difficult for a user to work out which piece of what file they need to use.
Making that sort of data consumable would be a huge piece of work.

There are some online sources give you a picture of wherever you like in the world.
All the ones I've seen are coloured.
You could use one of these as a source for greyscale import.
It will take a wide range of picture files and converts colour to greyscale.
So you'd be able to get some sort of elevation numbers out of one of these.
You'd probably do better doing some pre processing using a graphics package and converting to greyscale with higher contrast.

Ezra and I have different opinions on the "best" way to build a map.

He particularly likes the period maps you'd see in many history books.
These are, however, often quite different from reality.
You could maybe call these "sketch maps" because it's pretty obvious someone just sketched them out.
Maybe whilst in a local tavern.

These maps give you some interesting period feel kind of graphics and will often be familiar to wargamers.
And these are what our commercial maps will use.
In order to add elevations, an artist builds a greyscale representation of elevation.
This is then imported using greyscale import.
To add rivers, forests etc these are added either by tracing over the map as a background or using custom import.
The custom import is pretty much necessary to get a good match for a river whose width varies.
Custom import is kind of fiddly but basically the rivers are drawn and saved as a picture with a transparent background.
InkScape is used to "bitmap trace" that into vector representation and the geometry pasted into the custom import resource dictionary.
The import process is fairly straightforward if somewhat manual.
If you already had a map with rivers and water in a different colour to everything else you could "just" use filters in a graphics app to separate that out or you could use bitmap tracing via colour in inkscape directly.
The reason all that isn't just in the map editor is because of the huge extra functionality a graphics app offers.
It'd take forever to reproduce a fraction.

My own thinking is that getting the elevation map "right" is probably the hardest part of many maps.
Which is why I wrote the google elevation import.
There's a lot of fiddly detail in reality.
Once you have that the hypsometric layer shows you where all the hills and valleys are.
Google maps itself shows you where villages etc are now.
It got renamed but I doubt they moved Pratzen.

If you're doing imaginations and just want any old piece of land then you could choose a bit of real world or build something simple using just the shapers.

All sources are potentially going to give you step changes.
Google elevation is approximate - so you get noise values.
Greyscale only has so many levels in it and you can build something looks fairly smooth only to find it's not quite as smooth as you were hoping. It's therefore best to test what you have using tooling such as the terrain visualiser.

You can round everything off a bit using the new "smooth" shaper.

Back to the slope costing.
I've got the pieces done that work out what points a move will cross and to cost for each of them.
I'm about to bring all that together.
I then see what result it gives.
Compare that to Naismith and make sure a unit (of maybe 900 men in a formation all lugging packs and weapons) will move slower than a rambler.
But not super slow until it gets close to the limits.
4
General Staff Support Forum / Re: Slope costing
« Last post by zu Pferd on May 31, 2020, 09:26:00 PM »
Hello Andy

very Interesting !
when will you know and how will you test?
second question
did you find a suitable working app to create a sat image map
(google maps pay version)

Laying down creeks and rivers would require some careful plotting?
My only experience with sat data was applied to Histwar map editor and there was a ceiling
where the 3D engine of editor could not go over and create
second point when it came for the units to slog it out over these steep elevation they did so
without any real loss in cohesion or speed of ascent.
Will the program take care of what is possible to climb, as in choosing to use a road instead,
and how will the roads correct or allow for the climb as they often are steep in themselves.
 
5
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on May 29, 2020, 03:16:42 AM »
Pieces

I've added a small line to the front of pieces.
This is similar to those you see on maps of this period, within the limits of practicality of the code base.

Whilst doing the slope work I found it's fairly easy to forget some of those pieces are in column formation.
The line makes it a bit easier.
I chose a line because a more complicated or bigger symbol would introduce problems.
This will also still appear in "game" mode where it might be between two symbols.
( Have to consider that, it might be best to hide this thing in "game" mode.)
It will also still be visible when two pieces are in close combat and could well overlay an opposing piece.
It's not hugely intrusive so I don't see that as a problem.

I tried various options starting with a plain black line.
What seems to work best is a gradient white to black or black to white.
I switch between these depending on the facing of the unit to try and give best contrast against the dropshadow.
And because it's white-black-grey some part of the line will always contrast with whatever it's on top of.

6
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on May 28, 2020, 08:55:03 AM »
Map Editor

Following the changes of elevations, Ezra re-imported the Antietam greyscale data.
Something odd went wrong with the background picture on saving.
I've spent some time trying to reproduce the problem.
Tricky one this because fixing something that you can't reproduce is quite a challenge.
I've made some changes intended to improve stability in this area.
7
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on May 27, 2020, 07:32:04 AM »
Scenario Editor

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



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

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

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

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

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

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

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

8
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on May 27, 2020, 03:31:15 AM »
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.
9
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on May 26, 2020, 08:40:41 AM »
I used my austerlitz-ish map to build a simple test scenario.
Added costing to the movement process.
At this stage a prototype because I want to see this working with simple stuff before I do anything harder.
There were some problems.

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

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

I then tried the slope code with real world data.
Even after running the smooth shaper over it a couple of times it is obvious that slopes which will stop something moving completely in Kriegsspiel style rules are all too common from one px to another.
This means the simple approach of calculating difference from one pixel to another is likely to give you results which seem over sensitive.
Bit of a nuisance but a more sophisticated approach is necessary.
Probably best to give this more thought but.
Maybe two fails on the run or over 1.5 * the current limit in one.
The mechanism needs to stop a unit leaping up a cliff or moat so there must be some sort of a limit.
I've previously considered mechanisms like averaging but that isn't going to work because a long move would likely produce different results to a short one.
10
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on May 25, 2020, 05:14:34 AM »
Slope Costing

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

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

Although the code is working I've still to use those costs in the orders code.
Next step will be to plug the calculations in and check the overall results look right.
Pages: [1] 2 3 ... 10