-
Notifications
You must be signed in to change notification settings - Fork 247
Fix adjacency error caused by dummy unit from drones/external factories #6863
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
Fixes adjacency error
This reverts commit ff70d4f.
|
Great catch on the missing call to I do not fully understand the context about UEF construction drones (from kennels), these generate calls to |
|
It is, but we have a "guard dummy" unit (zxa0003) which uses the The dummy is used to save assist orders onto the drone after a drone docks. |
| -- make sure we're both finished building | ||
| if self:IsBeingBuilt() or adjacentUnit:IsBeingBuilt() then | ||
| if self:IsBeingBuilt() or adjacentUnit:IsBeingBuilt() | ||
| or adjacentUnit.Blueprint.CategoriesHash["DUMMYUNIT"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the suggested logic the dummy unit should not have adjacency.
Whats the reason to put this check into Structure?
Why not to add OnAdjacentTo OnNotAdjacentTo to the Dummy class that would return?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^Second this suggestion. Keeping things modular means that any future changes/removals don't leave lingering logic in the base class. Additionally, as the original implementer of zxa0003 I'll say that I knew enough to get it working, but not enough to know all the details exhaustively. Somebody with more experience in the unit blueprints could remove the structure-ness of it and address the problem at the source (add a movement type, maybe?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not to add OnAdjacentTo OnNotAdjacentTo to the Dummy class that would return?
The error pops up in the script of the structure that is adjacent. Returning in the dummy class does nothing to prevent the adjacent structure unit script from running.
don't leave lingering logic in the base class
I agree, I'll try to find a different solution.
remove the structure-ness of it and address the problem at the source (add a movement type, maybe?).
I tried other motion types but the engine removes the assist order once the drone is attached to the SACU (and the dummy unit is finally attached indirectly to the SACU).
Fortunately, upon some investigation, it seems related to the "Attached" state of the unit, so we can do self:SetUnitState("Attached", false) in OnAttachedToTransport and then remove all the guard re-assignment behavior, since assist orders no longer get removed.
I haven't yet figured out how to deal with fatboy detaching its external factory when you give the dummy unit a motion type.
|
Now I understand the context more, the guard unit is introduced with: #6176 And it only applies to the construction pods of the (S)ACUs. The drones from Kennels do not use this class. They are 'regular' construction units. |
Description of the proposed changes
Fixes #6425.
Testing done on the proposed changes
The t2 mass fab is placed here so that it triggers the adjacency for the dummy unit of the fatboy. Using debug logging it shows that the dummy unit is ignored correctly.
You can also trigger the adjacency by having the UEF engineer SACU build any structures.
Checklist