|
|
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. |
|
|
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 |
|
|
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 |
|
|
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! |
|
|
Still happens in .888 unfortunately, see attached screenshot and save where I caught some ships doing it red-handed. |
|
|
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! |
- Anonymous
