API Changes:
- Remove
wrapped
field fromAdventureMessage
. - Remove many methods from
GameProfile
- not required.- Possibly remove
with
- usetoBuilder
to convert to a builder and edit in bulk. - Remove
withName
- changing the name of aGameProfile
is hardly ever going to be required. - Remove
withUUID
- changing the UUID of aGameProfile
is hardly ever going to be required.
- Possibly remove
- Remove
ProfileCache
and replace withProfileProvider
- removes dependency on modified vanilla names, and removes the requirement for implementations to need a cache forGameProfile
s. - Remove many implementation details and unclear fields from
Block
.- Remove
id
andstateId
- unstable network IDs, subject to change, huge implementation details. - Remove
speedFactor
andjumpFactor
- unclear, used to do specific calculations, implementation details. - Remove
isSolidBlocking
andisReplaceable
- unclear, implementation detail. - Remove
lightEmission
,hasDynamicShape
,useShapeForOcclusion
,propagatesSkylightDown
,lightBlock
,isConditionallyFullyOpaque
,isSolidRender
,hasLargeCollisionShape
, andisCollisionShapeFullBlock
- implementation details used for light.
- Remove
- Rearrange the order of
BlockFace
constants to align with natural order - current order doesn't make sense, as it's an implementation detail. - Remove
PushReaction
andRenderShape
and related fields - implementation detail. - Remove
isValid
fromBlockEntity
- implementation detail. - Make
world
ofBlockEntity
be non-null - it being null is a broken implementation detail. - Remove
isAscending
fromRailShape
- not required. - Remove
isConnected
fromRedstoneSide
- not required. - Replace the
properties
map ofPropertyHolder
with something that makes more sense, and isn't reliant on implementation details. - Address the issue of different properties with the same name but different ranges in
Properties
. - Make
BrigadierCommand
an interface in the API for consistency with the rest of the API. - Assess whether
name
ofSender
being aComponent
is a good idea. - Assess whether having a separate concrete type for each particle type is a good idea.
- Particles should probably not be built using a builder retrieved from the type.
- Assess everything that is exposed by all entities and determine whether they are necessary.
- Rework the event API to be more unique, and also better support different execution scopes.
- Remove
id
andstateId
fromFluid
- unstable network IDs, subject to change, huge implementation details. - Rename
colors
inFireworkEffect
toprimaryColors
- Remove all
fromId
functions from enum classes - implementation details. - Remove
eatingSound
anddrinkingSound
fromItemType
- implementation details. - Review the
ResourceKey
andRegistry
API and remove a lot of unnecessary vanilla Minecraft and implementation details. - Review the services system and decide whether more things should be services, such as authentication.
- Look at possibly introducing a
CustomStatistic
, to differentiate custom statistics from regularKey
s. - Remove
StatisticFormatter
and related fields/methods - not necessary, implementation detail. - Clarify/rename fields in
Statistic
-value
is actually the type that the statistic applies to, not to be confused with the actual value of the statistic, which is per player. - Clarify what
User
actually is - current wording suggests it can represent an online or offline player, but a user is actually the representation of a player's persisted data. - Potentially rework the ban API to remove it from vanilla attachment, and allow it to better be used and hooked in to by third-party ban plugins.
- Reorder the
Direction
enum constants to match natural ordering. - Consider whether
StringSerializable
fits in the API at all. - Rework
AmbientMoodSettings
to remove implementation details, such astickDelay
,blockSearchExtent
, andoffset
- consider alternatives that still allow modification of client calculations, but don't expose what is actually going on. - Rework
AmbientParticleSettings
to avoid needing to provideParticleData
directly. - Rework
BiomeEffects
to remove implementation details - consider alternatives that still allow modification of client calculations, but don't expose what is actually going on. - Remove
GrassColorModifier
,Precipitation
, andTemperatureModifier
if possible - replace with alternatives that still allow the features provided, but remove the implementation details. - Remove
lastUpdate
fromChunk
- implementation detail. - Rework the
DamageType
API to feel less vanilla, and include less implementation details.- Possibly make
DamageType
the actual type of damage, e.g. fire, magic, projectile, etc. - Possibly add a new
DamageSettings
that allows one to configure what the source actually damages. - Possibly allow users to calculate damage themselves by using a
DamageCalculator
, or similar. - Possibly even allow users to override the entire damage system and do all the damage calculations themselves through a damage service.
- Possibly make
- Rework
DimensionEffect
, which purely exists for access to the settings, and doesn't actually affect anything. - Remove
canBuild
fromGameMode
- used in internal calculations, implementation detail. - Remove
folder
anddimension
fromWorld
- implementation details. - Review whether
difficulty
andgameMode
inWorld
make any sense. - Remove the rain and thunder settings from
World
- replace with better Weather API. - Review the
getChunkAt
/getChunk
mess - having both types that use different types of coordinates, with no way to ensure the correct coordinates are entered is confusing and error prone. - Remove the
force
parameter fromunloadChunk
- implementation detail. - Remove the
ResourceKey<World>
constants fromWorld
- implementation details. - Possibly rework parts or all of the
World
system to remove the details on dimensions, and how worlds can be linked with other worlds, and also part of a heirarchy. - Remove
save
fromWorldManager
- saving is an implementation detail that assumes all worlds are saved on disk, which may not always be the case. - Make the
Krypton
object internal - should only be used internally. - Remove
isStable
fromPlatform
- variable, ambiguous as it depends on platform, implementation detail, and not necessary. - Remove
dataPackVersion
fromPlatform
- Krypton doesn't even have data packs, let alone this being an implementation detail. - Move a few server settings to a new
ServerSettings
type, specificallymaxPlayers
,motd
,isOnline
, andaddress
. - Create an abstraction over Spark to make it an implementation detail, rather than part of the API.
Server changes:
- Rewrite anything that was outright stolen from vanilla Minecraft. Seriously. It all needs to go.
- Look at Minestom and other server projects for help on replacements.
- Rework
KryptonProfileCache
to fit theProfileCache
->ProfileProvider
change, and also stop usingusercache.json
, which is something we really don't need. - Try and rework a lot of the built-in arguments, so they take less from vanilla, and more from the wiki.
- Try and split entity logic in to separate parts, to avoid God objects.
- Rework the whole item handling system to remove vanilla parts, and clean it up.
- Try and use Guice much more on the backend.
- Rewrite the entire LegacyQueryHandler, as it's a mess, and also can likely fire ping events when the server list ping API exists.