jabelar

It's strange. I traced the jump event call hierarchy and there is one place that might be a bit buggy. In NetHandlerPlayServer, in the processPlayer(C03PlayerPacket) it calls a player jump() method based on the following logic: if (this.playerEntity.onGround && !packetIn.isOnGround() && d12 > 0.0D) { this.playerEntity.jump(); } And d12 is simply the player posY. I'm not really sure why it is checking if the Y position is greater than 0.0D because that position is down in the ground, I guess it is just to disallow jumping if you're falling through the bottom? What is interesting is that it isn't looking at the isJumping boolean, but simply based on if the player update says that the player isn't on the ground! So I think it may be a bug because I assume that the isOnGround() would also be false when knocked back, falling, and so forth.

Did you trace the execution using debug mode in your IDE? I'd set breakpoints in the code that does the substitution to see if it is properly executing.

Okay. Well anyway you have to resort to standard debugging. Are you sure the method is being called? Use a console statement to confirm it. After that, in the pre-init I think your registry of your blocks and items is wrong -- I don't think you can (or at least I think it is a bad idea) to set the unlocalized name to "minecraft:snow". The "minecraft:" is for vanilla items and it should really have your mod id. After that, are you sure that the instances you are passing have in fact already been constructed (not null). Again use console statement to confirm it. That's the only things I can think of, otherwise it looks pretty simple.

How come you don't have @Mod.EventHandler annotation before each of your event handling methods? I think your methods probably aren't being called at all because you don't have the annotation.

I recommend the following book: Java in Easy Steps http://www.amazon.com/Java-Easy-Steps-Fully-Updated/dp/1840784431 What I like about it is that it covers all the key topics but isn't as boring or scary as many coding books. It is a nice quick read and you'll learn a lot. Also, I believe coding is something you need to learn from an actual book. Video tutorials have a set pace that may not suit where you're at in your learning. Also, people tend to skip ahead in videos and miss some of the key early concepts, whereas a book will lay it out for you in very specific way to build up your knowledge.

That is an interesting idea. By the way, are you sure you can't use some of the render events to make sure you're in proper world for rendering?

Wait, what do you mean exactly about a vanilla server? For this mod to work it has to be installed on the server, since only the server knows how to send things to all the other clients. If you think about it, it would be a security problem if people could make a client side mod that sent messages to other clients without being processed through the server. So when you say it only works in single player mode, when you were trying multiplayer mode did you have the mod on the server?

Sometimes this happens -- you come up with a clever architecture and start coding it and after a lot of work it is mostly working but then you find a fatal flaw in the approach. That might be your case. Instead of multiple active client worlds, can't you recode the airships so they don't require different worlds?

I believe the yOffset is to correct the fact that the center of the model that you display will be at 1.5 blocks up, whereas the entity position is at its "feet". So basically the center of your entity (as displayed) will be at yOffset above the entity position.

Couldn't your mod take any packet received by any one of your worlds and propagate the info to the other worlds?

I've never seen one. If you truly cared about real-time seconds you could use the system timer functions in Java, but most people believe that any time-based activities in Minecraft should lag together with everything else (which I agree with) so yeah just divide by 20.

Nevermind. You have to edit the gradle wrapper properties to pick the right distribution link for 2.8.

I noticed that the most recent version of ForgeGradle is 2.0.2 so I figured I'd try to update by making my build.gradle have this (this is directly from the official ForgeGradle plugin site (https://plugins.gradle.org/plugin/net.minecraftforge.gradle.forge): buildscript { repositories { maven { url "https://plugins.gradle.org/m2/" } } dependencies { classpath "gradle.plugin.net.minecraftforge.gradle:ForgeGradle:2.0.2" } } apply plugin: "net.minecraftforge.gradle.forge" But when I do have that and run gradlew setupDecompWorkspace I get an error that says "ForgeGradle 2.0 requires Gradle 2.3 or later". I remember when I updated Gradle to 2.2 but I can't for the life of me remember how to do it. What do I need to do?

Yeah I guess I could just consider it something that people would tolerate. I definitely noticed it in testing though which is why I tackled the problem. I guess I can handle the dying as a separate case, like you said, so that if it loads and is already dying then it would go straight to carcass pose.

No don't do it from a .bat. Just run it from a command window that contains the downloaded forge stuff. It will then go through a fairly long series of steps to download various things, make deobfuscations, etc. Also, if you're just trying to get started in 1.8 again, I have a bunch of tutorials that can help. Here is the tutorial for setting things up: http://jabelarminecraft.blogspot.com/p/quick-tips-eclipse.html

You got it exactly. However, when you say in Minecraft the animation state isn't saved, I think it works for vanilla because the animations are so short and not very distinct. So the disruption isn't noticeable. In my case however, I have things like a dying animation that goes on for about 10 seconds (entity sort of rears up, staggers back and forth, falls then flops on the ground) and actually persists longer than that to create a "carcass". So if you save the game while looking at a dying entity (or carcass), when you load the game it will look like it is alive and then die all over again. It is just extremely noticeable. I think generally if someone has a long, distinctive animation then ideally when you load the animation would be is same point.

I agree. In fact, he might be better off if he's forgotten the 1.6.4 stuff since then he can just start in re-learning 1.8. In many ways 1.8 is easier or at least improved. But I suspect he may have some 1.6.4 mods that he wants to convert, although that wasn't clear from his post. That could be a chore if he had a lot of custom blocks or items to convert.

The reason I took the approach is that I based my animation system off of vanilla. In the vanilla code, the server doesn't know anything about model rotations and arm swinging and so on. However the vanilla animations aren't complex, long or persistent so I guess the problem isn't very noticeable. So even vanilla offloads some stuff to client! Anyway, my point is I DO want the server to know the state and manage this (i.e. sending out spawn data and such) but most animation code I worte is intertwined with classes like models and renderers which are client-side only. I also can't have the server actually control the animation by sending model and rotation information every tick to every client, so best case is to try to have the code run in parallel on both server and client. So I think this is leading to me trying to recreate some of the animation loading and execution to also happen on server. It's just also going to be a bit of a pain. Unless there is some other mechanism for client-side saving readily available, I think I'll consider this problem solved and do it this way.

For the same reason I just responded to yoshiguest -- the server actually knows nothing about the animation, except the id. The animation (i.e. the sequence of pose models and the number of ticks between each pose) is loaded from custom JSON files in a client-side only class. The animations are basically a resource and could presumably have resource pack to replace them if someone wanted to go through the trouble. I do think that I will have to have the server estimate the animation progress so the question is how the server gets the information about the animations. I could have the client send all the animation info when first connecting but I'm thinking maybe at the start of each pose I can send the number of ticks for the next transition. That might not be too much spam on the network and would allow the server to estimate. There is still the issue of multiple clients each sending this info, but I guess I can just accept all packets as they come in. It doesn't need to be perfectly exact per client, just close so it doesn't look noticeable. EDIT: I suppose another way is to recode the animation loading so server can load it too. Just little tricky because the code is mixed up in models and renderers which are client side only. But I could probably make a server side loader for the animation information.

That was similar to what I was thinking of doing, basically make my own file/cache. I was just hoping to avoid the trouble. I only need to save it when world is saved or client disconnected and similar, so file write performance shouldn't be a problem.

The problem is that the animation is done in client-side only classes. So the server actually doesn't even load the classes that have the information about the loops. Yes the animations are predictable, but only on the client. If the server had the information then it could probably predict the animation point. It would still create a lot of network traffic because the information on the animations would still need to be sent to server, but I think it is probably the way I have to do it. I was just hoping for a cleaner way to save directly on the client. Configurations are actually saved on client but since the information I have to save is dynamic and has to be associated with specific world saves, it doesn't make much sense to use a Configuration file for this.

The problem is that the server doesn't know the animation state (it knows the id of the last animation but doesn't know anything about the animation itself -- these are contained in client-side only classes), and keeping it up to date would require every client to send a packet with information on every entity every tick. That would kinda spam the network, which is what I'm hoping to avoid.

Actually quite a bit has changed. But if you're decent in Java it is generally pretty easy to figure out how to update things. The question is whether you want to port some of your old mods from 1.6.4 or whether you just want to start new mod in 1.8. If you want to port your old mods, I suggest you look at tutorials for both converting 1.6.4 to 1.7.10 and also converting 1.7.10 to 1.8. I have a partial list of changes that I've run into here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-converting-your-mod.html Honestly a lot has changed. Blocks in particular use a very different system for managing state and models. Entity ID registration has changed. Lots of new events available, and some no longer available (i.e. sound events). There are also lots of little changes that can trip you up if you were counting on your previous understanding, like some methods have simply changed names or been deprecated/removed. But it is all Java so if you use your IDE (like Eclipse) you can explore the vanilla code and learn how things are done and adapt that to your liking.

Sorry but this needs a long explanation... Okay, I've run into an interesting problem. I've made an entity animation system for a mod and it works well -- the server decides to initiate an animation based on the entity and sends a packet with the animation id to all clients, then the clients step through an animation sequence consisting of poses and tweens (intermediate steps between poses). That works well, except if you try to save the game in the middle of an animation it doesn't remember it. Since the server knows the last animation it sent, i'm able to save the animation ID as NBT and then load it and send it as spawn data. However, that isn't good enough because that starts the animation over at the beginning. I really want to remember where it is in the animation. Only the client really knows where it is in the animation. I could have the client send packets back to server but that would really spam the network since all the clients would be doing it every tick. So I think what I need to do is to save the animation point on the client side. But what is recommended way to store entity data on the client side? I know how to do file access in Java so I know I could create my own save system, but it would be complicated as it would need to be mapped to the world and such. Is there already some way to store per-entity data on client side? The only other thing I could think of is whether there is a way that before the server saves the game that I could have it send a packet to query the clients, but that also seems a bit complicated. Any ideas? EDIT #1: Configurations don't seem a good way to go because this isn't fixed set of data, but variable depending on number of saves and entities per world. EDIT #2: I'm thinking maybe the best way is to estimate it by having the server guess at where it is in the animation. The problem is that the animations are defined client side only so I guess I'll have to have the server query the client to give the number of poses and tweens for each animation, then count ticks on the server.

I think there must be something unique about the save games though, because if you create two worlds with same name and same seed they both still show up in the load world list as separate worlds. I would look at how the load game menu works as it must iterate through some list with unique entries.