Gregory

Just posting an answer for others to find when searching the same issue. Yes, I know it's two and a half years old, but still.... One problem in the code might be that your get/set Profession code uses dataWatcher watchable object index number 16. That's already defined in EntityTameable as a byte. For anyone using the dataWatcher instance, please be aware of the many possible combinations of watchable objects in the super classes. For example, my own investigation might have produced data such as the following table: Entity 0 flags (bit-based?) 1 air (entity breathable amount) 2 custom name tag text 3 using custom name tag 4 isSilent/setSilent: whether to play sound EntityLivingBase 6 health: a float value representing the current HP 7-8 potion effects mapping 9 arrow count in entity EntityLiving 15 is AI enabled/disabled; may not necessarily be used, AI seems to be always-on EntityAgeable 12 growing age, negative values for child entities, positive for adult entities EntityTameable 16 byte-flags for dual-use, maybe? 4bits for tamed state, 1bit for sitting state, .. remaining bits unused? 17 String for owner-entity "name" and so on, and so forth, et cetera, et cetera... In any case, using watchable object index 16 may be one problem, easily fixable; I assume any index not used by a superclass of the Entity subclass you extend, may be used as necessary.

Yes, I have at least one suggestion. I don't know if you play on any SkyBlock maps; but in those, dirt is ever-so-valuable, especially very early on after starting the map. I had the thought that rotten flesh, along with a few other organic mob drops (miscellaneous items like spider eyes and skeleton bones) could be crafted together to make a very crude compost block. After a while, this compost block could have decayed enough to change into a pseudo-dirt-block, with perhaps a chance of a random effect. In some amount of time, it should turn into a dirt block and be farmable, placeable in the world, etc. Of course, if you don't have any interest in the idea, I may just make a one-off proof of concept mod for it.

It worked, and I'm able to edit with NetBeans providing appropriate syntax assistance. Just have to set the jvm options and Launcher classpath in project properties. You, sir, are very appreciated for your helpfulness. Kudos to you. ... I also note that in your last Youtube video, you mentioned perhaps doing a video for building projects with cross-project dependencies, so that debugging/testing will work. Might that still be in the works?

I'm still trying to get that far. My computer is a Windows 7 Home Premium Service Pack 1, 64-bit. I'm using Java JDK 8 with the public JRE within it. Also using the gradle 1.10 and forge build 1047. My JAVA_HOME is set to "C:\Progra~1\Java\jdk1.8.0\jre". My JDK_HOME is set to "C:\Progra~1\Java\jdk1.8.0\bin". My path *begins with* "%JDK_HOME%;%JAVA_HOME%;" followed by the rest of the Windows system paths (the Java pathing goes before the Windows system paths because some older versions of Windows may still have older java.exe files within them). I'm trying to create a "commons" library as a dependency for all of my modding efforts. Yet when I run "gradlew setupDecompWorkspace" I get the following in the gradle log file: https://www.dropbox.com/s/5a424es59j329so/gradle.log but the above process results in the following file system structure (nicely zipped up): https://www.dropbox.com/s/9do345h170tkd0o/GregoryCommons.zip I did, however, notice that while it was processing in ":doFmlPatches", the output had some lines that said "Cannot find hunk target" for some of the classes. Here's the command-prompt results: resulting in some patching rejects among other things. Then, running "gradlew eclipse" on it results in BUILD SUCCESSFUL. Proof: And the new NetBeans 8.0 will import the project, but with a broken dependency on forgeSrc-10.120.0.1047; also, the IDE shows errors in the project's source where the Forge classes are not being recognized.

Okay, I will try updating to the lastest NetBeans; good catch, I didn't realize a newer version could be the answer. If that works, you will have my gratitude. It may not mean all that much to you, but I'm a man who will always share my appreciation where so deserved. For the record, I had been running the gradlew commands as specified in your previous video and in the other threads in this forum. Whether with setupDevWorkspace or setupDecompWorkspace, I was getting the same results. The one difference noticeable about how some of the metadata was being generated and stored, is that a ".gradle" directory was made under the forge root, but where I attempted to load the project, NetBeans also would create its own ".nb-gradle" directory under the forge root. NetBeans puts the log file generated from the attempt of loading a Gradle project into this latter path; but the IDE itself also has a global log file for all of the IDE (generally, plugin loading states and diagnostic information). Not sure how much logging and diagnostic information anyone here is willing to look into; but in the interest of helping other NetBeans users out, I'll try to post more, later. The installer is downloaded now; I'll get things set up, and try without a Gradle plugin first, and report if that was the issue. Expect my next report within a few hours.

This is still an important issue to me. I am almost 100% convinced that the issue has something to do with the difference in the way Eclipse and NetBeans store the dependencies. For the record: I have used NetBeans for a long, long time, at least since I got into C++ and Java development pre-Y2K; and never have I had so much trouble with trying to satisfy the Minecraft + Forge + Gradle dependencies as I have of late. This Gradle setup may make sense to LexManos and others who use Eclipse; but for me, who will not use anything _but_ NetBeans, ... I need more information on the internal workings of the "workspace" setup and how it translates to a NetBeans project. Note that I could go back to the old way of doing things, by creating an empty Java classlib project for each mod and manually linking to deobfuscation-decompilation output files and the assorted utility libraries. But I do think it would be easier to have the (Gradlized) forge directory be the initial dependency for each mod, and figure out some way to link to it from within the NetBeans+Gradle project hierarchy. The truly, seriously, epically REQUIRED part is, documentation on how to setup the dependencies from a NetBeans+Gradle project. If someone has already figured this out, it would be much appreciated pointing out where to look. Eclipse, to all appearances, seems to store its project metadata in a "messy" way, nothing at all like the tidy way that I'm used to.

But that's what I'm already doing!!! *sigh* It's the stress of the situation, really it is. I know this forum has quite a few decent people who are willing to help others, and I'm not trying to come across as being angry; it's just ... the frustration of not having something work. So, I've decided I'll try to help find what more I can do, as much as possible, insofar as I'm able to show you the "big picture". This will be a lengthy post with images, showing the results of my work in the NetBeans end of things. (This post is a work-in-progress. The raw pics should be accessible from https://www.dropbox.com/sh/cryj3aig2a4sl4s/sO7Ggybnvj on Dropbox. I'm tired; Iwill fix the pictures later.) I'm rather new to all this Gradle work; so bear with me if I'm not getting it right. I'd like to begin with a bit of information and a general question about the Gradle project aspect, at least as much as it is used by Forge now. In this third-party module you spoke of, the one I'm using, three variations of Gradle projects can be created: a "Gradle Root Project", a "Gradle Subproject", and a "Single Gradle Project". In context, the first appears to be the "parent container" and the second is the "child container"; the latter one seems to be for making "one-off" Gradle projects where inter-project dependencies are not so much required. So my question is, which of these project models is the forge source download supposed to be? I might guess it would be the latter one, but I could be wrong and NetBeans might be recognizing the forge root as a child project without the parent. Next, I'll begin with the screenshot images, clipped in size as much as possible to show relevant detail. I am creating a smallish sample of four Gradle projects to start. First, in creating the usual sample Gradle project(s), I'll begin with the "root project"; in the dialog wizard I am able to enter the usual sample project name and set the folder location, as well as specify some "Maven" things. (I don't know anything about Maven; I haven't had to use it anywhere else, so I don't know if it's necessary.) I fill in the text-fields and let it create the project. Then I create two Gradle subprojects for the root project, and one singleton or "lone" Gradle project (as this progresses, I can see about making one or more of these depend on the other(s)). Since this is a Minecraft mod I'll be testing, I figure I won't need to specify a main class. Notice also that for subprojects and singleton projects, I do not need to specify anything related to Maven. The parent project has only the links to the two child projects under the Subprojects project node, and three .gradle files under the Build Scripts node. The child projects and the singleton project are identical, both in that they have the same dependencies and that they have only two gradle files for setting up project declarations and things. The Project Properties dialog for configuring each Gradle project looks similar, as is designed by default. Most of the things in the screenshot should be easily understood and configurable; it's with the two buttons near the bottom of the dialog where I could go to manage the Built-In and customizable Tasks (sort of like editing Ant tasks for Java projects, I would suppose). The Built-In Tasks dialog on parent Gradle projects supplies four tasks by default (Build, Clean, Clean and Build, and Test) that are initially empty, via inheritance from somewhere up the Gradle chain of things; for each of these, I can disable inheritance and enter what each command is supposed to perform. Custom tasks must be created from clicking the other button. The Built-In Tasks on a child project are somewhat expanded from its parent; see the pictures for proof. So, I take it to mean that I could potentially be able to setup and maintain quite rigorous task configurations through a few contextual clicks; the next problem would be in what tasks I need to specify. Again, I'm truly new to this Gradle stuff; but I really would like to see what needs to be setup, and how. I am quite willing to show the text in the gradle files, although they look to be just generic stuff that will have to be replaced with duplicates of what's in the forge gradle configuration. Until later...~ (DiggingStraightDown)

I tried both forms gradlew setupDecompWorkspace --refreshDependencies and gradlew setupDevWorkspace --refreshDependencies and then finally gradlew eclipse --refreshDependencies which at this point I am led to believe that the Gradle-support module in NetBeans should be able to properly load the forge root directory. Not the eclipse subdirectory, even though NetBeans has a support module to import other Eclipse projects; but the forge-1.7.2-10.12.0.1024-src package root. The Gradle project does load, initially, but NetBeans repeatedly warns about the errors I posted in the OP's spoiler section. I assure you, I have indeed tried the combinations that I could think of. Edit: I have also watched LexManos' Youtube video for setting it up in Eclipse, but I'm pretty sure I've handled the adaptation from that to NetBeans.

Really? No reply at all?? REALLY?!?!?!? No love at all for the best IDE in the world?

I'm trying to use NetBeans IDE, my development environment of choice. Following the wiki page for setting up Minecraft Forge, I get through everything to the point where NetBeans IDE will recognize the Forge root folder as a Gradle project. First, yes I have ran gradlew eclipse to setup the root project; and yes, NetBeans does have a third-party Gradle project module that I have installed. Everything to that point indicates no errors, and so I believe it should be able to be imported as an Eclipse project into NetBeans with all project dependencies. In attempting to open the Forge root directory as a Gradle project, it will do so, though I'm getting a long error indicating some dependencies may not have been met, perhaps indicating it's not looking in the same location as Forge Gradle has just setup the dependencies: Notice the double-forward-slashes in the URLs at the beginning of the log. Is this normal? If not, where can I go in my development setup to correct this and have things as expected?

Thank you for the response.

Good to see someone besides myself working on mods with NetBeans. Step 2. Typographic error, you have "Force" instead of "Forge". Also, clarify "working directory". Do you mean, as it was previously, a subdirectory of the MCP stuff? Or, do you mean inside of the gradle path? Or, do you mean as a copy within the mod's structure? Hopefully, NOT the latter, ... I have enough mod projects that I would be frustrated if I had that many duplicates..........

Or, going another way, perhaps creating (yet another) chest type by adding a new chest entity that handles loot randomization after the contextual click but before any gui is shown... No tick handler necessary with this method (I presume).

I don't know anything about Bukkit or this loot mod you speak of, or even how complex you mean this mod idea to be, especially the config file part. However, ... I do assume it would not be too difficult to create an item-iterator that randomly select a bunch of blocks and items from vanilla Minecraft and possibly even other mods. I've sorta had this idea as well for my adaptation of the old CaveGen mod, so that the sparsely-available chests may have more items, and more random types of items.