Moving to Beta

I'm moving the classification of the mod from alpha to beta: this represents my feelings of the mod's done-ness. It is as far as I'm aware, feature complete and just needs some polishing.

Bug fixes

Command Structure.

Some paraenthesis in the command registration were in the wrong place, conoddling their neighbors spouse, causing erroneous behavior. The offending punctuation marks have been appropriately blackmailed with picture of the affair, and have returned to the correct positions in the code.

Feature Changes

Feedback

All commands entered into chat should now give the user appropriate basic feedback.

Future Plans: Natlang Feedback

I do plan on making feedback better and more naturalistic, but for now; it delivers the information it needs to, albeit rather dryly. It's gonna be on my low priority list because of how frustrating I've found the whole idea of implementing it

Units

Units of measurement such as kilometers of distance or hearts of damage, or cakes worth of cake slices have been re-implemented as a system.

New Units

The following units have been added to the game:

• Blocks
  • Chunk layer (256 blocks)
  • Subchunk (4,096)
  • Map Layer (16,384)
• Item
  • Stack (varies per item: [1 | 16 | 64] items )
  • Hopper (5 stacks)
  • Dropper (9)
  • Chest (27)
  • Player Inventory (36)
  • Double Chest (54)
  • Chest of Shulkers (729)
  • Double Chest of Shulkers (1,458)
• Distance (Metric)
  • Meter (100cm)
  • Kilometer (100000)
• Distance (Yanklandaen)
  • Inch (~2.5 cm)
  • Foot (12 Inches)
  • Yard (36)
  • Mile (63360)
• Time
  • Second (20 ticks)
  • Minute (60 seconds)
  • Minecraft Day (20 minutes)
  • Hour(60 minutes)
  • Day (24 hours)
  • Week (7 days)
  • Month (~30.4 days, exactly 1/12th a year)
  • Year (31,556,952 seconds)
• Damage
  • Heart (2 points)
• Cake
  • Cake (7 slices)

Function

Most commands can now be appended with a string word which will be parsed as a unit. This will affect how the command executes. For Query and Store, the stat value will be divided by the unit's conversion factor before being used. For Add, Set, and Reduce, the argument will be multiplied by the unit's conversion factor before being used.

Alternate Names

Most units have more than one string that can parse as it. For example, the kilometer can be specified using "kilometer" or "km", or "chest" and "shulker". A complete list of these has not been provided.

Sanity Checks

A command with a unit will only properly function if that unit is a sensical measure of the stat; trying to measure distance in years will fail. Commands which

Future Plans: Command Suggestions

When typing the command, I'd like to have the mod suggests the units.

Future Plans: Project Units

Currently project cannot use units. Adding units to the project feature is at the very bottom of my priority list right now, below even implementing natlang feedback, not because it'd be difficult; but because it'd be annoying.

Future Plans: More Units

I will hear requests for any addition units you might want to use. I will not necessarily accept them, but I will hear them. To be considered, any such request must be come with a relevant wiki or wikipedia article, and a conversion factor.

Updated v0.73 to 1.21.

No new features: Feedback still removed from commands (commands still function but don't provide chat feedback) as I work on cleaning it up.

Added Project

/statistics project [ list | start | pause | stop | query | store ]

Project is a new execution mood with six further branches. It's purpose is to allow for stats acrued during a specified timeframe to be tracked seporately from stats in general without interferring with general stats nor with each other.

It accomplishes this by giving each project it's own statHandler and a directory to save it's UUID.json to.

List

/statistics project list @p

List all active and inactive project for the target players.

Success and Failure

List succeeds if it finds at least one project, active or inactive, among any the target players, and fails only if it finds exactly none.

Start

/statistics project start @p <project_name>

Start adds or activates ('unpauses') the StatHandler associated to this project to each target for whom it is not already an active project. A project once started will accrue stats overtime until it is paused or stopped.

Project Names

A project can be named almost anything which minecraft considers one word. For simplicity periods are allowed in line, but for safety, project names are sanitized during execution to swap any periods [.] to underscores [_]. Therein, the project name, "project.name" is functionally identical to the project named "project_name." They are the same project

Furthermore, the string "all" is reserved for functionality in pause and stop branches. A project cannot be named "all" and the command line /statistics project start @p all will fail.

###Success and Failure Start succeeds once it has tried to start the project to each of its targets if it succeeded in starting the project for at least one of those players. A project can only be started if it is not active. Start fails if all its targets are already active members of the project or if given an illegal project name (eg. "all")

##Pause

/statistics project pause @p <project_name>
/statistics project pause @p all

Pause adds as paused or pauses the StatHandler associated with the project name. While paused, the StatHandler is inactive, and does not accrue additional stats whenever the player's stats increase or change, but will remain available for project query and project store.

All

All is a special execution mode of pause triggered by putting the string "all" as the project_name arguement. In this special cause, rather than pausing a project for each of its' targets, pause pauses every project any of its' targets is an active in for that target. To protect this functionality, the string "all" is reserved and cannot be a project name.

Success and Failure

Pause succeeds once it has tried to pause the project for each of its targets if at least one of those targets was not an inactive member of that project, and fails otherwise.

Pause All succeds once it has tried to pause all projects for each of its targets if at least one of those targets had atleast one active project, and fails otherwise.

##Stop

/statistics project stop @p <project_name>
/statistics project stop @p all

Stop removes the StatHandler associated with the project name from both the active and inactive pools. It does not delete the project's existing stats .jsons; but those jsons stop acruing stats and stop being accessable to project query and project store.

All

All is a special execution mode of stop triggered by putting the string "all" as the project_name arguement. In this special case, rather than stopping a project for each of its' targets, stop all stops every active and inactive project any of its' targets is a part of. To protect this functionality, the string "all" is reserved and cannot be a project name.

Success and Failure

Stop succeeds once it has tried to stop the project for each of its targets if at least one of those targets was an active or inactive member of that project, and fails otherwise.

Stop All succeeds once it has tried to stop all projects for each of its targets if it stopped at least one project for at least one of those targets, and fails otherwise.

Query and Store

/statistics project query @p <project_name> <stattype> <stat>
/statistics project store @p <project_name> <stattype> <stat> <objective>

Query and Store Project Query and Project Store mimick the functionality of the general query and store execution moods, except they use the project's dedicated statHandler to look up the information, meaning that for each target, they find the stat as known to the project.

Project Add | Set | Reduce

There is currently no plan to implement Project Add Set Reduce for version 1.0; If I find a more compact way of registering the command, that might change but it's not currently planned.

Success and Failure

Query and Store succeed under the same conditions their general analogues do, except they have the additional failure condition of not finding the specified project, active or inactive, among any of their targets.

Refactoring

Record -> Store

To align with existing commands keywords, record's name has been changed to store.

Reduce is still reduce

I have not and will not be changing reduceto remove to align with existing command keywords, because I think reduce more clearly signals the purpose of the command compared to vanillas analogous "remove."

Command feedback

In this version feedback is almost completely broken. This is because I intend to completely rework it in the next alpha release. The functions still work as intended. Only their user feedback has been altered or removed.

Added scoreboard objectives to [add | set | reduce]

The execution modes add, set, and reduce for statistics commands can now accept scoreboard objectives as alternatives to integers. They will add, set, or reduce the statistic by the score the player being modified has in that objective.

Feedback when using an objective for add, set, reduce is different compared to using an integer, but is stilly equally rudementary.

Added /statistics record

Record your statistics to a specified scoreboard objective.

Changed custom stats's input behavior

Input custom stats now accepts a registry entry, in line with the behaviors of other stat types

Added basic feedback.

All modes of execution for the statistics function now provide user with rudimentary feedback. Translatable feedback coming eventually™.

MINIMUM VIABLE PRODUCT It needs a lot of polish, but this version adds the bare bones of a /statistics command that can query, add, set, and reduce a player's statistics which was my initial goal.

It performs the functions I set out to create: polishing past this point is scope creep.