Avicii’s music was a formative element in my life. My sister and I would always sing Hey Brother when driving home from school or around
town when it was on the radio, it was one of the first songs that I felt we truly bonded over. About a year after it stopped playing
regularly, it just so happened to come on one time, and we immediately got excited and started singing it like old times. A few years after
that, she sent me a message one day saying she had heard it while walking around campus one day (she had went on to college, I was still in
high school), and just by mentioning it, I was taken back to those days.
Wake Me Up was probably one of the first songs I truly felt I enjoyed. It helped me accept who I was and that I didn’t
have to hide what I enjoyed to do just because I was afraid of what other people would think. Each song he made always carried a weight of
significance for me. Thank you Avicii, for impacting my life and for everything you’ve given me, while I’ve never known you or met you,
you were a friend to me through your music.
Since the beginning, the MCEdit-Unified team has had a very interesting build/release pipeline. Up to this point,
all of our releases had been built by Project Organizer/Leader @Khroki. He had access to both Mac and Windows
machines, so he was in the best position to build our releases. However, if we wanted to test a feature when it
was compiled, we would have to wait for him to build a testing build. We thought about finding a continuous
integration service to periodically build testing releases, but we couldn’t find one that ran a Windows
environment, so we just stayed with out current system.
The problem
While our system had been successful so far, it relied on Khroki’s availability and resulted in us having to
find days when both we were available to test the compiled build and address any last minute issues and that
Khroki had enough time to build the release and notify us of any errors. With our various schedules and the
fact that we’re located around the world, it took a lot of effort. However, now with none of us being able
to contact Khroki, we had to build testing releases ourselves and without any references to our old build
set up.
Setting the stage (Environment)
When I started looking for a Continuous Integration system that supported a Windows environment, I recalled that
@codewarrior0 had a system similar to the one we wanted to implement. The service he used called Appveyor had an
option for a Windows environment. The next step is to configure the said environment. Appveyor uses a YAML file to
handle the environment and build stages. Since we can just build MCEdit-Unified from two commands, we just set one
build stage to run
which installs all of
the requirements needed to run MCEdit and another to run
which runs our PyInstaller script to actually build the executable.
Building the build script
With the environment set up, I now needed to create a completely new build script for PyInstaller since we couldn’t
get the one we’ve previously used for our releases from Khroki (see “The problem” section). While looking over how
CodeWarrior0 organized his build system, I realized that the PyInstaller build script is actually just a python script
with some fancy functions that PyInstaller imports to know how to build the executable. Using MCEdit2’s script as a
reference, we created a automated build script
that includes all of our data files (like filters, schematics, etc) andmoves DLL binaries into the executable’s folder.
After all of this happens, the directory is collected into a ZIP file for uploading.
Conclusion
With all of this inplace, we’re now able to build testing releases on a regular basis without needing to install various
utilities and programs. While we would’ve liked something like this set up earlier, we feel that introducing this for
1.6.0.0 will help us make a smoother and more stable release.
I’m going to try to make weekly posts on projects I’m working on and going into detail about design choices I make. I know
this post wasn’t very technical and was a wall of text, but I’ll try to keep posts like this to a minimum. If you have
any tips or things that I might be able to improve on, please put those in the comments or contacting me on Twitter.
Since there has been a decent amount of time since our last release, I decided to
write a quick summary of all the features/changes that have been made. Please note
that some of these changes are internal, so you won’t necessarily notice them. This
is probably not an exhaustive list, and is mostly just the feature I worked on.
Structure Blocks
In Minecraft 1.10, Structure Blocks were introduced to save in-game buildings to files,
where you could them share them with friends or reimport them in another location
in the world in-game via another Structure Block. (IE: Vanilla Minecraft’s version of Schematics)
Well, MCEdit-Unified now has the ability to import and export .nbt files! Importing them
is the same way as importing a regular schematic. However, for exporting, you will need
to change the file type in the save dialog to change the format the file is saved in.
(Schematic vs. Structure .nbt)
Filter creators can also use Structure files in their filters, but this will be detailed in a later section.
Blockstates
Blockstates have been present in Minecraft for a few versions, however, they way they would
be saved wasn’t, until Structure .nbt files were introduced. To achieve this, I created an
API to convert from Integer-based IDs to Blockstates. Here is a very brief and bare-bones snippet
of how to use it:
Note: This currently only works with PC Blocks, but materials.<function>
(like the way in example_3) will always point
to PC Block definitions/”alphaMaterials”
Additions to Filters
BlockstateAPI
With Minecraft moving away from IDs and using a string/name system for identifying blocks, you can now
have blocks inputs based on a Blockstate string. Example:
This will still present a regular Block picker option to the user
StructureNBT
You can also now interact with Structure NBT files by using the StructureNBT class in pymclevel.schematics.
Here is an example:
Block Info Summaries
Hovering over a block now gives a summary of important information about the Block. Example
Static Block Definitions
Due to various reasons, I am (unofficially) stating that accessing the static block definitions
is deprecated and shouldn’t be used. They will still work, however. I’ve come to this decision
due to the following reasons:
Static Block definitions are missing lots of blocks
It’s hard to find which blocks are missing
Naming and Data values are inconsistent
Some Blocks have all of their various Data values present, others have none
Facing Direction Data values are also inconsistent (in Minecraft)
Blocks with Data values are sometimes hard to name (IE: Blocks that can face different directions)
Blockstates/names can exist across various editions, while Static definitions don’t
IE: “minecraft:grass_path” points to 208 for PC/Java, while it points to 198 for Pocket Edition
We actually have this problem with our renderer, to check it out, open up a MCPE world and look at a Grass Path block or here
Aren’t based off of our definition files
They have to manually added to pymclevel/materials.py
Requires knowledge of what kind of materials are being used
While PC (Java) edition supports Command Blocks, MCPE doesn’t, so if a filter puts a Command Block in a MCPE world, it could cause the game to crash or perform unexpected behaviour
Here’s an example of why using Static Block Definitions is bad:
As you could probably tell, this is a simple filter, it just puts End Rods on every side of a Purpur block.
However, it places completely different blocks if it’s in a PC world vs. a Pocket Edition world:
PC World Output Pocket Edition World Output (This is renderer issue I mentioned earlier, those wierdly
textured End Rods are actually Grass path blocks, and would be so if opened in MCPE)
This is not only inconsistent behaviour (the Grass Path block vs. the End Rod), but it introduces a Unknown Block
into the world, which could cause a crash. It also makes the output unpredicatable, if the filter is ran
with default inputs (and in a MCPE world), the block picked is not the block actually placed, which would confuse the user.
So in conclusion, I would like to ask filter creators to use the Blockstate API for any new filters they create after the
next release (preferably use the way used in “Block Method #1”). Again, the old way will still work, so your filters
won’t break, at least until PC switches completely from IDs to Blockstates.