I am testing a game shipping in the googleplay store trying to make the AI do a simple move to. I would really like it if someone could test it on their projects to let me know if it is an issue on my side or on the engine side that needs tweaking. Regardless, here’s the issue:
In PIE, when you load the main map, load a level or whatever, the AI pawns will wander as desired.
In packaged android builds, the AI either in the main map OR in a loaded level will stand still.
I tried rebuilding the nav mesh system through command AND C++, it did nothing.
I tried to rebuild manually levels. Also did not work.
I tried setting the nav meshes to dynamic, did not work.
I tried using AI controller with crowd avoidance and without, unsuccessfully.
I am not sure what else I can try to make this work.
Here’s for reference:
Using 4.27.3 source build of the engine to mod it for billing.
I went ahead and did more debugging.
I checked if the nav reloading was working and it is. So the nav itself is not the issue.
I checked if the defaults are set properly (use AI and use Wandering logic). This is also working right.
The part where it stalled was in the behaviour itself.
I did a couple more debugs which some worked and some failed.
I decided to add a pause before the AIC would start the behaviour and that did not work, or at least did not fix the issue.
So i started back from scratch with a new BB, BT and BTS and BTT.
I tried assigning the new AIC and using a simple BB and BT to just do a BTT_Spin. All this does is spin the pawn 10 degrees each time.
The AIC:
All seems to work as intended in this scenario.
The AIC works with the pawn and triggers the BT.
The BT works with the BB and the Pawn and makes the spin happen as intended.
So it seems all connections work.
When I substitute the Task with MoveTo, all else fails:
The radius is set to 500 and in PIE works as intended: the pawn wanders around.
In android, when running a debug text, it also shows the right number, so the radius variable is not the issue.
After testing it with the impure cast and using the alternate function to find a location, the node finds the location but the bool states false meaning requirements are not met.
I am not sure how to proceed further:
I managed to fix this and it was related to the settings. Apparently, when you toggle off the use main nav it will stay off forever and toggling back on doesn’t change the settings back. I discovered this when transplanting settings from another new project.
Well I thought I fixed it but the problem appears to be deeper.
When using SimpleMoveTo or AIMoveTo in blueprints, this works fine for movement.
But behavior tree moveTo or even Custom BT moveTo doesn’t work at all in Android whereas the other works.
I made a simple test:
SimpleMoveTo
AIMoveTo
BT, BB, Service to find random location
BT, BB, Service to find random location with values setting
BT, BB, custom MoveTo and Service
BT, no BB, custom MoveTo Task with Find location
All BT failed whereas the cases 1 and 2 worked in the same level with the same navigation and same methods of finding a location.
At this stage, I am willing to throw in the towel and to consider that BTs cannot use any form of movement nodes, either because they stall or cannot work at all.
I did do something interesting and created a custom moveTo task using this node
Navigation issues in packaged Android builds can be caused by various factors, so it’s essential to investigate the specific problem you’re facing. Here are some general steps you can take to troubleshoot and address navigation problems in your Android app:
Check Navigation Graph: Ensure that your navigation graph is set up correctly. Check if the destinations, actions, and the connections between them are accurately defined. Make sure that the correct fragments or activities are specified for each destination.
Resource Files: Verify that the XML resource files, including layout files and navigation resource files, are correctly configured. Ensure that IDs and references are accurate.
Proguard/R8: If you’re using Proguard or R8 for code shrinking and obfuscation, it might affect navigation. Make sure you have the necessary rules in your Proguard configuration file to keep your navigation components intact.
Runtime Errors: Check the Logcat for any runtime errors, exceptions, or warnings related to navigation. These messages can provide valuable information about what might be going wrong.
Deep Linking: If your app uses deep linking, ensure the deep links are set up correctly and match the navigation graph.
Dependencies: Verify that you have the required dependencies and versions for Android Jetpack Navigation components. Outdated or mismatched dependencies can lead to navigation issues.
Fragment Transactions: If you’re using Fragments, make sure that you’re handling fragment transactions correctly. Improper fragment management can lead to navigation problems.
Testing: Create a comprehensive test suite for your navigation components. Use instrumentation tests or UI tests to simulate user navigation and identify any issues.
Device and OS Compatibility: Test your app on different Android devices and versions to ensure that the navigation works correctly across various platforms.
Logs and Debugging: Use logging and debugging tools to trace the flow of your app’s navigation. This can help you pinpoint where the issue is occurring.
Community and Documentation: Consult relevant online communities, forums, and official documentation for Android app development. Others may have encountered similar issues and can provide insights and solutions.
Update Libraries: Ensure that all libraries and SDKs used in your project are current. Updates may include bug fixes related to navigation.
If you can provide more specific details about the navigation problem you’re facing, I can offer more tailored assistance.
I figured it out in the end and it was a blackboard issue.
I had forgotten this thread altogether since I moved away from android builds but basically here’s what happens:
Blackboards (BBs) only exist when Behavior trees (BTs) run.
In the editor and in development builds, the BB exists
In shipping builds, the BB does not just exist, you have to call it using a BT.
If you call the blackboard or get something out of it before it is instantiated, it returns max float values and chokes the BT.
The solution is to create a service that GETs the blackboard value before you trigger the selector of your BT.
Example:
I have an enum that has idle, patrol, attack.
I can have a selector with a condition “if enum == idle” do this.
However, this value exists in the BB and if you do not set it anywhere else in the BB or get it into the BB somehow, the BB value becomes null or invalid and the BT fails as a whole.
The only other work around is to use non-BT AI on constant loops or times that circumvents the need for the BT altogether, thus the BB.
