jabelar

I admit that that crash report is a little weird, but the second crash report definitely is indicating problems related to the effect. I think the problem is likely related to the fact that you're calling a method from the Thaumcraft.proxy which probably isn't set up as an actual proxy in your mod. What I think you want to do is: in YOUR proxy you need to have a method for creating the particles, and in the common proxy version of that method you just do nothing, but in the client proxy method you should call the Thaumcraft.proxy method.

I think I said to put it in your CommonProxy not your ClientProxy. The point is that when you registered the event handler you referred to "this" so that means you need to have the @SubscribeEvent method in the same class that you register the event handler, which I believe in your case is the CommonProxy. Anyway, the key point is that wherever you register the event handler you need to reference the proper class that contains the event handling method.

Yes, this can be a bit tricky. Usually the configuration file is loaded/synced in the common proxy so technically it will be loaded on both sides. But the actual file would of course not be the same file on two different computers when you're running server/client or LAN. So the "safe" thing to do would be to sync as needed. In the case where the config info is only used by server, then there is no problem -- just the config on the server will be used and there is only one so there is no conflict. Similarly, in some cases you might have config options that are purely client side (like maybe change rendering, or add info in HUD) and you could just allow each client to load their own config and it is okay if they are different. But in other cases you might have some config that is used on both sides. I think you're right that the config is not synced automatically so the safe way to do that is to load only on server side and sync the values to client using packets.

So now the log shows it printing out "Latest version is ..."? That is better than before, right? Does it give the right version as listed on your URL that you pointed to? For it printing a message in the game, the problem would be that your PlayerTick event isn't firing any more. That is because the registration of on the event bus refers to "this" but since it is in the CommonProxy it doesn't see the methods with the @SubscribeEvent. So you need to move your @SubscribeEvent methods from your Main class to your CommonProxy.

I have a tutorial on this: http://jabelarminecraft.blogspot.com/p/minecraft-forge-publishing-to-github.html This tutorial uses Sourcetree, which I recommend (like the others posting above). It is a graphical interface to git so you don't have to do command line stuff. Some people like to say "real programmers use command line" but honestly why not use a good graphical interface when it is available -- you can see graphical representation of your branching and everything.

Okay, you're not using the proxies properly. Here's what you need to do. Create methods for the pre-init, init and post-init in the common proxy. So your common proxy should look like this: Then in your Main class, you should just call the proxy method for each of these events, like this: Then your client proxy should @Override any of these methods where you need to do something additional on client side by calling super method then do anything special for client side, like this: Note also that you should only have the @EventHandler annotation on the methods in the Main class. Then those methods simply call the methods in the proxy. Make sense? It is important to get a good understanding of this in order to do effective modding.

Okay, I was out at the gym but will take a look at it now.

Does your Reference.CLIENT_PROXY point to the right class? Maybe it is accidentally pointing to your common proxy or something. The way the client proxy usually works: 1) You annotate using @SidedProxy to point to path to the class for your client and common proxy. You have that, although you should check that it's referencing the right classes. 2) You instantiate a proxy field using the common proxy. You already did that properly. 3) Your main class handles each FMLInit, FMLPreInit, etc. and calls the method in your proxy (it will decide to call client proxy or common proxy depending on mode the program is running in) that handles those same events. 4) Your client proxy extends common proxy (you did that already) and implements @Override methods for any place the client needs to do something different/additional to client proxy. I think you're close, but for some reason your client proxy isn't going so the thread isn't starting...

The run() method has a console statement: System.out.println("Latest mod version = "+latestVersion); That should print out no matter whether your version is old or up to date. It may not print out if you get one of the exceptions in that method, but in that case you should also see some console exception output. So if you're really not seeing the "Latest mod version =" console output I think that implies that the run() method isn't being called. I suggest you add additional console statements to trace the execution. I'd add a console statement in the version checking class constructor to prove it is getting constructed, I'd add one in the client proxy method to prove it is getting called.

Hey, I'm the author of the tutorial. I admit it is prorbaly a bit hard to follow because it assumes you're comfortable with Java multi-threading, file I/O, and modding proxy stuff. I'll see if there is a way to link to more info on each topic for those who need it. The first question is: what do you mean it isn't working? Do you mean it never prints anything to the console at all? Or do you mean it doesn't find correct version from your URL? Or do you mean it isn't displaying a chat message? I'm interested actually in larsgerrit's comment. Can you post the rest of how you set up your client proxy? For proxy to work you need to have the @Mod annotation in your main class reference it, and you also need to handle the post-init event in your main class and that should point to the related proxy method. So it would help if you could post that.

Models are entirely dynamic. I mean that it is really just a hook for the the render calls. So you can do anything you want there. In many of my models I have alternate models that I render based on fields in the entity. For example, I have an eagle that has wings when flying but not when perched, or I have an elephant that has a multi-part trunk when adult but a one-piece trunk when a child. So if you want to swap with player model, just copy the biped model stuff and put that also into your custom entity model. Then in the render function just render the one that you need at the time.

Do you really need to do a different texture, or are you just coloring the hue of the existing texture. Above you mentioned that you want to change hue. In that case, I think you can look at how grass tinting works. In earlier versions you could also do multi-pass rendering of blocks, but I'm not sure how to do that in 1.8. TheGreyGhost is an expert at block rendering and can probably provide ideas.

As already mentioned, you just need to change the @Mod parameters in your whichever mod you want to load last. Have you tried that?

There is a program called Cubik that exports Minecraft JSON and has a fairly good graphical modeling editor. See this link: http://bdcraft.net/cubik

@Kwasti Perhaps you don't understand but a mod will only run the part relevant to the side (client, server, or both) based on the way it is launched and played. There is not really any reason to make separate mods for each situations. If you're worried about memory use and don't want to load client stuff on server, and vice versa, that is what the @SideOnly annotation is for. This is already implemented in fact for most of the vanilla client-side stuff -- so if you run any mod on a server it won't even load the classes related to rendering or input detection. Why exactly do you think there is an advantage to creating separate mods? Anyway, if you insist on making them separate then they should be simply created as separate mods.

That's the tricky part. Honestly, you shouldn't try creating a mod unless you already have an idea on how you will make it work... Anyway, the first question is: when do you want it to enter the water? The general idea would be that at the point it should go into water you'd have an AI task that would find the closest water and head to it. Then when you detect that the entity is actually in the water (I think there is a method like isInWater() or similar you can check) then you'd switch the navigator to swimming navigator. When doing custom stuff it is best to look at how other vanilla mobs do similar things. For example I think a burning zombie will purposefully go into water. So check how the zombie AI does that, but change the condition (in your case you don't have to be burning).

By the way, many of those methods with difficult names like func_175447_b() actually now have human-readable names -- in this case getNavigator(). To update the SRG mappings, in your build.gradle file add a mappings reference. For example, in my current 1.8 mods my build.gradle includes the following: minecraft { version = "1.8-11.14.1.1410" runDir = "../run/assets" mappings = "snapshot_20150518" } Then you need to run gradlew setupDecompWorkspace and gradlew eclipse again. Then your code will be easier to read. Anyway, so you're making a good start. But I think the getNavigator() method should return different navigator depending on whether your entity is on land or water. Also, I'm not sure exactly how to get the land navigator to get into the water, so you may have to detect that you're close to the water then change navigator.

If you're not replacing the blocks with your own custom invisible block, how are you making those blocks invisible? Are you intercepting the rendering somehow?

Well the navigator is one of the key things, and in your code you're assuming it is a ground navigator and you never set it to a swimming navigator. You'd probably want to change the navigator based on AI, but you haven't set up any AI at all.

Well, in MC when you are creating a new game you can choose to re-create a saved world, which I assume loads the seed from the save file and uses it, so you might want to trace that code to see where in the world save data the seed is stored. Similarly, you can create new worlds using a seed value and there are many seeds posted on the internet to allow people to copy interesting worlds, so you can trace the code that takes that seed as it might also give you an idea.

What have you tried so far? Post your code and ideas and we can help refine them.

Right. It is the same block, but with different metadata. Here is an explanation of how the metadata values (or block state in 1.8 ) work. http://minecraft.gamepedia.com/Lava#Data_values Note also what it says about how the blocks are mostly set as stationary even if they are in a position to flow -- the flowing is only set temporarily during block updates.

I agree that the fact that much of the attack code runs on the entity hit (the attackEntityFrom() method) does sometimes seem a bit obtuse. However, that is the way the code works and the events hook in as early as they can. I am not sure about your comment that the attacking entity might disappear while you're processing the attack -- the attackEntityFrom() which invokes the event is called from the attacking entity. I don't think there is a chance of the attacker going null due to timing of when the code executes. In other words, all this is really code executing from the attacker (even though the method called is in the target entity's class). To put it another way -- the events exactly match the way the vanilla methods work, so your concern would be a problem in vanilla too if it could happen.

Why do you say that? The forge hook onLivingAttack() is called as very first line in the attackEntityFrom() method. The attackeEntityFrom() returns a boolean that is used as a flag in attackEntityAsMob() and will prevent all the attack stuff like knockback.

Anything that is damaging an entity is considered an "attack", so yeah that is probably just suffocation due to poor spawn locations. In your LivingAttackEvent you should be checking for damage source type then process as needed from there.