-
Notifications
You must be signed in to change notification settings - Fork 244
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
Wander.java default timepiece #80
Comments
Just curious, what's your use case? |
I'm running a few different agents in a game. Each agent has their own timepiece because each agent runs on their own update loop and they do not depend on one another. The use case could be that there is a world that runs on a timepiece and then two agents that run on their own faster or slower timepieces. I'd imagine being able to have multiple timepieces would be essential in simulations. |
hi i added an overloading constructor that allows an addition of specified timepiece to the Wander.java class. this is my first ever contribution to any real project so please give feedback if there are any issues with the changes
hi i added an overloading constructor that allows an addition of specified timepiece to the Wander.java class. this is my first ever contribution to any real project so please give feedback if there are any issues with the changes
possible fix to issue libgdx#80
i took into account that i shouldn't change the static timepiece in the GdxAI class so i gave very wandering option its own timepiece based on the GdxAI class while having an overload constructor that would allow a different timepiece if needed.
Please ensure you have given all the following requested information in your report.
Issue details
Wander.java uses the default timepiece which limits its usage.
Reproduction steps/code
Run 2 agents in a wandering simulation separately and concurrently. Assume they need their own timepiece due to different simulation parameters
Both agents use the same timepiece which may be an unwanted behavior.
Version of gdx-ai and/or relevant dependencies
Current
Solution: Allow users to pass in a timepiece reference during construction or set it later on.
The text was updated successfully, but these errors were encountered: