Leaderboard

Entities are a more general concept than just throwables. An item on the ground is an entity. A zombie is an entity. A player is an entity. Particles used to be an entity too. Entity is basically any instance-based dynamic object in the world that needs to exist on both the client and the server and can interact with said world and it's contents in various ways. Blocks don't fit this description because they are not "instance-based dynamic object", they are singletons that are stored in fixed positions. Items don't fit this description either because they are not "instance-based dynamic object" either, they are also singletons and can only interact with other things by containers like ItemStack(inventory) or EntityItem(world). A particle doesn't fit this description because it only exists on the client, etc. Similar to items and models all entities need a renderer even if your entity is completely invisible. This is not necessairly true. Unlike items which are baked on startup entity models are drawn in real time, no baking required - the buffers are filled each frame. Which is actually the main reason why the game's framerate dies if there are a lot of them. This means that you can push any data into the pipeline. A lightning is an antity that doesn't have a ModelBase associated with it but is rendered perfectly fine. EntityItem fetchs a model to render from respective items, which have nothing to do with ModelBase either. EntityThrowables usually render a simple quad. A ModelBase is just minecraft's way of having "complex" entity models which are composed of cubes that can move around, like a pig's model for example. But nobody requires you to have a ModelBase, you are free to do whatever you want. This is pretty much correct. Register the entity's entry in the appropriate registry event and register the renderer in your client proxy. Well, entities move using the motion varables. motion is simply a vec3 that is the entity's change of position each tick. So if the motion is [0,1,0] the entity moves one block up each tick. Not everything works with motion though, some functions may straight up use the move method without changing the motion. Motion is usually used for "physics", like sliding on ice or falling down, etc. Pretty much all minecraft modding tutorials in a nutshell. This is exactly how you get cargo cult programming people. https://mcforge.readthedocs.io/en/latest/ You can read the explanation in the official docs - https://mcforge.readthedocs.io/en/latest/concepts/sides/ Basically the game has a concept called sides. There is always a server and a client, akin to any online game. The server's job is to do all of the game's logic - move entities, change blocks, do physics, etc. After it is done it sends the changes it made to all connected clients. The client's job is to have a local copy of all the data, receive the change from the server, update the data and draw it in the world. The client also processes input - like you pressing a key on your keyboard and then it sends the press to the server so it can decide what to do with it. There is always a server, even when playing single player you are connected to a server that is running alongside the client. So thus there are two sides - the client and the server. It's not however quite that simple. The sides can have a "prefix" to them. They can either be logical or physical. What's the difference? Well, the "logical" side is simply a thread that executes the code that that specific side needs to execute. So in your singleplayer game you have 2(actually 3, not counting workers and utility but that's not the point) threads - the server and the client. These are logical sides of your game. They are called logical because they separate different logic - the logical server does the game's logic, while the logical client updates the data of the client to later render it(again, a bit more complex in reality but that's not the point), The physical side on the other hand is the physical representation of your game, the binary itself. On your PC you have a binary of the game that contains the executable code. Since your binary creates a window and displays stuff it has client-like code in it, thus it is a physical client. However on the official website you can download a so called "dedicated server" that is basically a server. It does no rendering, it is just a console window(so-called "headless" application), in fact, it doesn't even have the code in it that does the rendering, nor does it have any rendering related libraries like LWJGL - that's why the file size differs even though they both have the same game. This is the physical server. It is physical because it is based on the actual binary - your game has no code that does dedicated-server specific stuff in it(like your game simply doesn't have the capability to process the server.properties file, it simply doesn't include that code), and the dedicated server binary has no rendering code in it. That's why in your IDE you can see methods marked with @SideOnly. This means that the code only exists on the specified physical side. So you need to be carefull when invoking those methods - if your mod runs on a dedicated server and you attemt to invoke a method that only exists on the physical client - that's a problem. A crash rather. So this is where forge's proxy system comes into place. The proxy is a way to distinguish between physical sides - you specify 2 classes, one that is client-based and is free to access client-only methods, the other is the reverse - server-side only. We are talking about the physical sides here! Typically you would have a contract both classes need to follow - a collection of methods for them to have. An interface works perfectly for that. Forge will then pick and instantinate the respective class based on the physical side and inject it into the field marked with @SidedProxy. A common proxy thus makes no sense because there is no "common" physical side. That is correct. Well here is one. It is in the wrong place though since it is client-only and needs to be located in a client only class(not in your client proxy, just in a class that will only be loaded on a client like this) By doing the same thing you are already doing, just in the ModelRegistryEvent instead of in your item's code. Like this for example. I don't think there ever was a good tutorial for earlier versions either. The CommonProxy dates back to the days the proxy system was first created for example and people have used it ever since even though this makes no sense. Simply deleting static will just make the fields instantinate when an instance of a class is created which doesn't really make a difference.

I know where he got those from. There's nothing wrong with IHasModel or CommonProxy, I have a small mod running on a public server with these and it works perfectly. IHasModel is just so you don't have to register them indevidually, and CommonProxy is just a proxy that shares code between client and server, but it does not run on both. Yeah, it's weird, but it works so it's more of code preference. You don't necessarily need ObjectHolders and all that for basic items, it's not perfect but static objects work for basic items and blocks. However, it will probably break down at some point for complex stuff. Never use ItemBase though, that's just ugly.

Well first of all you should probably read the comments of the code and understand them. // IMPORTANT! Only spawn new entities on the server. If the world is not remote, // that means you are on the server: if (!entityLiving.world.isRemote) { entityLiving.world.spawnEntity(new EntityTerraBladeBeam(entityLiving.world)); } else entityLiving.world.spawnEntity(new EntityTerraBladeBeam(entityLiving.world)); I mean you have them right there, above your code and still go against what they tell you to do. As for the issue - you are not setting the position of the entity you are spawning so it spawns at [0,0,0]. You can see an example of an item creating a projectile at ItemBow for example. What explanation would you like exactly? I am happy to provide, but you need to ask your questions first. Entities are kinda complex. Now, as for the other unrelated issues of your code that probably arose from the fact that you've used a crappy tutorial: CommonProxy makes no sense. Proxies exist to separate sided-only code that only exists on a specific physical side. If your code is common it goes anywhere else but your proxy. This makes even less sense. A server proxy either provides methods that would crash the client if executed on it or noop implementations for client-only stuff. Your common proxy can't be your server proxy because if it would it would crash the client. es is a terrible modid. You have 64 characters for a reason. The name property is supposed to be a user-friendly name of your mod. IHasModel is stupid. All items need models, no exceptions, and nothing about model registration requires access to private/protected data of the item. Register your models in the ModelRegistryEvent directly. This is kinda nitpicky but why is your entity renderer in your proxy package of all places? ItemBase is an antipattern. There is already an ItemBase, it's called Item. Don't ever use static initializers. Instantinate your stuff in the appropriate registry event. If you need a reference to the thing later use ObjectHolders. Same applies to your entity entry btw. This is probably the most, um, interesting way to use IHasModel. Especially considering that the renderer must be registered in preinit, not in a ModelRegistry event. Also the implementation @Override public void registerModels() { Main.proxy.registerItemRenderer(this, 0, "inventory"); } Entity is not an item. It makes negative sense to call a "registerItemRenderer" for an Entity. Actually now when I look at your methods this doesn't even compile. Are you using an IDE? I also don't think your entity is going to work too well since you've basically copied EntityFireball's code, but are also extending it and invoking the base implementations here and there. Chances are it is doing a bunch of redundant work and also it's movement is all sorts of screwed up since it is performed twice per tick.