Category: Mystcraft

New build!

Fixed some bugs and things.
Biggest new feature is rotatable Ink Mixers, Link Modifiers, and Book Binders.
Bit of API stuff. The API is beginning to ramp up some more, so I’ll hopefully get the API public again in the near future.

Things are happening in the background as well. My secret project is coming closer. 😀

I’ve moved my downloads over to CurseForge.

Enjoy!

Check the Mystcraft Forums for updates and the change log.

I hope everyone enjoyed the Mystcraft Easter easter eggs. 😉

This week the biggest feature is a huge performance improvement from threading the chunk profiling. Should help a lot.
I also improved some other things, like library generation and localization.

I’ve been working on some other things behind the scenes as well; hopefully that will come to fruition soon.

I’ve moved my downloads over to CurseForge. Existing downloads on my blog here will remain, but all future ones will be over on CurseForge. This will hopefully simplify things.

Enjoy!

Check the Mystcraft Forums for updates and the change log.

This build is just to add a little Easter “easter egg.” Shouldn’t be hard to spot, but it will only happen on Easter.
There’s not much else to it. Didn’t have much time to work on things this week due to holiday stuff for the Easter break.

Hope everyone is having a good weekend at the least, and a happy Easter Break for those that do that.

I’ve moved my downloads over to CurseForge. Existing downloads on my blog here will remain, but all future ones will be over on CurseForge. This will hopefully simplify things.

Enjoy!

Check the Mystcraft Forums for updates and the change log.

This build has various fixes and improvements to the baseline profiling system.
This includes some in-game notifications and indication to expect lag, as well as an option to prevent clients from connecting while a dedicated server is profiling.
Lots of performance improvements, so the lag should be very manageable now.

I’ve moved my downloads over to CurseForge. Existing downloads on my blog here will remain, but all future ones will be over on CurseForge. This will hopefully simplify things.

Enjoy!

EDIT: I’ve pushed 0.11.2.01 to fix a critical bug in generation. The Vanilla-Mystcraft mappings got flipped, so terrain was all wrong.

Check the Mystcraft Forums for updates and the change log.

I’ve been running low on time to do anything Mystcraft/modding related of late. To keep people from having to wait too long on new stuff, here’s an update.
This adds baseline profiling for instability, so configs which increase (or decrease) vanilla ore distribution will be accounted for. Other mods can register things to the profiling system now.

This also made major changes to how descriptive books and notebooks work. Hopefully things are improved there.

Symbol collection should be smoother now, in theory. It’s not all done, but it’s better.
I’m aware that the villager trading stuff is a bit off still, but you can convert emeralds to booster packs now, so that should help a lot.

Enjoy!

I’m moving my downloads over to CurseForge. Existing downloads on my blog here will remain, but all future ones will be over on CurseForge. This will hopefully simplify things.

Enjoy!

Check the Mystcraft Forums for updates and the change log.

Well this build took a while…
This one contains the big rewrite to instability from blocks calculations. It was a major change and took lots of time and testing to get down. Thank you everyone for being so patient.
I’ve also rebuilt part of my API. Again. Lots of it is still missing.
I did a lot of things since the last release. I have no idea what all is different anymore. 😛

I have a list of things to fix queued up and I’ll be getting builds out with fixes in no particular order fairly soon. Going to try to shift towards a release schedule now. ;P
The balance is hopefully better than it was, but it’s still by no means “done.” This was a big step in what I hope was the right direction, though.

Note that I have been working in Forge 1180, so it’s possible that you have to have at least that. This probably isn’t much of an issue, as many mods require much later versions. Tested up to Forge 1224.

I’m also planning on releasing this build on curseforge (in addition to here). Bear with me on that. I’ll try to get the old builds up there as well.

Enjoy!

Check the Mystcraft Forums for updates and the change log.

Download: [1.7.10] Mystcraft Universal 0.11.0.00

Geez, guys. You never let things go. 😛

I figured I’d finally address this, as I’ve just been ignoring it. Since it’s not going away, and I’m tired of the arguments, I’m going to make a short post on it.

If you’ve not actually read the whole EULA, please do. It’s really not that long. Most people have read one paragraph out of it and think that means no one has any control of anything anymore, and they aren’t even reading the paragraph for what it says, but for what they want it to say.

Given what the EULA says literally:
You may not charge for (especially vanilla) game content.
(Though you can apparently provide ranks on servers (non-mechanical “I’m Cool” indicators) to donators.)
Mojang has permission to do stuff to anything you make publicly distributed.

Most of what the EULA talks about is: “The game belongs to MOJANG, you may not distribute it. Mods are cool. Videos are cool. Etc. Just don’t go being mean, alright?” (Paraphrased)
It’s not a very formally written document. It’s pretty straight forward in what you can and cannot do.

There are two paragraphs which pertain most strongly to mods. One which pertains to all content made for Minecraft, and one which speaks directly on mods. Oddly, everyone likes to skip over the second of those. I’ll start with that one first:

Any tools you write for the Game from scratch belong to you. Modifications to the Game (“Mods”) (including pre-run Mods and in-memory Mods) and plugins for the Game also belong to you and you can do whatever you want with them, as long as you don‘t sell them for money / try to make money from them. We have the final say on what constitutes a tool/mod/plugin and what doesn’t.

This says that my mod is mine, which is really kind of obvious. My code is mine. My work is mine. You cannot copy it and create your own versions of it without my permission.

The quote everyone likes to run around with is this one:

If you make any content available on or through our Game, you must give us permission to use, copy, modify and adapt that content. This permission must be irrevocable, and you must also let us permit other people to use, copy, modify and adapt your content. If you don‘t want to give us this permission, do not make content available on or through our Game. Please think carefully before you make any content available, because it will be made public and might even be used by other people in a way you don‘t like.

Lets go over this in pieces.
I have created content which I made available on the Game: Mystcraft.
Therefore, I must give Mojang permission to use, copy, modify, and adapt that content. No argument there. I knew that. This basically says they can do anything with my mod they like. I even kind of assume that “distribute” is in there, even though it isn’t explicitly mentioned.
This permission must be irrevocable… I think this is obvious, again.
… and you must also let us permit other people to use, copy, modify and adapt your content. And this is also squarely within Mojang’s rights. They have the power to distribute Mystcraft, should they so wish it, and do anything else they want with it, and they can give that ability to, say, Curse. Or, if they felt like it, Lucas Arts. Or even Cyan (which would make more sense). Of course, if any of these groups wanted that permission I think they’d usually come to me first, just to be nice, but technically they only have to ask Mojang. I expect Mojang would tell them to ask me first, just to be nice, but they aren’t required to do that. I’m cool with this. 😛
If you don‘t want to give us this permission, do not make content available on or through our Game. Duh?
Please think carefully before you make any content available, because it will be made public and might even be used by other people in a way you don‘t like. This basically says, in the context of Mystcraft, that I can’t dictate the terms of use of Mystcraft. I can’t say you can’t play it a particular way, or that you can’t play it with particular mods. If you make a private modpack, you and your buddies, I can’t tell you what you can and can’t put in it. Mostly it’s a slap in the head to people who are uptight about how their mod is played… I’m not, so I’m cool with this. 😛 It’s also written as a warning to modders, more than anything, rather than as an affirmation of user rights, so I’m probably reading things into it that aren’t strictly there.

Now, there is one point I want to make really, really clear: No where in that did Mojang say that anyone can do anything they want with my mod. Quite the opposite.
Please think carefully before you make any content available, because it will be made public and might even be used by other people in a way you don‘t like. A lot of people like to point to this line and say it does. It doesn’t. It says people may USE my mod, which I have released publicly, in any way they please. It doesn’t say that people may take my code, or my work, or make demands on me, or do whatever else thing that tramples the implicit and automatic rights I have to my work, which were already affirmed earlier in the EULA, in the first paragraph I quoted. My work is mine, and it stays that way. Please don’t steal my code and say that one sentence in the EULA, written as a warning to people making content, says you can. That’s a quick way to make people stop making mods, guys. Especially when the EULA says you can’t (see first paragraph).

On the flip side, and this is important, it does give Mojang rights to do basically anything with my mod, and I am perfectly and absolutely OK with this. Mojang deserves those rights, it’s their game.
It can also share these rights with others (like with Curse). I’m, once again, perfectly and absolutely OK with this.

What this EULA doesn’t do is declare that YOU, the user, have been given those rights. Mojang can release those rights to anyone they wish, but the EULA didn’t list anyone it has given them to, and I’ve not seen anywhere (I’ve looked, but if you find it let me know) that Mojang says that users have been given these rights. Note that Mojang must say this, not a single person within Mojang. Mojang as the legal entity.

This long post (sorry, I said it was going to be short, didn’t I?) needs to include the two reasons I keep getting this thrown at me:
“You can’t require permissions” – Said in the context of me requiring permissions for public modpacks. I can’t say what mods Mystcraft is played with, but you better believe I’m going to try to limit distribution. Note also that distribution of mods wasn’t even mentioned in the EULA. I assume Mojang has that right, but that’s actually me assuming it. It doesn’t use that word except in saying that people can’t distribute Minecraft. Technically, the paragraph people like to cite as giving everyone the right to distribute my mod doesn’t even give that to Mojang.
Why am I limiting distribution? I want to limit the opportunity for people to include malicious things in my mod. It’s both for me and for you. I do it for you so there are a number of places declared “safe” for getting a copy of Mystcraft from. We can assert and double check the safety of these packs. On the flip side, this way I’m not liable for if you have problems with an unofficial distribution of Mystcraft.

“You can’t charge for your mod!” – Said about my Patreon reward tier. The main thing here is, I’m not. It’s early access, for starters, to builds which I will never otherwise make public. It’s a reward thing, for people donating, but if you want to be harsh about it it’s a subscription fee to have early access and unlimited access to all of my dev builds (from about 1.6.4). I’ll distribute my mod for free and without limitations when I hit a public release.
Anyone claiming this is apparently citing the “you cannot make money” line (Amusingly, from the first paragraph I quoted; the one that’s usually ignored until people want to make this complaint.). If you want to interpret this as me making money off of the mod (which is to say, selling the mod), then modders shouldn’t be able to have a Patreon tied to modding at all, and yet Mojang hasn’t said a thing to any of us, and we hang out with them.
This is kind of a weird grey area… I’m not allowed to sell my mod -and I’m not- but I can accept donations for my work time. Making a mod is a lot of time and effort, especially something as huge as Mystcraft; receiving money for it is kind of reasonable, especially since it will never reach the amount of money I’d be paid for the same number of hours if it were employed work. Dev builds are one of the best things I have to offer to people donating and supporting me in Mystcraft, and I want to offer something in return.

By and large though, I’m skipping the most important point, and we’ve all kind of missed it. It’s Mojang’s EULA, not ours.
What I mean is, let Mojang deal with it. If you think someone is doing it wrong, report them to Mojang. Don’t complain to me because you think I’m doing it wrong, complain to Mojang. This is because you don’t have the authority nor the proper understanding (neither do I, for the record) to say what Mojang deems in accordance with the EULA. If Mojang comes in and tells me I am doing something wrong and must change something due to the EULA, then I will. In a heartbeat. (Though it may take longer to implement the change, I will start the change within said heartbeat.)
So, please, leave me alone about it, eh? 😛 Just go complain to Mojang and let the entity of Mojang deal with it.

Stay frosty, everyone. 🙂 Most of you are awesome.

DISCLAIMER: I’m ca Computer Scientist, not a Lawyer! What do I know of EULAs? Well… I’ve read a lot of them. 😛 And I actually studied some copyright law and licenses stuff because it’s relevant, so… actually quite a bit. Still doesn’t make me an expert, though. You have to be a lawyer for that.

EDIT: I have been informed that the second paragraph I quoted (“If you make any content available on or through our Game…”) is probably targeted to maps and game saves, according to people inside Mojang. Even better, but I’ll leave the post as is. 🙂

Note that this version requires at least Forge 1083 (as did the last one). I actually have been working in Forge 1085, so it’s possible that you have to have at least that, but this shouldn’t be much of an issue. Many mods require much later versions. Tested up to Forge 1112.

Also note that some of my entities will evaporate in this update. They shouldn’t be major, however, as these entities have short lifespans to begin with.

I’ve also rebuilt part of my API.

Otherwise this update is largely bug fixes, some new symbols, and new visuals. I’ve added in some localization stuff as well and made the spawnmeteor command more fun for map makers. Oh, and you can hear meteors coming, now.

EDIT: As Bacon Donut reminded me, the writing desk also has a search bar functionality now. I’m sure that’s a plus. 😛

Enjoy!

Check the Mystcraft Forums for updates and the change log.

Download: [1.7.2] Mystcraft Universal 0.10.15.00

After making that post about my plans for the API, I sat down to do it, and instantly noted a few catches.

First of all, event handling got more complicated. I realized that each version of the API would have it’s own version of the events. This was solvable, however, so I continued.

I noted that constants got more interesting. I wouldn’t be able to have public static final variables in the API, as I’d have to set them from inside Mystcraft. This meant they couldn’t be static and final, which means that another mod could accidentally change them, which is undesirable, as that would break other add-ons.
Again, this is solvable, I’d just need to provide the constants in instanced containers. No problem.

Symbols and functions were actually going to be the easiest things to handle, and were part of why I was doing this. Each API would have an internal handler which mapped all the API calls to a core handler system (my internals, which I use). I could wrap each symbol so that the communication became uniform within my system.

Lastly I noticed that I have class definitions in the API which are used for direct communication between any add-ons. This became the stopping point. I realized that, in order to handle these objects, I’d have to have converters set up so that I convert into and out of my internal implementations and I’d have to break how communication currently works for modifiers. There would be some things which I couldn’t convert, either.

Ultimately, it looks like I won’t be able to do this, unfortunately. While looking at it, I did like some of the properties the architecture would provide, so I’ll likely try to do them regardless. I’ll also add in a check for the version of the API loaded, to ensure that Mystcraft provided the classes, and that no other mod contains the API.

I’m still going to take this opportunity to rewrite the API, and I’ll still leave out sections of it for the reasons mentioned in my previous post, but I won’t be splitting the API into packages this way.

I’ll probably continue to think about how I could version the API to make things easier for add-on developers, but this particular approach seems too limited. I can version some things, but not all of it, and if I can’t do all of it there’s not much point to doing some of it.

We’ll see how it goes. For now, I’ll continue restructuring the API.

Cheers!

As a number of people noticed, there was no API for Mystcraft 0.10.14. This was very much intentional.

I intend to completely revise how I do the API, at least on my end. From an add-on dev’s perspective it won’t change a whole lot.

I’m working on a versioned API system. This will mean that older add-ons won’t have to update every time the API changes and that I can add new things and alter the API without breaking stuff, so long as once an API version is released it remains stable.

It will mean I need to be slightly more clever in how I do things, in terms of handling the API, and that I’ll end up doing a lot of mapping API stuff into an internal handling system, but that’s OK.

One good example of why this would be nice: Recently, there was an issue where people would crash if they had both the DragonAPI and Mystcraft installed, because the DragonAPI included an older version of the Mystcraft API. The mismatched class files then caused Mystcraft to crash, as some functions didn’t exist.

So, why the versioned API? So I can support older things (as possible) while not being afraid to move the API forward. So I can easily know what version of the API mods are on. So I can introduce things in different versions without breaking older ones. So that users have fewer conflicts and crashes overall (defensive coding).

It may not be easy, and it might take a bit to move to, but I’m going to manage. 😉

That said, it’s looking like I’ll be releasing the initial API with a lot of missing stuff. Too many things currently being revised and I don’t want to release an API just to break it immediately. So, as odd as it seems, the first version of the API won’t be able to add symbols or instability effects. Most of my events and render handlers will be included, though, so most of the add-ons for Mystcraft will still be possible to update.

Why not instability and symbols? Because I’m rewriting instability. Since instability is tied into symbols at some points right now, I can’t change it without affecting symbols.

Just wanted to make a general announcement about this. It’s the main thing that’s holding up the next release, and I’m trying to sort out the initial API version now.

I hope to have the next release up soon. 🙂
Cheers!