Version Migration Bug Testing Checklist

[Emoticone11]

Compiled a list of issues we had to deal with back during the 1.7.10 -> 1.11.0 migration. A lot went wrong during that migration, so this list should be pretty thorough (many issues listed here probably won't be a problem anymore), buuuut...

Disclaimer: this should be considered a non-exhaustive list. New potential issues may always be introduced by new vanilla additions or new mods/plugins. Some unlisted previous non-issues may be introduced as issues. Bug testing should always be rigorous and thorough above all else.


Grief/Item Protection

1. Users can create explosions with any explosive block
   
2. WorldBorder not in place - users can generate vanilla terrain at edge of map
3. Guests can fire rockets
4. Guests can place boats and minecarts
5. Guests able to break blocks in particular world
6. Users can spawn mobs using spawn eggs

World Guard Settings

1. Mobs spawning
2. Snow layers forming on ground during snow weather
3. Water not updating/flowing when placed by hand with water bucket
4. Jumping on farmland turns it back into dirt
5. Pressure plates not activated by stepping on them

Permissions / Group Settings

1. Private messages and/or /staffchat shows up on dynmap, IRC, or launcher console
   
2. Mods can't use /mute, /ban, /jail
3. Mods can't use /warp set or /warp delete
4. Mods can't use /dynmap commands
5. No user access to /ptime and/or /pweather
6. No user access to /r and/or /msg
7. No user access to /back and/or /top
8. User prefixes do not have rank color applied
9. /plist doesn't group online players by rank
10. Placing a chest claims an area for a user and prevents others from changing it. This should be disabled
11. Claim protection for contest plots still enabled
12. Builders can't break entities (item frames, armor stands, etc.) placed by other users
13. Spawn in Westeros world prevents people from breaking blocks in a that area
14. No builder+ access to using bonemeal to grow crops

WesterosBlocks / Resource Pack & Support

1. CTM doesn't work
2. Textures in brazier blocks applied incorrectly
3. Door/shutter blocks have textures applied incorrectly to blockstates
4. Pressing pick block key on custom bed/door blocks gives vanilla bed/door
5. Pressing pick block on directional blocks gives tile entity item
6. Custom bed blocks should have top/oblique view in order to differentiate
7. Bottom/top of door/shutter blocks invisible
8. Arrow Slit blocks don't have proper hitbox anymore
9. Double sun/comet showing up in skybox
10. Random CTM applied to web-type blocks seperately for each plane in a block
11. Wall blocks do not attach to arrow slits
12. Weirwood face block orientation incorrect
13. Wave CTM no longer being applied to ocean water

WorldEdit / Voxel / SchemBrush

1. 2-wide chests present in a chunk prevent it from being deleted with WorldEdit
2. Copy/Cut/Paste sometimes disables teleportation until a user relogs
3. Sand doesn't fall when placed with WorldEdit and/or Voxel
4. Incompatibility with previous schematic format
5. /snowcone or other brushes no longer work effectively in new Voxel (custom build necessary?)

Other Mod/Plugin Support

1. BetterFoliage leaves don't have biome overlay applied in different biomes
2. BetterFoliage not being applied to custom foliage blocks
3. Carpet Blocks showing up incorrectly in Dynmap
4. Support for /prism type block-checking not implemented

Misc.

1. Quotation marks (") don't show up in /msg
2. Users can't drop items from their inventory
3. "World saved" or other chat clutter should be hidden

 

[Emoticone11]

Regarding BetterFoliage custom block support:

OK - upon further inspection, I'm seeing that the leaves that are still having issues are those that are being 'CTM hacked' - specifically, those that have the biome-specific reskinning going on (blackberries, blueberries, etc). It appears that the BetterFoliage processing doesn't 'see' the reskinning, and is using the default models for the textures. I've got an idea on how to deal with this, but it's nontrivial - I could extend the 'leaves' block type to incorporate a biome-derived blockstate attribute, which could be used to select across different models (and, thus, different skins): this would shift the biome-specific behavior from being derived from CTM to being intrinsic in the block. Given that the reskinning also includes random textures, I'd probably need to either support those as well, or still use the CTM for the random part (but count on the BetterFoliage handling things 'well enough' with the non-random biome-sensitive texture).

Hmm... so basically with the initial custom leaf blocks (fruit etc.) we used the "base" leaf textures, same as the vanilla leaves, and applied the biome color overlays to that using the colorMult attribute in the JSON. The fruit textures were then overlaid on top of the correctly shaded leaves using the CTM renderpass=overlay attribute. However, at some point the fruits began being overlaid before the biome shading was applied, resulting in the fruits being too dark. So we had to change to the hackish approach where CTM is used to reskin according to biome.

If there's an easier way to just revert back to the "initial" method, then that would be ideal and should also fix the BetterFoliage issue. Also, if we could use the vanilla leaf textures + corresponding colormaps as the source for the extra leaves for each of the fruit/flower custom leaves, that would also work fine. As the fruits aren't important for the extra leaves and the base leaves/shading are the same as the corresponding vanilla leaves.

 

[Emoticone11]

Regarding ocean wave CTM and water blocks:

Hey Mike, there seems to be a problem with CTM being applied to water blocks: The folder "water_ocean" has CTM that's supposed to apply waves to water in the ocean biome only. However, the CTM doesn't appear to be showing up. I've made sure that both property files use "matchBlocks=minecraft:water", but it still doesn't seem to work. Does the issue have to do with Optifine not applying CTM to water blocks normally?

OK - upon further inspection, I'm seeing that the leaves that are still having issues are those that are being 'CTM hacked' - specifically, those that have the biome-specific reskinning going on (blackberries, blueberries, etc). It appears that the BetterFoliage processing doesn't 'see' the reskinning, and is using the default models for the textures. I've got an idea on how to deal with this, but it's nontrivial - I could extend the 'leaves' block type to incorporate a biome-derived blockstate attribute, which could be used to select across different models (and, thus, different skins): this would shift the biome-specific behavior from being derived from CTM to being intrinsic in the block. Given that the reskinning also includes random textures, I'd probably need to either support those as well, or still use the CTM for the random part (but count on the BetterFoliage handling things 'well enough' with the non-random biome-sensitive texture).

Would this be a more feasible fix if we could create a custom water block which looks and acts exactly like the vanilla one?

If we stick to still water, I'd say it might work - the still water doesn't really need the custom renderer much, since it's basically just a layer style block, from a drawing point of view. Lemme see if I can scramble up something to try....

If we could get two water blocks, one that's "static" at the same height that vanilla water is when placed, and one that acts like a layer block, so we can stack it to get variable heights, that would be ideal.

Then, if I'm not mistaken, we could run the replace script like so:

9:0 -> static water block

9:1 - 9:7 -> the corresponding heights of the layer water block

all water blocks of ID 8 remain the same, as those are the vanilla flowing water blocks.

EDIT: Actually, I'm not so sure this approach will work- I tried doing //replace 9 0 on the following chunk of water, and it affected all of the blocks there, including the ones that are flowing rather than still: https://puu.sh/xeiNH/471d6c2318.png