3 possible behavioural bugs?
 

By way of preface, I'm still a noob here and so I'm not sure if the following things are WAD, real issues, or possibly I'm just imagining them:

1) Oblique missile fire almost never hitting. When I have archers positioned centrally and they fire more or less directly laterally across the screen, I get what seem to be reasonable results. But when archers are firing diagonally or vertically across the battle screen, they seem to hit very seldom. This doesn't seem to have any logic to it. Have others noticed the phenomenon?

2) Chasing enemy raiders all over the place. A few times I've had a relatively powerful AI army intrude into my territory. It's strong enough to overrun PI, so I send a strong army chasing after it. Trouble it, they never ever seem to catch it before it moves on to another province - ie, the AI army always seems to move before my pursuing army. The result is a highly annoying cat-and-mouse game where I have to try to anticipate which territory he'll attack next, or alternatively just chase him around until he attacks a fortress, in which case he stays put long enough for me to nail him. As I read the rules, I should have a 50% of attacking him before he leaves a province, but that never seems to actually happen.

3) Is it possible to attack a province simultaneously from two adjacent provinces? I've tried to do this, in the expectation that my two attacking armies would join up and attack as one, but instead it seems that only one of my attacking armies will move (and get slaughtered...), while the other one stays put.

Re: 3 possible behavioural bugs?
 

1) Oblique missile fire hits less often because the distance is greater. Instead of using the Pythagoras equation for calculating real distance (a^2+b^2=c^2 and then deriving c), the distance is calculated as a+b, so it's much longer. Hence less accurate.

2) Army movement happens according to nation number, from what I've seen. Nation with lowest number goes first, so they always move before you do. This is not as it should be, but I suspect fixing it at this point would be far more work than it is worth.

WRT the AI moving, you need two armies capable of crushing it. You chase after the AI with one and use the other to hit the province it will go next, which will result in it being defeated.

3) Moving in from two different provinces is certainly possible and often works. I have no idea why you've had such bad luck with it. A debug output of the game log could help sort that out, but you'd probably need one of the more experienced debug log interpreters to look at it for you. I've less expertise on that front.

Re: 3 possible behavioural bugs?
 

And how is this not a bug? Missiles don't follow the manhattan metric when moving! That the game calculates distance that way is clearly wrong, and should be fixed.

It may alternately be one of nation number or reverse nation number. But that's actually irrelevant for army chasing - you can *never* catch an army.

How it actually works is all armies move first, *then* battles resolve. Only if two armies move into each other and encounter each other does it have to check to see which army moves 'first', and thus which province the battle happens in.

This is actually a reasonable model - its hard to make an army in the field fight if it doesn't wish to, especially pre-Napoleon when armies couldn't easily transition to combat from being on the march. (Julius Caesar's campaigns in Spain have a good example of the necessary boxing in of an enemy in order to force a fight).

Re: 3 possible behavioural bugs?
 

It's not a bug because it has been designed to work that way for reasons known to Johan K. I don't know those reasons, but I do know that it is working as it is supposed to within the framework of the mechanics. It just uses the Manhattan metric for calculation and that's not broken.

I agree that it is not ideal and would much prefer for it to use the Pythagoras metric, but again, I have no idea whether fixing it would be more trouble than it is worth. I have no idea whether that would break something or not, but chances are that it could very well do so.

The difference between bugs and features is often one of perception, but from the standpoint of bug management, this is currently a feature.

Re: 3 possible behavioural bugs?
 

This is probably the problem most often encountered by new players, since the idea of simultaneous movement is quite rare in TBS games. Not 100% sure why the problem is seen so often, as can't exactly see how the manual is unclear on this, but guess it must be somewhere given the number of new players that struggle with it.

Some advice for new players though, your best friend for understanding how things work in Dominions (besides the great forum community) is often page 71-72 of the manual. ie. The Turn Resolution Sequence. A lot of mysteries can be solved by having that close to hand. And on this particular movement question, the relevant part is...

(friendly movement) happens before (other movement) happens before (battles from movement take place).

So there is no concept of 'chasing' armies in Dominions, since you can never catch them because movement is simultaneous, and all movement is resolved before any battles occur. There is only really........

- Predicting movement. Which means basically correctly guessing where your enemy is moving to, or covering a lot of potential bases with your own forces.

- Stopping movement. By assassinating the commanders that are leading the armies, or moving specifically from the province the enemy army was moving to. (this latter scenario is what results in a percentage chance to attack the enemy army. You mention 50%, but it's different to that in practice since there is a chance of both armies missing each other. Plus other unconfirmed factors involved such as the size of the armies)

- Attacking before the movement phase using teleportation spells such as "Cloud Trapeze" or "Teleport" for commanders (ie. Thugs/SC's). Or "Astral Travel" for armies.

Re: 3 possible behavioural bugs?
 

It's not exactly the Mannhattan metric, there is a little correction in the formula for things that don't go straight but mostly diagonal. I have given the formula used by the game in this post. The reason that this mostly linear metric is chosen instead of the Euclidean metric is mostly to speed up processing, I'd guess, as distances, ranges and movements are computed a lot during hosting.

I haven't checked now, but I'd guess that movement happens according to nation number, but randomly from top to bottom or from bottom to top, as it happens for a couple of other things - rituals, for example. That's what JK does to avoid the usage of higher level data structures instead of arrays, while still being somewhat fair to all the players. If you want to really make sure that you get an artifact that's available, then you should forge it twice, once with a unit with a very low unit id, and once with a unit with a very high unit id.

Re: 3 possible behavioural bugs?
 

3) the problem is that if you attack an enemy army with 2 armies of yourself.
that enemy army might decide to attack one of yours.
So half of your army will attack and half will defend.
Theres a chance of this happening instead of both of your armies attack and enemy defends. Having the bigger army increases the chance that you push the enemy to defend despite of his orders to attack your province.

Re: 3 possible behavioural bugs?
 

When the game developed to the point of majorly slowing down the hosting times it was already too late for this..
But I wish there had been a setting for host time from the beginning. Then everytime a formula or AI thinking or double-checking for logic was deleted or watered down, it could have been shifted to the long-hosting category.

Re: 3 possible behavioural bugs?
 

This is one of those things that should be prominently advertised in the manual.

I'd call it a bug because its not documented by the manual, and *no one* would expect ranged missile distance calculations to work like that without prior knowledge of what the game is doing. (Which, since the manual doesn't say, would require extensive testing or code hacking/diving).

I'm sure Johan did it, per other comments, to save computation time, but i'm not sure why the game doesn't compile or just have stored a matrix of all possible 'true' (pythagorean) distances from a fixed point to a variable point. It would be easy to calculate once and then quick to look up because its stored in a matrix. If I was trying to minimize distance calculation operations, that's what I'd do.

Re: 3 possible behavioural bugs?
 

Lookup tables are even more effective (and more oldskool! :cool:) than that, yes. It would be interesting to see how much hosting time those would save if they were used instead of the current distance function.