View Issue Details
|ID||Project||Category||Date Submitted||Last Update|
|0021536||AI War 2||[All Projects] Bug - Gameplay||Aug 27, 2019 11:32 pm||Sep 14, 2019 2:07 pm|
|Product Version||0.888 Astro Examination|
|Fixed in Version||0.890 Lighting and Darkness|
|Summary||0021536: Ships decolliding to odd places when traveling through wormholes|
|Description||Ships that go through wormholes have a tendency to decollide to the position of the entrance wormhole, except for on the other planet.|
Like the issue with ships teleporting to the other side of the planet that used to occur, except this time it occurs with decollision orders. Ships will properly appear at the wormhole exit, and then travel all the way across the planet before doing anything.
|Tags||No tags attached.|
This is now in for 0.885, can you test if it works?
* Fixed a potential cause of the bug where orders and stance could be lost on ships when a stack was being split or one ship in a stack died.
** Basically in the OnDeath logic we no longer need to clear orders at all.
* A HUGE amount of rework has been done with how orders are cleared from ships, and also regular move and decollision-move orders have been split out into two types.
** This lets us do things like clear just decollision orders but not other things, and we also no longer have a bunch of things referring to Rally orders, which haven't existed for a while.
** There may well be some bugs relating from this, but hopefully they are now easier to track down because the code is more sensibly-arranged for the current game design. It's possible that some things were previously working sometimes-but-not-always and will now work never, and that's actually preferable since we can then fix it to work always, once it's found.
** This needs lots of testing, relating to queuing orders and issuing orders of various sorts, and seeing that the AI doesn't do strange things with its own orders, etc, etc, etc.
** It's possible that this fixes the strange decollision logic when you queue a lot of move orders (that worked once upon a time, but has been broken since we revamped a bunch of the game code).
* Decollision-move orders are now explicitly dumped when a ship goes through a wormhole from one planet to another.
I can confirm that the transports go crazy sometimes after arriving at their destination from wormholes in the current patch (0.884). In this savegame, my transports juste came out of the wormhole and some of them have 8 move order queued that I never ordered them to do.
Transports going crazy .savemet (47 bytes)
Transports going crazy .save (1,178,073 bytes)
||Yeah, he's asking if you can retry once .885 comes out.|
0.855 - Ships still do this, occuring more often when coarse background simulation is enabled. With coarse simulation disabled, it's usually only 1-5 ships out of 400 per wormhole hop.
I think the fix needs to be done in decollision planning. Since decollision planning is over a period of frames, there should be some kind of check that the long range planet ID still matches up with the current planet ID before scheduling the game command.
I don't see any kind of planet ID checking in DecollisionPlanning.cs, and I don't know how game commands are handled. I see there's a planet ID attached to the decollision order command, but it doesn't do anything?
||WM, do you have a save game that makes it easy to reproduce this?|
Just select and send the fleets through any wormhole, I used Ersh when testing for myself.
Coarse Sim Off - https://youtu.be/39lPTg_h4-8
Coarse Sim On - https://youtu.be/VLzUZwXr7vk
123.save (692,450 bytes)
In theory this is checked for in the GameCommand handling:
int planetIndexEntityWasOnWhenSetToDecollide = command.RelatedIntegers[i];
if ( entity.Planet == null || entity.Planet.PlanetIndex != planetIndexEntityWasOnWhenSetToDecollide )
continue; //this entity changed planets, so skip it!
But apparently this check isn't adequate
||It probably was a command that was already given to them. When they go through a wormhole, I specifically destroy all of the decollision commands as well as the decollision coordinates; that's why I split out the decollision-move orders from regular-move orders. But apparently there's some case in the code where they make it through and it's not doing the clearing, or my clearing code has a typo.|
I'm not sure this is decollision per se. I think what's happening is this. I order a ship to go through a wormhole. The ship does. Then it winds up keeping the same "Move to Location" order, and starts flying toward where the Wormhole it just went through would be in the new planet.
ie If the wormhole from Murdoch to Old Murdoch is in the bottom left. I order a ship on Murdoch to go to Old Murdoch, where the destination wormhole is in the top right. Once on Old Murdoch the ships sometimes seem to keep their Move order and start moving toward the bottom left, where the source wormhole was.
Still experiencing this quite often in 0.887. I send a bunch of units through a wormhole, and once there a couple of them head straight for the opposite side of the system, getting slaughtered and waking up a slew of enemy units along the way.
It's one of the first things I noticed when I started playing, and it compounds the frustration from the absence of flexible control groups. You need to herd back those units to safety, but unless you permanently change your fleet hotkeys through the fiddly interface, you have no way of recalling the selection with a button.
||I've just pushed some code that changes the wormhole traversal logic. See if the problem reproduces on the next release|
Even more done on this:
* Decollision-move orders now track what planet they are tied to, and consider themselves as invalid if the ship with those orders is now on a different planet.
** There were a bunch of potential situations where a stale decollision order could potentially sneak through, and so keepiing track of this and invalidating the command at any point after all of them is hopefully the ultimate safety valve for this issue. If you still see ships doing anything strange after going through wormholes, please do let us know!
Still happens in .888 unfortunately, see attached screenshot and save where I caught some ships doing it red-handed.
008_PostWormholeNonsensicalMovement.savemet (63 bytes)
008_PostWormholeNonsensicalMovement.save (903,783 bytes)
||Are these ships actually decolliding, or are they doing regular movements. When you see their orders, what does it say?|
So I ran an experiment today where I reproduced the problem. Here is the order list as seen in EntitySimLogicImplementation::DoWormholeTraversal() for a unit that started flying to the wrong place
9/13/2019 7:10:12 PM Stingray #53198 Human Remnant on Trillian going through wormhole with 1 queued orders:
9/13/2019 7:10:12 PM 0: Order Wormhole related point (0,0) source HumanPlayer for planet Trillian
However once on the other planet I observed it flying off to where the wormhole was on the previous planet was with a Decollide order (per the entity hovertext).
Some sort of race? I'll need to add more debugging to see what's going on.
Edit: I have a theory to try tomorrow
||Fixed! Decollision was using the cached destination of the ship from the first planet, which becomes stale once we get to the second planet.|
||Kudos Badger, this bug was really maddening. What a relief!|
|Aug 27, 2019 11:32 pm||wm46||New Issue|
|Aug 28, 2019 10:02 am||x4000Bughunter||Assigned To||=> x4000Bughunter|
|Aug 28, 2019 10:02 am||x4000Bughunter||Status||new => assigned|
|Aug 28, 2019 10:51 am||x4000Bughunter||Status||assigned => feedback|
|Aug 28, 2019 10:51 am||x4000Bughunter||Note Added: 0052654|
|Aug 28, 2019 10:51 am||x4000Bughunter||Relationship added||related to 0021538|
|Aug 28, 2019 10:51 am||x4000Bughunter||Relationship added||related to 0021522|
|Aug 28, 2019 10:28 pm||Zoreiss||File Added: Transports going crazy .savemet|
|Aug 28, 2019 10:28 pm||Zoreiss||File Added: Transports going crazy .save|
|Aug 28, 2019 10:28 pm||Zoreiss||Note Added: 0052662|
|Aug 29, 2019 12:38 am||BadgerBadger||Note Added: 0052663|
|Aug 31, 2019 11:15 am||wm46||Note Added: 0052715|
|Aug 31, 2019 11:15 am||wm46||Status||feedback => assigned|
|Aug 31, 2019 11:32 am||BadgerBadger||Note Added: 0052716|
|Aug 31, 2019 1:18 pm||wm46||File Added: 123.save|
|Aug 31, 2019 1:18 pm||wm46||Note Added: 0052718|
|Aug 31, 2019 4:11 pm||BadgerBadger||Note Added: 0052720|
|Sep 3, 2019 9:05 pm||x4000Bughunter||Note Added: 0052794|
|Sep 3, 2019 11:22 pm||BadgerBadger||Note Added: 0052808|
|Sep 8, 2019 7:03 pm||Asteroid||Note Added: 0052924|
|Sep 10, 2019 8:29 pm||BadgerBadger||Status||assigned => feedback|
|Sep 10, 2019 8:29 pm||BadgerBadger||Note Added: 0052987|
|Sep 11, 2019 10:36 am||x4000Bughunter||Status||feedback => resolved|
|Sep 11, 2019 10:36 am||x4000Bughunter||Resolution||open => fixed|
|Sep 11, 2019 10:36 am||x4000Bughunter||Fixed in Version||=> 0.888 Astro Examination|
|Sep 11, 2019 10:36 am||x4000Bughunter||Note Added: 0052994|
|Sep 12, 2019 2:10 am||Asteroid||File Added: 2019-09-12 02_04_53-AIWar2 - Post wormhole nonsensical movement.png|
|Sep 12, 2019 2:10 am||Asteroid||File Added: 008_PostWormholeNonsensicalMovement.save|
|Sep 12, 2019 2:10 am||Asteroid||File Added: 008_PostWormholeNonsensicalMovement.savemet|
|Sep 12, 2019 2:10 am||Asteroid||Note Added: 0053012|
|Sep 12, 2019 2:11 am||Asteroid||Severity||minor => major|
|Sep 12, 2019 2:11 am||Asteroid||Status||resolved => new|
|Sep 12, 2019 2:11 am||Asteroid||Resolution||fixed => reopened|
|Sep 12, 2019 2:11 am||Asteroid||Product Version||0.884 The Helping Hat => 0.888 Astro Examination|
|Sep 12, 2019 2:11 am||Asteroid||Fixed in Version||0.888 Astro Examination =>|
|Sep 13, 2019 3:36 pm||x4000Bughunter||Note Added: 0053093|
|Sep 13, 2019 9:15 pm||BadgerBadger||Note Added: 0053097|
|Sep 14, 2019 2:15 am||BadgerBadger||Note Edited: 0053097||View Revisions|
|Sep 14, 2019 12:45 pm||BadgerBadger||Assigned To||x4000Bughunter => BadgerBadger|
|Sep 14, 2019 12:45 pm||BadgerBadger||Status||new => resolved|
|Sep 14, 2019 12:45 pm||BadgerBadger||Fixed in Version||=> 0.890 Lighting and Darkness|
|Sep 14, 2019 12:45 pm||BadgerBadger||Note Added: 0053102|
|Sep 14, 2019 2:07 pm||Asteroid||Note Added: 0053104|