jeffryfisher

I wonder if you could work metadata into the ore block (and furnace stacks) so that several smeltings would be required (increasing the metadata each time). Only raw ore (meta zero) would spawn in the world, and melting it would produce ore with meta=1. Smelting ore with meta=9 would produce your finished output material. You'd need 10 smelting recipes to convert each level of stack into its output. An automated factory would need to cascade 10 furnaces with 10 hoppers or else work out some way to recycle through one. The puzzle actually sounds like something fun to solve...

Is there ever more than one player in a physical or logical client? If a server sends any mana value to a client, then by implication it is the mana of the player there. Just be careful to send the correct mana value for each world access.

Somebody came up with a use case for it a few weeks ago. If I recall correctly, he wanted to produce a mod that would exclude some secret sauce from the client version jar file that he planned to distribute to WAN players (it referred to a DB engine installed on his server, something his players were unlikely to own). He used SideOnly(Server) to test that such a stripped client would still run correctly on his own physical server and client. It was temporary but still helpful during development/test cycles because it saved him from having to manually add and delete packages each time around.

I have created custom shears extending ItemShears (maybe that was a mistake). I want them to be enchantable in all cases that vanilla (iron) shears are enchantable. Sadly, my custom shears run afoul of a line in vanilla enchantment code where item == Items.shears (not instanceof). I wish the test could be changed to instanceof. The whole chain of "canApply..." methods are written into class Enchantment and the children for specific enchantments. I haven't found any call-backs to item objects where my custom shears could override something to assert their enchantability, even in an anvil. I've made some headway on the enchanting table, but the anvil is thus far resisting my efforts. My test case (on anvil in survival mode): custom shears as input1, and an enchanted book with eff V as input2. The output slot is empty, and there's an ugly red X before it. I want the X to go away, and I want enchanted (Eff V) custom shears in the output slot. If there's a Forge event somewhere in the call chain, I'm not seeing it. I tried overriding isBookEnchantable, but no joy. Maybe I'm almost there but blind to something obvious? For what it's worth, my shears class: EDIT: I've found something called ForgeHooks.onAnvilChange that might fill the bill. I'll give it a go this week.

What you have here is an almost pure GL question. Try searching for applicable GL threads on the web.

Unfortunately, you're having problems at the level of knowing Java and Eclipse. Eclipse's squiggly line is trying to tell you that you need to study the rules of Java (there are Java articles and tutorials on the web, and Google will find them for you). You must learn your tools before seeking help here. We don't write code on demand, and we don't teach the basics of Java, and we don't substitute for Eclipse to parse code by eye. Come back when your mystery stems from Minecraft's or Forge's internal data and coding peculiarities. If it turns out that you really really need access to private fields in a parent class, then you might need to shelve this project until you've learned an advanced programming technique called reflection. You should do a simple mod or two to become familiar with Forge and Minecraft coding before trying anything ambitious. PS: Something that might help you a lot would be to set a break point in the vanilla crafting manager code and then step through the entire process in the debugger. When you've seen all of the steps that Minecraft normally goes through (in order), then you'll have more ideas about what you want to extend, override etc to make your own table or other device.

This forum says that we don't teach Java here. Modders must find other Java help. I too started Forge modding without any Java experience. Nor had I ever used "reflection" in any language before. I invested two whole weeks immersed in the Minecraft source code before asking help here. There are resources on the net for learning Java. Some Java tutorials might be in your language (search). Eclipse helps with Java too. Eclipse also helps to trace code -- Learn to use Eclipse to find things like ForgeHooks.rayTraceEyes, and its parameters, and what it does.

If getResourceAsStream is returning null, then you want to set a break point there and (if possible) step into the method using the debugger. Do a double check that the asset path you're trying to read is correct (including case, because "files" inside jars are case sensitive even on Windoze systems). The logs will have more info than the console. Is there a log complaint about an asset not found?

If you run again to generate the error in the console in Eclipse, then you can click on the line number in the error message to be taken to the place where the error occurred. Better yet, if you set a break point, then you can step through the offending code in the debugger to see what's what.

The difference is one of instantiation. There is only ever one actual object created of each block type. The world has a huge array of block IDs and metadata nibbles, not block objects. A block class's design must function on that tiny nibble of metadata (sometimes augmented by position and other contextual parameters passed into its methods). Millions of stone and air blocks need nothing more, but some blocks do. For those special blocks, we have helpers called tile entities. By contrast, each tile entity gets an object (new TileEntity...) at each of its locations in the world. A tile entity operates while its chunk is loaded. Then (maybe) it writes its data to an NBT tag for storage (call super and then add data). When next the TE is loaded, it must similarly read NBT into an empty new object. Whenever that data changes, it must mark itself dirty to be sure it is (re)written. Because of their abstractedness, block classes must only store data that applies to all blocks of the type. If you ever catch yourself adding persistent situational data to a block, stop; you'd be changing some data affecting every block of that type in the whole world. Ask yourself if the information can be reconstructed from context passed to each involved method call. If so, then that's usually what you should do (even if the block already has a tile entity, you don't want to enlarge its NBT tag unnecessarily). If not, then you need to use a tile entity. If your block extends one that has a TE, then you usually want to extend its TE child class and add your own data (otherwise bad things may happen inside your block's parent). I hope that helps you wrap your head around the block and tile paradigms.

Every thread that starts this way gets the same advice: Don't extend BlockContainer. Google these threads, then filter for the most recent month (because there are so many of them here). At least one is on page 1 of this very forum. Read D7's frequent advice on what Block methods to override instead of extending BlockContainer (or implementing ITileEntityProvider). PS: Don't forget to register your TE. Whenever setting any data in your TE, mark it dirty so it is saved. Override (extend) the read and write NBT methods. See how far you can get on that reading and advice. If you then face a crash, come back with a log (in spoiler frame). If it's just not doing what you expect, then step through at least once in a debugger before posting what's happening (versus what you expect).

Aha, I've been seeing (frequently) the advice to use custom location, but not always the admonition "instead of mesher stuff". It's finally dawning on me that this choice is not just a personal preference. Is there an explanation somewhere of why the former is superior to the latter? (I searched, but the haystack of code excerpts swamped any hope of finding a comparison). Having finally learned the mesher well enough to make it work in all of my mods, I'm feeling reluctant to dig them up and change them, but a good reason could persuade me to do so during my port to 1.9. BTW, For grins, I just Googled Minecraft Forge 1.8 item model tutorial again. The top four tutorials all teach the deprecated mesher technique, so the parade of meshed up modders will continue If there's a tut that teaches the model loader, I can't find it. I looked at Forge's docs, but the "Models & Rendering" section only mentions blocks, not items.

I've seen at least one other "Ore not Generating" thread in the last month. Use Google to find it and others. Make sure you've handled all of the issues in them, and then post more specifics here (what you've done, your generator code and registrations, steps through debugger, and what you see versus what you expect. Ore generators can be tricky. I think the last guy was mis-handling his random number seed so he was starting every ore body with the same seed (and each successive ore body failed to replace the 1st one generated).

The daylight detector raises another opportunity: The game already has time, so you probably don't even need a counter, just a check against world time % 1000.

Reflection? Can a final field be brute-forced? (Probably bad style for anything shared beyond your own server and friends, somewhat like a core mod)

I feel your pain (every time I need a TE for one of my mods). What I finally realized is that the create method can't legitimately do anything more than instantiate a TE of a particular child class. That's all it's supposed to do. A TE's data-setting must wait until later, which is why TE constructors never take parameters. This is a consequence of some creates being real-time block-placement acts, but other creates are chunk-loading, NBT-reading acts. The former offer niceties such as blockstate and placer entity via an override of onBlockPlacedBy, which can fetch the newly-allocated but empty TE and finally provide it with data by calling the TE's setter methods. Chunk-loading employs a TE's own NBT methods, which should save and restore all of a TE's data, so no block-state (or pos or worldIn etc) is needed until there's an update (and heaven help you if you haven't overidden "shouldRefresh" to return false for most state changes not replacing the containing block).

I think the OP is asking for a more thorough debobfuscation (replacing srg names with meaningful names) as well as injecting comments along with hooks. These things are not done lightly, and they're not done "at home", but they are done by Forge's developers. Each major revision of Forge seems to name several more methods and variables for ease of reading. Comments are generally written on methods and fields injected by Forge, but Minecraft's vanilla elements are usually bereft. To contribute your own advancement of Forge, you could start by locating the GIT repo and associated discussions. First learn the customs for suggestions and contributions so you don't stumble in and bother some very busy volunteers with headaches they've already dismissed. Once you've gained enough familiarity to speak up, then you might be able to offer up a useful suggestion. If you're especially ambitious, then you could study up on the scripting technology that decompiles Minecraft, injects Forge hooks etc. If you then write a generally useful "transform", you can learn how to submit what's called a "pull request" to offer your transform to Forge. For the less ambitious: Whenever one of your mods encounters a srg name or poorly documented vanilla method, put your own comments into your own code. If you have some software methodology chops, you can organize your own modding in "layers", with your own interfaces, abstract classes etc to insulate your "on the ground" mod classes from the harsh pseudo-reality of decompiled Java.

If you need help with a crash, then post the log (within spoiler tags). Also, please reassure us that you were able to run your mod in Eclipse without crashing. PS: As a kindness to those whose help you want, please use punctuation.

Don't forgive your jsons just because you fixed one error in one of them. There are others to create headaches as well. And then there are their file names and directory structure... The code is the tail wagging the dog (while the json paradigm is a dog with fleas). However, it may be worth the trouble of checking code for exact spelling and capitalization. Remember to keep reading your log. Sadly the json paradigm is both fragile and (to Eclipse) opaque. Tools like JSONlint can check json syntax, but I don't know anything outside the log errors that can tell you about json semantics.

If you read other recent TE and BlockContainer threads, you'll see D7 telling modders to avoid extending BlockContainer. I don't know what it's issues are, but you may have run into another one. Instead, you should probably implement ITileEntityProvider. Not only will you be forced to override the create method, but class Block will detect you and return true from hasTileEntity. Remember to put NBT write and read methods in your TE, and register your TE in your main mod class. Also, if your host block ever does anything with states, you'll probably need to override shouldRefresh.

Look at netherrack

I too had been wondering about that, so I am glad to see your explanation. With such a long range, I can also see a potential difference in behavior with regards to unloaded chunks: A spawn-supressor remembered by the world will have its effect even if its chunk is "over the horizon". However, a ticking TE (or a block-seeking event handler) would only work while its chunk is loaded. If these blocks ever became common enough to make an absolute world-list tedious, then you might opt for a synthesis of strategies (having the world aware of what suppressor blocks are currently loaded, but otherwise leaving them in their chunks).

In what way are "items deleted"? What did you see happening when you stepped through these NBT methods in the debugger? Was data mishandled, or was there no data at all? Review a vanilla analog to see if there's a critical step your surrounding code might be missing (like flushing a cache to file, marking a TE dirty so it will be written, that sort of thing).

I worked on this for my "SmartHarvest" enchantment for tools (including my enchantable ruby hoe): instanceof BlockCrops will be mature at meta=7. instanceof BlockNetherWart will be mature at meta=3. Can't count on alien mods to use those though. The best we can do is to give them a chance to be rational. If they're not, then that's (usually) their problem. Don't worry about it until somebody gives you details in a comment on your uploaded mod.

You need site-selection and boundary matching strategies (and then lots of intelligent code) to blend rigid prefab into variable terrain. You might gain some insight by reading vanilla village generation code (and gain sympathy for writing a road-laying algorithm that almost works in hilly terrain). Also look through vanilla biomes for terrain generation, especially in transition zones. Consider breaking your structure into modular units that may be placed at different heights, reducing the amount of cutting and filling for each. Alternatively, you may have your structure "perch" on top of the highest (or nearly highest) surface block it covers, and then fill from there (if you like mountain-top forts). Enforce a minimum elevation to keep your ground floor above ocean water. Remember to use water rather than air as "empty space" below sea-level. Envision a transition zone around your structure/campus, and then design a method that fills in rings of blocks to smooth the height transition from structure to surrounding terrain... and you might even detect if you're impinging upon an open lava pool (so your castle doesn't immediately fill with lava and/or burn to the ground, fall over and then sink into a swamp). There are quite a few structure-generation threads buried in this forum. If the site-search isn't helpful, then Google is your friend (Google does a better job of prioritizing discussion above voluminous crash logs).