https://pastebin.com/Bvn5jx39

https://pastebin.com/cKbK8UHp

https://pastebin.com/eTbphx1i

Different crashes each time, I'm not sure which mod is at fault out of the two so posting on both.

It seemed to happen regardless of if I had creates "experimentalRendering" option set to on or off.

It appears the chunks the world is returning is returning chunks that return null for chunk status. Typically this value should never be null.

I believe this issue has been fixed in Create 0.3.2 and up :)

crash-2021-08-27_14.05.56-client.txt
Get this crashlog witch Create 0.3.2d, so it doesn't fixed(

Yeah I get the same thing, from what I can tell its fixed in starlight rc3 but that's only for 1.17.
#56 has the same issue which was fixed in rc3.

crash-2021-08-27_14.05.56-client.txt
Get this crashlog witch Create 0.3.2d, so it doesn't fixed(

crash-2021-08-27_14.05.56-client.txt
Get this crashlog witch Create 0.3.2d, so it doesn't fixed(

Yeah I get the same thing, from what I can tell its fixed in starlight rc3 but that's only for 1.17. #56 has the same issue which was fixed in rc3.

Well that sucks, I guess I will have to wait until all the other mods I like update to forge 1.17...

There is still a create/starlight incompatibility in Minecraft 1.18.1 : https://crashy.net/hyW1At23jTboxYBvOtu6 (generated using Not Enough Crashes) (even with /flywheel backend off)

@Spottedleaf Create puts its contraptions into a fake world and runs the lighting engine in it, so it'd be great to be able to take advantage of all the optimization work you've done here. This should be fixable on Create's end.

It appears the chunks the world is returning is returning chunks that return null for chunk status. Typically this value should never be null.

Starlight generally expects Vanilla chunk data when it's given an IChunk. For example, I expect the chunk to have a status (I don't care about chunk generation statuses though), and I expect the block data inside the chunk to be stored in the ChunkSection[]. I access the palette of the ChunkSection directly. I also expect the World object to give me chunks, but I rely on the chunk status and the hasLight() function to determine whether light should be propagated in chunks. I also expect chunks to implement ExtendedChunk and provide accessors to the light data and emptiness maps.

I also expect worlds to implement ExtendedWorld and the getCustomLightHandler method. It can return null if no custom light is used, but be aware this "api" will be dropped in 1.17 entirely so don't get comfortable using it.

So provided the above (maybe more, I don't know everything off the top of my head) is maintained it should work fine.