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.