View Issue Details

IDProjectCategoryLast Update
0024459AI War 2Bug - GameplayJul 13, 2021 1:39 pm
ReporterRyulong Assigned ToChris_McElligottPark  
Status resolvedResolutionfixed 
Product VersionBeta 2.744 Scourge Industries, Inc 
Fixed in VersionBeta 3.310 Engineering Intelligence Injection 
Summary0024459: Spurious engineer movement orders
DescriptionI have some engineers on Aalst I'm trying to park in the northeast of the map. Thing is, they keep moving off somewhere to the southwest. If there were tachyons on this planet, it would be a real problem.

The tooltip doesn't say they're decollision orders. What is making them move? Do I have to contact HR about substance abuse?

~Ryulong
TagsNo tags attached.

Activities

Ryulong

Feb 21, 2021 4:05 pm

reporter  

drunk engineers.save (728,683 bytes)

Strategic Sage

Feb 23, 2021 1:11 pm

reporter   ~0060612

Why the engineers want to go where they do I don't know, but you have Engineers Auto-Work set to On. When that's on, Engineers are autonomous unless you've given them a specific order. In this case, they arrive at the spot you want them in the system and move because they've finished your task, and their own logic takes over at that point.

Ryulong

Feb 24, 2021 2:20 pm

reporter   ~0060636

I just tried toggling off engineer auto-work and they still insisted on moving to the southwest. They're all moving to slightly different coordinates.

I had a similar issue with raid frigates in this game, but I didn't make a save for it and haven't been able to reproduce it yet.

Strategic Sage

Feb 24, 2021 3:00 pm

reporter   ~0060638

Confirmed, that is a strange one indeed.

Chris_McElligottPark

Jul 13, 2021 1:39 pm

administrator   ~0062367

Thanks!

* The "Guarding" field on units been renamed to GuardedUnit.
** This may or may not mess with some mods, but we're trying to clear up some semantics and also verify where everything is being used, since misuse internally was leading to some bugs.
** The "GuardingOffsets" list field on units has been renamed to GuardOrPatrolOffsetPoints for the same reason. This has multiple uses, and in the end we are keeping those, but making some other changes.
** The NextGuardingOffsetIndex field on units has been renamed to NextGuardOrPatrolOffsetPointIndex, which again makes that way more clear.

* Various cleanup and fixes related to guarding units and so on:
** When serializing a guarded unit, it no longer serializes dead or missing ones.
** When deserializing a guarded unit from disk, it therefore now complains about dead or missing ones. When deserializing on an MP client, it no longer overwrites the ID with blank if it can't find it, though. This is an order of operations thing, potentially.
** When guards are freed by an alarm, it is now more explicit about freeing patrollers that have no central unit they are guarding, if that's even possible (it may not be, but no chances).
** When AddToNewPlanet() is called, it now clears all of the guard and patrol information. Badger had discovered that this was the source of some insanity with engineers running off to places they should not.
** There is a new IsMobileAndHasRepairOrAssistConstructionFlowsOrIsMobileMeleeUnitfield used for things that would need a "return to" point during pursuit mode. Mainly engineers and combat factories and similar. The GuardOrPatrolOffsetPoint is now only set for units where that is true when the player gives a move order. This is more efficient in general, and leads to not having some strange data in there for other types of units.
*** It turns out this is also needed for mobile melee units belonging to players.
** During decollision orders, it was assigning the engineer "return to" point, which was a very strange thing and was probably the root of the original problem with them returning to a decollision-like coordinate in the first place. Of course we don't want that in there in general with them moving between planets (and that was already taken care of above), but this certainly didn't help and might have let some issues squeak through, just more rarely.
** Added moves_back_after_being_norrised="true" as a replacement for the tag "MovesBackAfterBeingNorrised". This is a lot more efficient to check on units.
** Overall things here were not as dire as they could have been, but this should correct some of the issues that people were observing with engineers being a bit looney at times. And if there were other really rare edge cases, this should also catch those.

Issue History

Date Modified Username Field Change
Feb 21, 2021 4:05 pm Ryulong New Issue
Feb 21, 2021 4:05 pm Ryulong File Added: drunk engineers.save
Feb 23, 2021 1:11 pm Strategic Sage Note Added: 0060612
Feb 24, 2021 2:20 pm Ryulong Note Added: 0060636
Feb 24, 2021 3:00 pm Strategic Sage Note Added: 0060638
Jul 13, 2021 1:39 pm Chris_McElligottPark Assigned To => Chris_McElligottPark
Jul 13, 2021 1:39 pm Chris_McElligottPark Status new => resolved
Jul 13, 2021 1:39 pm Chris_McElligottPark Resolution open => fixed
Jul 13, 2021 1:39 pm Chris_McElligottPark Fixed in Version => Beta 3.310 Engineering Intelligence Injection
Jul 13, 2021 1:39 pm Chris_McElligottPark Note Added: 0062367