Cadiboo

What I meant by a wrapper was an API built on top of Forge that handles all the registration, using an input system that doesn’t change per version. Why would you ever deal with unobfuscated Minecraft classes directly?

Getting a more updated version will probably help but

On the surface the problem appears to be Mekanism doing something wrong, you can try using MC Edit to look around and delete/replace any Mekanism transmitter blocks (cables probably). If that doesn’t fix the problem, you can try some other things. You could also talk to the author of Mekanism (or create an issue on their issue tracker) and see if they can help you. If that doesn’t fix it you can try removing your coremods Extra Utils 2 appears to be broken, you could try removing it. Something to do with events appears to be going wrong in the mod wasteland. The mod Ores Core has a weird character in its name

Other threads: ... And plenty more: http://www.minecraftforge.net/forum/search/?q=onUsingTick&type=forums_topic&sortby=relevancy&search_in=all

Yeah I did go through it with the debugger, but apparently forgot to post the results. This problem still isn't solved, so I'll go back to this project soon and get you a proper answer.

Multiple people have had this problem (ill link threads in a sec). I believe that the problem is due to modifying the item's NBT (this includes saving capabilities) while using it (which causes a sync, which causes the ItemStack client side to be replaced by a new one from the sync NBT, so the firing is force stopped on the client, while the server is unaware that you stopped shooting). This is just my hypothesis though. There are some partial solutions to the problem: - Only saving (and therefore syncing) NBT in the onUseFinish method (this allows the player to keep shooting clientside but could cause desyncs) - Overriding shouldCauseReequipAnimation (doesn't solve the problem, only makes any visual glitches go away)

I did say "very simple mod", your wrapper could inject some autogenerated models (I'M NOT RECOMMENDING OR SUPPORTING OR ENCOURAGING OR ENDORSING DOING THAT!) Depends what your trying to port, I just ported a 1.7.10 rendering based mod to 1.12.2 (it took me almost a year to learn the stuff required, but the mod was pretty high level). If I remember correctly, aside from the rendering changes 1.7->1.8 wasn't that big of a change, so you could probably go straight from 1.7 to 1.12.2. The best guide is learn to mod in 1.12.2, then take that experience and use it to port the old mod. Forge code doesn't change too much except when a new version comes out (they save up forge changes for new MC versions), but yeah me/someone has to write a new wrapper for every supported forge version (which should be every forge version)

@Issac29 Please don't necro an old thread (this thread is over a year old) and please don't hijack someone else's thread - make your own. What are you trying to do (please describe it in end-user terms not how you've attempted to program it)? Please include your code (the JSON recipe).

Oprand stack overflow means that a coremod is messing something up (1 or more could be trying to modify the same thing, a coremod is broken, etc.) You have a lot of broken mods that you should fix. I've seen this error (or at least one very similar) before & I'm 95% sure its Better Foliage. You can find out the cause of these crashes usually by looking at what class caused the crash (net/minecraft/client/renderer/chunk/RenderChunk), thinking what mods are likely to be messing around with that function (rendering mods) and looking at the messages immediately before "[BetterFoliageLoader] Applying RenderChunk block layer override". I'm pretty sure that the devs of BetterFoliage have simply forgotten to add the proper flags (COMPUTE_FRAMES or/OR COMPUTE_MAXS) to their ASM class writter.

Well its actually 100% possibly if you're willing define backwards compatible as rewriting the mod for every version. If your mod is very simple (just adds blocks & items etc.), you could also use/make a system (API) that handles all the registration & stuff while not externally changing from version to version (this still means you/someone else has to rewriting the mod for every version).

Your probably going to want to give it more RAM (your giving it 1gb, I recommend about 3gb). This is probably your main issue. You could also try removing some of the mods that are throwing errors (solarflux, mysticalagriculture).

If you want help with anything we need logs

which one? you can't have both. Can you please post your entire debug log? I can't see the cause of the error from that snippet

your log will be in .minecraft/logs/

Well, that does change the context a bit.

I think using 4 ids with an axis variant is better that using 1 id and squeezing 4 variants and the axis into 1 block. To be fair you only need 2 bits for the variant and 1 and a half (2) bits for the axis if your being efficient, still thats your 4 bits used up with space for only 1 more axis/variant.

do you know what exact version of forge they stopped spawning in?

You should update to a modern version of Minecraft, can you please post your entire debug log as described in my signature and DaemonUmbra's signature (the text below all of our posts)

How did you download it? where from (post the url) and can you post any logs too please

Try removing heroesexpansion, malisiscore and LucraftCore also update your forge to the latest stable version

We can't help without your new log

Make a new thread

do you control this entity (is it yours/are you able to override it)

Can I reccomend not using metadata? In 1.13 the flattening is happening and all the different types of wood are moving to different blocks (this doesn't mean different classes).