jeffryfisher

What's your modid, and is it all lower case? If you're working in Windoze, the file system will ignore case while in your dev environment. As soon as you compile into a jar, you move into a case-sensitive environment. Class-not-found errors are usually case mismatches or reobfuscation failures. Put at least two pairs of eyes on literal matching of you class and path names (these are things that can "look right" at first and second glance before palm finally hits face).

Oh... That can get you into trouble in this forum if you stack up Java ignorance. Once is understandable, because anyone can have a slip, but a losing streak will wear out mods' patience. I recommend finding a Java helper through whom you can filter your questions, at least until you have more confidence that your questions are really about Forge and Minecraft, not basic coding. Also: Eclipse (or any IDE worth the name) can help you too. It has features to show you matching braces, whole statements etc. Running in the debugger can let you step through your methods to see what it is doing and what variables have what values at various places. If you use these features before posting here, then you'll have solved more yourself and arrive with more information to give us. PS: Yes, your program logic makes no sense. Find help with intro programming (ask a programmer to tell you how local variables work within computer programs) and get it cleaned up.

I think you also need to add a variant to your blockstates json. After adding a comma to the last block variant, add something like this: "inventory": { "model": "pressure_plate_up" } Here's a whole bs file from Uncle Jeff's sensors (which includes a raft of pressure plates): { "forge_marker" : 1, "defaults": { "textures" : { "texture": "blocks/hay_block_side" } }, "variants": { "power=0": { "model": "pressure_plate_up" }, "power=1": { "model": "pressure_plate_down" }, "power=2": { "model": "pressure_plate_down" }, "power=3": { "model": "pressure_plate_down" }, "power=4": { "model": "pressure_plate_down" }, "power=5": { "model": "pressure_plate_down" }, "power=6": { "model": "pressure_plate_down" }, "power=7": { "model": "pressure_plate_down" }, "power=8": { "model": "pressure_plate_down" }, "power=9": { "model": "pressure_plate_down" }, "power=10": { "model": "pressure_plate_down" }, "power=11": { "model": "pressure_plate_down" }, "power=12": { "model": "pressure_plate_down" }, "power=13": { "model": "pressure_plate_down" }, "power=14": { "model": "pressure_plate_down" }, "power=15": { "model": "pressure_plate_down" }, "inventory": { "model": "pressure_plate_up" } } } As you can see, I only use vanilla models, so I don't even have variant models. If you want p-plates shaped like vanilla's, then you can toss those.

Hence my original suggestion to start there looking for ideas. If Kokkie can find that code, then maybe players will appear. BTW, does the mirror reflect any mobs at all? Maybe try spawning a creeper in creative mode to see if you can see its reflection.

Two suggestions: 1) Gather info from stepping through your code in the debugger. (Why are people so averse to getting into the debugger???) If that doesn't immediately show you what went wrong, then post updated code and tell us what you found out (e.g. what variable values you saw when you expected something else). 2) You'll get clearer images if you work in Minecraft daylight. I have my monitor brightness up at 97% and can barely tell that the mirror image is anything but black.

For starters, you're using 1.7.10, which is no longer supported here. If you are stuck in an old Minecraft world, then you'll need to Google the problem and hope for a match with a solution. Secondly, use the power of your IDE to trace compilation errors before you try to compile and run. My guess would be that the method is private or protected, so it can only be called from within the class. Try passing your argument to the constructor after creating a parameter to receive it. Then set the name from inside.

As usual, I'm here to suggest setting breakpoints and stepping through your code (or discovering that something isn't even being called). You'll get more information to tell us so we know where to look. Right now "not working" and "black thing" are too mysterious. *I* want to run your mod in my debugger, but I am too lazy to set that all up. Get in that debugger and find out what's really happening in there. PS: Don't trust the console for rendering feedback. To see all warnings, you need to find the client's log file.

That doesn't look like a crash report (There's no crash location, only a hint of a crash with "Fixed client side crash when placing the Turbine Rotor Bearing"). Instead, it looks like an excerpt from the console output, and one that has had mod loading info cut so we can't see what mods were involved. However, even in the excerpt, I see something called "Deep Dark" and "ExtraUtils2_Quarry_Dim", which imply the Extra Utilities 2 mod-pack with its long raft of inclusions. There's no telling what interactions might be happening (especially if there's a core mod or non-Forge mod in there anywhere). Try your mod again in a new, pristine world (1.10.2) that has no other mods. See what your blocks do there. If there's no crash, then you have a problem with another mod, and we probably can't help you. Perhaps updating your mod packs will resolve the issue.

If you look inside gradlew.bat, you'll see it is primed to execute something like "setupdecompworkspace" (check the capitalization). So follow the directions by typing "gradlew setupdecompworkspace" and "gradlew eclipse" in a command window.

Again, you've given too little info. If you still have a crash, then you need to show the log. Also: Have you tried to sneak up on the crash using the debugger? If not, then try to do so. PS: There's another gotcha between Eclipse and standard Minecraft: If you run Eclipse in Windows with its non-case-sensitive file system, then capitalization inconsistencies will not be detected. Contents within JAR files are always case-sensitive, even when running MC in Windows, so those mismatches show up when a mod moves beyond Eclipse. However, the sorts of errors caused are missing resources, which usually don't crash the game (they just display the missing model / texture).

Bugs that arise outside Eclipse are often Side-Only violations, but I've seen reobfuscation problems too. However, without a clearer explanation of exactly what you did, what you expected to have happen, and what actually happened, we don't know what problem you're trying to solve. You need to finish all of your TODO work. After all of those methods have been fleshed out, then come back with a new crash report and revised source code. I don't see any Block class. What's a DataConnectedDevice? If that's something from somebody's library, then get them to fix it before asking here. Also post a new log (not console output) even if you don't see meaning in it.

When a player scores an achievement, everyone sees both a chat message and a brief corner popup. You might find that code to see how vanilla code manages those messages.

What happens if you try to stack your compasses together? When an item is generated by a loot table, then there is no crafting. I'd give such a compass the coords of the chest where it started. It would be kind of cool to have an item that could point back to a special location. But, if you don't like that, then you could treat these like maps. They could be undifferentiated and stackable until activated. Once activated (by right-clicking), a compass would retain the spawn coords of the player who used it.

Try refreshing the folder contents (its display might be stale).

You mean "TitleCase"?

In a tool as versatile as Eclipse-J, there's more than one way to move around. In the future, if you can't remember where to look for something (or can't guess which package you need even after remembering the lib), then try throwing a spurious declaration into a method in any class you're editing. Write something like: BlockTNT tnt; At that point, Eclipse will underline BlockTNT, and hovering will raise a complaint that it's unresolved. Right-clicking then should offer you the option of importing the class from Minecraft (NB: A handful of classes, like "Block", have very common names, so you may be offered imports from weird places that are almost always not what you want, and you won't have their source code anyway). Once you do that, then you can select it and hit F3 to open it in a new tab. Then delete your spurious declaration and type ctrl-shift-o to fix your imports. Once you get into even one vanilla java file near what you want to use or imitate, then you can select things in it and use F3 to open more files. You may also ask eclipse to show any of those classes to you in the package explorer, which will expand whatever package you need wherever it is. In that package you may see other classes that could be instructive. And then there's "show references", which can show you how something is used. General take away lesson: An IDE is a powerful tool. Learn its features and use them. PS: For vanilla source to show up, one must have setup a decomp workspace. The dev workspace doesn't include the vanilla source. It doesn't seem to be as much of a problem as it was a few years ago, but there may still be some necrotic "how-to" articles on the web telling noobs to setup the dev workspace.

If the OP needs to check for a particular instance (one with a particular buf value), then one needs more than a class check. I suppose the value could be copied into the player, which in recent versions would utilize the capability system. I'm not sure about 1.8.9; it might have been using extended entity properties. If 1.8.9 is the old way, then the mod might want to upgrade to 1.10.2 or 1.11 before coding in an obsolete paradigm.

When code like that is doing unexpected things, it's much much more informative to step through it live in the debugger than for someone on the outside to look at it dead at a distance. Set a breakpoint and look at what values your internal variables are acquiring as they acquire them. When you get to one of your mismatches, palm will hit face and you should be able to fix the error (could be something as simple as ore -> ores somewhere, or maybe dusts.get(0) isn't always what's needed?). Anyway, catching it in the act will make analysis easy.

And: I just learned that all resource file names must be all lower case.

Whatever else you do, make sure you clean up your paste by deleting the OBFID reference. It pertains to vanilla (re)obfuscation, so it has no place in your mod's code.

What is ForgeCraft? It obviously has an internal error. Either rewrite your mod without ForgeCraft, or write to the ForgeCraft authors to repair their API. I suspect that nobody here can help you, because the problem is not in Forge itself.

I agree -- extend BlockGlass and delete any methods that it handles for you. It sounds as if you've tricked MC into not rendering blocks behind yours, and yet your block is transparent. Note: This sort of effect pops up in vanilla from time to time, especially at chunk boundaries. Test your problem in multiple locations to see if it is consistent (your problem) or intermittent (possibly a vanilla bug). PS: Investigate using the debugger and report back to us with more of what you learn!

Firstly, you don't need a TileEntity to do connections. Look at how fences and walls work. The block can have its own boolean method for isConnected (World, BlockPos, Facing). Since connections are all calculable from looking at neighbors, none of those states need to be saved. If your TE wasn't used for something else, then you wouldn't need it at all. Secondly, if/when you ever really need a TE to save data, make sure that the write to NBT is being called. This may require a mark-dirty somewhere. A subtle change between 1.9 and 1.10 may have stopped MC from doing it for you. But, as I said above, you shouldn't need a TE to determine these connection states anyway. You might need it to "distribute power", but the block can determine its own state to support its own rendering.

Something else to watch out for: The default behavior for tile entities is that updating the blockstate will cause the TE to be replaced. There's a "shouldRefresh" method somewhere (I think in the Block class) that needs to be overridden -- but it should not always return false. Instead, it needs to return true when the TE is really not needed anymore (like after its block type has been replaced with something else). If you haven't dealt with "shouldRefresh" yet, then Google it. It has come up several times in this forum.

Have you set breakpoints and then stepped through and into code using the debugger? If not, then you have more to think of. The debugger is such an essential tool that almost all non-crash runtime weirdness reported in this forum should include at least some observations made in the debugger before we can help most effectively. Also, have you looked beyond the console output and scanned your log files? The log files contain warnings that do not show on the console (but are more likely to be helpful with rendering and crash issues).