View Issue Details
ID | Project | Category | Date Submitted | Last Update | |
---|---|---|---|---|---|
0024459 | AI War 2 | Bug - Gameplay | Feb 21, 2021 4:05 pm | Jul 13, 2021 1:39 pm | |
Reporter | Ryulong | Assigned To | Chris_McElligottPark | ||
Status | resolved | Resolution | fixed | ||
Product Version | Beta 2.744 Scourge Industries, Inc | ||||
Fixed in Version | Beta 3.310 Engineering Intelligence Injection | ||||
Summary | 0024459: Spurious engineer movement orders | ||||
Description | I 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 | ||||
Tags | No tags attached. | ||||
|
|
|
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. |
|
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. |
|
Confirmed, that is a strange one indeed. |
|
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. |
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 |