Home » Stars! 2.6/7 » The Academy » New item for the known bugs / features list
New item for the known bugs / features list |
Wed, 22 March 2006 04: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.
Ptolemy
[Edit - I still can't spell 'the' correctly]
[Updated on: Wed, 22 March 2006 04:50]
Though we often ask how and why, we must also do to get the answers to the questions.Report message to a moderator
|
|
| |
Re: New item for the known bugs / features list |
Wed, 22 March 2006 05:51 |
|
|
Well, as for the effects of enemy fleet targeting, that would run into the area of the split fleet dodge and how Stars! re-assigns the targetting based on boranium concentration. 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. The example I like for a reason for having a fleet use another fleet as a target is for freighters getting minerals from remote miners. In this type of case, the freighters have repeat orders and simply follow the mining fleet if it is moved and pick up the minerals.
I use the philosophy of Keep it Simple Stupid in my own targeting and assignments of fleet destinations since overloading 16 bit code is fairly easy and then unpredictable results can happen. I have yet to see a case where a fleet I assigned a specific destination to, did not get there, or keep working on getting there - which is why this new free ramscoop error has me quite curious.
Ptolemy
[Updated on: Wed, 22 March 2006 05:52]
Though we often ask how and why, we must also do to get the answers to the questions.Report message to a moderator
|
|
| |
Re: New item for the known bugs / features list |
Wed, 22 March 2006 06:21 |
|
|
This is only going to be a problem if it happens when targetting enemy fleets tho. otherwise, its kinda your own fault.
Report message to a moderator
|
|
| |
Re: New item for the known bugs / features list |
Wed, 22 March 2006 07:30 |
|
|
Quote: | 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?
|
This is what is commonly referred to as the split fleet dodge if he sends those freighters as diferrent fleets in different directions - which many people consider as a perfectly legitimate tactic for avoiding fleet destruction. If the fleet remains the same and only the ID changes, your fleet would follow as normal. This condition I have tested ONLY affects one's OWN fleets.
Ptolemy
[Updated on: Thu, 23 March 2006 11:58]
Though we often ask how and why, we must also do to get the answers to the questions.Report message to a moderator
|
|
| |
Re: New item for the known bugs / features list |
Thu, 23 March 2006 12:01 |
|
|
The only way to actually examine the turns in question for this particular case that m.a. is referring to would be to get the .m and .x files for the previous turn from AH. The files for the 2 yeasr old turns may also shed some light. However, the basic fact that 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.
Ptolemy
Though we often ask how and why, we must also do to get the answers to the questions.Report message to a moderator
|
|
| |
Re: New item for the known bugs / features list |
Wed, 29 March 2006 13:05 |
|
|
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...
** Storm **
"Yeah... but... Jar Jar makes the Ewoks look like f***ing Shaft!"
Report message to a moderator
|
|
|
Re: New item for the known bugs / features list |
Thu, 30 March 2006 03:08 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
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.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
|
Re: New item for the known bugs / features list |
Thu, 30 March 2006 15:54 |
|
|
Quote: | so far, I haven't been able to reproduce the damn bug.
|
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.
Only so many ships have orders to chase other ships, and one of these is likely setting the beast off.
Report message to a moderator
|
|
| | | | |
Re: New item for the known bugs / features list |
Tue, 11 April 2006 10:37 |
|
Micha | | | Messages: 2342
Registered: November 2002 Location: Belgium GMT +1 | |
|
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
|
|
|
Re: New item for the known bugs / features list |
Tue, 11 April 2006 11:13 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
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]
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| |
Re: New item for the known bugs / features list |
Tue, 11 April 2006 12:57 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
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]
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| | |
Re: New item for the known bugs / features list |
Wed, 12 April 2006 02:20 |
|
Micha | | | Messages: 2342
Registered: November 2002 Location: Belgium GMT +1 | |
|
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
|
|
|
Re: New item for the known bugs / features list |
Wed, 12 April 2006 02:42 |
|
Micha | | | Messages: 2342
Registered: November 2002 Location: Belgium GMT +1 | |
|
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
|
|
|
Goto Forum:
Current Time: Wed Jun 05 16:03:23 EDT 2024
|