jeffryfisher

In earlier versions of Forge, there were ways to see the vanilla assets. Everything from json files to sounds was available (with textures being critical starting material for the artistically challenged). In b1450 I see the assets in my Forge installation at ...Forge1450\build\tmp\recompSrc\assets. I also vaguely recall finding assets in my app data for .minecraft. However, since upgrading to mc 1.10.2, I can't find any assets (except my own) anywhere (and I've done several full-disk searches as well as Google searches for info). App data .minecraft has a bunch of objects, but they're all hashed. They don't even have file extensions. Where Have Vanilla Assets Gone? -- Peter, Paul and Mary will want to know. If we truly have lost intelligible vanilla assets, then (besides blaming Microsoft) I'll encourage every modder to install a prior version of Forge just to gain fertile examples to emulate and work from.

Did you step through its execution? Did you see what was returned by isBottom? Did you step into withProperty to see what happened there? If all those things went well, then post your blockstates json file.

Unless Windoze has claimed 3G of your memory, which is the sort of thing that Windoze can do (and why so many power users hate it with a passion). You may need to tune some of your Windoze settings to make more memory available for applications.

You can only boost it if your machine actually has the physical RAM to give. Instead, try cutting back that RAM setting to something safely below your machine's physical RAM. That forces Java to make do with less. It will be slow, but it can then succeed.

You might try this event hook: net.minecraftforge.common.MinecraftForge.EVENT_BUS.post(new net.minecraftforge.event.terraingen.DecorateBiomeEvent.Pre(worldIn, random, chunkPos)); ... and at that moment, vanilla ore generators have been instantiated and assigned to public fields, but they have not yet been used. A mod should be able to replace the coal ore generator by assigning its own custom WorldGenerator instance to public BiomeDecorator.coalGen (likewise any other ore generator). The vanilla coal generator instantiation looks like: this.coalGen = new WorldGenMinable(Blocks.COAL_ORE.getDefaultState(), this.chunkProviderSettings.coalSize); Try instantiating one like that but with your static custom coal ore block instance in its place. Also explore the vanilla code using your IDE's reference widgets. It's really interesting to see how various things work (once you know where to look).

I guess I didn't say it well. For block texturing, just read about blockstates and go from there. For items, ignore tutorials about the "mesher". Set a custom resource location instead (see the ModelLoader class). You should Google this forum for past discussion. In either case, you'll need to write json files (maybe many of them). Use a json validator tool such as json lint. (I wonder if there's a way for me to add one to Eclipse). Much of the discussion on upgrading from IIcon is now more than a year old. Do a Google search of this forum and then narrow your search using a custom date range (and continue to ignore the mesher).

IIcon has been replaced with the ResourceLocation class (at least that's where my strings went). Usage differs depending on whether you have an item or a block. You also need to learn all about block states and the JSON files. There has been much written over the last two years, please Google the Forge + keywords and look for forum posts from mc 1.8 forward.

You could store the eaten integer in metadata in an abstract cake block class. Then make three different blocks (Poor, Decent, or Superb) extending that class. This would eat (pardon the expression) block ID bits instead of metadata bits. The concept here is that the quality doesn't change over time (does it?) but the eaten does. So you can place the block once as some quality of manufacture and then update its metadata as it is eaten. It's only a matter of convenience; there are objects in the game that swap blocks when conditions change (or at least they did in past versions of MC). The downside is that each new block needs its own registrations, ItemBlock and JSON, but you've learned to love writing JSON files right?

I think that means that you forgot to set the custom model resource location during client-proxy preinit. There are many threads around here with examples.

And whenever you ask for help with a crash, always post (in a frame) or link the crash report.

Ah, I thought silver meant you wanted a mirrored surface. Much simpler to do a matte surface. Still, to show "rolling", the surface needs details to rotate about a point. Without details (texture), all orientations would look the same (allowing you to skip a bunch of math).

Short answer is "probably" it can be made. If perfectly silver, then you can forget about rolling. There would not be any visible features to rotate about the center. The really difficult part would be ray-tracing world images reflected from the spherical surface. You might get away with creating a "camera" at the center of the sphere that looks back at the player with a 180 degree field of view (imagine the F5 view from the center of the sphere). Then map what it sees to 180 degrees of the sphere's surface facing the player. If you use the right GL calls in your renderer, the client's graphics card should do most of the heavy lifting. Even so, you might want a fall-back rendering scheme when the ball is beyond some useful distance from the player. God help the client who puts 2 or more of these spheres near each other (rendering reflections of reflections).

Look at Blocks.FIRE.setFireInfo and Block.isFireSource. See what netherrack does so that it burns when lit, but fire neither consumes it nor spreads to it. It's bad form to ask the forum to write your code for you.

if(block.getRegistryName() != null) If you're unsure whether your blocks have set their names, then you need to show us some block initialization/constructor code so we can tell you what might be wrong with it. You should probably also emit a warning to the log whenever that check does catch a block's name being null. If you have a problem with missing textures, then get ready to post all related JSON files and a most-recent log file (not console output). Running in the debugger can help you see what's happening so you can make more progress on your own and give us more info on a more narrowly defined problem when you get stuck.

That sounds familiar. I think you're right. The OP might only need IEntityAdditionalSpawnData (my situation did not quite fit because I needed the data you see me extracting by force, i.e. reflection)

So it is actually placed, just not visible? Look at my callback. Use it to set breakpoints. See what the client is doing in the vicinity of the EntitySpawnMessage hook.

1) Core mods often do not play nice with Forge. You might not be able to get help here unless you develop in a pure Forge environment (and you might get better help from the core-mod makers). 2) When posting a crash report or other lengthy piece of technobabble, please encapsulate the paste in tags (e.g. code-tags or spoiler-tags) 3) NoClassDefFoundError usually means that your mod referred to a client-only class in a common context, causing a dedicated server to look for a class that was not load on the server. Read class MovementItems, including all of its comments and annotations. Then edit your mod to obey its limitations. Finally, if you're not designing a mod but trying to load someone else's mod, then you're in the wrong place to get help. This forum is for mod developers. If you're loading someone else's mod, then you need to talk to that someone else.

My custom paintings extended EntityPainting and went through all kinds of contortions (including writing my own renderer) in 1.7.10 and 1.8 to deal with the stupid final enum etc. There's at least one gotcha in the client-side message handling code where it checks explicitly for class==EntityPainting, so no instance-of will be rendered unless you defeat the check. I am currently upgrading my mods to 1.10.2 and will get to my paintings this week. I'll let you know what I discover. One thing I can tell you right away though: NOTHING renders on a server. ALL rendering is client-side only. You should do some reading and then start over on your design to avoid any attempt to render on your server. Here's the critical piece of my code to defeat client-side message handling in mc 1.8 (I'm looking at it, but even though I wrote it myself, I no longer understand it): @SideOnly(Side.CLIENT) public class classAltPaintingSpawnCallback implements Function<EntitySpawnMessage, Entity> { protected Field fieldStream; public classAltPaintingSpawnCallback() { // This will be constructed in the init phase try { // Crack open the message and enable access to dataStream via Field variable (reflection) this.fieldStream = EntitySpawnMessage.class.getDeclaredField ("dataStream"); this.fieldStream.setAccessible (true); } catch (NoSuchFieldException e) { System.out.println ("ERROR (" + e.getMessage () + "): Field 'dataStream' does not exist in class EntitySpawnMessage. "); } } /** * Helper class with one function to parse message and call the correct entity constructor that returns an instance of my entity * class. Got all that? I wrote it, and it still makes my head hurt. * * Why does the message protocol delay reading my extra data until after entity construction? I may never know, but I do know that * it's there waiting for me, so I'm taking it by force. */ @Override public Entity apply(EntitySpawnMessage m) { WorldClient wc = FMLClientHandler.instance ().getWorldClient (); try { ByteBuf b = (ByteBuf) fieldStream.get (m); // Steal the dataStream from message m int x = b.readInt (); // world tile x (+ is East) int y = b.readInt (); // world tile y (+ is Up) int z = b.readInt (); // world tile z (+ is South) EnumFacing facing = EnumFacing.VALUES[b.readByte ()]; // Compass dir 0-6 is D, U, N, S, W, E int lot = b.readByte (); // Texture number 0-15 taken from carpet color used to craft item String title = ByteBufUtils.readUTF8String (b); return new classAltPainting (wc, new BlockPos (x, y, z), facing, lot, title); } catch (ReflectiveOperationException e) { System.out.println ("ERROR: classAltPaintingSpawnCallback.apply() threw: " + e.getMessage ()); return null; } } }

In fact, you might even get away with extending the EntityAINearestAttackableTarget class. If the existing parameters include the zombie (is that the "this"?), then you should have enough information to avoid attacking other instances of its class.

java.lang.NullPointerException: Initializing game at net.minecraftforge.client.model.ModelLoader.setCustomModelResourceLocation(ModelLoader.java:1095) at matthew.mcmod.init.ModBlocks.registerRender(ModBlocks.java:35) at matthew.mcmod.init.ModBlocks.registerRenders(ModBlocks.java:26) at matthew.mcmod.proxy.ClientProxy.registerRenders(ClientProxy.java:11) Each of those line numbers is clickable, taking you right to the source. If it's not obvious what is null and needs to be initialized, then set a breakpoint at ClientProxy.java:11 and rerun in the debugger. Step into each call and examine the arguments being passed.

You might want MID to be !isBottom

Hmmm... Try setting a breakpoint on the EntityGuardian's contructor(s). See what method is spawning so many of them. Sset another breakpoint and step through the method that decided to spawn yet another guardian. Examine its variables. It should be apparent where it's trying to test for "too many" and why the test isn't working as expected. BTW, Vanilla mc had a similar problem with squids a couple years ago.

This is on line 64, I can't tell what is null: SpearMod.network.sendToServer(new MessageExtendedReachAttack(mov.entityHit.getEntityId())); Whenever you (or anyone else) reaches such a problem, set a breakpoint and rerun in the debugger. That's a large part of what the debugger is for: Examining what's happening at certain points in a program's execution. In this case, you would have an opportunity to examine every value at work on that line simply by hovering over it, and you would know for certain what was left null. With a few more clicks in Eclipse (or other decent IDE), you might even trace back to where null object should have been set. I don't know why modders are so reluctant to get into the debugger. It's an essential tool. Every programmer should be as comfortable with it as with the editor. Using the debugger is a normal phase of program development that is needed in all but the simplest programs. Every modder should force himself to learn the debugger's basics be ready to jump into it at the first hint of run-time misbehavior.

Edit? Or extend? Please don't edit vanilla java files.

If your problem is a crash, read what caused it and try to solve it yourself first. If stumped enough to post about a crash here, you should ALWAYS include (within tags) or link to the crash log. Asking for crash help without posting the crash log is a way to rapidly earn negative karma