ZTagre

Thanks for your response, Alpvax. After realizing what the value 32767 actually REPRESENTED (the WILDCARD_VALUE for the damage value matching), I was not SO surprised about that particular value; however, I have NEVER set any of my ORES or ITEMS to any metadata value but ZERO. I checked that out thoroughly. I DO, however, admit that, in the case of the ORES and ITEMS in question, I might not have supplied ANY "default" value for metadata myself at all! Some of my ores (those that "dropped" items other than themselves [in the "block" state] when mined WERE given a default value of zero, but I did NOT continue that process with my copper and silver ores. So, I can say that I did NOT actually give these ores any default metadata value myself. Was I supposed to? I was not shown this in the tutorial I read, nor was that ever mentioned as a point in the procedure of creating your own "custom" ore and ingot pairs... I think I am going to have to go back and see what other mods which create "custom" ores are doing, say, when they are "dropped" after having been MINED or SMELTED, because apparently I am missing something in my block and / or item handling... Thanks anyways, and cheers to you! ZTagre.

Not helpful, but thanks anyways Cadiboo :-; I have a little insight into the issue, but I could still use a little help if any of you are really interested in giving a fellow modder a hand... As it turns out, it isn't an Ore Dictionary issue at all, but simply a strange way that other mods are treating my items. Whereas I did not assign any metadata value to my ore blocks (for example) when I created and registered them, and by default the metadata value is ZERO when I look at each of my mods items in JEI and press the [CTRL] key, when I look at the ore block that is generated by the Void Ore Miner from Environmental Tech, the value for the ore block is (for some reason) 32767! Why has the "sign bit" of the metadata value been "flipped", and how do I stop that from happening (I know that there must be a way, as it treats the ores from other mods correctly!). In every case I have seen this problem, I have found that the metadata value for my items has been "modified" to the value 32767! So, because of this , that block is NOT treated "the same" as my normal ore block, and I don't know why that is happening! Did I need to assign an EXPLICIT metadata value for each item my mod uses, in order that some other mod won't need to "guess", or what the heck? Where and why did the "Void Ore Miner" give the ore block from my mod a value other than the default? If I was supposed to provide an explicit metadata value to each item when my mod registered it, I was not aware of this, and for the most part this has not been an issue! Any REAL suggestions for me? I could really use some insight into this issue! Thanks again, ZTagre.

Hello again gents! I have an issue that only surfaces in specific situations, so its sorta weird... I have several ores (namely, a copper ore and a silver ore) that I created and use within my mod, which I also registered with the Ore Dictionary as oreCopper and oreSilver, respectively. These ores work just fine in my mod; I can see the correct texture(s) when the ore is either in "item" state (dropped on the ground), as well as when it is still in the un-mined (block) state (player has yet to use a pick on it). The respective ingots for each ore type mentioned also display their textures correctly when stored in my inventory, or any chest, etc. I guess what I mean to say here is that, all textures utilized for these ores and the respective ingots, whether in inventory, or in the world, in the item OR block state, all appear normal whenever my code or vanilla Minecraft interact with them. Also, other mods that are able to utilize copper and / or silver in recipes accept my versions within those specific recipes, without issue. However, when I go to use my ore in a "custom" furnace (for example) from a different mod than my own, what appears (instead of the expected "ingot" image I registered for it) is that default purple-and-black image, indicating that a texture for my copper or silver ingots can not be found. In a similar way, when the "Void Ore Miner" from the EnvironmentalTech mod "finds" either of my two ores, it also displays the purple-and-black icon, instead of the texture(s) I registered for them! JEI, however, "sees" the correct textures, and I can "pull" ore samples out of JEI that display the correct textures (same with either ingot form...). Whenever I myself smelt those ores, I get the correct ingot texture(s)! Basically, if I had NOT seen the correct texture(s) after having smelted these ores, I would have known I had a problem with one or more of the textures right off the bat! I believe that it has something to do with the way I registered my ores with the Ore Dictionary, but I really don't know what I missed! Like I said, everything works as expected when only Minecraft and my mod are operating on these ores, but when OTHER MODS try to figure out what texture is connected to my ore and its respective ingot, I get the familiar (bad) purple-and-black box icon. Is there some more up-to-date info. on the requirements for properly registering an ore from a custom mod with the Ore Dictionary, or any tutorial tailored specifically to MC 1.10.2 and above? I never really read any tutorial on the "proper" way to do this, and just sorta "winged it", using another mods source as an example. I was happy when the process I used appeared to work! Any pointers would be greatly appreciated, as always! Thanks again in advance, ZTagre.

Hello; I have spent a lot of time setting up automated scenarios in Minecraft worlds, where I often need a chest or crate "filled up" with a specific item or stacks of items, for use in testing. This gets very tedious, even using JEI or the like, because you have to "click" on the item in JEI, and then shift-click the item or stack from your inventory into the chest of crate, often many many times! My question is - does there exist (in any mod) a device that, when supplied with either a specified item (or list of items) will begin to output the items in such a way as one could utilize a pipe or conduit to easily transfer these items into any inventory? Maybe one could turn the device on with a redstone signal (a lever or some such)? So, for example, I need a LARGE CRATE from the Actually Additions mod, completely FILLED with cobblestone. The device I am describing would have a slot (or a group of slots / filter sockets) that would accept the item(s) you need as a sort-of "whitelist", and would (upon receipt of a redstone signal, maybe?) would begin to output either single items, or full stacks, in such a way that I could pipe them into the large crate using conduits from the EnderIO mod (again, as an example)? This device would really be useful in CREATIVE MODE, but could then be utilized to fill containers much more easily than the manual method. Perfect for testing things such as OVERFLOW situations, etc. in automated world build(s). Or simply for supplying any new redstone builds with a "testing" supply of an item... This device would simply "create" the item(s) it sent out (you would NOT need to have those items somewhere in you inventory already, thus the "Creative Mode" concept...). Kinda like an "infinite gas pump", but for whatever item or full stack you desire! Does anyone out there see the benefit of such a device? Have you spent countless minutes transfering stacks of cobblestone (for example) from JEI to your inventory, and then to a target container, just so that you could test what happens when that container overflows within your automated build? Or, say, you need a container with a lot of items to test a new redstone creation out? You CAN get stacks of an item from JEI via countless mouseclicks, but wouldn't it be nice if you could hook up a conduit, turn on a device, and let it run until the "target" container was filled or nearly filled? And you would still have the benefit of CREATIVE MODE, so you would not need to mine or craft these items yourself. The would simply be "pulled from the ether", creative-mode style! I know that I myself could really use such a device; I'm just wondering about anyone else? I am just curious if such a device already exists, and what the name of the mod and the described device is within that mod. I am considering creating such a device myself, as I have never come across just such a device in my modded Minecraft travels. Anyways, again, just curious! Thanks for your time, ZTagre.

Thanks , diesieben07! I did not realize that NOT updating my JDK could have that kind of effect. I get busy, and neglect such things quite often, and I have not made changes to my mod's source in ages. I usually work on the mod during vacations from work (like today), which happen so rarely! This DID solve my problem!!! I won't make that mistake again :-} P.S.- I *KNOW* I should "move on" from 1.10.2, but SO MUCH of the work I've done (plus my entire mod pack) rely on it. And, so far, my mod has strictly been for my own home server use, so I really have little reason to do so!

Sorry to bother you gents, but just today I went to try and update my mod for MC 1.10.2, when I received the following error: FAILURE: Build failed with an exception. * What went wrong: Could not resolve all dependencies for configuration ':forgeGradleMcpData'. > Could not resolve de.oceanlabs.mcp:mcp:1.10.2. Required by: com.ztagre.MysticRevisited:Forge_1.10.2-2.2118:1.10.2 - 1.4.5 > Could not resolve de.oceanlabs.mcp:mcp:1.10.2. > Could not get resource 'https://files.minecraftforge.net/maven/de/ oceanlabs/mcp/mcp/1.10.2/mcp-1.10.2.pom'. > Could not GET 'https://files.minecraftforge.net/maven/de/oceanlabs/ mcp/mcp/1.10.2/mcp-1.10.2.pom'. > sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target I was always able to add new recipes, etc. every other time before now, with the build being easy and successful. I just don't know what's up here... I have not changed any configuration settings at all since my last build...

Update: What I'm going to relate here might just seem a bit crazy, but let me just tell you what I found out! In early development, as I was creating my dungeon (call it my "development" version), I placed it fairly close to my base (which is also just a stone's throw away from my initial spawn point in this world...(sound familiar?). This dungeon was then used to test all subsequent development. So this was also used to test my mob spawner placement within this dungeon. And, as I have already stated, everything appeared to work "normally" (nothing out of the ordinary). My generated skeleton spawner(s) always functioned as expected (within Minecraft "norms"...). But, lately, I have begun to generate dungeons that are at a relatively FAR DISTANCE from my base, so that I could make said dungeons both larger, and more realistic. However, this distance also makes it very hard to get back and forth from my base during testing, so I routinely utilize a mod that has both WAYPOINTS and TELEPORTATION. And now, here's the "rub"... If I place the spawner within the dungeon, and then then quit and save AT MY BASE LOCATION, and then subsequently re-load the saved game, to get back to that dungeon I use teleportation (via this mod I mentioned previously). When I do this, the skeleton spawner behaves badly (as per the problem I have brought up here in this posting...). BUT, if I quit and save while in the relative location of the dungeon, and do not require teleportation to the dungeon site upon re-load of the game, then the spawner behaves exactly as it should!!! So, to reiterate: When I quit and save in a location outside the relative location of the dungeon / spawner in question, and then subsequently use a teleporation mod to get back to the dungeon site, the spawner does not behave correctly! But saving and re-loading while in the general vicinity of the dungeon has the placed spawner(s) working as per design! While I don't yet understand fully just what is actually causing the problem yet, I know that it is NOT (at least, not entirely) the spawner's fault! I seems to have something to do with my "overuse" of this teleportation system and the mod that supplies it! So, for now, this case is closed! Thanks again, diesieben07! ZTagre.

Wow - so this is a wee bit of a mystery, then eh? I know I'm pretty confused, and so I was hoping that someone just might have had the same experience / problem! So, we'll break out the old debugger, and take a gander at what's going on, then! Thanks for giving your time, diesieben07! I as always am much appreciative, and I'll keep you and others up to date on what I find out... ZTagre.

Thanks for the reply, diesieben07! My code? Okay, but you just might be reading more into my "problem" than I intended! In my mod, once I have finished generating a dungeon, I have a "list" of locations x,y,z that I wish to place chests, spawners, etc. Suppose that I have the following coord. picked out for just such a generated skeleton spawner: int x, y, z; String mobName; // Using the following as a template, you can generate // all "on-the-fly" mob spawners with this method! // You simply set the x, y and z coords. to the desired // world coords. for the spawner, and then call utility // method StructureUtils.setSpawnerInWorld(...) with // the world, x, y, z, and mob_name params.! - ARG. x = -179; y = 17; z = 209; mobName = "Skeleton"; StructureUtils.setSpawnerInWorld(world, x, y, z, mobName); Now, whether or not the code below is considered good "practice" for placing a spawner into my world or not, this is what I use: public static void setSpawnerInWorld(World world, int x, int y, int z, String entity_name) // ************************************************************** // A method developed because of the need to generate spawners of // specific mobs within our test worlds during Mod development, // we found it useful enough to add it to our utility library! // // More or less "self-explanatory", the method will generate a // mob spawner of the mob whose "name string" is passed as the // single String param., at the given coords. in the world // specified by the "world" param. // // Some possible mob "name strings": // Blaze // Skeleton // Zombie // Spider // Ozelot // Wolf // (just look up the rest - they're easy to find online or in // the vanilla MC source...) - ARG. // ************************************************************** { BlockHelper.setBlock(world, x, y + 1, z, Blocks.MOB_SPAWNER); BlockPos pos0 = new BlockPos(x, y + 1, z); TileEntityMobSpawner spawner = (TileEntityMobSpawner) world.getTileEntity(pos0); if (spawner != null) spawner.getSpawnerBaseLogic().setEntityName(entity_name); } Please do note that I have used this code VERBATIM to produce skeleton, zombie, and enderman spawners into my maps that all behave exactly as they should! The skeletons actually occasionally generating armor and sometimes enchanted items as well! But, this time, I am trying to place a spawner into a slightly different surroundings - a tower (of sorts). The top of the tower is actually at normal ground level (y = 64, I believe), and the tower "body" actually extends DOWN into the ground (a sort of 20-block deep "pit", if you will...). So you would actually be underground when you "discover" this tower that contains both treasure and generated mods. Skeletons are one of the "key" mobs within this structure. However, like I said in my posted question - this time, for some strange reason, my skeleton spawner will NOT, EVER generate anything but vanilla skeletons, with no armor, and no enchanted items! I just don't understand what has happened here! This exact same code, when it places a skeleton spawner in a different environment, works perfectly well! So, yeah, I'm just a bit confused here! Same world, same game difficulty! In some cases, "normal" random skeleton generation by the placed spawner, and, in THIS CASE, only "vanilla" skeletons! I have even manipulated the size of the rooms at the top of the tower, as well as the position of the placed spawner (from inside the stone ground (inset) to suspended above the ground (hanging from the ceiling). The light level (for all rights and purposes) is exactly the same. Nothing changes! Anything? ZTagre.

I have a quick question concerning mob spawners I am generating in "dungeon"-type structures within my mod. I have created a skeleton spawner in a mod-generated dungeon, and then when I run the code, for some reason the skeletons my mod generates don't ever seem to have supplied random armor, or randomly enchanted bows? I only get "standard" skeletons, with normal, un-enchanted bows. Do I need to tell my mod's skeleton spawner(s) to do the random armor / enchanted bow generation? I thought this would simply occur automatically, simply due to the way Minecraft handles any such spawners (ie.sometimes a spawned skeleton would be given an automatic, randomly generated set of gear, NOT the same as the previously generated skeleton). And, moreover, if in fact I do need to set this up myself (using an / several NBT tag(s), I would imagine?), what do I need to do to produce this random gear effect? I'm just a little bit confused as to how this works, I guess (sorry if it seems a bit of a noob question :-} Any help greatly appreciated! ZTagre.

Thanks for that advice, larsgerrits! I plan on doing just that; however, I felt that KNOWING how to do this would assist in any situation I might encounter, including those where the author(s) no longer maintain the mod(s)... I can't INSIST that those author(s) who haven't already USED Ore Dictionary registration begin doing so, and since the process of ore registration is so straightforward, it's really surprising to me that they didn't do this in the first place :-} I'm relatively new to Minecraft modding, and I realized very quickly just how important ore dictionary registration was for overall mod resource cooperation. PS.- Yeah, it's OreDictionary (one word) I know, I just find that WHAT IT IS looks more understandable when discussed as two separate words...my bad... Again, thanks! ZTagre.

Thanks for the advice, Choonster! Here's what I did (in postInit() ) // Here, we are using the method Choonster provided to // acquire an Item ID for the zeiyocraft:copperIngot" // item, which we will then use to add this ingot to the // Ore Dictionary... ResourceLocation rloc; final IForgeRegistry item_registry = GameRegistry.findRegistry(Item.class); rloc = new ResourceLocation("zeiyocraft","copperIngot"); final IForgeRegistryEntry<Item> zeiyocraft_copper_ingot = item_registry.getValue(rloc); OreDictionary.registerOre("ingotCopper", (Item)zeiyocraft_copper_ingot); It works splendidly :-} Thanks a bunch... ZTagre.

I have recently ran into a situation that I would like to find a way of rectifying (if indeed it is possible!). I have / am developing a mod that has a copper ore and ingot as items. I use these blocks / items for various purposes within my mod (duh), and this is all working out - no problems in this regard. I have added my copper ingot to the ore dictionary as is the "norm", and I know that my copper ingot is usable by other mods which utilize copper ingots in their recipes, so that's working (yeah!). The problem is that I also like using a mod that I have NOT developed myself, but that works fine nevertheless. However, this particular mod ALSO has a copper ore and copper ingot; the KICKER is - that mod's author did NOT add his copper to the ore dictionary. That mod's copper ingot will NOT work in mods whose recipes call for "ingotCopper", etc. Thus, his copper is not compatible with my mod, either :-{ Which leads me to my question: Is there a way to "search" through all the registered items in the RUNNING GAME, "looking" for specific items by their registered ID's? And, then, should a specific item be found, is it then possible to add that item to the ore dictionary "on the fly" so to speak? This would allow my mod (and others I use in my game play) to utilize that particular mod's copper ingot (as an example) in all ore-dictionary-aware recipes. The alternative is to not be able to use that mod's copper for any other purposes but in which that modder intended (ie. recipes within that particular mod only.). That would be a shame! Now, I am aware that there are mods out there that work to "merge" all items of a certain type into one "global" type (that is, take all "ingotCopper" entries in the ore dictionary, and merge them all into a single "ingotCopper", compatible with all mods utilizing the ore dictionary (at least, I think that's what those mods do?). But this particular idea is different, because the item does not yet have an ore dictionary entry (otherwise, I would not be asking this question!). Is what I'm describing at all possible? If so, a small snippet of example code would be most helpful! I would of course provide full credit in my mod's code for the example code I wind up using (or, even, simply giving credit to anyone providing me with a "leg up" on how I might do this). I really hate having that mod's copper going to waste, but I just can't use it for what I need!!! But, even if what I have described (finding an item from an "outside" mod, via its registered ID, and then adding it to the ore dictionary "on the fly" ) is NOT possible, is it still possible merely to find out if a SPECIFIC ITEM is present in the running game? That is, if I wanted to know whether a specific mod's copper ingot was indeed "registered" in my running game, could I do so, and how would I accomplish this? Thanks in advance, ZTagre.

Thanks for your input; I most certainly respect your opinion on this, as (after all) you ARE the "Forge Code" god! My reasons for moving "up" the versions of MC + Forge are really too varied and esoteric for me to go into here, within the space of this forum; suffice it to say that I have many reasons, and they DO make sense to me. I will most certainly arrive on the 1.11.2 MC modding platform eventually! For now, what I am trying to do is ascertain just what mods I WANT to use are actually available for which versions of Minecraft, and THEN I begin to not only RUN that version of MC + Forge (and all the "bells and whistles", such as LiteLoader, OptiFine, etc.)), but I also begin learning to mod for that version as well, so that, in the end, MY mods complement those that I am already using while playing. I started out with MC 1.6.4, with absolutely NO ideas about doing my own mods; then I moved up the list from 1.7.2 to 1.7.10, at which point I knew I wanted to begin modding for my own mod. I only actually began modding for MC 1.8 around 3 - 4 months ago, and have enjoyed the "ride" immensely, troubles trials and tribulations notwithstanding! I only made the "jump" to 1.9.4 after much soul-searching, as each and every time I change MC versions, I seem to lose one or more of my all-time fav mods!!! This is an extremely depressing situation that I do not enjoy at all; however, I know I need to move on eventually. So, yeah, I will EVENTUALLY work on MC 1.11.2, but NOT until I've gotten as far as I can go with 1.9.4 (as I have just done with 1.8...). I am doing it simply for the fun of it anyways, and wouldn't even dream of trying to make money at it or anything! I simply wanted to know if there was something I needed to do in order to run a mod that relied on a seperate secondary mod (such as a library) from within the Eclipse environ. As you have quite clearly stated, I shouldn't be running ChickenBones mods anyways, but that still doesn't tell me how I might set up the conf. dir for mcp. Is this even "a thing" in 1.9.4, and, if so, what is it all about? That's what I need :-} Again, thanks for your input! I am very glad to have finally gotten a response from the famous LexManos, and I DO love Minecraft, Forge and modding!!! Thanks for the BEST TOOL (Forge) a modder could ask for! ZT.

Hello again, folks! I have recently "made the jump" from modding MC 1.8 to MC 1.9.4, and by now I'm finding this version very refreshing (compared to 1.8, that is)! I had learned a TON of stuff from my time spent on 1.8, and a lot of it transferred well to 1.9.4. Recently, I have begun to "test" my mod in use with other mods, to check for problems with compatibility, etc., and for the most part, this has gone quite well. Today, however, I hit a "brick wall", so to speak - I attempted to include a mod which had a "library mod" as a dependency (specifically, the Translocator mod for 1.9.4 by CodeChicken (I think that's his handle, anyhow :-} The Translocator mod apparently requires the "CodeChickenCore" mod to work properly, so I also included that in the /mods/1.9.4/ folder. I first tried this in the "normal" Minecraft environment (that is, NOT the Eclipse "modding" environment...). Everything worked as expected.., and so I expected no problems moving the mod (both Translocator and CodeChickenCore) into the Eclipse modding environment's /mods/1.9.4/ folder. When I tried to run the code, though, I was quite surprised when several windows popped up during the initialization, one of which was asking me to (quote) "Select an mcp conf dir for the deobfuscator", while the other one told me I that it was experiencing difficulties downloading the "CodeChickenLib-1.9.4-2.1.2.42-dev.jar", and that I should try to download the file myself. It was even kind enough to provide a link to the aforementioned missing file. However, upon clicking on this link, I soon discovered that it was invalid! But, like a trooper, I went on a Google search, and although I was able to find several sources for a file named "CodeChickenLib-1.9.4-2.1.2.42-universal.jar", I was sadly unable to find the "dev" version of that file :-{ So, now I was left with a dilemma - I needed to try and figure out just what the heck that window asking for the "mcp conf dir" was all about...; I had never even heard of such a thing before! So, once again like a diligent trooper, I went on a Google quest in an attempt to find out all I could about this "pop up", and what I needed to do in relation to it. What I found was mostly out-of-date info. telling you where you could find what was expected by going to Users/[$USER-NAME]/.gradle/cache/.../.../.../, looking to eventually find a folder named "unpacked", and in that folder one named "conf", and within you would find files with names such as "methods.csv", "fields.csv" & "joined.srg" (well, something along those lines, anyways!). However, in a related post, I soon discovered that as of 1.9.4 this "/unpacked" folder no longer existed, and at that point, the trail grew cold! I now had seemingly no where else to turn ! I could really use a bit of help sorting out some of this, as it is really very new to me, and I'm sure I will need to understand this a lot more as I progress in my MC modding. Some of the things I would like to know are a: Why does the mod work properly in the "normal" Minecraft environment, properly downloading the file "CodeChickenLib-1.9.4-2.1.2.42-universal.jar" and storing it in the .minecraft/mods/1.9.4/ folder like it is supposed to, but when it tries to run under Eclipse, it INSTEAD needs to download a DIFFERENT, "dev" version of the "CodeChickenLib" library (which is no longer present at the specified url...)? b: Where (in the 1.9.4 Minecraft world) is the "mcp conf dir for the deobfuscator" to be found? I have not been able to find any answers on the 'net. I have to assume that there actually IS such a beast, but I have been through the entire .gradle folder tree, and nothing "stood out" as that which the pop-up was looking for... c) I know it's not your problem, but why do you suppose that a file such as the "CodeChickenLib-1.9.4-2.1.2.42-dev.jar" is not kept in the same location(s) as the "universal" format of the file? I mean, since it has obviously been removed from the linked URL, how else is the user of the mod within a development environment supposed to find the thing? I know WHY some mods require "library" mods as dependencies; what I don't understand is why one needs a "dev" version specifically for a development environment? Is this necessary for ALL mods that have "library mod" dependencies? Where can I read more about this topic, as well as about the "mcp conf dir"? Thanks for any and all help in advance! ZT.

Yes, that is of course VERY PRUDENT advice! I check for null all the time; its just a few short if-statements to do a better job! In retrospect, that is was I would have done, were it not for merely trying to get it to WORK in the first place, which I was really focused on! Checking for null alone simply doesn't cut it... Now, while I have your attention (so to speak); what are your feelings on doing what I did within the matches() method (other than, of course, being a complete DOLT and overwriting the saved output ItemStack with a new one, which I can't believe I actually DID :-{ ) ? (That, btw, was fixed IMMEDIATELY!) It sure LOOKED like it did the job, much the same way as what I loosely based it on (RecipeFireworks, MC v1.8). I could EASILY change it so that is copies the NBT data from the staff to the the orb within the getCraftingResult() method, but how "dangerous" or "hard to maintain" is it really, just the way it is? I'm only looking for other opinions...; I already know Choonster's thoughts on this! Thanks bud! ZTagre

So, you mean like if I was perhaps using some other mod along with my own - a mod that (for whatever reason), needed to "modify" the order in which the IRecipe stuff was done, then it is possible that matches() might then NOT be the primary function, called before the other methods as one would expect? Wow; I don't know... But, I do see your point, and, like I said to Choonster, I AGREE that keeping each method and the data it works with "encapsulated" as a unit is a good design consideration. I really was simply trying to save some "clock cycles" (so to speak) . I'm an old C and assembler coder from way way back, and much of the things I do in code is because, unlike with Java, NO guarantees were made about the default values of created variables, etc; if you did NOT explicitly SET a value at creation time, then very bad things could come along later and bite you on the you-know-what; also, saving every bloody bit of clocks was an issue as well back then! Heck, I would not even DREAM of performing a loop more than ONCE, if I felt that I could get away without doing so!!! So, yeah, I'm finding some of these aspects of Java hard to get used too! I will though, I promise!!! Thank you for your input, as well :-} Cheers, ZTagre.

You know, I considered that EXACT POSSIBILITY when I saved the index; like "what if the other functions don't get the correct value for the staff index", and then I reasoned: a) If matches() has NOT yet been executed, then exactly why is/are the other method(s) even being executed at all? I mean, if the physical "test" for a legitimate recipe has NOT PASSED MUSTER, then no item should be available as an output from said recipe. b) What would method getCraftingResult() use as the result of a recipe that had not yet gone through the check(s) done by matches()? Would it be LOGICAL to show that "result" item? If so, would the "result" item appear only momentarily, until matches() failed? Now, please understand, I fully agree with you that each method should be "self-contained", as you say, and should not rely on any previous method having been called first. It's just that, when I considered what the "order of operation" should be within the entire item-crafting process, the only logical order I could SEE was that matches() would be called almost immediately, and at the VERY LEAST before getCraftingResult(), getRecipeOutput() or getRemainingItems(), because each of those methods should do NOTHING when the recipe is a non-match. And those methods are the only ones where I might have used this saved index! It seemed like a "no brainer", really :-} So that's why I felt it would be safe to save this index for later use... Once again, I thank you for your advice! ZTagre.

Hey, Choonster, if I could ask you just one more quick thing before I do the re-write on this? Is it NOT okay to "save" the index of the staff that was found in the crafting grid in matches() in a private class variable, for later use by the other methods? I just thought that by saving it, I would be saving a few more lines of iterative code, "looking" for it all over again...; if this is wrong, I don't want to repeat that mistake :-} As a class private member variable, I know no other class code can touch it, so I felt this would be "safe" as you say "across states"...; if this is not the case, then maybe explain? Thanks a bunch.

Yeah, you're right! I didn't need that .copy() method there...; I think I put that in while trouble-shooting, and just forgot about it! You only have to set the array index to the value of the stack "directly"... So, instead of: itemstack_array[this.source_item_index] = stack.copy(); it should just be: itemstack_array[this.source_item_index] = stack; Got it! Thanks!

Wow! Thanks, Choonster! Geez, I'm kinda surprised that it actually works, now! Let's see, what I did wrong: 1) I actually used a new ItemStack to set the OUTPUT stack, thus OVERWRITING the one I passed in with the constructor! - yep, I see that quite clearly now! 2) I got WAY carried away doing most of the stuff in matches(); I realize I was not sure about just WHAT to do in most of the other methods, so I hung everything on matches; when it worked, I assumed that was okay. My bad! BUT - in my own defence, let me just say that if you were to look at (say) RecipeFireworks for MC 1.8, they did a LOT of stuff in matches(), and so very little in any of the other methods! It may have been a bad example, but , hey, it was VANILLA code :-} 3) Sorry, exactly WHERE did I "copy" an ItemStack that "wouldn't be stored anywhere" (I mean, if more than one, then WHICH) ? I used output_stack.copy() because the VANILLA code did, in getCraftingResult(...). Otherwise...(?) Thanks again for the input! Much appreciated... ZTagre.

Just FYI, people: So that you know your help has been useful, I would like to report that the item I was describing at the start of this topic is now FULLY FUNCTIONAL, and I have you folks to thank for this! So, in the spirit of sharing with the community, I have attached a link to the working Minecraft 1.8 source for my IRecipe implementation "RecipeDetachChargedOrb", which is fully commented, in case anyone may be interested! I have not attached the source for the reverse recipe "RecipeAttachChargedOrb", but if anyone is interested in THAT, I will happily post that as well! Thanks again! ZTagre. PS - I have a strong chin so if anyone wishes to critique my work, go right ahead! I welcome all insights and suggestions! Also, before you begin : I LIKE (and probably OVERUSE) the "this." when referencing class member variables; I am aware I don't (always) need to do this :-} RecipeDetachChargedOrb.java

Good to know! Thanks, Choonster!

Thanks for your input, diesieben07! It sure looked good "from a distance", and when I could not find ICraftingHandler in the vanilla 1.8 code, I was quite disappointed! I assumed, once again, that it was something "new", added to later versions of MC / Forge, and that I would sadly have to do without! It's kinda nice to know that it wasn't "all that"! ZTagre.

So, all I really need to do is create an IRecipe implementation? That's it? Wow, I had that WAY overcomplicated! I'll need to have a think about it, but I'm pretty sure I've got it covered...thanks, bro! As per the info on ICraftingHandler - it seemed like a pretty cool thing; I saw a piece of sample code, and I thought it looked like just what I needed! I have included it as an attachment to this reply, if you'd like to see it! Thanks a bunch! ZTagre Minecraft forge tutorials sea2 - item taking damage when used in crafting.Source.txt