Add 1.8 blocks and items

[JiFish]

Add 1.8 blocks and items

[JiFish]

I need to add the new blocks/items added in 12w25a.

[JiFish]

Chests, Trapped chests and ender chests crash the with a data value of 0 in 14w25b. I've fixed this by updating materials.cfg. If this still crashes it in 1.8, we should advise people to regenerate their existing dungeons.

[JiFish]

More items added in 14w27a.

[sshipway]

Can there be an option ('compatibility' ?) in the configuration file to allow the user to preserve 1.7.x compatibility when running mcdungeon? IE, to ensure the additional v1.8 features are not used, in case the user is only running a 1.7.x client/server and so does not want these. I'm not sure how 1.7 would react if a world contains a 1.8 feature, but it would likely be sub-optimal

[JiFish]

No, we are very unlikely to add this.

This will become exponentially difficult to maintain as newer and newer versions are released. Instead, our efforts are directed towards implementing new features - not maintaining compatibility with older versions.

You have two options: You can use older versions. (We maintain a list of which versions are compatible with which versions of minecraft.) Or you can create a 1.7 compatible configuration bundle, with it's own items and materials file. (Even then it is still likely to break in the future as Mojang make alterations to the save format.)

[sshipway]

I can understand not wanting to support all versions for all time, as this would become unwieldy, particularly if the world format changes again.

However, you might like to reconsider dropping support for 1.7.x just yet? Version 1.8 is not yet a stable release; also, many people will continue to use 1.7.x long after 1.8 appears, if they use modules that have not yet been ported to 1.8. These people would be excluded from being able to safely run this highly useful utility.

Since (as far as I know) the incompatiibilites between 1.8 and 1.7 are basically (a) new blocks and (b) command block functions, maybe an easier solution would be to implement a 'compatibility mode' switch, that simply disables use of certain feature classes, and switches to using an alternative materials.cfg and items.cfg? Thus 1.7 users could still run it, though they would have progressively fewer features available. When 1.9 comes out, 1.8 becomes 'compatiiblity' mode, and support for 1.7 is dropped...

At the very least, providing a 1.7-compatibile config file (that sets a zero weight for noncompatible rooms, features, loot or mobs) would be a good idea.

[JiFish]

Support for 1.7 will not be dropped until 1.8 is out. That is the purpose of the development branch - so there is a cutting edge version ready for the launch of 1.8.

At the very least, providing a 1.7-compatibile config file (that sets a zero weight for noncompatible rooms, features, loot or mobs) would be a good idea.

If somebody creates this, it would definitely be something we should include. It is possible for configuration files to be bundled with item.txt and materials.cfg files to allow exclusion of the new blocks.

[sshipway]

I think that, even when 1.8 is officially out, many people will continue to use 1.7 because their favourite mods are not (yet) available for the 1.8 branch. Some people even still use 1.6 for this reason.

I'll have a go at creating a 1.7-compatible config that works with the mcdungeon dev snapshot this week -- however I think this would be much easier for the core developers to do, since it is not immediately clear to me which rooms and features use new 1.7-incompatible functions (and so should be disabled) or which objects, textures or mobs are new. Possibly the current stable branch items and materials files would work for this purpose, if there are no format changes in the mcdungeon dev branch.

[orphu]

Unfortunately, it's not as simple as just ignoring new blocks. For example, in the current dev branch, all hall traps have been rewritten to use command blocks and 1.8 only features. A 1.7 compatible version can't easily be done.

[sshipway]

Good point... however, on the plus side, I notice that the new version now holds hall traps in a separate class structure, with weighting configured in the config file. So, a v1.7-compatible cfg file can be made which puts a zero weighting on any items, mobs, and hall traps that use 1.8-specific features.

Of course, this means that the only possible v1.7-compatible hall trap is the 'nothing' trap :). Maybe the old non-cmd-block versions of piston and dispenser traps could be preserved in legacy classes with a normal weighting of zero that could then be optionally enabled in the legacy cfg? Though that of course immediately doubles the size of the hall_traps.py and the coding work, which I know you're reluctant to do.

I can see why v1.8 cmd blocks are needed for portcullises and non-lootable dispenser traps, but not why you'd need them on piston traps. I'll have to examine the code again, I think. I wish I had more free time to properly contribute to this project as mcdungeon has been the most useful utility for minecraft that I've come across so far.

[orphu]

Part of the effort in this example was to break hall traps out into their own class. Previously they were hard coded into halls.py, which was not a good thing. They had to be rewritten, so I took the opportunity to make them better/simpler with command blocks. It seemed like a good time since some 1.8 commands made them a lot easier and smaller and I could finally implement working portcullises. Getting the old versions of the traps in there would require rewriting them as well, but without all the nice stuff 1.8 provides.

Supporting older MC versions with the current MCDungeon is kind of a never ending rabbit hole. I'm not interested in taking up all my (increasingly little) spare time maintaining the tool for what is ostensibly a small number of the overall users. It's not fun, and it stifles making new stuff.

[JiFish]

I need to add the new items up to 14w32b. This includes being able to create Armor Stands which are entities, not tile entities.

[orphu]

Hmmm... should be able to expand the entity utils that I used to make villagers.

[JiFish]

Yes, good idea.

Armour Stands are very customisable under the hood. You can give them arms and have them hold items, set their pose and size and lock slots to prevent them from being looted.

These would go well in the armoury secret room and possibly some of the other features.

[orphu]

In the latest snapshot, all chests seem to disappear. Not sure if there is a tag missing, or what.

[JiFish]

Confirmed. This would seem to be why: https://bugs.mojang.com/browse/MC-65874

[orphu]

AH good. I'll leave it alone for now then.

[JiFish]

Chests fixed as of 14w32c.

[JiFish]

Mass closed a bunch of my issues that should now be ready for a 1.8 release.

Please reopen any that need more attention.