Bug: 3 possible behavioural bugs?

[Edi]

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.

[Squirrelloid]

Originally Posted by Edi

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.

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.

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.

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).

[Edi]

Originally Posted by Squirrelloid

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'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.

[Squirrelloid]

Originally Posted by Edi

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.

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.

[lch]

Originally Posted by Squirrelloid

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.

Lookup tables are even more effective (and more oldskool! ) 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.

[lch]

Originally Posted by Edi

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.

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.

Originally Posted by Edi

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.

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.