MassiveCraft staff is hard at work updating all of our inhouse plugins in anticipation of converting and updating our server to 1.13. Tech staff and direction member @TheComputerGeek2 is the leader of this project, and has outlined the work being done, and what is still being worked on.
The first obstacle was to address tab completion commands, which were broken with the 1.13 update. A rework of the command tree is being implemented to allow tab completion for the commands. MassiveQuest is also a plugin that will need extensive work due to the 1.13 changes that handle data management due to the required changes in quest rule storage.
Do you have the talent to assist? Tech requires those with strong capacity for using the minecraft console client, the minecraft macro mod, or both, for the automation systems provided.
Expect another update on our march towards 1.13 soon, and thank you all for being a part of the MassiveCraft community!
Minecraft 1.13 contained many changes internally, from commands getting an entirely new dispatch engine to the great flattening of items and the dropping of support for numerical ids other than old material types.
As you all (hopefully) know, commands are important here at Massive and a lot of effort has gone into making them high quality. Initially, the 1.13 update resulted in a large segment of our command usability being lost, largely the tab completion. This is because we have very dynamic commands which are modifiable while the server is running.
Previously, all that needed to be done was swap out entries on a map of aliases to the commands. That map still exists, HOWEVER, it no longer is what is directly used for performing command lookups at dispatch time. What happens is that after the plugins load, the command map is used to build the command tree essentially for the new dispatch system, this tree is then used at dispatch time rather than the map. In the interest of preserving compatibility and making the least breaking changes, I have been focusing on allowing this tree to be partially rebuilt rather than fully rebuilt as to avoid incurring performance loses during command updating. This also will allow us to make proper use of the benefits offered by the new dispatcher such as more readily available template displays.
While the commands need a lot of attention, there is the flattening to address with item handling. One example of where this may be problematic is within MassiveQuest. Currently, MassiveQuest uses numerical data for some of its conditions, for example IfHaveItem 1:3x1 would be stored as “ifhaveitem” and “1:3x1”, both as a java String. This means that the normal migrator system will struggle more to be the solution. On top of this, we may have cases where we have a rule that looks like “docmd /q e tf ifhaveitem 1:3x1” because the outermost rule id is “docmd” which doesn’t necessarily need to have an item specification attached, but it happens that the command it is running does require one. Requiring knowledge of all commands which may involve this format or which may invoke quest changes is not exactly practical, nor is just matching for the item pattern itself, because if an item had the text “1:3” or something along those lines, which could be seen as a ratio display, that should not be converted.
Assistance: those with strong capacity for using the minecraft console client, the minecraft macro mod, or both, for the automation systems provided would be able to assist by producing automated test cases for various plugins (such as Factions protection aspects being performed by having two clients scripted to setup factions and then attempt to perform certain actions which should either be allowed or denied depending on the configurations and then verify that the action was handled properly. I can handle the determination on if the actions were allowed or disallowed based upon command feedback and such easily enough provided the scripts for the clients.) Where applicable, the minecraft console client is the preferred solution.