Startup crash with TCon

[Secretname2009]

I just got this error and it repeatedly happends at every startup.
It seems that TCon is rejecting start due to a invalid alloy recipe but im not sure if its TCon or BaseMetals and ModernMetals. I dont know if this is a bug or not, i just need help to see whats wrong and preventing start.
I may provide the forge log if needed but ill be ready to give more info if needed.
crash-2019-04-05_10.53.34-client.txt

[dshadowwolf]

Have you happened to have turned off fluids provided by BaseMetals or ModernMetals ? I can see that we did not thoroughly test that area, but it is the only reason I can see this crash happening. Either the fluid was turned off in the configs or something has caused data to disappear

[Secretname2009]

Yes i did actually turn off some unneccesary fluids in the ModernMetals config, more specifically i disabled Beryllium, Chromium, Cadmium, Galvanized Steel, galvanizedsteel, Magnesium, Nichrome, Stainless Steel, stainlesssteel and Zirconium.
As im writing this there is apparently duplicate configs for galvanized steel and stainless steel.
I was intending to disable the metals entirely but i realize i only touched the fluids section.
EDIT: Also Aluminium Brass has a duplicate but i didnt disable that.

[dshadowwolf]

There are configs for the materials and separate ones for the fluids - it seems the team member that added the "can turn off fluids" config didn't make sure all places the fluids are referenced got the check so in the TiCon interface code it says "oh, I can make Stainless Steel" and tries to register... This is going on my TODO

[Secretname2009]

I actually was intending to disable the materials mentioned entirely, not just the fluids. I werent aware of the fact that there was another section for the rest of the items.
Oh well i did find some bug with this and thats Nice.
I did just try to disable the materials entirely aswell with the fluids and that let the game start.

[Pythonic-Rainbow]

Can this relate to #345 ?

[dshadowwolf]

No - this arises from a change done to allow people to turn off fluids separately. The Tinkers' Construct interface code was not audited to check if the fluids were available. We've corrected this by changing the code to use the Minecraft/Forge fluid registry rather than our own inside storage but it can still crash if there is no provider for a given fluid, period.

There will be some changes to the code to check for the fluid actually existing in the -rc2 release.

[Pythonic-Rainbow]

But in my configs, all metals and liquids are by default, which still suffers from this crash. Is there some temporary resolution for this?

[dshadowwolf]

@Pythonic-Rainbow from the crash reported here...

net.minecraftforge.fml.common.LoaderExceptionModCrash: Caught exception from Base Metals (basemetals)
Caused by: slimeknights.tconstruct.library.TinkerAPIException: [TCon API] Invalid Alloy recipe: No result for alloy present
    at slimeknights.tconstruct.library.smeltery.AlloyRecipe.<init>(AlloyRecipe.java:28)
    at com.mcmoddev.lib.integration.plugins.TinkersConstruct.lambda$registerAlloys$11(TinkersConstruct.java:319)

See: MMDLib Source, 'registerAlloys'

In here we just loop the provided fluids. If you're having the same crash with nothing turned off (go check - I've found that there actually is a bug that turns off some fluids for vanilla materials that we fixed recently... The fix will NOT affect existing configs)

If you've got a copy of the crash report covering this, please attach it in some manner - we need those to track down bugs and having multiple ones covering any given bug is helpful in determining exactly what is going wrong in the case that there are multiple causes.

[Pythonic-Rainbow]

I don't have a client log, but I do have a server log available
https://gist.github.com/Pythonic-Rainbow/78cbfbf97896a3c8004ab4369ffc7c0d

[dshadowwolf]

Log is not showing the crash - I am seeing some issues (nothing for *Metals, aside from the "things moved about with MMDLib being split out from inside BaseMetals) but not the reported crash.

[Pythonic-Rainbow]

then I am not sure about it, as there is no crash report for server. It can't even start so theres no client crash. I had executed /fml confirm and results in a server crash but I found it completely useless.

[dshadowwolf]

Different issue - this did not show in pre-release testing, but what you describe sounds like an issue arising from the registration change, where extensions to vanilla stuff is now in mmdlib instead of basemetals. I am wondering if you ran into a bug where an event was being called server-side when it is related to things done client-side, like rendering.

[dshadowwolf]

Afterthought: there is a newer MMDLib released that does fix that, if my memory is working correctly. (if not, I can make it happen)

[Pythonic-Rainbow]

The world was generated in Beta5-7

[dshadowwolf]

Yeah - I actually tested the conversion. Issue is that we had a small...bug with the original -rc1 release where code was being called that exists only in the minecraft client. (that is, the code does not exist innthe minecraft server jar file, at all) I have a feeling this is what you ran into - it is fixed, as of -rc1.28 (released 5 days ago).

Unless you have data from the "crash-reports" directory or a log from using -rc1.28 showing otherwise, that is :)

[Pythonic-Rainbow]

thanks , will look into it soon.

[Pythonic-Rainbow]

Is this fixed in rc2?

[Pythonic-Rainbow]

It looks like the issue resolves at my side somehow! I am leaving this, thanks for everyone's help :D

[Pythonic-Rainbow]

Well it doesn't fixed, it just didn't crash. those materials are still gone..