Different combat results on different speed settings !

This is a known phenomenon. I have heard it said that combat in simultaneous games is resolved at 32x speed. The simulator must be used in strategic mode to achieve this.

I don't know if this is on MM's short list of pending patch issues.

That might explain why I managed to capture your planet in that KotH game, while the log showed mys ship destroyed before it could land troops. It doesn't explain the other ground combat bugs though...

That would be very annoying for multiplayer games.

So thats how blue templar stole my homeworld? Stupid protoss...
(jk I had no defences ):D

For Aiur!

I assume you did each of these test runs more than once?

After a bit of thought, what the speed multipliers must actually do is coarsen the time increments of the simulation (lower temporal resolution, to put it another way). Ships and seekers will effectively move in bigger, jerkier, jumps.

Given the way things work in SEV, in general I suspect that longer-ranged direct fire weapons (such as are available on larger mounts commonly found on bases and planetary weapon platforms) will have an advantage up to the point where the movement jumpiness is on scale with their range advantage, which is probably more than 32x.

Seeking weapons and possibly short-range fighters may have problems refining their solution to close on target if the jerkiness is significant on their scale. To put some imaginary numbers on the problem for illustration, let's define the "blast radius" of a seeker as 1.0. This is the range at which it considers itself to have hit, and does damage. If the time scale is such that the seeker moves at 0.3 per internal turn, and the target ship at 0.2, as long as it heads for the target it will work properly.

But if you multiply the time rate by 10x, now the seeker is moving in jerks of 3.0 per internal turn, and the target ship at 2.0... it may never be able to get within 1.0. Consider that if at time T=0 the range is at (viewed from the perspective of the seeker) 3.0 and mutually closing; at time T=1 the range will be -2.0, ie they flew past each other, but since you only process things each integer time period, at no point when the game checked was the range less than 1.0 for it to explode and do damage.

A better description than "Speed Multiplier" would be "Resolution Loss", with 1/1, 1/2, 1/4, and so on. Perhaps that would give people a better idea of what is happening. This sort of thing comes up a lot in the real world when designing feedback loops for complex systems, and when trying to simulate analog physical processes with quantized digital simulations.

You're making an assumption that that is the way the system works, though. It could be that the system just do the internal turns at a faster rate, i.e. more of them, the higher time compression is used, thus ignoring the problem you present entirely.

However, I'm inclined to agree; there's definitely something odd going on in combat, because results do vary depending on the time compression used. I've bugged Aaron about this for months, but it appears he thinks the problem was fixed in an earlier patch.

it's probibly something tied to the real time clock still, instead of tied to the speeded up one...

-----
an se5a is a ww1 fighter, it is also a car.

Yah, but interestingly the problem is either non-existant or barely perceptible using the stock data files, but it's very easily detected in for instance the BM.

It's as if the accuracy of projectile weapons( possibly also beam weapons, or even all weapons ? ) decreases the higher up you put the time compression. It's especially bad when missiles are involved, since this problem renders point-defense useless.

Well, clearly the Xiati's temporal technology is more powerful than we previously thought.

---
"No greater love hath a man than he lay down his life for his friend. Not for millions, not for glory, not for fame... for one person. In the dark. Where no one will ever know or see"

Jack.

Actually, if you can confirm that with proof, post it in the bug thread. That's a tough one to catch and I haven't seen anything on it thus far, so it might be a new bug.

"Once you have tasted flight, you will forever walk the earth with your eyes turned skyward, for there you have been and will always long to return." ~Leonardo DaVinci

Double post.

I definitely saw that speed affected combat results. I was using "kamikaze" drones against an enemy's satellites. Half the time the drones just flew up and hovered above the satellite at 1X speed. But if I put it on 8X the drone hit the satellite 90% of the time.

I was using the 1.35 patch.