LegendLength

I'm confident this happens due to annotation compiler settings in Eclipse. I never had this problem until I reinstalled Eclipse recently and used default settings. In my previous installation i had played around with annotations, and therefore enabled options to auto compile annotations or whatever.

I believe it should be marked as a resources folder rather than a sources folder.

I've never done it but you should be able to iterate through the global ForgeRegistries.RECIPES array and find the one for Log .

Running 'MinecraftClient' works for me. You probably just forgot to choose the module in the run configuration screen (halfway down). Need to choose 'main' from the dropdown. Did you get a specific error when you tried to run MinecraftClient configuration?

I'm having a small issue with Intellij. When there is an error in the source code the IDE points to the wrong file. It should go to "MyProject/src/main/java/MyClass.java ". Instead it gives "MyProject/build/sources/main/java/MyClass.java" . I tried looking through all the settings but i can't find anything that would cause this behavior. I tested without ForgeGradle and the issue didn't occur so I assume this is just part of how FG does things? In summary, the IDE is giving me a mirrored file rather than the actual source when a compile error occurs. It means when I click on the error message i get taken to a generated version of the source file in "build/sources" rather than "src" directory. This is using latest 1.12.2 Forge mdk and latest IntelliJ ide (version 2019.3 i think) . I tested with other gradle versions but problem remains. Doesn't seem to happen in Eclipse.

That also looks good. I ended up using JsonToNBT class as suggested and it turned out fairly straightforward. Took me a while to realize quotes are needed for some values but not others. So i decided to just add quotes around every value and allow the user to enter key value pairs without quotes. Otherwise they'd have to escape the quotes in the mod's JSON configuration file. customBlockStateText is text such as "facing:east" and blockStateTextDecorate() is a little method that formats it to the liking of JsonToNBT. Turns it into {Properties:{facing:"east"}} .

Thanks it's a handy looking class

I've searched for a few hours but can't find a way to create a blockstate from a string. I want the user to specify a blockstate in the configuration file and then load that into the mod to create that block. For example I want them to be able to create a grass block with snow on top (blockstate property 'snowy' = true). There's more to the design but that's the gist of this specific problem. I can convert from blockstate to NBTTagCompound but can't go that extra step of converting a string into NBT. I considered allowing the user to write out separate key + value pairs in the configuration but it's also difficult to work out the type needed for each property (something that NBTTagCompound.readBlockState() seems able to do). I'm surprised there isn't some common method to do this as I imagine other mods would need to read blockstate that's written the user.

Ok thanks for the tips from both of you. I have only just started looking at the client / server issues for mods so that will come in handy.

I think I found a solution so i'll give some details in case anyone needs it in future: The goal is to move the player by position rather than using motion. The problem is if you directly call something like setPositionAndUpdate() you don't get the benefit of minecraft's position interpolation, among other things. After looking through the movement code I saw that the Entity.motionX fields are simply added to the Entity.posX fields every tick. There are no special physics derivations etc. going on. This means you can simply set motionX to be your position delta and the game will move the player by that amount. It allows you to use any kind of physics system you want because most of the advanced ones (like Runge Kutta) require you to adjust position, rather than velocity. So it would look something like this: @SideOnly(Side.CLIENT) @SubscribeEvent public void onPlayerTick(TickEvent.PlayerTickEvent event) { if (event.player.world.isRemote) { if (event.phase == TickEvent.Phase.END) { EntityClientPlayerMP player = Minecraft.getMinecraft().thePlayer; // calculate all the physics you need Vector3F deltaPosition = myCalculateDelta(); // you can store current velocity in your own variable somewhere // move player player.motionX = deltaPosition.x; player.motionY = deltaPosition.y; player.motionZ = deltaPosition.z; } } }

Thanks. I did test test player.setPostionAndUpdate() but wonder if it's the 'correct' way. I noticed there was no interpolation when doing it this way. From my research it seems that method is used mainly for setting the player's position during a teleport event. Do you think it will still handle interpolation, collision detection etc. properly? I'm also not sure if it is the right way because it seems to send a network update straight away, whereas using MotionX etc. may do network updates a little differently.

I am trying to move the player by a small amount in x,y,z during each game tick. I have done various searches on this forum and stepped through the code but still struggling to find the correct way to do it. Currently I'm able to set the player's motion during the player tick end event and it works well. But if I try to set position instead then the player will bounce a bit in the direction and then reset back. I assume it's not getting sent to the server. I also tried player.setPositionAndUpdate() but I believe that is for when you are teleporting a player. The aim of this is for normal movement (trying to implement physics on the player using a certain type of numerical integration , hence the need to set position rather than motion). Feel free to offer a solution for a higher minecraft version instead.

Actually I wasn't after a lecture on why things should generally be updated. I was after one or two of the main improvements in 1.10 over 1.7.

I would also like to see compelling reasons for updating. I'm not doubting they exist. Nor have I bothered researching it yet. As I stands I choose to start with 1.7.10 and implement the newer versions when the mod is stable. In my opinion the popularity of 1.7.10 is still too high to ignore (regardless of the reason).

If you want roll then i highly recommend using quaternions rather than vectors. Otherwise you will quickly run into problems, the main one being gimbal lock. That is where vectors effectively break down and don't display the rotation correctly. The problem is quaternions can very difficult to work with as a developer and debugging rotations can be soul destroying. Other tips that I would add: - Minecraft treats zero rotation as the player looking down the z axis, whereas quaternions and math in general treat as the x axis. (Please correct me if that's wrong). So you'll need to do 90 degree rotation to the left when calling most quaternion library code. - You can change the player's roll by setting the private 'camRoll' field in EntityRenderer class, using reflection. - You should ensure the z axis rotation is capped between -90 and 90 degrees (pitch). The x and y axis rotations should be between -180 and 180. The player will still be able to do loops in any direction, but the minecraft code kind of requires these values (speaking roughly). - When converting from Euler angles to quaternion (e.g. when reading current player rotation) you should ensure you use YZX order. This ensures that roll is done last. Same for converting from quaternion to Euler. That will sound confusing if you haven't dealt with it before but it's a problem that caused me over a week of debugging so maybe bookmark this if you choose to go down this path. Other orders may be ok but the standard XYZ order does roll before it does pitch which is wrong. - If you simply add a 360 degree rotation to the player, the player will spin around quickly in-game. You would think they would just stay still but the minecraft code interpolates between the two values automatically. This can be a problem if your rotation formulas decide to add 360 degrees etc.. This is related to the point about keeping the y axis between -90 and 90 degrees.

If your only goal is to provide dvorak support, wouldn't it be better to just let the operating system handle it?

I had a look over the code and in my opinion it is remarkably clear and well structured.

I know this is an old thread but I have just gone through this same issue. In particular trying to lock the mouse so the player angle doesn't change. I found this to be a good solution, anywhere in your initialization code: MouseHelper customMouseHelper = new MouseHelper() { @Override public void mouseXYChange() { deltaX = 0; deltaY = 0; } }; Minecraft.getMinecraft().mouseHelper = customMouseHelper;

Thanks Ernio. Could you tell me where you got the field "field_110449_ao" ? Is that something that will remain constant across version 1.7.10 up to the current version? Also is there a non-reflection way to access a custom resource pack?

Ok so you have 168 for the 10% value when the screen is 1680 . But what about the values when you make the screen smaller? Did you ensure it was (for example) 70 and 700? You might be using the wrong value for screen width even after the user resizes the screen. You might be using the old width value that you calculated earlier.

It's possible load external images using DynamicTexture . I have some code around here if you want it.

When you are logging the values, do this: posX= ( (int) (displayWidth * 0.1F) ); posY= ( (int) (displayHeight * 0.1F) ); and get rid of this: //Offset added for the gui whit the buttons // posX = posX + ppx; // posY = posY + ppy; You should always see the button at the top left of the screen and it should always start at 10% of the screen size (use a ruler in real life to check).

My JAVA_HOME is set to "C:\Program Files\Java\jdk1.6.0_45" . Are you sure it is able to use the JRE as opposed to the JDK?

You imply it should be easy to create a workbench GUI without having an actual workbench at that location. But it's not necessarily true because the workbench GUI interacts with the workbench itself (by holding items while they get crafted etc.). That is all speculation I haven't worked with that particular object in the game.

I don't see a problem with what you are doing: posX=(int)(displayHeight * 0.1) I am doing the same in a mod I am currently working on to do percentage layouts as well. Have you tried writing the positions to the log along with the screen width values? What does it say when the position appears wrong on the screen for: 1. The position of your gui element 2. The width of the screen