Changelog - picture heavy

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

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Andy ONeill

Game

Calculating and storing distance from co to unit when an order is placed and it has not already been calculated for that piece for it's current position.

Andy ONeill

Game

When you select a piece now shows the path the courier will take from it's HQ with orders.
You ideally want that to be short but the hq to be safe from enemy,



The driver for which piece you're giving order is you click to choose it.
You may then click esc to de select or click on another piece.
Whichever way you do this, the previous courier path will be removed.
That choosing a piece also sets up the container for orders.
Currently, if you go back to a piece you already input orders for you lose those.
Final behaviour is still TBD. 
I'll likely allow clicking a previous move arrow to allow additions to this turns orders.
Once a piece is underway though, you're likely to have to issue a halt order first and get a known location before you can issue further move orders.
A move has to be from a given location ( point ) to another in order to carry out calculations.
We can't do "just go to X, from wherever you are".

Andy ONeill

Game

Started organising a Turn object which will be used to hold the orders players give.

Andy ONeill

All

I've upgraded the suite to .Net 6 ( and Visual Studio 2022 ).

Andy ONeill

Game

Tracked down and fixed a bug in selecting a piece for orders.
Unless the piece is the army commander, always calculate the courier distance to it's CO.

The time taken for that courier is still the original calculation purely based on distance.
I need to make that more sophisticated and use a similar calculation to light cavalry.
We'll need fallback values because there are edge cases where there will be none.
An army might not have any light cavalry.

Andy ONeill

Game

Initial refactor adding timing for direct move order.

Andy ONeill

Map Editor

Importing a particular type of area terrain resulted in an error.
Bit strange because seemingly very similar geometries worked fine.
I refactored the code manipulates an imported geometry to make it more flexible.
When I then tried the fixed version it gave a patchwork of woods across the entire map.
That made the process which "plants" trees very slow because I didn't have a bounding box filling the entire map in mind when I built it.
I therefore refactored this.
Another thing I changed since I did that original tree planting code was a mechanism for finding all the cells in a geometry.
I used that collection to ensure every point tested would at least be inside the woods area.
It's not quite as simple as that as all of each tree must be inside but it greatly reduces the cost of the process.
That change also speeds up planting trees in a woods you draw.
Unless you draw a perfect rectangle, some of the bounding box won't have woods in it.

In case you're wondering.
A bounding box is a (sort of imaginary) rectangle you would draw which just fits all of a given shape in it.