jeffryfisher

It's a lost cause. I nerfed the offending line to see what I could see beyond, and it wasn't pretty. My mods ran afoul of some other missing elements (complaints about BlockCompressed among other things). I think that a mod compiled in mc 1.8 and using certain features simply can't run (or can't run simply) in a Forge for 1.8.8. Some classes and their methods are just not quite compatible. Now a client compiled by and running 1.8.8 or 1.8.9 might be able to login successfully to a server and world using just 1.8, but I'm not being paid enough to port a bunch of mods to a risky level just to find out. So I'll try to revise my compatibility checklist at CurseForge and aim my 1.8 client and server at the latest Forge build for 1.8 (not 1.8.8 ). When I'm ready to start another whole new world, I'll skip all of the way to a recommended Forge build for 1.9+ with no expectation of compatibility. @D7, regarding why: Each of my mods' main classes is an extension of a home-grown abstract mod class. That abstract class sets up many elements, including proxies, common to all of my mods. It also has some comments to remind me to do some other routine things I couldn't express in Java. Yes, it's a pain when it changes, forcing all of my mods to a new version so they can continue to operate together. However, it's nice when I get something to work just right in that one place, and every mod (including the next one I write) inherits that success. It's probably poor style, but my common proxy benefits from being declared inside of that abstract mod class where it gains visibility to a few fields such as mod name. My mods' various (external) client proxies eventually use methods that access those fields. It's all horribly incestuous, but like the compatibility fight, I'm not being paid enough to go much beyond having fun with it (and devising a workable abstract mod class was actually fun).

Vanilla ores do have item versions, that's how you hold them in inventory after breaking them (perhaps with silk-touch). As with most blocks, their items are derived automatically, so they're hard to find in the code. Read down toward the long list of item instances in the Item class, and you''ll see lines such as: registerItemBlock(Blocks.gold_ore); registerItemBlock(Blocks.iron_ore); registerItemBlock(Blocks.coal_ore); I suspect that you've got a cart before a horse somewhere. We need to see more of your code, like where/when are your inits called to populate the fields you're using in the one line you showed us? If you're using a field before you set it, then that would explain your NPE. PS: What does "chunk" mean in your statement? Chunk has a special meaning in Minecraft coding, so I suggest avoiding it.

IIRC, Forge's wrapper calls events, and our mods subscribe to (handle) them. If you're thinking about calling (firing) events, then you're either way more advanced than I, or else you're asking for trouble. For starter tile entities, just writing a useful pair of NBT methods (override the read & write) and marking a tile "dirty" should suffice.

I'll try a cast, and then I'll see if code compiled for 1.8.8 will run in a 1.8 world (1.8.9 has already failed, so I am pessimistic). Yup, that's it, copied almost line for line. It's in an abstract "mod" class that is parent to each mod's main class.

I compiled in Forge build 1450 (mc 1.8 ), and I am trying to run in Forge client build 1655 (mc 1.8.8 ) which was supposed to be compatible. Maybe I need some conditional code? Near as I can tell, this method exists, although the newer version might return a subclass of what I'm looking for. I can't figure out why this blows sky high. My method, the problem line near the top: Crash report: In version 1.8.8, the getModClassLoader method returns a URLClassLoader instance, which should be an extension of ClassLoader, therefore assignable to my local variable. Am I reading this wrong, or have I missed a key rule in Java?

Yes, other players' chopping and picking and running etc makes noise that will play for you and all other nearby players. Tools initiate sound effects on the server that are eventually rendered on clients, with each client's rendition attenuated for distance (IIRC, zero-volume sfx are dropped before packets are sent). Therefore, one should normally call the playSoundEffect method. It does its own server-side / client-side check, only doing something on the server (causing packets to be sent). Counter-intuitively, this means that if you call playSoundEffect from inside a client-only method (such as inside a client-proxy), then it won't do diddly. You need to make sure that your call is executing on the server. This actually makes some sense when you figure that the server is the authority on what really happens in the world. The server is also (by definition) responsible for distributing info to multiple players.

I count 3*(2^9). That's still daunting, but not millions. Did I miss something? Depending on what each state does, you may benefit from Forge's advanced blockstates.

Counter-intuitively, vanilla Minecraft initiates most of its sounds on the server. That's because it wants all (nearby) players to hear the sounds, not just the player performing an action. You'll see calls to World#playSoundEffect. If you trace it, you'll eventually see a packet sent to all clients (World-Accesses) whose players are within earshot. The actual sound is eventually played client-side (of course), but only in response to the packet. Your code usually should not call those client-side methods used to render sound. Instead, your mod should almost always call the server-side sound-effect method and let vanilla handle the distribution to clients. An exception would be, for instance, if you set-up a tile entity to emit a continuous sound, or if you gave a helmet to one player to play sounds in response to objects in his environment.

First, you should articulate your code (assign each method result to a local variable before passing vars to the next method). Then set a break point and fire up the debugger to step through the articulated code, looking at values at each line. Find out exactly what is null. If you discover why it is null, then you don't even need our help. If not, then you can ask a better-informed question.

If you can't load the world, then your earlier bug may have corrupted it. Delete it and start a new world to resume testing. You were using an expendable test world, right?

There's probably more being ripped out than just some block IDs. Fixing this, if it's even possible, will probably require deep understanding of Bluepower. If it were me, I would just keep using the original mods in that world. To effect a sea change in mods, you should probably start a new world.

Right -- And that means that vanilla Minecraft is calling its own container repair method multiple times, so I don't think its a Forge or mod problem. It's almost certainly some code weakness within Vanilla Minecraft. However, don't even bother reporting a bug to Mojang. They reject all bug-reports based on modder's examinations of their internals. If it doesn't crash the game or produce some other visible effect, then they're not interested.

I noticed the same thing happening when I subscribed to this event in order to repair or apply enchanted books to my ruby shears. I had to remove my status msg because it would fire so many times. I haven't analyzed it, but it smells like a thread or client-server sync issue. Perhaps the condition that fires the event exists every tick until some interprocess communication clears it. The variability of the msg count suggests that lag contributes to it. If so, then it's likely a vanilla minecraft "feature" that we can't fix. However, if there's a fix or workaround, then I'd be interested.

If I recall correctly, you set the event's newSpeed to zero to prevent the player from breaking the block (he never makes any progress). I don't think you need to cancel the event. Put the event handler with its @SubscribeEvent annotation into a listener class, which may have multiple events. Your main postInit method needs to register an instance of each listener class with the bus(es) firing its event(s). Example: @EventHandler public void postInit(FMLPostInitializationEvent e) { NethergemEventSubs ES = new NethergemEventSubs (); super.postInit (e); MinecraftForge.EVENT_BUS.register (ES); FMLCommonHandler.instance ().bus ().register (ES); } If you have events from multiple busses, then you could be very clever and create a separate listener class for each bus. I'm too lazy to do that, so I bundle all my events into one class and then register its instance on every possible bus until all of my events work. Each registration's reflection code seems to be smart enough to pick out its own events without interference from other methods. You might even be able to nest an event handler method inside a block or item class and then register its instance with a bus. Then your method would have field and method visibility from inside the block or item. I'll have to try that sometime to see "What could possibly go wrong?"

Mods are loaded into Minecraft, not external map viewers, so I don't think we can help you. However, if you find the right viewer, then you may be able to add pixel colors for custom block IDs. Look for a viewer that is customizable. If you can't find one, then start writing to the viewers' authors (or poke around in the viewers' files looking for a config file or xml file to edit). Good luck.

Sorry about that. We may have a language barrier. Make a copy of the item stack using the object's copy method. Manipulate and return the copy.

That's the method. Remember that you're working with pointers, so you don't want to operate on the input until the product is removed from the output slot. If you act on the original, you could damage it while the output dust is just sitting in the slot waiting to be grabbed (and if the grid is updated every tick, then that might be why your mortar disappeared).

Does vanilla Minecraft subclass its slabs as double or half? If it doesn't, then you probably shouldn't either. Otherwise, you need to come up with a way to replace half-slabs with double slabs in the world. Why go to all that trouble when the vanilla code already handles half and double? Isn't that why you derived your cherry slab from BlockSlab in the first place? It looks like you've made a tremendous amount of work for yourself. What am I missing here?

"Doesn't generate the ores" is too mysterious. Check your log (not console) for errors and warnings. If there are none, then step through your generator in the debugger. Tell us what you see happening and what part of it you don't understand.

If you look into isDaytime, you find that it operates on light level. Unless you care about weather effects (which can turn day into night), use world time to get canonical sunrise and sunset. There are 24000 ticks in a day, starting with dawn at time=0 on the 1st day. From that you can calculate using modulo (and remainder) arithmetic, and it even works in the nether and end (unless you test for those and rule them out). On the other hand, if your solar panel needs to respond to light levels, then you should probably use skylight directly.

Did you put your mod's info into the build.gradle file? In particular, you need to edit three lines: version = "mcVersion-modVersion" // Follow pattern <mcVersion>-<modVersion> group= "net.domain.mod" // Inverted domain (jeffryfisher.net) dot package (always all lower-case) archivesBaseName = "modname" // modid = package name (always all lower-case)

You probably need to add an assets argument to Eclipse's run configurations (in run menu). Something like: --assetsDir "C:\Documents and Settings\<username>\Application Data\.minecraft\assets" And if other strange things fail in Eclipse, then you may need some other arguments as well.

There's a child board for Forge gradle. You might find more info there.

Can't you just extend helmets to make hats? Just treat them like custom cloth (leather) helmets, and even let them offer that small bit of protection (and apply a few enchantments).

It seems as if you've passed a tool material to super that super doesn't understand. You'll probably need to work around the limited array that super uses.