Sinhika

Ditto. Same error with both server and client versions.

I am porting code that, during an FOV event, checks to see if the player is using a mod-specific bow, and if so, adjusts the FOV. 1. Is the 1.9 replacement for player.isUsingItem() == player.isHandActive(), or something else? 2. Am I correct in thinking the 1.9 replacement for player.getItemInUse() == player.getHeldItemMainhand()? Or should I be using something else?

How do we replace the old ChestGenHooks() functionality? I noticed the new loot table JSON files--do we just add ones for our mod and they somehow get automatically added to the pool for a given loot source, or is there a method we need to call somewhere? (If so, where should it be called from?) Porting to 1.9 from 1.8.9 isn't nearly as easy as people suggested it would be--the changes are nearly as great as from 1.7.10 -> 1.8.9.

I am aware of that,which is why I was Willing to try the Ad link. But when the very first ad is shady as all get out, sneaks a pop-under, *AND* the "report ad" button did nothing when clicked on, I lose trust. If that's your "report ad" button, it did not work with Firefox with NoScript running, but minecraftforge.net and adfoc.us scripts allowed. (At the time).

The new Forge download page is "pretty". I personally loathe the Windows Metro aesthetic wherever I find it, but that's a matter of personal taste. - Unlabeled "mystery meat" icons that you have to mouse-over to figure out where they go are a step backwards in usefulness, IMHO. Is it really that hard to have labels underneath the icons? - Much more seriously, the adfly clone you are using is bad and will be blocked on my computer. The feedback button to report bad ads does not work, and the first damn ad opened a pop-under window AND tried to auto-download some shady "software updater". My first impression of 'Adfoc.us" is that they don't care what kind of sleazeware gets shoved at your computer, so screw them. Ain't getting my clicks. - You've really hidden the direct downloads links; I found them, but could you make them accessible from the fancy menu up top? I'm not going to be using the spamware links to get Forge, thanks. I don't recommend anyone else do, either, because that ad vendor is deceptive and untrustworthy.

Thank you for the in-depth explanations of the simple stuff. Your meta-data block tutorial contained the bit of information I needed to figure out why my custom meta-data blocks weren't properly converting between ItemBlock in hand and Block in the world. (New GameRegistry method not in 1.6.4). None of the common tutorials mentioned that sort of thing.

I had a similar problem--updating someone else's semi-abandoned closed-source mod from 1.6.2 to 1.6.4. BON using Searge deobfuscation got me something to work with, then I used JD-GUI, then sat down with MCPBot to update all the still semi-obfuscated names. Which version of JD-GUI are you using? I had to grab a development snapshot (20130926) to get a version that would properly decompile classes with private internal classes, for example, and even then, I had to go in and hand-edit for bugs. It didn't apply trinary (? operators properly.

I used the 1.5.2 installer for the server and ran into the exact same problem ("Java Exception") pop-up box. However, when I ran the java command from the command-line (Windows 7-64 bit), I got the following:

It's not just IE. Site is failing with Firefox, too. Something is broken at the server end or you wouldn't be seeing that error.

This turns out to be a better way than using a CraftingHandler, which is what I had also been doing and advising others to do. I worked it out from someone else's code, somewhere, and it worked, so I had no reason to suspect it was not the "right" way to do ti. What's wrong with using the CraftingHandler, anyway? There really needs to be a "Best Practices" guide for Forge, because one really has no way of knowing if someone else's code that one is learning from is good code or not. Or is modding like Perl: "There's more than one way to do it"? Now, on to a related problem: if a tool is not consumed by a recipe (because of hasContainerItem()/getContainerItemStack()), how do you keep the repair function of the crafting table from turning into a tool duping machine?

So... if I just create new tools, blocks, items and recipes for the standard crafting table or forge, is the client-server communication handled already at the level of the parent classes? i.e., do I need a custom packet handler for placing blocks derived from class Block? I'm sort of getting the idea that packet handlers might only be needed for new GUIs, such as new crafting interfaces and new inventory containers, and for things that move, like vehicles, riding animals, etc. Is that correct? ...I probably should look at the packet handler tutorials in more detail.

Okay, I get that there are tutorials on how to set up packet handlers. What I am having trouble wrapping my head around is what information does a mod need to send from client to server and vice versa? Versus what is auto-magically handled by Forge & Vanilla MC parent classes. My brain is failing to make a crucial connection somewhere for this all to make sense. How do you know what you need to set up packet handlers for? Where does that information come from and when? Is it related to events? Which events? For what? When? I'm really lost when it comes to figuring out what needs to be done to make sure a mod works in both SSP and SMP modes. Simple explanations and links to open-source/github/etc code that does what you are talking about would be appreciated.

Actually, my mod does not "know" what textures exist; it just blithely assumes that when it synthesizes a texture name from material & tool suffix, then that texture exists. Is there a handy way to enumerate over the contents of an assets directory?

Before I start rolling my own code, I thought I'd ask to make sure I'm not re-inventing the wheel. Is there an easy way (aka, a pre-existing function/class/method) for checking if an icon or texture file exists before registering it? The use case I'm looking at is where my mod has a custom tool (call it cTool), and during postInit, the mod checks to see if any other mods have added custom tool materials. If so, my mod then auto-generates more cTools made with the added custom materials. These auto-generated cTools need icons; if I've heard of the mod, I may have already created an icon for custom-material cTool; if so, all well and good. However, if I haven't, I'd like the option to fall back to some generic-looking icon rather than tossing up a "Missing Texture" icon.

So why can't you just monitor the Forge-client log (or server log)? There are ways to tee that to a window, depending on what OS you are using. (In linux it would be "tail -f <filename>", of course) Why does it have to be the console log?

Are you looking at the console window in Eclipse for your messages, or at the '\forge\mcp\jars\ForgeModLoader-client-0.log" on your hard drive? Like I said, you can't change the logging level of the console window; but if they are not showing up in the "ForgeModLoader-client-0.log" log file, something is definitely wrong.

I figured this out last night in my own code. The console log defaults to INFO level, and is not affected by setting log levels on the FMLLog. However, if you go check your Forge log files, I think you'll find all those missing FINEST/FINER/FINE messages being written out. The console log cannot be changed via the "logging.properties" file; it is hard-coded in the initialization to "INFO", and the console logger object is private and cannot be accessed. I decided for my own project a logging.properties file wasn't necessary because the FMLLog can be set internally, so I did not retain one. However, if you want one, it goes in the top level of your config directory. You can find an example one the one used by your JRE, with comments, in the jre/lib directory of your JDK. (In my case, that would be C:\Program Files\Java\jdk1.7.0_25\jre\lib\logging.properties). Don't tamper with that one, just use it as an example. The general use of it is discussed in the Java LogManager class documentation at http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html. Here's the important contents: # Default global logging level .level= INFO would set the FMLlog and all child logs to default level of INFO, unless otherwise specified. You can either specify otherwise programmatically, or by using the name of the logger (as set by "getLog()") + '.level'; e.g. ForgeModLoader.level=ALL should set the FML file log to level.ALL, for example.

http://docs.oracle.com/javase/7/docs/api/java/util/logging/Logger.html http://jd.minecraftforge.net/cpw/mods/fml/common/event/FMLPreInitializationEvent.html#getModLog%28%29 I can't believe that the Oracle Java Trails have nothing on the Logger API, so I googled a tutorial that didn't look too shabby: http://www.journaldev.com/977/java-logging-api-tutorial-examples-logger-levels-handlers-formatters-filters