2 hours ago, Animefan8888 said:

When your mod is compiled it doesnt just stay as extends Item or new ItemStack it is translated into the obfuscated names. Which is why using an IDEs built in compiler doesnt work, you have to use gradle.

Sorry, I thought this was related to the wrapper, obviously mods break between versions because of that

7 hours ago, Animefan8888 said:

@Cadiboo @desht @Zeigfreid You are forgetting about obfuscation of Minecraft classes. In one version the Item class could be called a while in another it could be called b. You can't fix that by creating a wrapper.

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

8 hours ago, Cadiboo said:

Your probably going to want to give it more RAM (your giving it 1gb, I recommend about 3gb). This is probably your main issue.

 

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)

12 minutes ago, Zeigfreid said:

What about things like the formats of the various json files? That's something I would not be able to encapsulate with a wrapper, if the formats have changed I would need to either... generate the json files from some common format, or write everything twice.

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!)

 

14 minutes ago, Zeigfreid said:

What would be a good guide to look at for porting from 1.7 to 1.8 ? (just to get a sense of the concerns involved)

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.

 

17 minutes ago, Zeigfreid said:

It could mean that, but couldn't it also mean that you/someone just has to write a new wrapper for each supported forge version?

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.

5 minutes ago, Animefan8888 said:

No this is impossible. In 1.8 a lot of things changed method names, models, etc. Its basically impossible for mods to be backwards compatible between minecraft versions like 1.10 to 1.11 but 1.11.0 to 1.11.1 would be possible.

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

2 hours ago, Invalidm said:

Java 8 for 64bit and 32bit.

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/

1 hour ago, Cadiboo said:

with space for only 1 more axis/variant

 

Well, that does change the context a bit.

13 minutes ago, Animefan8888 said:

Of course.

But going by this logic he shouldn't be developing at all, because 1.13 isnt out yet. Because there would be no point in releasing the mod for 1.12 if it uses too many block ids.

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

2 hours ago, Samv2005 said:

i don't know how to get the debug log

22 hours ago, Cadiboo said:

post it using pastebin or GitHub Gist as described in my signature (the text below all of my posts)

 

We can't help without your new log

 

Just now, vXsouleaterXv said:

I'm having the same issue here is the crash report 

Make a new thread

4 minutes ago, Discult said:

The max health of an entity.

 

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