They do indeed force a block update once per second, which when collected many per chunk will ultimately mean once per tick. This is to ensure it updates with liquid state changes, but I may be able to streamline it.
Also, is this WAILA handling correct? I built it into my registries to save work:
-snip-
Um... that is just completely stupid. What even is this? Go look at my implementation again, you're supposed to subclass IWailaDataProvider once for the whole mod, and put your handlers in it. Also, we need to have a talk about how to properly use the world render, because I can't even begin to write down all the things you are doing wrong. What you are doing is breaking Minecraft's whole rendering pipeline. Can you get on IRC or something?
The pipes do use an ISBRH. The old TESR might still be in the code, but it is unused.
Oh? Well, if it's not TESRs then what is it? I was building a pipe cube but I had to stop as my FPS was plummeting, though only while unpaused. I'm going to run VisualVM on it and report back. In the meantime, somewhere between 1000 and 2000 pipes...
EDIT: Here's the VisualVM report, looks like it's making the chunk re-render every tick. Upon further testing I noticed each pipe re-renders the chunk once per second, regardless of state change. This is a REALLY bad idea, like worse than using TESRs.
Also the liquid rendering is making everything mess up because you're making direct GL calls and messing with GL states in a world renderer. This is a really bad idea and should not be done under any circumstances, only use the tessellator in world renders. http://github.com/ReikaKalseki/RotaryCraft/blob/master/PipeBodyRenderer.java#L239
Reika, I looked at your pipe render, and this is an absolute disaster. Why are you using a TESR for pipe renders? Hell, you're using a TESR for everything, this is going to lead to some serious performance issues in bases with a lot of stuff. I understand TESRs for machines with animations, but why non-animated machines, pipes and other things that don't change state often? You really should be using ISimpleBlockRenderingHandler for that, as that is cached and doesn't have to re-render every frame.
Reika, I'm noticing really odd flickering issues with the alpha pass. Anything that's partially transparent (water, stained glass, etc.) is flickering randomly between opaque, normal and invisible. It does this when any of your blocks are on-screen. If you need a video of it I can try...
EDIT: It's not any blocks, just pipes/hoses/etc with liquid in them.
Should probably note an odd glitch with Waila after doing all this.
Yes, that's known. This is caused by Reika using a deprecated API in WAILA.
Reika, I've provided more details for updating in this post, you really need to update your implementation as IWailaBlock is going to be removed entirely. It's been marked as deprecated for months.
I don't have Biomes O Plenty and I'm not crashing when generating a new world.
Looking at the crash report, it's a stack overflow which means the tree generator is calling itself recursively. And it's not occurring without Biomes O' Plenty? Weird...
EDIT: Looking at the code in question, it appears to be some unexpected values resulting in breakage of compatibility with most biome adding mods.
I still do not understand how this works. The tutorial mentioned earlier described many classes. This is one.
No, you just misinterpreted it. It was showing all the ways you can register your IWailaDataProvider, and some example @Mod classes. All you need to do is make one class that implements IWailaDataProvider, have getWailaStack return null (this will make it just use the default), and make sure getWaila(Head|Tail|Body) all return currenttip passed to it, or you'll just have empty text. Then have a static method in the class named something like callbackRegister (that's what mine is), though exact naming isn't important as long as you use it in the code below, and have it register a new instance of your class as a body provider (again see my example class, no need to register head or tail provider unless you want to mess with block or mod names). Finally, send an IMC to WAILA with the fully qualified path to your static method, here's my IMC line as an example:
Then all you need to do is put your handlers in getWailaBody.
EDIT: I should also note that doing this means you no longer need to package the WAILA API in DragonAPI, since the class is never loaded unless WAILA is there is recieve the IMC.
I see the similarity, but have no idea what is going on here. How does one use the old block classes and methods in said classes while using the new registration systems? Registering a custom handler and registrar and like 3 other classes for every block ID is absolutely unacceptable. I would sooner completely remove Waila support than have 80 classes dedicated to it.
Also, I have no idea what the WAILA issue is, but I know that the reason my blocks do not have messed up names is that I specify them manually, as it used to not print them at all in later versions for 1.6.4.
I talked with ProfMobius, and apparently the method you're using for WAILA support (implementing IWailaBlock) is deprecated (has been for months). You should need to switch to the IWailaDataProvider method, as IWailaBlock is going to be removed entirely. The new API is pretty similiar so changing should be a quick and painless process, details here: http://mcpold.ocean-labs.de/index.php/Waila_API#Registering_with_Waila
Abrarsayed. He is the creator(or at least one of the creators) of ForgeGradle, a tool Forge modders use for compiling and building their mods.
Ah, okay. Yeah I know what ForgeGradle is as I make mods as well. So then this might be an issue in Forge itself? That would make sense given how strange this is.
Abrar says that ASM is probably involved, so now all bets are off. I would submit this as an issue request, but I want to ensure it is both my fault and not fixed in newer versions before doing so.
Who is Abrar, and what are you submitting an issue report to?
No, the event handler issue does not prevent ElectriCraft from working or its networks from being constructed; it merely prevents them from ticking, which is essential for the wire melting (though in hindsight, I should maybe move that to on update).
-deleted-
Had the setup backwards, my bad. Carry on.
Also, I had a look at the bytecode of one of your event classes and a Forge event class, there's no defined zero-arg constructor in either of them. I also had a look through the code, I see what you mean about the construct inheritance, and I honestly don't know why Forge's events work and yours don't. Maybe it has something to do with when the event handler is being registered, since it's after game startup rather than in preInit or init. Perhaps Forge doesn't like that.
Oh, and is it possible in the future for you to just put your mods on a local server and make sure they load and function before doing a release? Because client class dependency crashes seem to be a common thing.
0
It's Techjar. My forum name is different because I lost access to my account in the move to Curse.
0
Yeah, but the last time I got on there you were in a private channel and the server wouldn't allow me to PM you.
0
Um... that is just completely stupid. What even is this? Go look at my implementation again, you're supposed to subclass IWailaDataProvider once for the whole mod, and put your handlers in it. Also, we need to have a talk about how to properly use the world render, because I can't even begin to write down all the things you are doing wrong. What you are doing is breaking Minecraft's whole rendering pipeline. Can you get on IRC or something?
0
Oh? Well, if it's not TESRs then what is it? I was building a pipe cube but I had to stop as my FPS was plummeting, though only while unpaused. I'm going to run VisualVM on it and report back. In the meantime, somewhere between 1000 and 2000 pipes...
EDIT: Here's the VisualVM report, looks like it's making the chunk re-render every tick. Upon further testing I noticed each pipe re-renders the chunk once per second, regardless of state change. This is a REALLY bad idea, like worse than using TESRs.
Also the liquid rendering is making everything mess up because you're making direct GL calls and messing with GL states in a world renderer. This is a really bad idea and should not be done under any circumstances, only use the tessellator in world renders. http://github.com/ReikaKalseki/RotaryCraft/blob/master/PipeBodyRenderer.java#L239
0
0
EDIT: It's not any blocks, just pipes/hoses/etc with liquid in them.
0
Yes, that's known. This is caused by Reika using a deprecated API in WAILA.
Reika, I've provided more details for updating in this post, you really need to update your implementation as IWailaBlock is going to be removed entirely. It's been marked as deprecated for months.
0
Looking at the crash report, it's a stack overflow which means the tree generator is calling itself recursively. And it's not occurring without Biomes O' Plenty? Weird...
EDIT: Looking at the code in question, it appears to be some unexpected values resulting in breakage of compatibility with most biome adding mods.
0
0
No, you just misinterpreted it. It was showing all the ways you can register your IWailaDataProvider, and some example @Mod classes. All you need to do is make one class that implements IWailaDataProvider, have getWailaStack return null (this will make it just use the default), and make sure getWaila(Head|Tail|Body) all return currenttip passed to it, or you'll just have empty text. Then have a static method in the class named something like callbackRegister (that's what mine is), though exact naming isn't important as long as you use it in the code below, and have it register a new instance of your class as a body provider (again see my example class, no need to register head or tail provider unless you want to mess with block or mod names). Finally, send an IMC to WAILA with the fully qualified path to your static method, here's my IMC line as an example:
FMLInterModComms.sendMessage("Waila", "register", "com.techjar.hexwool.integration.WailaDataProvider.callbackRegister");Then all you need to do is put your handlers in getWailaBody.EDIT: I should also note that doing this means you no longer need to package the WAILA API in DragonAPI, since the class is never loaded unless WAILA is there is recieve the IMC.
0
The IWailaDataAccessor passed to it will allow you to access whatever data you need. Here's my implementation as an example: http://github.com/Techjar/HexWool/blob/master/src/main/java/com/techjar/hexwool/integration/WailaDataProvider.java
EDIT: Fixed link.
0
I talked with ProfMobius, and apparently the method you're using for WAILA support (implementing IWailaBlock) is deprecated (has been for months). You
shouldneed to switch to the IWailaDataProvider method, as IWailaBlock is going to be removed entirely. The new API is pretty similiar so changing should be a quick and painless process, details here: http://mcpold.ocean-labs.de/index.php/Waila_API#Registering_with_Waila0
Ah, okay. Yeah I know what ForgeGradle is as I make mods as well. So then this might be an issue in Forge itself? That would make sense given how strange this is.
0
Who is Abrar, and what are you submitting an issue report to?
0
-deleted-
Had the setup backwards, my bad. Carry on.
Also, I had a look at the bytecode of one of your event classes and a Forge event class, there's no defined zero-arg constructor in either of them. I also had a look through the code, I see what you mean about the construct inheritance, and I honestly don't know why Forge's events work and yours don't. Maybe it has something to do with when the event handler is being registered, since it's after game startup rather than in preInit or init. Perhaps Forge doesn't like that.
Oh, and is it possible in the future for you to just put your mods on a local server and make sure they load and function before doing a release? Because client class dependency crashes seem to be a common thing.