Currently having this registry issue
#Bruh
deft flume
Its simply a Oak_Ship_Helm not being rendered/found? idk probably something to do with a value or something
fading scroll
hmm its froge right il check it later today
deft flume
hmm its froge right il check it later today
If you do manage to fix it that would be epic
But ye its probably something to do with a missing value that isn't defining the Oak ship helm variant
and also Optfine crashes the VS2 Stand alone mod
idk why
sleek stone
Optifine works in Optifine ways
deft flume
Optifine works in Optifine ways
Optifine works like King crimson
sleek stone
Just out of curosity
have you tried it with rubidium?
Not suggesting you switch to Rubidium, I am just curious if it runs on there
deft flume
The chemical or the server?
deft flume
Never heard; Why you ask?
sleek stone
since both mods do optimising
deft flume
ah I'll look into it then
sleek stone
and I believe there can be times where one works but the other doesn't
I could just be completely wrong here, but I am curious
deft flume
because atm I am waiting for the forge Eureka crash to be fixed (possibly)
so I can do some compatibility testing
sleek stone
hopefully it does, tbh I just haven't tried anything VS2 yet because afaik, it just isn't ready yet
deft flume
I don't mind it being unstable as long as I can load it up and mess around with it
deft flume
@fading scroll I think you have to work overtime because I have encountered another issue with the forge loading
Its registering 2 Ship_Helm registries
I think this has to do with the versions though.
My guess is that all the oak_helm varients are borked
@viral ibex hello welcome to hell
viral ibex
are you sure you're not running 2 eureka versions
deft flume
I sandbox'd them so only one runs and comes up with the same issue
viral ibex
wild
deft flume
Yes
viral ibex
is this on a server or singleplayer
viral ibex
it really do be a froge moment
deft flume
Well using KoltinForForge is already funky though but hey aslong as use the debug stuff to its advantage it shouldn't be too much of a pain
Imma test something
Actually lemme ask something @viral ibex are the Oak_helms registered by ID's ?
deft flume
That sounds pretty frustrating when you don't have an ID system
viral ibex
it's a lot easier, usually
architectury is supposed to communicate between forge and fabric
but forge doesn't like how i implemented flammables
deft flume
Wait I think I know what you mean
viral ibex
thinks that the block isn't registered by the time flammables are made
deft flume
About the flammable stuff right?
So there used to be this old bug on Flans 1.12.2 where the block IDs would replace itself with a fire block for a Placeholder fallback; Do you think the registry isn't being defined and just reverting to something close to it
viral ibex
uh
deft flume
Would explain why it keeps switching between different oak helm verients
viral ibex
no
deft flume
viral ibex
so the way i understand it
and i could very well be wrong
architectury uses something called a deferred register
that the blocks are registered on
i think the issue resides in the way that fabric and forge use that deferred registry
and that forge is deferring it too late, causing the flammables to fail?
idk how ewoudje meant to fix it tho i haven't been home up until a few mins ago
deft flume
personally I think all of the Helms are doing funky shit on forge and are completely fine on fabric
deft flume
Perhaps do a test and remove the flammables on the blocks and re-implement them one by one to see what's causing it
viral ibex
the first one defined is the oak ship helm
so it's all of them
they all register flammability the same way
and all register as blocks the same way
in the same file
deft flume
Just try it 
because like
This error isn't defining as Oak_ship_helm
Just Ship_Helm unless woudje changed the defining
viral ibex
oh it's complaining about the gui
viral ibex
not likely 💀
