• 1

    posted a message on To Mod Creators: Copyrights and Malicious code
    Quote from EnzerDeLeo

    Edit: I had a much larger post here regarding this issue, but I am going to replace it with clarification I got after the matter.

    "User vs provider.
    MCedit uses Pygame, it does not provide code to Pygame that would create the "down stream cascade" link necessitating handoff of rights.
    Same with Bukkit and Worldpainter with GSON, SQLite, MySQL, SnakeYAML, and Install4J.

    Remember, cascades go down, not up."


    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.

    Quote from EnzerDeLeo

    I'm sorry, but you cannot infringe on my protected right to free speech to spread the information Mojang has presented.

    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.
    Posted in: Mods Discussion
  • 1

    posted a message on To Mod Creators: Copyrights and Malicious code
    Quote from EnzerDeLeo

    The thing you are missing is that the EULA states "If you make any content available on or through our Game". It doesn't matter if the mod uses Forge or whatever. Is the content you produced available on or through (this is the part that overrides excuses such as "But my mod uses Forge" since the modded content is still available through Minecraft) Minecraft? Did you release this content publicly? If yes then you agree to their EULA. If you do not agree to the EULA, then do not release the content publicly and keep it to yourself.


    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.

    Quote from EnzerDeLeo

    Most of your post is a bit irrelevant since for the most part we have only been discussing mods while you are discussing things like filters or theoretical applications that do not have a real life equivalent for the game currently.


    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.

    Quote from EnzerDeLeo

    Things like your "dungeon code library" would fall under the end bit. In my opinion, on what the EULA states and what Mojang has said, the application of that code that is used on/through the game would fall under Mojang's rights, but the actual library may not if it is a standalone thing. Really this is a tricky thing to ask because in my opinion I do not think Mojang as a company would care (because honestly they are only putting their foot down on this issue right now because the modding community has decided to not play nice), but that example would really be something that would have to be fully discussed in court. You take your dungeon library and make your own game completely unrelated to MC and it uses that library, is Mojang going to care? Probably not since it doesn't directly affect their game at that point, what is the official stance? You'd have to ask a judge.


    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.

    Quote from EnzerDeLeo

    Content you make still belongs to you, however content belonging to you is completely different than having copyright over said content and completely different from giving the right to Mojang to extend privileges to itself and the rest of the user base through agreement (publicly releasing your content) of the EULA.


    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.

    Quote from EnzerDeLeo

    Ultimately you are thinking of things a bit off. You are not losing rights, as per the EULA, by agreeing to through releasing your content publicly, you never had rights to the content and it is not so much as Mojang holds copyright over that particular content, but rather that the content falls under Mojang's current copyright for Minecraft (which is standard for derivative work law as copyrights are not given out freely separately from original works and when they are it is usually granted by a judge.. this is why Mojang is stern about any content you release has to be your own, since that released content is filed under their copyright, so if you release content from a copyrighted source, that copyrighted source is now being pushed under Mojang's copyright which could get the company into trouble, which is why the EULA states "we may hold you responsible and that means you may have to pay us back for any damage we suffer as a result" in regards to Mojang being sued because of content you released). The only time this does not apply is if the content is not publicly released.


    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.

    Quote from EnzerDeLeo

    As for this "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)" that is more or less people not understanding what copyright is and Mojang has never stated they had any intentions to do this. Mostly this would be more a trademark issue, I think, where a game is a little too similar that it could be considered to be infringing on Minecraft's trademark. Kind of like how if you made bootleg versions of an action figure, you would be infringing on the owners original trademark.


    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 :P
    Posted in: Mods Discussion
  • 2

    posted a message on To Mod Creators: Copyrights and Malicious code
    Quote from Marc

    Mods are subject to the Minecraft EULA.


    Quote from Marc

    I picked the less nonsensical choice, but don't misunderstand me. I think the poll on this topic was created from a misinformed viewpoint, so the poll itself is sort of invalid, regardless of the results. It's not that modders should or should not copyright content, it's that they cannot do so.


    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.
    Posted in: Mods Discussion
  • 0

    posted a message on Rainbow Sheep - New and Exciting Ways to Liven Up Your Livestock
    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.
    Posted in: Minecraft News
  • 0

    posted a message on Cause for concern
    Quote from IronMagus

    Basically by creating content for the game, you're granting Mojang license to do whatever they want with it, including share it with other people. But you're not necessarily granting those other people the same right, unless and until Mojang decides to share it with them.


    Alright, that's what I was hoping. Thank you.
    Posted in: Discussion
  • 0

    posted a message on Cause for concern
    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.


    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.
    Posted in: Discussion
  • 0

    posted a message on MCEdit: Minecraft World Editor (Now open source!)
    Quote from Cathulion

    I LOVE THIS! I'm making a adventure map....

    I have a few questions if anyone can answer them please :)

    1) Is there a way to add variable triggers with MCEDIT?(Ex: Boss dies, treasure room opens as a result of what I need done). If not, what other programs can create stand-alone triggers(downloaded with map files for unmodded minecraft) not needing to download BUKKIT variable trigger plugins just to make my map work properly?

    2) For adventure maps where I need to disable block damage, can I disable player damage to items from MCEDIT or ingame player commands or how else if not either of those 2?

    I don't know how to java code yet, but I plan to in the future so it's hard at the moment...thank you for your time in advancement for answering my questions.


    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:
    • The most generic solution would be to have the boss drop a custom item, and have the player use that item as a "key" in an item detection system, unlocking the treasure room. Two issues: if you've disabled mobLoot, this won't work at all. Even if you haven't, there's always the risk of the player losing the key item, meaning they won't be able to progress (at least, not unless you let them fight the boss again).
      • You can actually use command blocks and the /clear command to remove the item from the player (and trigger a redstone output), removing most of the risk. Even so, the drop could still be destroyed by an explosion or fire before the player has a chance to pick it up.
    • If your boss is the only entity of its type in a particular area, you can have a spawner capped to 1, attempting to spawn another of the same type somewhere outside the battlefield, on a pressure plate. When the boss is killed, the entity is spawned, triggering redstone. This trick won't work if non-boss enemies of the same type are also in the vicinity, and also, you can't control the vertical detection radius very easily so the battlefield will have to be mostly flat. This is what Hypixel did in Herobrine's Return 2's final battle.
    • If your boss is the only entity of its type which the player can kill without leaving the boss room, you can use a scoreboard objective. Reset the player's score when they enter the room, and when the score goes up, you know the boss is dead.
    • A bit of an unorthodox method, but have some combination of negative-sized invisible slimes and other entities ride the boss. When the boss dies, the negative slime on its head will fall through the floor, and you can use the rest of the entity stack to detect things (e.g. if they pass through tripwire, or if detector rails no longer detect a minecart which was part of the stack).
    None of these things require MCedit, although it can help. Also, none can be done magically at the click of a button, since they're made of many smaller steps (although, a filter could condense that to the click of a button! But first, you'd have to find such a filter). I recommend looking into command blocks, redstone, and NBT editing. There are plenty of guides and videos out there, and the wiki has a handy Chunk Format page for NBT editing. I don't think I'll explain any of these tricks in-depth as some are rather involved and you'll only really need to pick one. Your best bet is probably the scoreboard objective method, as it's pretty much the least involved/finicky.

    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.
    Posted in: Minecraft Tools
  • 0

    posted a message on MCEdit: Minecraft World Editor (Now open source!)
    Quote from ZockerAxel

    if you create shops they arent working in 1.7.2 the only thing which happens is that your minecraft crashs or if its a server where you playing on you get disconnected because of "Internal Server Error"

    Can you fix it, pls?

    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.
    Posted in: Minecraft Tools
  • 0

    posted a message on MCEdit: Minecraft World Editor (Now open source!)
    Quote from evilsupahfly

    MCEdit will move or copy everything in an area that you select, including biome data, and you can export raw chunks, and while I don't know for sure, I assume it saves these markers too, since they would be part of the NBT data, but there is no mechanism in place (yet) to specifically maniplulate these data specifically in MCEdit. Now if you take this up with Sethbling, he can probably make a filter to do this.

    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.
    Posted in: Minecraft Tools
  • 0

    posted a message on [1.7.10][Beta][WIP]Colored Light - Progress and Discussion
    I noticed that Minecraft stores all blocks light values into an array of integers.


    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!
    Posted in: WIP Mods
  • 0

    posted a message on MCEdit: Minecraft World Editor (Now open source!)
    Quote from aaronfranke

    Hey, does anybody know why MCEdit forces you to light chunks when you save the world? As far as I am concerned, as of 1.2 the lighting calculations were done by the client, so lighting should be an option for older versions instead of a requirement in my mind.

    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).

    Quote from Lufnar

    So from what i understand, its not for 1.6.2 yet?

    It works perfectly fine in 1.6.2. If you want to use blocks it doesn't recognize, just use their ID values.
    Posted in: Minecraft Tools
  • 0

    posted a message on MCEdit: Minecraft World Editor (Now open source!)
    Quote from wideload

    Or you can get better AV software.


    It might be tough to come by another one that gives free massages :P

    Quote from Pigos2000

    I got a massage from my Antivirus


    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.
    Posted in: Minecraft Tools
  • 0

    posted a message on [1.7.2][Forge] In-Game MCEdit Filters & Scripts - A new Map Making tool! Updated!
    This is pretty cool!

    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):
    • Does your scripting support allow scripts to use the player's location as implicit input? Three of my scripts use the player's location to determine their effects, allowing the user to not have to worry about typing in coordinates manually (if you're wondering, they have to do with appending coordinates to command blocks and assigning spawners' spawn positions). This was actually the entire reason I learned craftscripting - so we could finally stop having to hit F3 and type out our coordinates: things become so much more convenient when your in-game avatar can be used as a cursor.
    • Can scripts for your mod gain access to other APIs? WorldEdit craftscripts have full access to the Java API, WorldEdit API, and can even hook into Bukkit/CraftBukkit. Your mod uses the Forge API - by any chance, can scripts access that?
    • How does Undo support work for you? WorldEdit craftscripts have the full backing of the WorldEdit Undo/Redo history system for any blocks which they modify (unless they're coded incorrectly - but, for a proper script, the undo/redo feature is passively functional without the need for explicitly defining history-related data). It's interesting to note that the undo support in WorldEdit works even if a script edits blocks outside the selected region - a feature not present in MCedit.
    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). I just thought I'd ask those questions as they may give ideas for future features, if the mentioned things aren't already possible.

    Anyways, great work.
    Posted in: Minecraft Mods
  • 0

    posted a message on MCEdit: Minecraft World Editor (Now open source!)
    Quote from Davidee

    For those interested, I ported over some of these MCEdit filters into my new mod. That's right, you can now run filters in game! Note that the filters must be written in javascript (not python), so porting a script will require some work.


    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).
    Posted in: Minecraft Tools
  • 2

    posted a message on [rd-160052] DiamondDung: A mod for Pre-Indev rd-160052, aka "RubyDung" - 12+ Features and 250 new blocks
    "Mods don't exist for this old, old version."

    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:
    • Leftclick now breaks blocks, and rightclick places blocks, to mimic modern Minecraft default behavior.
    • Middleclick or LeftControl-Leftclick serve as the Pick Block function.
    • F key toggles "fast" mode, which allows you to quickly place/destroy blocks.
    • Escape and T keys now pause the game. Any key except Escape will also unpause the game.
    • LeftShift+Escape saves and quits the game. If the game is already paused, Escape will do this as well.
    • LeftMeta (Windows Key on many computers) is no longer interpeted as Jump.
    • Double-tapping Spacebar allows you to fly or stop flying.
    • LeftShift makes you crouch (move slower horizontally), and descend if flying. You will stop flying if you press this key while on the ground. Note that crouching does not prevent you from walking off ledges!
    • Double-tapping W or UpArrow lets you run. You stop running if the key is released or you press LeftShift. If you're flying, you can still begin running - you will fly faster.
    • F11 toggles fullscreen (but causes Steves to glitch out).
    • F2 takes a screenshot.
    • 250 new blocks have been added. All are building blocks - none have GUIs or special functions, although plants will die unless planted on soil-type blocks and mycelium will spread like grass.
    With a total of 256 blocks (255 of which are selectable... sorry, no Air blocks in your hand, although there is an invisible block you can build with), some controls have been added to make the blocks more accessible:
    • All 10 number keys now have blocks assigned to them. These are spread across the full range of available blocks, to make it easy to skip to certain block groups. The next three functions will let you get blocks which aren't.
    • Scrolling the scroll wheel will change your selected block type by 1 in the direction you scroll.
    • Similarly, Equals/Plus will change to the next block type, and Minus/Underscore to the previous.
    • Period/RightBracket (>) will skip ahead by 16 block types, while Comma/LeftBracket (<) will skip back by 16.
    For all of these, the block inventory will "wrap around" in a circular fashion if you try skipping past its end.
    • Adjusted windowed version to be the same size as modern Minecraft (854x480 rather than 1024x768).
    • Made walking speed slower (flight and running are fast, however).
    • Made FOV change based on whether you're walking, running, flying, or run-flying. Similarly, your screen will lower when crouching.
    • Made blocks darker on the underside.
    • Increased building reach distance.
    • Your location, flight state, and selected block are saved, and restored when the world reloads (you can still use R to respawn at a random location).
    If you're unfamiliar with RubyDung, the following controls are not changed by this mod and are from vanilla RubyDung:
    • Arrow keys or WASD make you move around
    • Spacebar makes you jump
    • Number keys change your selected block type
    • R respawns you at a random location
    • G spawns a Steve
    • Enter forces the game to save

    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.
    Posted in: Minecraft Mods
  • To post a comment, please or register a new account.