[1.12.2] How to make a custom projectile (that behaves similar to a fireball)

[Korlimann]

Hello everyone!

I created a custom Sword (for anyone who knows Terraria: the Terrablade) and I want it to shoot a projectile, just like in Terraria, which also damages mobs.

I've been working approx. 10 hours on this, and I can't get it to work. I've searched for tutorials, but I only found one single tutorial that was kind of useful, but it's from 2013, so kind of outdated.

I got to the point where the swords does the animation that comes up whenever you shoot a fireball, but there's nothing that actually shoots out. I'm sure I just made one or many stupid errors when copying and trying to understand code (this is my first time working with entities)

Since I think it's easier and I'll most likely forget some important code here is the link to my github.

I'd really appreciate any input, be it a link to a tutorial, or a small explanation of how entities actually work.
Thanks a lot and have a great day!

[V0idWa1k3r]

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.

 

22 minutes ago, Korlimann said:

small explanation of how entities actually work

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:

 

Quote

public class CommonProxy

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.

 

Quote

serverSide = Reference.COMMON_PROXY_CLASS

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.

 

Quote

public static final String MOD_ID = "es";

es is a terrible modid. You have 64 characters for a reason.

 

Quote

public static final String NAME = "O O F";

The name property is supposed to be a user-friendly name of your mod. 

 

Quote

public interface IHasModel

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.

 

Quote

package com.korlimann.epic_swords.proxy.client.renderer.entity;

This is kinda nitpicky but why is your entity renderer in your proxy package of all places?

 

Quote

public class ItemBase

ItemBase is an antipattern. There is already an ItemBase, it's called Item.

 

Quote

public static final Item TERRA_BLADE = new ItemTerraBlade("terra_blade", ToolMaterial.STONE);

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.

 

Quote

public class EntityTerraBladeBeam ... implements IHasModel

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.

 

 

[Korlimann]

Quote

 

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.

 

I know, that wasn't really a smart idea. I just thought that maybe the entity is not spawning because of this, so I wanted to make sure that it spawns anyway. I already deleted the else but haven't pushed it yet.

Quote

What explanation would you like exactly? I am happy to provide, but you need to ask your questions first. Entities are kinda complex.

Well, how entities work in general. As far as I understood, certain items, such as snowballs for example generate (is that the correct term?) a entitythrowable when, for example, right clicked. This entity will need to be rendered seperatly, and I saw someone use some kind of ModelBase instead of a Render if I remember correctly, so I guess if you want the entity to have it's own model, you'll need a class that extends ModelBase.

You also need to register the entity, for me this would be in the ObjectRegistry, but also in the ClientProxy.
Is this correct, or did I mess anything up?

Also I wondered how my entity will be moving when spawned. I saw some variables like velocity or motion, but I don't think I understood them yet.

Quote

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.

If had made a mod some time ago, also in 1.12.2 and the tutorial I followed to create this had me create a ClientProxy and CommonProxy class. I have no idea why it's called like that and there wasn't much of an explanation going on, so I figured it wouldn't be that important and is simply needed to register stuff. (And since I'm unable to find any good tutorial on 1.12.2 and the documentation is far from existent, I didn't bother searching for it, just like for many other things)

1 hour ago, V0idWa1k3r said:

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.

 ^^See above. I'd be happy if you could quickly explain the concept of the Client, Server and CommonProxy classes to me.

 

1 hour ago, V0idWa1k3r said:

es is a terrible modid. You have 64 characters for a reason.

Well, thanks. I'm going to change this as soon as possible.

 

1 hour ago, V0idWa1k3r said:

The name property is supposed to be a user-friendly name of your mod. 

Just like the modid, I just typed something in real quick. I don't even really have a name for the mod yet, I just thought the general concept of the mod was nice and wanted to get to work as soon as possible. After all, there should be enough time to think of one during the process of making the mod. But I'm also going to change this, as soon as I want to publish it/have a name for it.

 

1 hour ago, V0idWa1k3r said:

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.

I also created this, basically copied it from a tutorial. So, if I get you correctly, I don't need the Interface "IHasModel" at all, right? But, where is the ModelRegistryEvent, and how do I register models without the class?

 

1 hour ago, V0idWa1k3r said:

This is kinda nitpicky but why is your entity renderer in your proxy package of all places?

It's like that because I checked the original minecraft files and found the renderer.entity package inside the client package. And because my client package is inside the proxy package, I simply put it there, because I thought it would have more structure like that, but I guess it doesn't

 

1 hour ago, V0idWa1k3r said:

ItemBase is an antipattern. There is already an ItemBase, it's called Item.

I'm starting to question the tutorials I watched. A lot, actually. Why is there not a single good tutorial for 1.12.2?

 

1 hour ago, V0idWa1k3r said:

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.

So, I would be fine with this line of code if I simply deleted the static, or do I need anything else to make it work then?

1 hour ago, V0idWa1k3r said:

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? 

After 10 hours of trying to get this to work, I became kinda desperate and tried all sort of random (and dumb) stuff. Since there was no model showing up for the entity, I just put this there and tried, but it didn't work either. And yes it did compile, since I was "smart" enough to create another registerItemRenderer() method only for EntityTerraBladeBeam
And yes, I am using eclipse.

 

So far, thanks a bunch for all the stuff you made me realize is wrong and thanks for the quick answer. I'll probably just throw everything out and start all over again.

EDIT: I just thought, would it maybe be smarter to extend EntityArrow? Can I change my EntityTerraBladeBeam to fly until it hits something or is not in sight anymore?

Edited November 17, 2018 by Korlimann
EDIT

[Cyberdragon]

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.

[V0idWa1k3r]

6 minutes ago, Korlimann said:

As far as I understood, certain items, such as snowballs for example generate (is that the correct term?) a entitythrowable when, for example, right clicked

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.

 

6 minutes ago, Korlimann said:

This entity will need to be rendered seperatly

Similar to items and models all entities need a renderer even if your entity is completely invisible. 

 

11 minutes ago, Korlimann said:

I saw someone use some kind of ModelBase instead of a Render if I remember correctly, so I guess if you want the entity to have it's own model, you'll need a class that extends ModelBase.

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.

 

15 minutes ago, Korlimann said:

You also need to register the entity, for me this would be in the ObjectRegistry, but also in the ClientProxy.
Is this correct, or did I mess anything up?

This is pretty much correct. Register the entity's entry in the appropriate registry event and register the renderer in your client proxy.

 

16 minutes ago, Korlimann said:

Also I wondered how my entity will be moving when spawned. I saw some variables like velocity or motion, but I don't think I understood them yet.

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. 

 

18 minutes ago, Korlimann said:

there wasn't much of an explanation going on, so I figured it wouldn't be that important and is simply needed to register stuff.

Pretty much all minecraft modding tutorials in a nutshell. This is exactly how you get cargo cult programming people.

 

19 minutes ago, Korlimann said:

the documentation is far from existent

https://mcforge.readthedocs.io/en/latest/

 

20 minutes ago, Korlimann said:

I'd be happy if you could quickly explain the concept of the Client, Server and CommonProxy classes to me.

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. 

 

34 minutes ago, Korlimann said:

I don't need the Interface "IHasModel" at all, right?

That is correct.

 

34 minutes ago, Korlimann said:

where is the ModelRegistryEvent

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)

 

36 minutes ago, Korlimann said:

how do I register models without the class?

By doing the same thing you are already doing, just in the ModelRegistryEvent instead of in your item's code. Like this for example.

 

37 minutes ago, Korlimann said:

Why is there not a single good tutorial for 1.12.2?

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.

 

39 minutes ago, Korlimann said:

I simply deleted the static, or do I need anything else to make it work then?

Simply deleting static will just make the fields instantinate when an instance of a class is created which doesn't really make a difference. 

1 hour ago, V0idWa1k3r said:

Instantinate your stuff in the appropriate registry event.

 

[V0idWa1k3r]

6 minutes ago, Cyberdragon said:

There's nothing wrong with IHasModel or CommonProxy

There is EVERYTHING wrong with both of them both design-wise and implementation wise. A string is an array of characters but I don't see you storing your strings as byte arrays. By your logic - it works so there is no harm in it, right? Even if it works it makes no sense logically - you are not going to use ByteBuffers for your numbers and you are thus not going to use a CommonProxy, the string is not annotated as Iterable<Byte> and your items should not be annotated with IHasModel. It also confuses people all around the world who look at your code - there is no Common side, so why is there a common proxy then? And some of them start using common proxy to execute code they consider common which is plain wrong and has lead to numerous issues, some of which I have helped people with on these very forums, so it IS HARMFUL! Don't just shrug it off because it works. If something works it doesn't mean it's right. 

 

11 minutes ago, Cyberdragon said:

I have a small mod running on a public server with these and it works perfectly

If you know what you are doing then by themselves these classes don't do harm. It's a whole other story if you don't though. And a lot of people don't.

 

12 minutes ago, Cyberdragon said:

IHasModel is just so you don't have to register them indevidually

You are still registering them individually though. Just this time your code is in your Item class instead of your event class. It is also in your proxy. You are actually legitemately writing 300% MORE code by using IHasModel. It also makes no sense design-wise since all items need models. A string isn't IHasCharacters for a reason. Again, this HAS caused issues some of which I had to help people with so it IS ACTIVELY HARMFUL.

And in any case you can iterate your items just fine since they already share a common ancestor - Item! So the argument of "but I can iterate them now" is also invalid.

 

15 minutes ago, Cyberdragon said:

CommonProxy is just a proxy that shares code between client and server

It can't though. Proxies by definition contain code that will crash the game if ran on the wrong side. You can't share code between server and the client like this, it happens anywhere else but your proxy. Again, there were numerous issues caused by people trying to do exactly that. 

 

16 minutes ago, Cyberdragon said:

Yeah, it's weird, but it works so it's more of code preference.

Again, if something works doesn't mean it's right and you can't say "code preference" either. You can use strings to store any information but you are not doing that and it's not just "code preference" even though it works. 

 

18 minutes ago, Cyberdragon said:

You don't necessarily need ObjectHolders and all that for basic items

Yes you do, actually. There are multiple reasons to use object holders, the main of which is the fact that stuff in registries CAN BE OVERRIDDEN! If you don't use object holders you now have a useless thing that is not used in the game at all.

 

19 minutes ago, Cyberdragon said:

it's not perfect but static objects work for basic items and blocks.

No, they really don't. The main reason is that they offer no control over when the stuff initializes, so one wrong mention of a class that contains them and now you have nulls everywhere because they reference things that have not been instantinated yet. Actually around 20-30% of issues I have seen on this forum related to blocks/items have been caused by people using static initializers! It is actively harmfull! Additionally if that wasn't enough on it's own it breaks the whole "registries can override stuff" concept and it prevents reloadable registries. 

 

21 minutes ago, Cyberdragon said:

However, it will probably break down at some point for complex stuff

Worse, similar to bytecode editing it can and WILL break unpredictably when you least expect it regardless of "complexity". It already had for multiple people who then went to this forum. 

 

So please, don't encourage cargo-cult programming and spread misinformation. There is a reason we tell everyone not to use these things beyound simple design issues. There are guidelines to using forge for a reason. Even if you yourself know how everything works you are actively confusing people who don't and are creating more issues in the process. Imagine if opengl had no guidelines and people started doing stuff like IHasVertex for their buffers, or CommonShader that holds the "common shared" shader code, or god forbid used static initializers to instantinate VBOs and other stuff *shrugs*. 

[Korlimann]

@V0idWa1k3r Thanks a ton for all the suggestions, the links and the help in general. I just wanted to let you know that I'm going to be away from home soon so I don't have time to respond. I'll answer tomorrow. Thanks!

[Korlimann]

@V0idWa1k3r

Thanks again for the explanation and the help yesterday. I tried to follow as many point as you mentioned and basically started over, threw the IHasModel out, created ObjectHolders, renamed the mod_id and name and so on. I also deleted all the entity related classes and started over. I recreated them but more like the general class and constructor without copying too much code, trying to write only those parts I'm sure I understand.

I would be very thankful if you could have a quick look and tell me if there's anything I'm still doing wrong and what I'll need now to get the Entity to work.

[V0idWa1k3r]

43 minutes ago, Korlimann said:

if there's anything I'm still doing wrong

Well, you still have a CommonProxy, for one.

 

https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/util/handlers/RenderRegistry.java#L20

21 hours ago, V0idWa1k3r said:

the renderer must be registered in preinit, not in a ModelRegistry event.

 

https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/proxy/client/renderer/entity/RenderEntityTerraBladeProjectile.java#L26

You are not actually doing any rendering, just screwing up the matrix stack, but I assume this is still unfinished, similar to how the sword currently does nothing. 

 

https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/proxy/client/ClientRegistry.java#L19

Don't have your proxy as an event subscriber. You already have a dedicated class for that.

 

https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/entity/projectile/EntityTerraBladeProjectile.java#L12

Why are you calling onUpdate in the constructor? That is a very bad idea that is likely to crash the game.

[Korlimann]

46 minutes ago, V0idWa1k3r said:

Well, you still have a CommonProxy, for one.

 

https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/util/handlers/RenderRegistry.java#L20

 

https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/proxy/client/renderer/entity/RenderEntityTerraBladeProjectile.java#L26

You are not actually doing any rendering, just screwing up the matrix stack, but I assume this is still unfinished, similar to how the sword currently does nothing. 

 

https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/proxy/client/ClientRegistry.java#L19

Don't have your proxy as an event subscriber. You already have a dedicated class for that.

 

https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/entity/projectile/EntityTerraBladeProjectile.java#L12

Why are you calling onUpdate in the constructor? That is a very bad idea that is likely to crash the game.

Okay, so I think I fixed everything you mentioned here. I looked at your code and kinda confused ClientRegistry and ClientProxy, but I think it should be fine now

Also, yes, the Render class is unfinished. I'm currently trying to figure out everything I'll need to get the entity to work.
So, looking at it now, my ItemTerraBlade will be the class that "spawns" the Entity. I think the method I want to use for this is "onEntitySwing", which should be called everytime when the Player that holds the item swings it, if I'm not mistaken.
I already noticed that when using this class in addition to my EntityTerraBladeProjectile, since it's extended from the Fireball, the sword doesn't actually "swing" anymore, but instead does the animation that comes up when shooting a fireball. So my first question would be, should I use another method? Or is there another way to maintain the swinging animation.
Moving on from ItemTerraBlade, everytime it gets swung, a new EntityTerraBladeProjectile should spawn. I'm a little unsure, but the EntityTerraBladeProjectile class should declare how fast and in which direction my Entity in this case moves and also what happens on impact or when it moves out of sight.
Since I want it to behave like a fireball, it should shoot straight in the direction of where the player is looking at, which I figured shouldn't be too hard, since this is basically what a fireball does anyways. But since I made a custom model for the entity, it should have specific rotation. Basically, it should always be that the blade of the entity (which currently looks like this:)
is horizontal to the players face
Despite that, this should basically be it for the Entity class. Of course it will still need to damage entitys it hits and I also wanted to make some sort of animation when it hits something, but that's something for later I suppose.
Next would be the RenderEntityTerraBladeProjectile class. I think this is the class where the Entity actually gets rendered, so I suppose the code that makes it so that the entity has the right rotation when spawning should be placed inside this class.Other than that there should be a custom resource location declared so that the Entity will have textures, but it also leaves me wondering if I'll need a class that extends from ModelBase in order for my custom model to work.
Last but not least, the Entity will need to be registered, once the entity itself in the EntityRegistry, but also the Renderer in the ClientProxy (so I'm guessing I won't need the RenderRegistry class I made?)
I believe this should be everything I need for an entity to work, right?
 

Edited November 18, 2018 by Korlimann
Typo

[Cadiboo]

I think for the item you should extend ItemSword and override the leftClick method (I’ve forgotten what it’s called). What is your entity meant to be? A thrown sword or something else?

[Korlimann]

2 hours ago, Cadiboo said:

I think for the item you should extend ItemSword and override the leftClick method (I’ve forgotten what it’s called). What is your entity meant to be? A thrown sword or something else?

That's what my Item is currently doing. It extends ItemSword.The method I think you mean is called onLeftClickEntity and it's for attacking an Entity directly, so it will only be called when the player actually hits another entity with the sword, which would kind of miss the point of the sword, because it should not only be a melee weapon but also some sort of magic ranged weapon, so if I wanted to hit a mob further away, with this method it wouldn't work.
EDIT: I just noticed I didn't answer your question. It's meant to be the Terra Blade from Terraria

This is how it looks like in Terraria.
I want to create a sword that shoots the green sword as seen in the gif upon attacking or rather left clicking.
As of now, I have the sword, but now I need an Entity that behaves like the green sword.

Edited November 18, 2018 by Korlimann
Missed a question

[Cadiboo]

Make an entity that dies after a few ticks, and doesn’t stop/die on collision. You should be able to just extend entity throwable and spawn some particles on its path

[Korlimann]

10 hours ago, Cadiboo said:

Make an entity that dies after a few ticks, and doesn’t stop/die on collision. You should be able to just extend entity throwable and spawn some particles on its path

Well, for what I know, the green swords actually flies 2500 blocks (in Terraria) and then dies, or it dies after colliding with a wall OR hitting 3 enemies, so it's not that easy. Currently, it's working that the entity flies at least somewhat far before the particle track disappears, but I have two rather big problems.
First one is, that the entity doesn't render, and I don't know how to render it.
Second problem is, that it's somewhat random in which direction it shoots. I want it to fly directly at the point where the players crosshair is, like a fireball, without changing direction. But as it is of now, it feels more like shooting a shotgun, sometimes the entity will even come out behind me or on my side, and I don't know which piece of code makes it do that.

Edited November 19, 2018 by Korlimann
additional information

[Cadiboo]

Pretty much nothing about Minecraft is optimised, so you should probably make it only fly for 5-10 seconds (it should probably go less than 100 blocks in that time) before it dies (you should use the ticksAlive field, and have your logic in onUpdate). I suggested you extend entity throwable because it has a very accurate onImpact method. In this method you should check

- if the entity hit a block (if so kill it)

- if the entity hit an entity (increment a counter, if that counter is at max, kill your entity)

 

As for the weird spawning, how are you getting the x, y, z and the pitch & yaw to spawn your entity with? Your GitHub links all return

Could you post that code please?

 

With rendering, you need a class that extends Render<YourEntity>. Register your rendering class in the ModelRegistryEvent with

RenderingRegistry.registerEntityRenderingHandler(YourEntity.class, RenderYourEntity::new);

or

RenderingRegistry.registerEntityRenderingHandler(YourEntity.class, (renderManagerIn) -> new RenderYourEntity(renderManagerIn));

if you don’t feel comfortable using the :: operator

[Korlimann]

3 hours ago, Cadiboo said:

Your GitHub links all return

https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/items/ItemTerraBlade.java

I don't know why that is, everything works fine for me. Does that link work for you?

[Cadiboo]

That link works, as I said, you should probably be extending entity throwable instead of entity fireball. Take a look at https://github.com/Cadiboo/WIPTechAlpha/blob/fb5883e9d76ef0361ec1ebbcb9c508611dd2ef6b/src/main/java/cadiboo/wiptech/entity/projectile/EntityNapalm.java#L18-L89

Ignore the igniteBlocks method (it sets everything on fire) and lines 83-85 (they deal with approximating the nearest air block to the collision point)

[Korlimann]

On 11/20/2018 at 12:48 AM, Cadiboo said:

That link works, as I said, you should probably be extending entity throwable instead of entity fireball. Take a look at https://github.com/Cadiboo/WIPTechAlpha/blob/fb5883e9d76ef0361ec1ebbcb9c508611dd2ef6b/src/main/java/cadiboo/wiptech/entity/projectile/EntityNapalm.java#L18-L89

Ignore the igniteBlocks method (it sets everything on fire) and lines 83-85 (they deal with approximating the nearest air block to the collision point)

Hey there! Sorry for not answering so long.

Thanks for the suggestion, I'm gonna try to implement it like that, but I still think that the main issue is, that my Renderclass doesn't work, because I don't know how to operate the GLStateManager

[Cadiboo]

You can take a look at this implementation which renders an item, or this implementation which renders a textured cuboid

[Korlimann]

3 minutes ago, Cadiboo said:

You can take a look at this implementation which renders an item, or this implementation which renders a textured cuboid

Thanks a lot! I'll check it out as soon as possible. Right now, I changed the Entity to be extending EntityThrowable, which gave me some funny results.
https://imgur.com/a/USerdh4
As you can see in the gif, the block now gets...  ...somewhat rendered? And seems to behave like a fireball (which might be because I took the code from the RenderEntityFireball class, but I'm not sure anymore)
I always need to doubleclick for it to shoot, altough shooting only once does the job too, but only sometimes, which is quite confusing. Also, after shooting, while moving it behaves somewhat like a "magic missile" and follows the cursor, but stops after maybe 3-4 seconds of flying. I think this is probably due to EntityThrowable not having acceleration, so I had to cut a lot of code pieces out. Also, the entitys have no collisions and just disappear in the underground BUT they can push each other, when you shoot them at each other after they stopped and float in the sky.

I don't even know where to begin first to fix all of this.

[Cadiboo]

I suggested entity throwable because it has a good collision method that you can override, I didn’t know that you were making a magic missile (it’s been a long time since I played terraria) type entity. For the collision you need to do appropriate stuff in the onImpact method. How are you implementing the magic missile functionality?

[Korlimann]

8 minutes ago, Cadiboo said:

I suggested entity throwable because it has a good collision method that you can override, I didn’t know that you were making a magic missile (it’s been a long time since I played terraria) type entity. For the collision you need to do appropriate stuff in the onImpact method. How are you implementing the magic missile functionality?

No no no, I don't want to make a magic missile. I want to do something like this. I don't know how or why it works like that, but it does and I have no idea on how to fix it.

 

On 11/18/2018 at 2:30 PM, Korlimann said:

This is how it looks like in Terraria.

So, basically I want this sword to spawn one of those green swords in the gif as entity that shoots out until it has either traveled 100 blocks OR hit 3 enemies. It should move approx. like a fireball, but with more accuracy. So, you shoot it and it shoots exactly in the direction you're looking at. It doesn't drop down, go up or anyone else, just travels into the direction you looked at when firing it with the same speed and everything, until it should be declared dead.

Edited November 22, 2018 by Korlimann

[Cadiboo]

So, you’ve somehow extended a generic class with no specific functionality and suddenly have a magic missile that follows your cursor? I want programing magic like that to happen to me!

[Cadiboo]

The way I would do it would be to extend entity throwable, move the entity & check how long it’s been alive in the onUpdate method and handle collisions (blocks and entities) in the onImpact method

[Korlimann]

2 minutes ago, Cadiboo said:

So, you’ve somehow extended a generic class with no specific functionality and suddenly have a magic missile that follows your cursor? I want programing magic like that to happen to me!

I think it's awesome too, although it's not really what I wanted