Improve Abstract Instances and FGBuildable #268
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At least in the modding environment, trying to use abstract instances would crash the editor quite often, and compiling blueprints that use abstract instances would always crash the editor. Looks like the crashes happen because `StaticManager_PIE` is a global variable that stores pointers to UObjects, but is not an `UPROPERTY`. When the GC kills those UObjects, the pointers in the global variable become dangling pointers without warning. Make abstract instance managers clean up global state when destroyed, and use `IsValid()` to avoid returning UObjects that are about to get killed (as this will result in unpredictable undefined behaviour). Tested in PIE in the modding environment, this allows seeing abstract instances in the editor previews (blueprint and level editor) as well as in PIE worlds. No crashes observed. FIXME: It is likely that crimes against UE were committed in here... TODO: There seems to be a bug somewhere that makes abstract instances in editor worlds get duplicated for some reason, but it does not seem to cause issues? NOTE: This also adapts the non-editor code path accordingly, as these problems could also occur there. However, these changes have not been validated. Signed-off-by: Angel Pons <[email protected]>
Be a bit more paranoid when handling abstract instances to avoid NULL pointer dereferencing. Checking whether `this` is NULL gets optimised out by most compilers (a NULL `this` is undefined behaviour), so drop the checks as they are misleading. Define the `LogBuilding` log category to log a single error, but also to allow using some inline functions defined in base game headers. If the log category is not defined, using said inline functions causes a build-time error. Signed-off-by: Angel Pons <[email protected]>
Looking at the game's binaries, the root component of buildables has to default to static mobility. Otherwise, pre-placed buildings do not work properly in the editor. The pre-placed buildings in ExampleLevel should no longer be stuck at 0 (which is inside the starting cube), but the level needs to be resaved. Signed-off-by: Angel Pons <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See individual commit messages for information.