[Updated on: Wed, 22 March 2006 04:50]

Report message to a moderator

Ptolemy wrote on Wed, 22 March 2006 10:49

FEATURE: A fleet targeting another own fleet does not move. This can happen when 1 (or more) fleets at the same location target a fleet also at the same location. If a fleet at location x targets another own fleet at location x with the intention of going to the same location as the targeted fleet, then the targeted fleet is split / merged so that the original fleet ID has changed, the targeting fleets target becomes it's own fleet ID and the fleet will not move on the next turn. Example: Fleet 12 and fleet 34 at the same location. Fleet 12 targets fleet 34. Fleet 34 is manually split / merged (or simply merged with another fleet at the same location) and now becomes fleet 25. Fleet 12's target is now set as Fleet 12 and on the next turn Fleet 12 remains at the same location. Fleet 25 has moved where it was intended. NOTE: If fleets 12 and 34 are at different locations, the split / merge will cause the Fleet 12 target to be changed to the new fleet ID. Fleet 12 will go to the location of the new fleet ID.

This seems unrelated to the "stuck" bug, and I hope it won't interfere with possible foreign fleets targeting any of the incumbents, either.

It would indeed seem minor if not for the amount of split/merging some games/races endure. Great work!

Report message to a moderator

[Updated on: Wed, 22 March 2006 05:52]

Report message to a moderator

Ptolemy wrote on Wed, 22 March 2006 11:51

The obvious solution to avoid this problem altogether is to assign fleets their destinations and not give them other fleets to follow except in very predictable circumstances.

Which might have the unfortunate side effect of doing away with the best part of tactical skirmishing so far possible in Stars!.

Report message to a moderator

Report message to a moderator

gible wrote on Wed, 22 March 2006 12:21

This is only going to be a problem if it happens when targetting enemy fleets tho. otherwise, its kinda your own fault.

Of course, now that the problem is known to exist and its mechanics are understood, it should be routine to avoid. Just one more of these MM chores we all love.

Assuming it is a pure UI bug and an enemy can't exploit it to escape pursuit. What if you have your chasers at the same location that, say, some enemy freighters that survived battle, and he changes their fleet ID before fleeing?

Report message to a moderator

[Updated on: Thu, 23 March 2006 11:58]

Report message to a moderator

Having looked at the turns in question, I'm beginning to think that this is definitely a Fleet ID related bug...

Having looked at the turn myself, the Fleet ID's associated with the problem do not exist when using my copy of Stars!

Report message to a moderator

Report message to a moderator

Ptolemy wrote on Thu, 23 March 2006 18:01

if the fleets had been given the planet as the designated destination instead of some other fleet as a destination, the problem would not have happened.

We don't actually know that for sure.

Report message to a moderator

I'd like to shed some light on the "fleets not moving" situation in the Armistice Too game.

Two moving fleets at Deep Space points x and y target a moving fleet, which is heading towards a planet... point z.

Everything is going to plan. Until the next turn, when the fleets positioned at x and y refuse to move, despite no change to their orders.

The only discernable changes of circumstances are as follows;

The followed fleet at planet z is now stationary.
The fleets at x and y have been targetted by multiple fleets of enemy vessels.

I think this second point is key, and ties quite nicely in with the "stuck fleet" bug... although that stipulates that enemy fleets do not trigger the aforementioned bug.

Bear with me - here come some numbers;

The attacked fleets belong to Race#8
The attacking fleets belong to Race#5

Both attacked fleets are trying to rendez-vous (not merge - and no other screwy orders) with the stationary fleet of the same race at point z, which is Fleet#311

Fleet#11 has orders to move and attack Fleet#449
Fleet#s 97, 8, 18, 88, 97, & 108, are set to move and engage with Fleet#487

Note the low Fleet #s of Player#5 in comparison to all of Player#8's fleets.
Also note that Player #8's fleets at x and y hold higher Fleet#s than the stationary fleet at z.

I believe these are the key points.
I'd be grateful if someone could analyse similar bugs for these patterns as and when they occur, or if someone could run a few testbeds that would be nice!

I don't want to look at another turn for a while...

Report message to a moderator

Storm wrote on Wed, 29 March 2006 20:05

The only discernable changes of circumstances are as follows; The followed fleet at planet z is now stationary. The fleets at x and y have been targetted by multiple fleets of enemy vessels.

Hhmm. I hadn't included the targeted fleet changing from moving to stationary in my tests. This bug gets more and more interesting...

Quote:

I think this second point is key, and ties quite nicely in with the "stuck fleet" bug... although that stipulates that enemy fleets do not trigger the aforementioned bug.

And in fact I haven't been able to reproduce the bug using targeting enemy fleets. Perhaps others have been luckier?

Quote:

The attacked fleets belong to Race#8 The attacking fleets belong to Race#5

I didn't find race # affected the tests.

Quote:

the stationary fleet of the same race at point z, which is Fleet#311 Fleet#11 has orders to move and attack Fleet#449

Tested that situation, too (not with the exact fleet IDs, tho) and found nothing.

Quote:

Fleet#s 97, 8, 18, 88, 97, & 108, are set to move and engage with Fleet#487

There's a repeated fleet ID there. Typo?

Quote:

Also note that Player #8's fleets at x and y hold higher Fleet#s than the stationary fleet at z.

As per the "stuck" bug workaround. That wasn't even necessary once their target had stopped moving and was in no risk of getting stuck.

Quote:

I believe these are the key points.

Me too, but so far, I haven't been able to reproduce the damn bug.

Report message to a moderator

Report message to a moderator

multilis wrote on Thu, 30 March 2006 21:54

Hopefully host or neutral party to game can get hands on enough backup files and race passwords (if tinkering useful) to be able to regenerate the turn to learn more.

I have them here.
I'm just waiting 'til the weekend 'til I have time to do anything.

No more Stars! at work for me!

Report message to a moderator

Storm wrote on Fri, 31 March 2006 00:23

multilis wrote on Thu, 30 March 2006 21:54 Hopefully host or neutral party to game can get hands on enough backup files and race passwords (if tinkering useful) to be able to regenerate the turn to learn more. I have them here. I'm just waiting 'til the weekend 'til I have time to do anything.

The more I test for it, the more I'm convinced the darn thing is random.

But yes, it will be the actual game files and the actual re-gen which will prove it.

Quote:

No more Stars! at work for me!

Oh my. You didn't actually get caught, did you?

Report message to a moderator

m.a@stars wrote on Fri, 31 March 2006 02:19

The more I test for it, the more I'm convinced the darn thing is random. But yes, it will be the actual game files and the actual re-gen which will prove it.

I'm going to do a vanilla regen, which should yield exactly the same result.
Then I'll start tweaking a little bit, to see at what point it mends...

Quote:

Quote: No more Stars! at work for me! Oh my. You didn't actually get caught, did you?

Yes. Official Written Warning.
Despite all the extra "free" work I do for them, apparently it's a misuse of work equipment.

I'm going to arrive at work on Monday with a fully armed Nubian, and hand in my resignation...

Report message to a moderator

Storm wrote on Fri, 31 March 2006 09:33

I'm going to do a vanilla regen, which should yield exactly the same result. Then I'll start tweaking a little bit, to see at what point it mends...

I'm *extremely* curious to know the results you get.

Quote:

Yes. Official Written Warning. Despite all the extra "free" work I do for them, apparently it's a misuse of work equipment.

Shame on them.

Quote:

I'm going to arrive at work on Monday with a fully armed Nubian, and hand in my resignation...

I would suggest you use a missile design, 2.5 moves and *retreat* orders.

Report message to a moderator

Storm wrote on Wed, 29 March 2006 20:05

I'd like to shed some light on the "fleets not moving" situation in the Armistice Too game.

Ok ... more about the arm2 bug ... I got the backup files and have been testing for about an hour now.

The situation:

Fleet #311 is at planet, NOT moving.

Same race fleet #449 is moving towards #311 at warp5 (17.0ly), target is the fleet, NOT the planet.
Same race fleet #487 is moving towards #311 at warp6 (26.87ly), target is the fleet, NOT the planet.
(no orders at destination, I tested "merge with fleet but that had no impact on results)

All enemy interceptors start at the same spot and are less than 16ly from #311, so should reach the target at warp4. They are also less than 16ly from their targets (#449 and #487) but are set to warp10.

Now what happens is that fleets #449 and #487 are intercepted BEFORE they can move themselves. The battles occurs where those two fleets were the previous turn. That does not make sense.

In case fleets #449 and #487 target the planet instead of the fleet, both fleets _and_ enemy interceptors arrive at the planet ...

... so far so good ...


HOWEVER ... this is getting even better.


I played with the speed settings of the interceptors.


Interceptors set to: (real game situation as above)
warp10 to #449 -> they intercept the target BEFORE the targets move
warp10 to #487 -> they intercept the target BEFORE the targets move


Interceptors set to:
warp9 to #449 -> same, they intercept the target BEFORE the targets move
warp9 to #487 -> same, they intercept the target BEFORE the targets move


Interceptors set to:
warp8 to #449 -> same, they intercept the target BEFORE the targets move
warp8 to #487 -> end up at #311 location !!!


(Here is an opening for abuse! I haven't figured it out yet, but here is proof that enemy fleet speeds can interfer with the fleet movements of another race. At least as the other player is targetting fleets, which is very likely with sweeping/counter-sweeping ... A quick test gave a vague impression that for this abuse to work the target fleet actually have to be in range of the enemy interceptor that is trying to stop the fleet in his tracks.)


Interceptors set to:
warp7 to #449 -> end up at #311 location !!!
warp7 to #449 -> end up at #311 location

(assuming warp6 same)

Interceptors set to:
warp5 to #449 -> end up at #311 location
warp5 to #487 -> end up at #311 location

(The next one I like even more. )

Interceptors set to:
warp4 to #449 -> end up at 11.31ly from their starting location, they did NOT travell the full 16ly, they are at 16.3ly from where target was previous turn
warp4 to #487 -> end up at 7.7ly from their starting location, they did NOT travell the full 16ly, they are at 21.21ly from where target was previous turn


Note: only one enemy interceptor has to have a "wrong" speed. 5 interceptors coming from same spot with only one warp10 speed is enough to effectively stop the fleet of the other race.

mch

Report message to a moderator

Micha wrote on Tue, 11 April 2006 16:37

In case fleets #449 and #487 target the planet instead of the fleet, both fleets _and_ enemy interceptors arrive at the planet ...

Phew. So there's an easy "counter" once you know what has happened, and an almost-straightforward regen can indeed fix things.

Quote:

I played with the speed settings of the interceptors.

Interesting. I tested with interceptors being able to arrive both to the target fleet of their targets and to their targets themselves, but never got either the weird results when "overshooting" neither the apparently unrelated bug when "undershooting".

Quote:

Interceptors set to: (real game situation as above) warp10 to #449 -> they intercept the target BEFORE the targets move warp10 to #487 -> they intercept the target BEFORE the targets move

That would be the most frequent set-up, indeed...

Quote:

Interceptors set to: warp9 to #449 -> same, they intercept the target BEFORE the targets move warp9 to #487 -> same, they intercept the target BEFORE the targets move Interceptors set to: warp8 to #449 -> same, they intercept the target BEFORE the targets move warp8 to #487 -> end up at #311 location !!!

It would seem something is trying to account for the fact that those fleets will actually converge all at the same spot, but perhaps the same trap which triggers the infamous "stuck" bug is lurking there and some fleets get bypassed during the move phase.

Quote:

[i](Here is an opening for abuse! I haven't figured it out yet, but here is proof that enemy fleet speeds can interfer with the fleet movements of another race.

The conditions seem quite restricted, but I'd say it has a devastating potential, indeed.

Worse, it seems actual ability to reach target matters less than actual speed, since w5 and above reach #311 but only w8 and above trigger the bug. What can possibly make w8 and above so special?

Unless it was that these higher speeds guaranteed the targeted fleets couldn't evade interception, and that's indeed what triggers some "special case" code or other, that is...

Quote:

Interceptors set to: warp4 to #449 -> end up at 11.31ly from their starting location, they did NOT travell the full 16ly, they are at 16.3ly from where target was previous turn warp4 to #487 -> end up at 7.7ly from their starting location, they did NOT travell the full 16ly, they are at 21.21ly from where target was previous turn

Well, now this one makes absolutely no sense. What could possibly be causing those swift interceptors to fail to travel their assigned path?

Quote:

Note: only one enemy interceptor has to have a "wrong" speed. 5 interceptors coming from same spot with only one warp10 speed is enough to effectively stop the fleet of the other race.

I'd say there's a loop somewhere which can "leave for later" some complex cases while the rest of the fleets are moved. Unfortunately, some of those "delayed" fleets are then either completely skipped in the end or assigned to some temporary coordinates with no further calculations at all.

I'll be re-testing tonight with a generic testbed to try and shed more light into this ever-more-confusing situation.

Update: I opened the same testbed that last week failed to misbehave, split a single nubian from the pursuer fleets and set its warp to 10, thereby guaranteeing interception no matter where the slow-moving target went. And WHAM, here's Mr. Bug in all its ugly glory, freezing the enemy fleet in place.

More tests to follow, but it seems the Gods^H^H^H^H Jeffs didn't do such a perfect job, after all.

[Updated on: Tue, 11 April 2006 20:25]

Report message to a moderator

Report message to a moderator

mazda wrote on Tue, 11 April 2006 18:28

Sounds similar to the effect of when 3 ships target each other in a circular pattern. In this case the third fleet is not moving or targetting anything, but the code might think that it has to resolve a circular scenario for some reason (e.g. in the first pass all 3 ships end up at the same point, so it goes back and uses the step method ?)

My thoughts, too.

I wonder if the "step" method is faulty, then.

Quote:

I don't think it is as random as m.a.stars is trying to paint.

Random? The Gods forbid. I've spent two bloody weeks trying to prove the contrary!

In case you wondered, fleet *speeds* weren't suggested as possible culprits by anyone at the time my comment was posted, and that was after some extensive and unfortunately unconclusive testbedding.

Quote:

There appears to be some "well-defined" rules in this bug. (i.e. the distance over which this happens is completely linked to the differential in speeds)

Which I hope to confirm in the next few hours.

Update: preliminary tests seem to confirm there's some special case in the code triggered when there's guarantee of interception. Since the "main" execution path seems bug-free, I'd guess this kind of snafu could be patched out by just disabling the check for the special case itself, at perhaps some negligible performance cost.

Quote:

One solution is already stated - don't target stationary ships.

Too drastic. Leaves out too many tactical options for both sides.

Quote:

Another way to avoid interception should be to go as fast as possible back to the stationary ship - the faster ship got back to the planet more often.

I'd suggest that myself unless minefields or fuel were a concern.

Even so, in some instances the bug might be triggered anyway, as you might not know about all possible interceptors.

[Updated on: Wed, 12 April 2006 04:24]

Report message to a moderator

Definately a PIA bug. If the stationary fleet were moving, would problem have still occurred? If it wouldn't have, then the bug is easily avoidable with no tactical loss.

m.a@stars wrote on Wed, 12 April 2006 02:57

I'd suggest that myself unless minefields or fuel were a concern.

Minefields isn't a worry as your speed for collision checks is treated as the minimum necessary to cover the distance travelled.

Fuel would still be an issue though (but from a 'real life' POV, moving slowly to gather fuel gives your opponent time to catch you before you reach your destination. From a game POV it irks me though )

Report message to a moderator

Dogthinkers wrote on Wed, 12 April 2006 00:03

Definately a PIA bug. If the stationary fleet were moving, would problem have still occurred?

I will test for that one, too. It might depend on the *guarantee* of interception in the new coordinates, but it might happen that the code involved was different and the bug is not triggered that way.

Report message to a moderator

mazda wrote on Tue, 11 April 2006 18:28

And there is some sense in it. A faster ship can catch a slower ship before the slower ship moves.

"Some" sense ... still ...

Quote:

Also, in the example, the effect at warp 8 is the correct way round - i.e. the faster ship escaped whereas the slower one didn't.

I think I figured out why, more in another post.

Quote:

One solution is already stated - don't target stationary ships.

Not really a solution. In another game my ally and I can across the same bug, sweepers were gathering back to an fleet as protection, no planet orbit was available, the main fleet was the target, no other option ... All sweepers were stuck and killed ... we were clueless at that point ... now we know what happened.

Quote:

Another way to avoid interception should be to go as fast as possible back to the stationary ship - the faster ship got back to the planet more often.

Minefields shouldn't be a problem like already mentioned they don't check against the actual speed used, but fuel is a problem ... DD sweepers usually don't have that much fuel to go on ...

Quote:

n.b. i) In the warp 4 case you have stated where the interceptors end up, but not the interceptees.

Either the interceptees get stuck or they arrive at the planet. In the warp4 case they where not stuck so the arrived at the planet as normal.

Quote:

n.b. ii) As an aside, what happens when 2 ships directly target each other ? I seem to recall they meet somewhere in the middle if they are far enough apart or going slow enough. But that might just be wishful thinking.

I'll leave that up to others.

mch

Report message to a moderator

Micha wrote on Tue, 11 April 2006 16:37

Storm wrote on Wed, 29 March 2006 20:05 I'd like to shed some light on the "fleets not moving" situation in the Armistice Too game. Ok ... more about the arm2 bug ... I got the backup files and have been testing for about an hour now. The situation: Fleet #311 is at planet, NOT moving. Same race fleet #449 is moving towards #311 at warp5 (17.0ly), target is the fleet, NOT the planet. Same race fleet #487 is moving towards #311 at warp6 (26.87ly), target is the fleet, NOT the planet. (no orders at destination, I tested "merge with fleet but that had no impact on results) All enemy interceptors start at the same spot and are less than 16ly from #311, so should reach the target at warp4. They are also less than 16ly from their targets (#449 and #487) but are set to warp10. Now what happens is that fleets #449 and #487 are intercepted BEFORE they can move themselves. The battles occurs where those two fleets were the previous turn. That does not make sense. In case fleets #449 and #487 target the planet instead of the fleet, both fleets _and_ enemy interceptors arrive at the planet ... ... so far so good ... HOWEVER ... this is getting even better. I played with the speed settings of the interceptors.

Some more information that might shed a light on why the speed settings have an influence.

#449 moving towards #311 at warp5 (17.0ly) and at 12.4ly from interceptors.
#487 moving towards #311 at warp6 (26.87ly) and at 14.14y from interceptors.

Quote:

Interceptors set to: warp8 to #449 -> same, they intercept the target BEFORE the targets move warp8 to #487 -> end up at #311 location !!! Interceptors set to: warp7 to #449 -> end up at #311 location !!! warp7 to #487 -> end up at #311 location

Now why does warp8 "fix" the bug for #487 but not for #449? Why warp7 for that one?

Easy!
Distance interceptor->#449 = 12.4ly + 25ly (speed of target =warp5) = 37.4ly
Distance interceptor->#487 = 14.14ly + 36ly (speed of target =warp6) = 50.14ly

...

With 37.4ly the target #449 is in range with warp7 where ever it decides to go, this speed is all that is needed, there is no "overshooting" so the bug is "fixed" and all goes normal.

With 50.14ly the target #487 is in range with warp8 where ever it decides to go, this speed is all that is needed, there is no "overshooting" so the bug is "fixed" and all goes normal.

If you go one warp faster than what is ONLY really needed ... BANG! BUG!



So it depends on speed of target as well ... Now I haven't tested yet with changing the speeds of the targets ... maybe there is some weirdness as the minefield calculation speed, ... to be investigated!

mch

Report message to a moderator