Quote from Voxel_Bender
I wonder if they dug through the game's code to find this or actually tried it in-game.. hmm
I was actually looking for some other code (NBT tags to update this article). I randomly noticed "jeb_" in a file with sheep code. I saw that it was checking for the sheep's name, and figured the rendering code was to make the sheep have special colors or something.
I tried it in-game, and I wasn't far from the mark.
1
These projects all distribute compiled code of their libraries, as opposed to source code. If that's acceptable, then so is my dungeon-generating library: its compiled code would be distributed with the plugins/mods which use it, but I retain the rights to the library itself. Good for me.
That also debunks an earlier claim that "all Forge mods and Bukkit plugins derive from Forge/Bukkit, which in turn derive from Minecraft, and thus all of them are derived from Minecraft". Forge mods and Bukkit plugins don't include/provide Forge and Bukkit - they merely use it. They actually don't even contain the compiled code. At that point, the only thing that lets the argument "Mojang owns the rights to mods/plugins" stand is the "content available through Minecraft" part of the EULA.
That, in turn, leaves me asking how far "content available through Minecraft" goes. Is a private, in-house server plugin available through Minecraft if the server itself is publicly available? According to your quote, it doesn't apply to libraries used by mods - but the general consensus here is that it does apply to mods used by other mods (mod loaders and APIs)?
As for cascades going down and not up - I suppose cascade was a poor choice of word. There is an "up", however: it comes from systems like Forge making mods available to Minecraft when they otherwise would not be. The mod itself is not available through Minecraft until Forge acts as the bridge, just as my dungeon library would not be available until connected via a mod/plugin. The "up" which propagates is not copyright or derivation, but rather the obligations described in the EULA: if all dependencies do not comply with the EULA, the content as a whole cannot comply. And that (combined with the "all content must be your own work" clause) is what puts MCedit, Bukkit, and WorldPainter in the gray area.
Anyways, as you suggested before your edit (at least, I think it was you), I've sent an e-mail to Customer Support regarding Mojang's meaning of "content" and interpretation of what the EULA means for projects making use of libraries. Given Grum's recent posts on Reddit, however, it would appear that the entire "Content" section has nothing to do with mods and tools at all, and the EULA thus has zero consequence on libraries and copyright.
Free speech is a liberty, not a claim right. It protects you from having others stifle your speech; it does not actually require anybody to listen. Sorry to be blunt, but implying Stratagerm's words interfere with your own right to free speech is absurd: he's well within his own right to free speech to say he doesn't want to hear something from you. Nothing personal; I just hate it when people try to use "right to free speech" as an obligation in internet arguments like that.
1
Alright, I suppose that settles Forge, Bukkit, and oddly enough, resource packs. That last one could actually be a can of worms itself, as it would imply that resource pack creators need the right to grant Mojang the permissions required by the EULA - and thus packs containing GPL or Creative Commons content (for example, Kevin MacLeod's music, or packs which add royalty-free weather sounds) may be in violation of the EULA, even without violating any copyright.
I felt the need to go beyond modding in the discussion, because mods are far from the only Minecraft thing where "ownership" has been debated. As for the dungeon-generating library I mentioned, I actually am working on one. I originally planned to just make a Minecraft Bukkit plugin, but I've since broadened the scope of the project and may want to use it in a stand-alone game unrelated to Minecraft - and don't want to be told somewhere down the road that I have no rights to that game.
I don't mind Mojang saying they hold the rights to the plugin, but I would mind them claiming the library behind it. I wouldn't expect Mojang to make such a claim, but I don't want somebody else to be able to argue that I have no legal rights regarding the work.
The term "belong" is never defined in the EULA, and could mean anything from "you have copyright" (which it clearly doesn't) to "you get to say you made it, but can't really say much beyond that", to even something as insubstantial as "it doesn't actually belong to you in any important sense, other than the fact that at some point in time you had a copy of it on your computer".
Without any explicit meaning given to the use of the word "belong" in the EULA, anybody can argue about what it does or does not mean. By comparison, YouTube explicitly states that uploaders retain copyright to their work but give Google the right to host and share the content. Mojang could have done the same - leaving the copyright to the creator and simply giving Mojang the rights outlined in the EULA - but the word they used is vague enough that they (and more importantly, anybody else) can say the creator has zero say over the work and need not even be acknowledged for creating it.
This is actually another reason I brought up the example of my dungeon generator library. If I wanted, I could decide to never produce any Minecraft-related content for it (unlikely, as Minecraft was the main reason I started the project), and thus it would not be bound by the EULA and also would be under my copyright. However, I could release the library (as open source, no less - and this is a thing I actually plan to do when the time comes, but currently I've been told to not do so). I could release the library and say that it can be used for anything anybody wants - I could choose a license such as GPL or Creative Commons; the only real term I care about is Attribution.
Now, the problem I have with the EULA is: from what we've discussed, it seems it would be a violation of the EULA for anybody to produce a plugin/filter/mod which makes content produced by my library available through Minecraft. I would not give people the permission to give Mojang their requested rights over the dungeon generating library - and as a result, any plugins/mods making use of it would be breaking Mojang's rules.
That is what I don't like about this "fuzzy rights" business. If you're right in saying that a plugin using the library makes the library itself available through Minecraft, that would mean that in order to comply with the EULA, Mojang needs not only permissions the library already openly grants via GPL/CC (which would have already given Mojang the permissions they needed, but would have had obligations of their own, such as attributing the work to its creators), but they need to be able to say that they have copyright over it.
Also, I don't think you're correct in saying I never had rights to the content to begin with: I am perfectly able to create the library before the plugins which associate it with Minecraft. If I never choose to make said plugins, the library would never have had anything to do with the EULA. That's why I would have expected the library to not be bound by an EULA even after a separate application gets involved - but you argue otherwise. If the plugin does cause the library to be subject to the EULA, then rights did get shifted to Mojang. Otherwise, I would not be able to agree to Mojang's EULA even though I wrote both the plugin and the library myself. Therefore, under that interpretation, agreeing to the EULA for that plugin will transfer my rights for the library to Mojang.
I'm sorry I've written so much, but I'd like to point out one more reason why this "cascading rights" idea is a bad idea if it's an actual consequence of the EULA. It would mean that it is already a violation of Mojang's EULA to use many libraries in any Minecraft-related content. MCedit would violate the terms because it can't give Mojang exclusive rights to Pygame. Bukkit would violate it because they can't hand over exclusive rights to GSON, SQLite, MySQL, SnakeYAML, or any of the other libraries they use. WorldPainter would violate it similarly by using Install4J.
For now, I'll be playing it safe and not publicly releasing the plugin or library even when it's done (I was already told to do that before anyhow, or I'd lose my shot at seeing the day a large server uses it). But I find it ridiculous to think the aforementioned projects are all in violation of Mojang's EULA. But, who knows, that may be exactly the case.
I'll agree with your first point, as those games clearly can't violate Mojang's copyright without any sort of derivation or content taken. However, I'm not so sure about your comments on trademarks: trademarks cover names/text/shapes/designs, not gameplay concepts. Unless Mojang has trademarked their GUI layout, or the offending game has re-used something like the creeper face or imitated Minecraft's name, trademark alone wouldn't win Mojang's case. If Mojang were to acquire software patents to concepts related to Minecraft-like gameplay, on the other hand, they may be able to get farther with regards to suing voxel games. Thank goodness Mojang's not like that
2
I've seen it argued that many mods bypass the "derivative of Mojang's work" clause by instead plugging into Forge, Bukkit, or other third-party APIs and not containing any work from Mojang at all. That, in principle at least, should mean that creators of such works have retained their copyright.
But whenever these big arguments flare up, many (some Mojang staff included) have apparently considered that view invalid. Sometimes, "it's a derivative of Mojang's work, and thus fully copyrighted by Mojang" is argued by various people to apply not only to mods, but to plugins, third-party programs, resource packs, and even completely unrelated games (think of the many people who have insisted Mojang can sue just about any voxel-based game for copyright violation, even when code and assets were never derived or reused).
Will there ever be a non-contradictory answer to this question? Will works which are on the fence (Forge/Bukkit mods and plugins, programs like MCedit, etc.) just constantly flip-flop between "copyrighted by the creator" and "copyrighted by Mojang" when people start arguing about who gets to do what?
Marc, if I produce a code library for generating dungeons, capable of functioning without Minecraft, do I have any rights to it? If I produce a Bukkit plugin allowing the dungeons to be created in Minecraft, do I lose what (if any) rights I had to the dungeon-generating library? If I produce an MCedit filter allowing MCedit to bring those dungeons into Minecraft, do I lose those rights? If I produce a mod so those dungeons are generated directly in Minecraft with no middle-parties, do I lose those rights? If somebody else produces a plugin, filter, or mod allowing my library to interact with Minecraft, do I lose those rights?
I don't honestly expect answers; sorry if you read this and feel I've wasted your time. I understand that you're not a lawyer, and from what I can tell, most of those questions couldn't be truly answered outside a courtroom. From what I've learned as a computer science major, I would have thought the answers were Yes, No, No, No, and No. But it seems the majority of vocal Minecraft mod users would argue otherwise, and copyright law itself is convoluted enough on the matter that it's not even clear-cut whether or not all Java code (Minecraft's included) is a derivative work of the Java API.
Sorry for the rant; this situation of ambiguity has just bothered me for some time.
0
I was actually looking for some other code (NBT tags to update this article). I randomly noticed "jeb_" in a file with sheep code. I saw that it was checking for the sheep's name, and figured the rendering code was to make the sheep have special colors or something.
I tried it in-game, and I wasn't far from the mark.
0
Alright, that's what I was hoping. Thank you.
0
The first sentence I fully understand and have no problem with, but the second seems to me to have a hitch. By "let us permit other people", does it mean only Mojang (or, obviously, you) could extend the permission to use/copy/modify/adapt your content, and must explicitly do so? Or would the full permission implicitly be extended to everybody without Mojang even having to say or know about it?
I.e. Let's say someone makes a private server-side plugin under a deal to get a cut of the profits made by using the plugin. If the server owners decide they don't need the plugin creator anymore, can they merely make some small modification to the plugin, call it their own, and stop splitting profits with the plugin creator? Or would Mojang have to step in and grant the permissions to the server owners before they can do this?
And regardless of how many people are granted permission to use, copy, modify, and adapt the content, the original expression (i.e. the original plugin, in my example) still remains copyrighted by the original creator, right? Although, I suppose in a more Creative Commons-like form, as the normally exclusive rights have been irrevocably given away.
0
1) Yes and no. There's no built in feature for event triggers like that; you'll have to clobber together something to accomplish that instead. It's the same way the game doesn't have individual blocks which act as redstone AND gates, but you can use other blocks to make your own AND gates - you need to put things together to build a system that'll accomplish what you want.
Although you're limited to standalone vanilla, you could still do a number of things:
2) By "player damage to items", do you mean how tools and armor take damage as they're used? You can use the "{Unbreakable:1}" tag when /giving yourself an item, or use and NBT editor (or NBT editing MCedit filter) to add the tag setting a Byte Unbreakable to 1. You can't control items the player crafts, however - only ones you give to the player.
Also, I'm not sure what you mean by "disable block damage". As far as I'm aware, there aren't any ways to prevent players from destroying blocks (Adventure mode still lets them break blocks if they have the proper tool), apart from giving them a very long high-level Mining Fatigue effect. If you mean disabling damage to blocks from explosions, that can't be done either (except for doMobGriefing, which only applies to mob-based explosions like creepers, ghasts, and withers, and doesn't block TNT damage).
Finally, you mentioned something about learning Java. Just as a heads-up in case you didn't know: you can't really use Java for standalone vanilla Minecraft maps. You can use it for mods or Bukkit plugins, but you don't include Java code in standalone vanilla maps.
0
That's because the filter (by SethBling) needs to be updated. It's using Block 36, and 1.7.2 has made that item forbidden in inventories and shop windows.
0
However, this data is not stored in chunks. Biomes, blocks, entities, lighting, tile ticks, etc. are stored in chunks, which is why manipulation operations in MCedit will properly move them around.
The new data is actually stored in separate .dat files in the data folder. That's the same folder storing the scoreboard, village statistics, maps, etc.
Also, it describes structures in terms of their components and arrangement, rather than areas where mobs can spawn, making it pretty inflexible for mapmakers*. I suppose this is also the reason it's not tied to chunks: even a single component of a structure can span several chunks, as is the case in a nether fortress. Unfortunately, MCedit would have a hard time moving structures around, due to that very fact, and I'll hedge my bets that no such feature has yet been implemented in it.
*well, you can specify a component's bounding box, but it's pretty inflexible in the sense that you're stuck with Witch Hut or Nether Fortress as your only distinct spawn condition sets - as far as I can tell, there's no reason to trick the game into believing a region of space is a mineshaft, stronghold, or any other structure without unique spawns.
0
Is that specifically at runtime? Because when chunks are written to disk, they seem to be only stored as 4 bits per block. Does your mod store new byte arrays for the RGB components, or does it convert all light data into a single int array?
All in all, nice work!
0
Lighting calculations are actually done by the server, not the client - the client can just convince the server to update its values, but even then the server decides how.
MCedit's reason for forcing the updating of lighting is a measure of convenience: to speed up operations, the pymclevel implementation doesn't worry about lighting at all, essentially destroying meaningful data (if I recall correctly, it simply winds up assuming a chunk is fully lit after operations occur in it). Thus, to prevent lighting glitches when returning to the world, it re-calculates lighting data.
I'd like it to be optional, but regardless, it should be enabled by default. If disabled, you could wind up with some pretty annoying phantom light sources (I've had these before - the light does not go away until you've placed a block in *every* phantom-lit cube, making it essentially unfixable in large areas without MCedit).
It works perfectly fine in 1.6.2. If you want to use blocks it doesn't recognize, just use their ID values.
0
It might be tough to come by another one that gives free massages
On a serious note, Pigos2000, try uploading the file to this and link the results here. That is, upload it after you've downloaded it. It's possible you have something nasty that's infecting the file after it's downloaded, so you don't want to set up an exception just yet.
0
From what I can tell, the scripting support here is very good compared to WorldEdit's own scripting support - even if only for the fact that filters can use GUIs and NBT tags aren't immutable (the latter of which tends to make WorldEdit craftscripts horribly verbose when doing anything even moderately advanced).
As someone with a decent bit of experience in WorldEdit scripting (I've written eight complete WorldEdit scripts which have noticeably sped up mapmaking work for a group I'm in), I have few questions (yes, I'm too lazy to look through the Github source in-depth):
Anyways, great work.
0
That's pretty neat!
It's a shame that filters need porting over - Python just makes filter creation so much more elegant.
From what I can tell, the scripting support is very good compared to WorldEdit's own scripting support - even if only for the fact that filters can use GUIs and NBT tags aren't immutable (the latter of which tends to make WorldEdit craftscripts horribly verbose when doing anything even moderately advanced). As someone who's been writing WorldEdit scripts in place of MCedit filters for in-game editing support, I have a few questions/suggestions about your scripting/filter support.
(cutting off my post here; will continue on your thread as I don't want to get too off-topic)
All in all, I'll probably be sticking with MCedit for filters and WorldEdit for in-game scripts, mainly because I'm already used to the workflow and have most of the scripts I'll need for ingame editing purposes (whereas I tend to reserve filters for operations which I don't use as frequently, such as converting chests into villagers and vice-versa).
2
This is a mod for an old, pre-Indev Minecraft version, called RubyDung, version rd-160052. I thank GiveMeKarmaOrDie of Reddit for inspiring me to make this, with the above statement.
This mod adds 250 blocks to RubyDung, as well as several of modern Minecraft's movement controls and a few other features.
Screenshots:
You may view a full gallery of screenshots in the Imgur gallery here. It also explains the changes made by this mod.
Full Changelog:
Download and Installation:
You can download the mod here.
The process of installing this mod is the same as any other mod installation, apart from the fact that it's for version rd-160052. To get this version, start the Minecraft launcher, click Edit Profiles, check the "Allow use of old 'alpha' Minecraft versions" checkbox, and set "Use Version" to "old-alpha rd-160052". You may also wish to choose a different directory other than .minecraft for this profile, to avoid corrupting any of modern Minecraft's files. Simply try playing the game once, and the version will be downloaded.
After this, you go through the normal process of mod installation by copying the folder, changing its name and the names of the files inside, and editing the JSON file's "id" tag. After you copy the files into the JAR, you are ready to reload the launcher, select the modded version, and play. There is no META-INF to delete; this version is too old to even have one.
Copyright © 2013 WolfieMario:
TERMS AND CONDITIONS
0. USED TERMS
MOD - modification, plugin, a piece of software that interfaces with the Minecraft client to extend, add, change or remove original capabilities.
MOJANG - Mojang AB
OWNER - WolfieMario, Original author of the MOD. Under the copyright terms accepted when purchasing Minecraft (http://minecraft.net/terms) the OWNER has full rights over their MOD despite use of MOJANG code.
USER - End user of the mod, person installing the mod.
1. LIABILITY
THIS MOD IS PROVIDED 'AS IS' WITH NO WARRANTIES, IMPLIED OR OTHERWISE. THE OWNER OF THIS MOD TAKES NO RESPONSIBILITY FOR ANY DAMAGES INCURRED FROM THE USE OF THIS MOD. THIS MOD ALTERS FUNDAMENTAL PARTS OF THE MINECRAFT GAME, PARTS OF MINECRAFT MAY NOT WORK WITH THIS MOD INSTALLED. ALL DAMAGES CAUSED FROM THE USE OR MISUSE OF THIS MOD FALL ON THE USER.
2. USE
Use of this MOD to be installed, manually or automatically, is given to the USER without restriction.
3. REDISTRIBUTION
This MOD may only be distributed where uploaded, mirrored, or otherwise linked to by the OWNER solely. All mirrors of this mod must have advance written permission from the OWNER. ANY attempts to make money off of this MOD (selling, selling modified versions, adfly, sharecash, etc.) are STRICTLY FORBIDDEN, and the OWNER may claim damages or take other action to rectify the situation.
4. DERIVATIVE WORKS/MODIFICATION
This mod is provided freely and may be decompiled and modified for private use, either with a decompiler or a bytecode editor. Public distribution of modified versions of this MOD require advance written permission of the OWNER and may be subject to certain terms.