ctbe

The mod quark does not wish to run in Minecraft version Minecraft 1.8. You will have to remove it to play. Perhaps that is the problem. I think you need to remove the quark mod as the version it was compiled for is different. Or so it gives the impression. I don't know about a best version as I think the word "best" is considered subjective in many places by many people and touching it is probably a hot button subject among players, but maybe you could try the latest minecraft version for which a stable version of forge exists.

Why thanks for the references and explanation. I know I said I'm leaving it, but just to show my whole problem, here is the rendering result of my code and the code itself that makes the linked video. Lid Rotation: https://vgy.me/EvxpWl Chest Body Rotation (how I wanted the lid to rotate): https://vgy.me/NOOLZg Code... (This code is quite a bit so don't worry if you don't look at it. I'm opting for going static.) TileEntity (TileEntitySimpleChest.kt) http://www.codesend.com/view/67ca9f38cda506bb1cbd0485d549aa8b/ Block properties http://www.codesend.com/view/b502d4257d3be71c3f7801d3dc34b0e1/ Block (BlockSimpleChest.kt) http://www.codesend.com/view/d1f28420c3518684918d930941e8e830/ TileEntitySpecialRenderer (TileEntitySimpleChestRenderer.kt) http://www.codesend.com/view/5248c50e70d83ba6b891a00e53100f45/ Blockstate JSON (blocksimplechest.json) http://www.codesend.com/view/2d66a1853026a2d6e1ce4a19aa08a7ea/ Chest Model (simple_chest.obj) http://www.codesend.com/view/4d62970462e21a83fd292d9f8c3d46ba/ Chest MTL (simple_chest.mtl) http://www.codesend.com/view/fbc3f45beb2651edde86582f9b83da82/ Lid Model (simple_chest_lid.obj) http://www.codesend.com/view/9715006f7c39b7dae56c42b795d0aa76/ Lid MTL (simple_chest_lid.mtl) http://www.codesend.com/view/dbf55dcb142c5aba6e9dee6ae2087c0e/ This was an extension of the tutorial: https://wiki.mcjty.eu/modding/index.php/Render_Block_TESR_/_OBJ-1.12 but I changed a lot of it to fit my purposes. Though the rendering code is pretty much a copy paste. No amount of transformation fixes the problem for me. The problem must be me and I could never identify what I was doing wrong. The code I provided here renders the first video only. The chest body rotation happens if one uses false for the IS_CHEST_LID property in the TileEntitySpecialRenderer... in case you wonder how I shifted from rotating the lid to rotate the chest body in the second video.

It's okay guys. I appreciate the intention on helping , but I'm really leaving it since this has been eating me for too long. If anyone asks me to add animation to my chests for when the lid opens and close I'll just tell them I don't know how to do it as I don't understand the GL. Don't worry . Here is an illustration in 2D of what I meant in my first post that is happening with the gl calls. In step 3, all the axes of reference get rotated. Meaning that any translation in the x axis afterwards, will be diagonal. This is 2D, but in minecraft, all 3 axes of reference get rotated together with the object (x, y, z).

Thanks for the answer, but I give up. I think no one has ever managed to do a custom chest in minecraft. If they did, they had a thorough understanding of what opengl is doing. I don't. I'll make my chest a simple static block. No animation or anything.

I previously asked this question and I was told to translate, rotate, then translate back. After many hours of debugging trying to understand what was going wrong, I have come to the conclusion that it doesn't work like that. When one rotates using GlStateManager.rotate, all the axes of the OBJ rotate as well. In other words, the final translation will translate in reference to the rotated axis, making it impossible to translate to it's previous position. For example: // Move in the x axis 0.5 (works fine) GlStateManager.translate(0.5, 0, 0) // Rotate around the z axis, 45 degrees (code breaks. the object rotates as intended, but all the axes get rotated as well) GlStateManager.rotate(45f, 0f, 0f, 1f) // Return the object to its previous position (Doesn't work, translates the object diagonally because the axes changed) GlStateManager.translate(-0.5, 0, 0) How would one rotate the OBJ without the OBJ axes being rotated?

The lightning got fixed by using this.setLightmapDisabled(true) as in the solution found here. But I feel I'm still doing something wrong since if I place more than one block, one lid renders normally lighted, and the other dark. Perhaps I should change the model of the block below the lid to be less than 1x1x1. After all, I have read various times it is not recommended to render anything bigger than 1x1x1. Edit: After a check, this doesn't solve the brightness issue. As when the chest and the player stand in a completely dark area, the lid can be seen clearly despite there being no source of light. After all, the lightmap was disabled.

I'm trying to use ModelChest to render a lid for my chest in a TESR. However, the lid renders dark and upside down. I don't know if calling render on a model from the overridden function is not the correct way to do it or recommended. I do know that when I tried this but while extending FastTESR, the code crashed because of some buffering issues and the crash was caused by the call of render(0.0625f) over the model. Not understanding how it works I might me doing something ridiculous here. This is my code: class TileEntitySimpleBoxRenderer : TileEntitySpecialRenderer<TileEntitySimpleBox>() { private val TEXTURE_NORMAL = ResourceLocation("textures/entity/chest/normal.png") private val simpleChest = ModelChest() override fun render(te: TileEntitySimpleBox, x: Double, y: Double, z: Double, partialTicks: Float, destroyStage: Int, alpha: Float) { // Store rendering flags GlStateManager.pushAttrib() // Store the viewport GlStateManager.pushMatrix() // Bind the chest texture this.bindTexture(TEXTURE_NORMAL) // Translate the location of the lid and knob GlStateManager.translate(x, y + 0.9, z) // Render the lid this.simpleChest.chestLid.render(0.0625f) // Render the knob this.simpleChest.chestKnob.render(0.0625F) // Restore the viewport GlStateManager.popMatrix() // Restore rendering flags GlStateManager.popAttrib() } } Result: Is there any way to make it normally bright, like a normal chest and flip it? By flipping it I mean maybe a method that takes care of it without having to use rotate and translate. If not I suppose I will have to use rotate and translate. I'm more concerned on fixing the brightness of the model rendered.

Oh no, it wasn't because I didn't want to write Java. I was okay with it . I was expecting to make a mod which when I finished planning it, it required me to use a lot of Collections, and with that expectation, I knew I could use Scala (from previous experience) to my advantage and their immutable collections for a little bit of additional performance if I were to program it correctly. But after writing a good amount of code for my mod in Scala I was like "Ugh, going back to Java". Right now yes, though I'm okay with it, I'm reluctant to use Java, but at first no. This is very true . Thanks for the Kotlin suggestion. I'll look into it. Because my mod is still small, I might as well re-write it in Java before it grows further and use the default language most of the community uses. That way I'm more in sync whenever I have a doubt. Thanks for the feedback, much appreciated.

The answers I look on this question would be answers that would be mostly based on opinion. But if you have predictable facts, that would be awesome. Yesterday I found out my project didn't compile and had to use Scorg to be able to compile it. I was thinking of re-writing it from scratch, but this time using Java because of fear that Scorg may stop being available in the future. I have been using Scala because I had many immutable collections which were providing me a slightly better performance although that wasn't always the case. In order to perform some operations, sometimes I had to make conversions from Scala collections to Java collections and those little pieces of code reduced my performance a little as well. Other times it was simply impossible to use some features of Forge due to the requirement of the use of static variables and/or classes which require you to do a little of workaround to get an equivalent in Scala. For example, I was unable to use the new @Config system with Scala. I had to use Java because no workaround got me a working config menu for my mod. Maybe if I had fiddled a little more with the code I could have gotten something working, but it was growing too ugly for the Scala style so I decided to use Java and combine it in the project. Previously I also had problems when using IProperty due to boxing concepts. I can't use Enums, but instead use objects that extends Enumeration. I cringe everytime I have to use equivalents to statics, but at the end have no options because of the way minecraft and forge were made. Something tells me I should just use Java which is what minecraft and forge were made with and save me all the workarounds and pain simply because I like the Scala style more and it offers me just a slight performance in some specific cases (in ocassions a cleaner look of code too). At this point I am trying to decide what to do. Simply use Java or stick to Scala and risk having to do many workarounds in the future to compile my project in case Scorg becomes unavailable or other kinds of workarounds to be able to use some features of Forge. What are your opinions, what would you do?

Quite interesting. I was unaware of those details. Thanks. I will use the ClientTickEvent.

I recently read somewhere in an answer to an old thread that rarely one should subscribe to KeyInputEvent when handling KeyBindings. That one should subscribe instead to ClientTickEvent. Of course, the answer was fitted to the context of that thread. In my case, in which all I do is open a GuiScreen menu should I subscribe with this @Subscribe def onKeyInput (keyInputEvent: KeyInputEvent): Unit = { // Do my logic here using KeyBinding.isKeyDown() } or with this @Subscribe def onClientTickEvent (clientTickEvent: ClientTickEvent): Unit = { // Do my logic here using KeyBinding.isKeyDown() } I have only one KeyBinding, the one for opening the gui. For my purposes, I currently find no use for the keyInputEvent variable. Also, will subscribing to check for key inputs on the ClientTickEvent consume more processing power than using KeyInputEvent? I somehow feel it does because while I am not moving or doing anything, minecraft would still be checking for the key binding state every tick.

Makes sense. Thanks for your reply.

I was so tired that I accidentally used sendChatMessage(String) instead of sendMessage(ITextComponent) which is what I really needed. (I know, programming while tired is not a good move) However, it surprised me that one cannot use color codes for sendChatMessage as they get filtered and the § character is treated as disallowed. The offender will get disconnected with the message: "Illegal characters in chat" on the screen. Would anyone happen to know of reasons for why sending chat messages with color is disallowed? I don't need to broadcast chat messages with color. I just need to display a colored message to the player performing an action and because said messages can display many times per player it would flood the chat if it is broadcasted. So I'm okay with sendMessage. I mean, imagine if I have 100 players online and at least 50 decide to perform a message displaying action at the same time or with 1-3 seconds of difference. It would be awful for all players to see 50 messages in such a short amount of time flooding their chat. Still, it made me curious as to why it is not allowed to use sendChatMessage with color. (Nothing occurs to me, I hope I am not touching a sensitive subject here, it's just curiosity)

I see. Then config is not the way to go for my purposes. I'll use GuiScreen with GuiButton then. To apply a custom property from my own mod to other items that may not necessarily come from my mod. If you take two of any, all properties would be mutually exclusive so I wanted a radio button. A GuiButton for example could work to remember only one property and then the player applies it to any item it wants in the game. But now I understand I'm doing the wrong approach. I'll use GuiScreen instead of a Gui config. Thanks.

My code is like this (source @Choonster): @Config(modid = TestMod3.MODID) @Config.LangKey("testmod3.config.title") public class ModConfig { @Config.Comment("This is an example boolean property.") public static boolean fooBar = false; @Mod.EventBusSubscriber private static class EventHandler { /** * Inject the new values and save to the config file when the config has been changed from the GUI. * * @param event The event */ @SubscribeEvent public static void onConfigChanged(ConfigChangedEvent.OnConfigChangedEvent event) { if (event.getModID().equals(TestMod3.MODID)) { ConfigManager.sync(TestMod3.MODID, Config.Type.INSTANCE); } } } } I'd like to know if one can have a button, radiobutton or checkbox in the config GUI. The following picture down to the right has a checkbox that says "Apply globally". Is it possible to use a checkbox like that in the GUI and if so, can buttons and radio buttons be used as well? If yes too, how? What data type or class should one use for a variable if it is that it already exist? Source