[cloud]

Example: Looking to find entities with animations that don't equal -1, so you would invoke a method that would make the next method call do the exact opposite or something. Typing super quickly as I'm in a rush and this implementation I proposed is shit but yeah, the point stands that it's something useful. Gotta run.

 

[party]

Excellent idea, I'll tag in @Vap...

Joking aside, isn't this the purpose of predicates?

 

[savior]

Good suggestion, @SlashnHax can you add this please?

 

[arbiter]

*previous method call

It's more standard. animations(-1).negate(). But @Party brings up a good point. Predicates handle this already. I'd rather keep the wheel re-invention to a minimum. Our wrapper methods should be used exclusively for simple things and Bot Authors should graduate to using Predicates once their needs are greater than the available convenience methods.

 

[slashnhax]

Good suggestion, @SlashnHax can you add this please?

I would if I could

Iirc, the QueryBuilders have an .accepts(T t) method, so a simple implementation would be to use that, in a similar way that Predicate's negate uses test.
Idk how efficient it would be though.

Edit: nvm I misread and thought you were talking about negating the entire query xD

 

[cloud]

*previous method call

It's more standard. animations(-1).negate(). But @Party brings up a good point. Predicates handle this already. I'd rather keep the wheel re-invention to a minimum. Our wrapper methods should be used exclusively for simple things and Bot Authors should graduate to using Predicates once their needs are greater than the available convenience methods.

Our convenience methods are not adequately convenient once they inconvenience me.

 

[slashnhax]

Our convenience methods are not adequately convenient once they inconvenience me.

What if you added MORE convenience methods? Like idsExcept() or namesExcept() : ^)

 

[arbiter]

What if you added MORE convenience methods? Like idsExcept() or namesExcept() : ^)

pls no
 

Our convenience methods are not adequately convenient once they inconvenience me.

Use a predicate. >.>

 

[cloud]

pls no
 

Use a predicate. >.>

We can't optimize order and implement elegant caching when a predicate is used, thus defeating the purpose of us lazily evaluating queries.

 

[arbiter]

Sure we can by allowing the user to specify what data the predicate tests by as an Enum... argument. It would yield a more robust solution anyway. @Vaped


Sent from my iPhone using Tapatalk

 

[arbiter]

GameObjects.newQuery().filter(() -> ..., GameObject.FilterType.ID, GameObject.FilterType.MODEL)


Sent from my iPhone using Tapatalk

 

[arbiter]

We could then use these FilterTypes on a 1-X intensity scale to prioritize filtering. We could also allow devs to provide their own intensity level when our defined ones aren't sufficient.


Sent from my iPhone using Tapatalk