You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 26, 2023. It is now read-only.
A central object for a player could store data, as well as configurations (if set per player), all by check types. The problem would be how to fetch those efficiently and as type-safe as possible.
A getData(CheckType) method would likely have to return an Object. In the context of overriding checks of the same type it might not be fun to have to check what object is returned (not sure we allow such anyway, but it might be needed for backwards compatibility in some cases).
Making the method return "the desired" type will probably demand passing a class or similar in order to be able to check and return null or invoke a registered factory-method or return an actually present object.
We could consider having getData(CheckType) as the "slow method" for such as command use rather, while we maintain a getData(Class) or similar for "fast" access, which then returns the desired kind of thing, depending on registration. Of course this does not do recursive checking, it is meant for direct lookup.
After all it is still open how to do the contract for data / configs within a central player data object: Unique classes for differing check types? Allow storing multiple classes per check type? Register arbitrary object factories and classes for a check type and receive an integer id and/or a fast-access object to use for getting data fast later, something like "DataHolder getFastAccess(CheckType checkType, Class dataType)"?
The DataHolder would be for storing it during runtime, raising the problem of what happens on data removal or adding a new component or removing one such that the factories have to change (could provide events + setting the factories to null-factories on unregistration, it would probably be advanced user anyway.).
Should make example implementations / interfaces, probably...
The text was updated successfully, but these errors were encountered:
I wonder if we can do something against duplicated names (NPCs that carry the same name as other player) also. Will Consistency checks also be implemented in NoCheat? They seem to do a pretty good job in NoCheatPlus.
This might be the next session :p - main question will be if to have unique data classes, or combinations of checktype + data or some general type object + data. An alternative can be to register data classes with a range of (check) type objects, so we can have different mechanisms to accessing all check-related data.
Another point to decide is if / how to use a base class for check data, in order to call things like onClearData(CheckType xy) or onPeriodicCleanup(CheckType yx), or if we allow setting certain policies for data types (DataBroker.setDataRemovalPolicy(Class<?> dataType, DataRemovalPolicy policy) and similar.
Then again we will have to consider having two-fold access (async + sync) ... store global data (in data broker, not in player data), if to have per-world data or just general data, and other side topics.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
A central object for a player could store data, as well as configurations (if set per player), all by check types. The problem would be how to fetch those efficiently and as type-safe as possible.
A getData(CheckType) method would likely have to return an Object. In the context of overriding checks of the same type it might not be fun to have to check what object is returned (not sure we allow such anyway, but it might be needed for backwards compatibility in some cases).
Making the method return "the desired" type will probably demand passing a class or similar in order to be able to check and return null or invoke a registered factory-method or return an actually present object.
We could consider having getData(CheckType) as the "slow method" for such as command use rather, while we maintain a getData(Class) or similar for "fast" access, which then returns the desired kind of thing, depending on registration. Of course this does not do recursive checking, it is meant for direct lookup.
After all it is still open how to do the contract for data / configs within a central player data object: Unique classes for differing check types? Allow storing multiple classes per check type? Register arbitrary object factories and classes for a check type and receive an integer id and/or a fast-access object to use for getting data fast later, something like "DataHolder getFastAccess(CheckType checkType, Class dataType)"?
The DataHolder would be for storing it during runtime, raising the problem of what happens on data removal or adding a new component or removing one such that the factories have to change (could provide events + setting the factories to null-factories on unregistration, it would probably be advanced user anyway.).
Should make example implementations / interfaces, probably...
The text was updated successfully, but these errors were encountered: