-
Notifications
You must be signed in to change notification settings - Fork 70
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
Entity Avoidance Feature #281
Entity Avoidance Feature #281
Conversation
Updated parkour schematic to include two new courses Added a full list of entities that do not prevent building Reorganized a few things
The unit tests are done. I also did some performance testing and it takes ~10ms to index and path with 10,000 entities that have a 1x2 bounding box loaded, so I think it will be alright. |
Changed the entIntersections dict to be indexed by a string entIntersections['x,y,z'] = #ents Fixed over-weighting issue in parkour movement
bf903f6
to
bf7c33e
Compare
Changed passable ents and interactable blocks to be modifiable fields. Added new `entsToAvoid` field. Useful for legacy or modded additions from user. Moved `updateIntersections()` into movements. `entIntersections` only needs to be externally accessed when necessary.
On small thing. Can you rename the things like ents to entities? I say the confusion caused by having to think about what this variable does is not outweigh by the few characters you save. Plus all other variables are named in full length too these would be the only one doing it differently. For variables that are used in closed scope this is not that big off an issue. But public API facing properties should be kept consistent and readable. |
Also another thing I just noticed. There is API documentation in the readme. Can you add the changes you made to the code to the API documentation? Should be ready to be merged then. |
Continuation of #155
As requested, I made it so that the entities/intersected blocks are indexed before computing each path. The way it passes the indexed data to the Movements object in use is kind of ugly but, just using what already exists I couldn't think of a better way to do it.
I have tested this with 500+ entities and it seems to handle it no-problem but more extensive performance testing may be necessary.
I'm working on a basic internal test for checking that the feature is functional