View Issue Details

IDProjectCategoryLast Update
0021536AI War 2[All Projects] Bug - GameplaySep 14, 2019 2:07 pm
Reporterwm46Assigned ToBadgerBadger 
Severitymajor 
Status resolvedResolutionreopened 
Product Version0.888 Astro Examination 
Fixed in Version0.890 Lighting and Darkness 
Summary0021536: Ships decolliding to odd places when traveling through wormholes
DescriptionShips 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.
TagsNo tags attached.

Relationships

related to 0021538 resolvedx4000Bughunter Stacks still interfere with stances (FRD, etc) 
related to 0021522 resolvedx4000Bughunter Decollision problem with queued moves 

Activities

x4000Bughunter

Aug 28, 2019 10:51 am

administrator   ~0052654

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.

Zoreiss

Aug 28, 2019 10:28 pm

reporter   ~0052662

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)

BadgerBadger

Aug 29, 2019 12:38 am

manager   ~0052663

Yeah, he's asking if you can retry once .885 comes out.

wm46

Aug 31, 2019 11:15 am

reporter   ~0052715

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?

BadgerBadger

Aug 31, 2019 11:32 am

manager   ~0052716

WM, do you have a save game that makes it easy to reproduce this?

wm46

Aug 31, 2019 1:18 pm

reporter   ~0052718

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)

BadgerBadger

Aug 31, 2019 4:11 pm

manager   ~0052720

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

x4000Bughunter

Sep 3, 2019 9:05 pm

administrator   ~0052794

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.

BadgerBadger

Sep 3, 2019 11:22 pm

manager   ~0052808

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.

Asteroid

Sep 8, 2019 7:03 pm

reporter   ~0052924

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.

BadgerBadger

Sep 10, 2019 8:29 pm

manager   ~0052987

I've just pushed some code that changes the wormhole traversal logic. See if the problem reproduces on the next release

x4000Bughunter

Sep 11, 2019 10:36 am

administrator   ~0052994

Thanks!

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!

Asteroid

Sep 12, 2019 2:10 am

reporter   ~0053012

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)

x4000Bughunter

Sep 13, 2019 3:36 pm

administrator   ~0053093

Are these ships actually decolliding, or are they doing regular movements. When you see their orders, what does it say?

BadgerBadger

Sep 13, 2019 9:15 pm

manager   ~0053097

Last edited: Sep 14, 2019 2:15 am

View 2 revisions

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

BadgerBadger

Sep 14, 2019 12:45 pm

manager   ~0053102

Fixed! Decollision was using the cached destination of the ship from the first planet, which becomes stale once we get to the second planet.

Asteroid

Sep 14, 2019 2:07 pm

reporter   ~0053104

Kudos Badger, this bug was really maddening. What a relief!

Issue History

Date Modified Username Field Change
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