jeffryfisher

While recently installing a decomp workspace for recommended build 1722, I ran into the dreaded heap failure at 56% of decomp. After following a whole bunch of bad advice that only made more errors earlier in the process, I finally hit on a solution: Prevent the JVM from asking for more memory than it can use. NB: Don't ask for a daemon, because it will claim even more memory. NB: Don't use gradle.properties, because it will cause a daemon to be spawned. The solution for older, limited machines is to edit gradlew.bat, changing the JV OPTIONS. I had less than 2000 megabytes of free (physical) RAM, so I set a max heap of 1536 MB thusly: set DEFAULT_JVM_OPTS="-Xmx1536m" Your number after the mx may vary, depending on how much free physical RAM your machine has (gradle seems to be unable to use virtual memory, so the size of your swap file is irrelevant). The key, if you're running out of heap space, is to enforce a limit so Java stays under it. setting a higher minimum (as many other forum posts advise) will only get you into more trouble sooner. PS: Setting a ceiling will make you pay in time for the memory you don't provide at start, so only go this route if the default generates a heap error.

When you place your crop on top of another crop, it is not on farmland. How do you handle that?

It looks like your rendering will not depend on "powered", but your error message shows that MC is trying to use it. You need to tell MC to ignore that property. In client proxy, call StateMap.Builder ().addPropertiesToIgnore(...). One of mine looks like this: @Override public void preInit(FMLPreInitializationEvent e) { Builder sm = new StateMap.Builder (); super.preInit (e); sm.addPropertiesToIgnore (BlockFenceGate.FACING, BlockFenceGate.IN_WALL, BlockFenceGate.OPEN, BlockFenceGate.POWERED); ModelLoader.setCustomStateMapper (AnystoneWallsMod.blockIronGate, sm.build ()); iwall1 = (ItemWall) Item.getItemFromBlock (AnystoneWallsMod.blockAnystoneWall); iwall2 = (ItemWall) Item.getItemFromBlock (AnystoneWallsMod.blockAnystoneWall2); addVariants (iwall1); addVariants (iwall2); }

Since I style myself as a professional who follows "best practices", I'll proceed as if my 1.8 world and mods can (probably) survive the upgrade. Of course, best practices include backing up the world before such an upgrade. I'll report back on any issues / workarounds.

I haven't yet because I was at the choice between versions to try. I was hoping that the compatibility was better known, but I guess I'll have to setup b1722 first and try it myself on one of my expendable SP test-worlds. Then I might find out that I need to use b1563 instead as the final resting place for my 1.8 worlds. Has anyone here upgraded to 1.8.9 on a world that created in an earlier 1.8 version? Were there any issues, or did mods' blocks survive intact?

1) I wouldn't cast an entity into IShearable until after the test for instanceof IShearable (declare target inside if). 2) Right now, your shears need to act on one sheep in order to affect other sheep near the first. If you wished, you could set the area of effect to center on the player doing the shearing.

The original blockstates file required a Cartesian product of states, each of which required a model file. For mods having N factorial permutations, the nightmare was positively medieval. There was much weeping and gnashing of teeth. But lo, Forge did invent an advanced blockstates format that could greatly simplify the process for mods possessing symmetry (and all well designed mods are so possessed). It also enabled a modder to move some information from model files to the blockstates file, so much so that many mods now need only a blockstates file (with references only to vanilla models). MC itself is rumored to be advancing to a similarly intelligent design. Thank Forge for leading the way!

I'm looking to update my mods from mc 1.8 (Forge 1450) without crossing a line that would break an existing server world. Some upgrades break worlds. Others don't. My server has been running Forge b1450 (mc 1.8 ) since summer. I'd like to top it out at (and upgrade my mods to) the highest recommended Forge build that won't break things (e.g. interpret my mods' blocks as new vanilla types). Looking at the files area here, I see two candidates. Build 1563 is the highest recommended for "mc 1.8", and build 1722 is the highest recommended for "mc 1.8.9". What I don't know is if it is safe to open a 1.8 world using a 1.8.9 server. I've searched, but the haystack of new features and bug-fixes is too deep to find a clear compatibility answer. I know that 1.8.9 clients can enter 1.8 servers, but I can't see that a 1.8.9 server can open a world saved by an earlier 1.8 server. Can I jump my mods and world to mc 1.8.9 and Forge 1722 without gross glitching? Have any of you upgraded last year's 1.8 worlds up to 1.8.9 without serious incident? In other words, does mc 1.8.9 play nice with earlier subversions of 1.8? If I can get clarity, then I can plan my project to upgrade my mods.

1) Why does your recipe have spaces around the P's? Wouldn't a 1-wide recipe work? 2) Why do you define 'L' as wool when it's not used in the recipe? 3) (Naked) Block properties do NOT survive recipe calls. The 1st thing that happens is that each block is wrapped in a default item-stack with metadata = 0 (ignoring block state). If you want your recipe to treat all plank subtypes as equall, then employ the Block as you're doing. On the other hand, if you want to specify each subtype, then you must wrap the plank block inside an item stack call that defines how many (usually 1) and which metadata value. To do a whole sequence, put the recipe call inside a loop through the metadata values (and don't forget to specify the metadata value in your output item-stack too).

Turn on the diagnostics (F3) and get an entity count. Having too many entities doing lots of thinking and fighting can bog down the game (maybe because of messaging). Loads of tile entities can slow you too.

The problem is in your source code. You need to instantiate your blocks and (in client proxy) mesh your items. I don't see any of that. You can't do everything in blockstates. Null is rarely a good thing in your log file error messages. A mod needs Java too. Also, for example, one blockstates file has "model": "commumod:retawBlock" , but the log shows need for commumod:retaw#level=14. Find out why there's a difference.

Download Recommended 1.8.9 - 11.15.1.1722 BTW, Have you looked at how crops grow in the first place? Can you see a way to override a method so that the final stage has a chance to roll around to the 1st stage?

That might explain the +5/-40 karma. I smell a thread-lock coming.

The problem now looks to be an execution-order error, probably in your main class. Why else would you try to register a null block?

Since the error message complains about "block null" while attempting to set shade to normal at line 36, you need to look into getBaseState called on line 35 and find out why it returns a BlockState with a null Block in it. BTW, When Eclipse gives you error messages with line numbers, you can click on the references to jump there and see what it is. You can then set breakpoints and re-run in the debugger to step through the erroneous code. Things often become much clearer when you can see what's what (variables, class members, parameter values passed, branches taken).

Often in such cases the "problem" is the very vague "syntax error". That's when one must kick Eclipse until it sees changed source elsewhere. Clean does a good job of that (at least in the Java version of Eclipse).

It looks like Dijkstra has started two threads on the same subject. Can they be consolidated?

And if you wanted all of your ore types to share some characteristics/behavior, then you could first create an abstract class implementing what's shared. Then each set of up to 16 ores could extend that class. How many ores does a game need anyway? Well, I suppose if you're using Minecraft to teach the periodic table to students... Otherwise game playability should be a consideration.

Many tutorials (including an entire child forum on this site) are geared toward earlier versions of Minecraft. However, they're still worth scanning to get a sense of the general Forge paradigm. Once you have a basic foundation, you can see what's peculiar about 1.8. Jabelar has some good articles: "Jabelar's Minecraft Forge Modding Tutorials"

You need to get the correct MCEdit version from the MCEdit folks. They currently have PC versions to edit Minecraft worlds running mc 1.7, 1.8 and Forge 1.7. They don't yet show one for editing Forge 1.8. You'll have to talk to them about what you're trying to do. Over here at Forge, especially on this forum, you can get help writing mods (not editing worlds). However, a mod can be something that generates structures, either as part of world generation or as a result of some kind of block activation. I wouldn't recommend such a mod as your 1st Forge project. If I understand your question correctly, you really want to get info from MCEdit (read their FAQ etc).

Sometimes Eclipse can get confused, and the cause might be in editor metadata, not your code itself. Try doing a project "clean". It's likely that Eclipse hadn't yet recognized that your ExampleMaterial fit the calling profile of the ItemPickaxe constructor. Kicking Eclipse a few times can sort it out. When that doesn't work, then it's time to look closely at elements like ExampleMaterial to confirm that they are what you think they are.

Did you get the "most recent drivers" via automatic Windoze update or via manual download from your adapter's manufacturer? It looks like Open GL support is missing. If you Google the key phrases in your errors, Windows' automatic driver update problems run like a rash through the analyses. Get graphics drivers manually and don't let Win-10 screw them up. Also follow D7's suggestion.

Have you Googled the error phrase and tried any of the solutions out there (e.g. graphics drivers)?

You should study both substitution aliases (which are currently problematic) and the missing id event (fires after postInit). If the site-search doesn't turn up useful threads, then try Google from outside (it often does a better job of filtering out lengthy crash reports to show more relevant posts). Even with those however, moving an existing modded world from 1.7 to 1.8 is a frightful project. 1.8 introduces blocks at IDs that mods love to use, so mods' blocks in a 1.7.10 world are interpreted as various new block types when opened in MC 1.8. We had a brief discussion of how to program a transition. It was brief because the amount of work was immediately obvious (and elegant solutions were not). What it did look like was that one would need a two step process: First make a 1.7.10 mod that would translate its blocks and items to ID numbers out of the range used in 1.8. Then open the world in an updated mod for 1.8. However, we abandoned that line of thought because the transition mod would need to force every chunk in every dimension to load and be converted and saved again (ugh!). It may be possible to create a conversion/export command to be run from the server console, but the discussion ended before we took it that far. Somebody may have gone off and done some programming, but I haven't heard about it.

Code tags are even better for most of the big text blobs pasted around here. You may use the editing button that has the hash mark on it, or you may put code and /code in square brackets to make tags before and after your text. When displayed, the very long text will be boxed with a scroll bar so the message doesn't become a haystack that obscures other messages. Suggestion: Go back and edit your opening message to put code tags around that pile of console output.