Inclusion of 1.8 features?

[Niadevv]

As far as I know, Corundum is 1.7.10. Some entity stuff includes Guardians and Rabbits, entities not implemented until 1.8. Is this intended? There is also inclusion of 1.8 blocks, like diorite/andesite/granite, not to mention some I've missed.

[Variadicism-zz]

Ah, sorry. You're right. I put them in because the list I was using included them, but since the rest of the code works on 1.7.10, we probably actually shouldn't have them yet. They can be commented out for now, but I'd prefer that we leave them in commented form so that I don't have to do them again.

WAIT! While writing this, I had a better idea. Let's make all the options version-controlled! Remember how we were discussing before being able to allow Corundum to run on different versions of Minecraft? What if we could make it so that each EntityType or whatever has a minimum version associated with it and whenever it is given to the Minecraft code (like in changing a Block's type), we just compare the current version to the minimum version of the BlockType they're trying to set it to and if the current Minecraft version is too low to support that, we throw a special CorundumException like a "WrongMinecraftVersionException"?

If we format the system like this, we could potentially make Corundum versions independent of Minecraft versions. (...well, backwards, at least.) So, a Corundum program built for Minecraft 1.8 could also work with all Minecraft versions prior to 1.8.

[Niadevv]

That's a good idea. I like that :) I may, however, have to add a version comparison system somewhere. Fortunately, it's not too difficult at all with dot based versions, it's mainly just iterating over the results of .split(".") and casting it to an int. Question answered now, but leaving open for if more discussion needed.

[Variadicism-zz]

I've already been considering a version comparison system for a while now since we'll need it for plugin dependencies and automatic plugin updating, too.

I was thinking that everything could be kept in a Matchable (Comparable) Version object with a "major" version number, multiple optional "minor" version numbers, a field for optional "alpha" or "beta" tags, and one last field for any other special tags we can think of like "Pre-" or "Dev-".

The only thing I'm worried about is how specific our versions need to be, specifically for Minecraft. We may need to be able to parse Minecraft snapshot versions as well, like "13w35". (I think that's what they look like, if I remember correctly.) maybe that would need an MCVersion subclass.

I'll add a card for it on Trello today.

[Niadevv]

In the case of snapshots, it'd be quite easy, just .split("w") instead of "." and parse it the same way. Special symbols are easy as well, before the casting to an int, just .replace("specialsymbol", "") to delete it, and then proceed as normal.

[Variadicism-zz]

Oh, I forgot Minecraft snapshot versions also end with a letter starting from "a" and incrementing whenever more than one snapshot is released in the same week.

Maybe we should make a separate MCSnapshotVersion class for parsing those since they have different data like "month" and "week". We could still store those as major and minor versions, but have extra getters and setters for "week" and "month" just to make it easier in the A.P.I. The letter at the end could be treated like the last minor version and we could have a char getVersionLetter() that just converts that byte to a char where a = 0 (which would just be the byte + 97 casted to a char since 'a''s ASCII/Unicode value is 97).

Implementation-wise, I think we would just have to change the String constructor to first check if it matches a Minecraft snapshot version ("\d+w\d+[a-z]" in regex).

Oh, I also looked up Minecraft snapshot versions. They have a second format: the version number (e.g. "1.8" or "1.7.10") followed by "-pre" and optionally ending with a single digit (regex "\d.\d+(.\d+)?-pre\d?"). We'd have to account for that one, too. Sheesh.

[Niadevv]

Mojang: Have one consistent versioning system? Nether no! Let's have 3 different versioning schemes because why not!

Unfortunately, I don't understand regex at all. I just see a bunch of assorted characters. For now, at least. But I get the general gist of the formats even without the regex stuff.

[Variadicism-zz]

Yeah, no kidding.

Actually, I've been thinking about it and I don't think we can actually make Corundum work with multiple versions of Minecraft anyway. Each version changes the code, which means we would have to change our code to match it. Also, the obfuscator may obfuscate differently depending on the number of arrangement of the classes, which would break our code.

Maybe it would be better to just make one regular Version class. Let's forget about the Minecraft snapshots, at least for the first version; they're not really all that important. As for the 1.8 entities and blocks and such, maybe we should just comment them out. You're right; our first version should be for 1.7.10.

For the record, "\d" means digit character (0-9), "." represents a literal period (as opposed to the regular use of a period in regex to mean any character other than a line break), "+" means 1 or more of the previous character or group, "?" means the previous character or group is optional, and the "[a-z]" is a "character class" that represents one character within the (inclusive) range from 'a' to 'z' (i.e. any lowercase letter).

[Niadevv]

Fortunately, most of the potentially code breaking changes in 1.8 were client side, with the exception of block metadata using BlockStates instead of metadata. Of course, it'd be easy to map old 1.7.10 byte data to it's current BlockState and set a block's metadata to that. I made a compilation of major (and some minor) code changes between 1.7.10 and 1.8. A lot of it is new util classes and client changes, except for, again, BlockStates. However, for the first few versions, we should probably focus on the current Minecraft version before backward compatibility. Two of the major changes planned for 1.9 that I know of are client side (some OpenGL function stuff and moving to an entity model API, both details revealed by MogMiner), so, assuming Mojang doesn't rewrite how Entities work or give Items some form of ItemState, we should be fine for 1.9 and 1.8, perhaps some backward compatibility features to smooth the transition.

[Variadicism-zz]

I'm going to go ahead and close this issue. I'd say that if the code changes are minimal as you say, then maybe we can look into some multi-version compatibility, but considering that even one method change could break Corundum and make it look for a method that doesn't exist or doesn't return the same type any more, I'm guessing we won't be able to do much of that.

Let's say for now that we will not be trying for any multi-Minecraft-version compatibility and we'll just try to make Corundum Minecraft-version-specific; if we have ways to change this later, then maybe we'll look into it.