Would it be possible for you to see if you can replicate it using a windows standalone build? I believe android uses IL2CPP usually, so an IL2CPP windows build would be the closest.
I understand. I will give it a try.
1 Like
Thank you for your patience.
We have confirmed the build with Windows Standalone.
No error occurred.
The “script backend” is “Mono”.
Curious.
Would it be possible for you to try the following?
- Copy the com.arongranberg.astar package from your
/Packagesfolder to the/Assetsfolder, to make it editable. - Replace the BlockableChannel.cs script with this: using System.Diagnostics;using System.Threading;using Pathfinding.Util;usi - Pastebin.com
- Make an android build, observe the issue.
- Send me the player log file.
I understand. We are currently trying it out.
We will send you the log, but please understand that we will cut off the log if there are any confidentiality issues involved in its contents.
1 Like
Hmmm, I’m stumped.
The error no longer occurs.
It used to occur often before the modification…
I copied and pasted all the linked code in the BlockableChannel.cs modification, is this correct?
Sorry for not being able to help you.
Hmm. Likely the Debug.Log calls take so long that some other race conditions do not happen.
Try this one instead: using System.Diagnostics;using System.Threading;using Pathfinding.Util;usi - Pastebin.com
I’ve switched out all the Debug.Log calls with System.Console.WriteLine, which are a lot faster.
Understood.
It is almost midnight, so I will try tomorrow.
Thank you for your long consultation.
I will contact you again tomorrow.
1 Like
Dear, Mr. aron.
Thank you for yesterday.
System.Console.WriteLine did not output the log, so I made my own modifications to store the log in StringBuilder and output it all together before Close.
The logs have been uploaded.
Please take a look.
PlayerLog.txt (9.2 KB)
Hi
Thank you!
But are you sure you got all WriteLine calls? It looks like some are missing.
Also. Do you lock the StringBuilder before writing to it? The StringBuilder is not thread-safe, and there are a bunch of threads writing to it at the same time now.
Also, the logged timestamps looks really off… Not sure what’s going on there.
Ahh! I forgot to lock.
Some replacements may have leaked out of Console.WriteLine.
I’ll check again and try logging again.
And I’ll try to give the log a unique ID.
I have plans for today, so I’ll upload again tomorrow.
1 Like
Hi,
Thank you for your patience.
I have reacquired the log.
StringBuilder also used lock.
I checked the output log and the character output is cut off in the middle.
Perhaps it was interrupted as a result of the scene unloading being completed.
After deactivating all agents, I wait 5 seconds before unloading the scene…
I have cut out from the log anything that is not a Unity log, or anything that violates confidentiality.
Can you tell us anything from this log?
Also, the [1] in the log is a unique number that is numbered per PathProcessor.
Is there only one instance since only the log with number 1 is output?
PlayerLog.txt (2.5 KB)
Yes, there’s only 1 path processor.
Hmm, yeah that looks weird, with it being cut off like that. I also don’t see any of the log messages saying that it closed the queue. It just looks like it continued to calculate paths without even trying to stop…
That code is running in a separate thread, so it really shouldn’t.
I have tried to replicate this by running the package’s whole test suite on my android phone (pixel 6).
This test suite contains tests for reloading a scene many times.
However, I have not been able to replicate any kind of crash 
What happens if you place a large number of agents on a trial basis?
For example, 2,000 agents.
In my project, 2,000 agents are constantly on patrol.
When they reach their destination, after a few seconds of waiting, they start moving again toward a new destination.
Thus, a large number of agents are constantly looking for routes.
If there are many agents, they should be implemented in ECS, but due to project constraints, they cannot be used. I am very sorry and sad.
Yeah. Or at least I scheduled 3000 paths in a single frame, and unloaded the scene the next frame (when only about 300-400 paths had been calculated). I also tried with varying number of threads from 0 to 7.
The AI of the agent in my project uses Seeker.StartPath to perform the path finding.
In the end, there may not be a big difference in the processing content, but this is where it differs from my project.
Oh, Sorry, I forgot to report that we use RVOController.
A slightly modified version of the sample SimpleRVOAgent.cs is used.
Neither of those things should have any impact on this…
I understand you might not want to share your project with me, but would it be possible to talk over discord to debug this?
Sorry, no sharing of projects.
Discord conversations are allowed.
I was able to join Discord.
The user name is the same.