PhilipChonacky
-
Posts
76 -
Joined
-
Last visited
Posts posted by PhilipChonacky
-
-
I would suggest trying the following:
1) use "if (world.remote)" to call FireParticleEffect
2) Preface the FireParticleEffect method with @SideOnly(Side.Client)
-
Can you post a repository of your code? It's still not clear which class FireParticleEffect belongs to
-
Ads long as you don't use ArrowItem for you munitions Item, you won't get them mixed up.
Creating a new AbstractRenderer won't be much work, but creating an Entity that essentially does the same thing as (or close to) AbstractArrow is going to be a really big pain.
-
2 hours ago, xieao said:
This solved the problem for me
First register your entity with custom client factory like this
.setCustomClientFactory((spawnEntity, world) -> new ExempleEntity(world))
And then use forge hooks to get Entity Spawning Packet
@Override public IPacket<?> createSpawnPacket() { return NetworkHooks.getEntitySpawningPacket(this); }
that's it ?
That was it! Thanks! [so simple]
If only that had been mentioned before, I would have had to try and reinvent the wheel.
-
Even if static fields are working for you, the experts will still tell you not to because they can fail in unpredictable and strange ways that can be hard to troubleshoot. It’s not really that hard to implement.
Extending ArrowEntity won't have an impact on launching your munitions, because ArrowItem is a separate Class, just use a generic Item, not one based on ArrowItem.
There are a lot of behaviors in AbstractArrowEntity that would be difficult to implement in a custom entity. If you can find a way to extend ArrowEntity, you might get past the custom spawn packet problem i've run into.
-
Use ObjectHolders where you need to refer to an entity in multiple registries. (i.e. registering Entity Types and Renderers)
If you are modding in 1.13+, you will also need to override createSpawnPacket() if you are extending AbstractArrowEntity (something I am trying to figure out on my own).
-
I put in logging code to track the entity on both Server and Client, which clearly shows the Entity gets spawned on both Server & Client with matching IDs, but the rendering stops almost immediately. The Client-side entity is
being removed after one or two ticks. Not sure why this is happening.
-
Same result. The client entity disappears while the server entity still exists
-
9 minutes ago, FilUnderscore said:
I believe that this line:
world.addEntity(msg.shooterId,entity);
should be:
world.addEntity(entity.getEntityID(),entity);
I don't know whether this has anything to do with the threading?
That doesn't make sense. Entity ID is an index number given to keep track of the entity in the world.
Normally when you create a new entity, this number is incremented (so all entries are unique)
I think this is the filed that MC uses to synchronize objects between server and client side.
Using ClientWorld#addEntity(id, entity) adds the entity to the [client] world using the provided ID instead of the ID from the entity you just created
public void addEntity(int p_217411_1_, Entity p_217411_2_) { this.addEntityImpl(p_217411_1_, p_217411_2_); } private void addEntityImpl(int p_217424_1_, Entity p_217424_2_) { if (net.minecraftforge.common.MinecraftForge.EVENT_BUS.post(new net.minecraftforge.event.entity.EntityJoinWorldEvent(p_217424_2_, this))) return; this.removeEntityFromWorld(p_217424_1_); this.entitiesById.put(p_217424_1_, p_217424_2_); this.getChunkProvider().getChunk(MathHelper.floor(p_217424_2_.posX / 16.0D), MathHelper.floor(p_217424_2_.posZ / 16.0D), ChunkStatus.FULL, true).addEntity(p_217424_2_); p_217424_2_.onAddedToWorld(); }
using addEntity(entity.getEntityID(),entity) copies the ID from the entity you just created, which is the next sequential ID, that's why I pull the ID from the spawn packet (which has the original ID).
I resolved the cross-side [thread] issue by creating a separate client-only Class [ClientWork] and putting the spawn code there as a static method. It works now, but the client rendered entity disappears almost immediately. If I increment the ID, it spawns an unsynchronized client entity that just drops to the ground (can't even kill it with '/kill @e' .
...so close
-
You should always spawn your entities on the server. Use: !world.isRemote()
Also, model registration is client only, so it should go in a proxy and not in you Item Class
-
Using that [ClientWorld], and I spawned the entity - now I have a thread violation (reaching across server/client).
I think the server thread is crashing or getting caught in a loop
...I think I need to make sure the handler code runs only on the Client
-
19 hours ago, FilUnderscore said:
you need to call
world.addEntity(entID, entityInstance)
instead of world.addEntity(entityInstance)
Which version of MC are you using? I'm using 1.14.3 [Forge 27.0.25] and that overload isn't available
-
Update: I got the SimpleChannel system to work (mostly)
entityLaser#createSpawnPacket sends packet with PacketDistributor.TRACKING_CHUNK which is passed and handled by LaserSpawnPacket.Handler#handle
I confirmed the new EntityLaser instance is accurately created, but for whatever reason, it doesn't get added to chunk (if I'm understanding that field entity correctly)
...need to double-check my math, I may be spawning in the wrong location
-
7 hours ago, FilUnderscore said:
Hey, so I've managed to spawn my custom entity by letting my custom spawn packet implement
IPacket<ClientPlayNetHandler>
and processing the packet in the packet class as well by using some of the code from
ClientPlayNetHandler - handleSpawnObject(SSpawnObjectPacket packetIn)
I also return a new packet instance in my entity class in the createSpawnPacket() method.
How did you handle the networking? ClientPlayNetHandler usually receives the spawn packets. Is there an event that can be subscribed to?
Do you have a GitRepo I can look at?
I've seen other posts advising to stay away from IPacket, so I didn't and sent the packet using SimpleChannel
(returning super.createSpawnPacket to keep MC from crashing)
...not working yet, but at least it doesn't crash
I'll post my code when I get home
-
I would suggest you start with the documentation so you can understand the basics of modding (as well as the difference between Server and Client side).
Stay away from the YouTube videos - there are a lot of people out there who give bad advise and teach bad coding practices.
Here are some good starter tutorials: https://cadiboo.github.io/tutorials/ .
I would also recommend starting with MC 1.12, the later versions are still being flushed out.
Good luck!
/Philip
- 1
-
For the past couple days, I have been attempting to make this work creating what I believe to be the correct class files.
The original reason that object entities (extended from AbstractArrowEntity and probably Snowball as well) won't spawn on the client is that the Class ClientPlayNetHandler which handles SSPawnObjectSpawnPackets is testing for specific Vanilla EntityTypes and doesn't recognize my custom entity.
I have created the following classes to implement a SimpleChannel spawn packet
1. LaserSpawnPacket.java which is the spawn packet class - includes encode, decode, and handle methods per the requirements. I put the code for spawning the entity [Client Side], but I'm not clear if it should go here, or I should create an additional class (Client only) to perform the spawn.
2. ChickenModPacketHandler.java which holds the static SimpleChannel instance, and registers the spawn packet methods
EntityLaser.java is the [Object] Entity I am trying to spawn, it overrides the createSpawnPacket method from AbstractArrowEntity.
EntityLaser is spawned from an onRightClick method from ItemLaserCannon.java.
Where I'm currently stuck:
1. The Java compiler is not accepting my methods as meeting the requirements (int, Class<MSG>, BiConsumer<MSG,PacketBuffer>, Function<PacketBuffer,MSG>, BiConsumer<MSG,Supplier<NetworkEvent.Context>>) and I'm not sure why - to my knowledge (which with regards to Java/Minecraft is somewhat limited) I have done it correctly.[fixed, I was loading the wrong Supplier library]
2. As mentioned above, I'm not sure if I should spawn the client-side entity from my own method, or hand it off somehow to a Forge method[I determined that the SpawnPacket class is responsible for this, that's why we use NetworkEvent.Context#get.enqueueWork to execute on the Main (Client) thread]
3. As I'm not really sure how Minecraft tracks the plurality of entities between Server and Client, I don't know if I'm successful, whether tracking from Server to Client would continue (or not). Assigning ID?
Any help would be appreciated, as I have looked around, I haven't found any mention of others doing this in 1.14, and the only advise I have gotten so far is "override Entity#createSpawnPacket and return a custom packet which will spawn your entity on the client.". Maybe I'm overlooking something obvious. in 1.12 it was as simple as extending AbstractArrow or Snowball and it would work with relatively little coding, since 1.13, all this has changed.
-
-
The more I'm thinking about this, the more I'm thinking that my custom packet 'handle' method needs a spawn [LaserEntity] in it. The only remaining question would be what I data would I need (UUID?) in order to keep it associated with the copy on the server so that it properly receives tracking updates.
Comments?
I promise when this is all over I will write a brief tutorial for others (assuming I'm not the only one going down this road)
/P
-
Do I need to spawn the custom entity using my custom packet handler, or is there already a process within Forge that will handle that
(and if so, which process is it and what data do I need to send).
Apologies if this sounds like a stupid question, but much of the networking process is a bit over my head, and I haven't as of yet found any other code examples for spawning custom entities in 1.13/1.14]. I tend to learn much better by example
Thanks again.
/P
-
My guess to what's happening here is the handler is canceling the event, but only after Vanilla has done its thing.
Maybe you need to target which side Client/Server you subscribe the event?
-
I can understand needing to override createSpawnPacket and using it to send a custom packet, but what to send? I don't know what class is handling it so I can't look.
/P
-
You're using static fields in you registry entries
Instantiate your blocks and items at the same place you register them
It should look more like this:
public static void onBlocksRegistry(final RegistryEvent.Register<Block> blockRegistryEvent) { blockRegistryEvent.getRegistry().registerAll( new Block(Block.Properties.create(Material.IRON)).setRegistryName(MODID,"test_block")); }
For blocks, you will either need an Object Holder, or iterate the Block Registry to register the corresponding ItemBlocks
-
OK, I read through the SimpleChannel documentation [several times], and have some idea about how it operates. I also read some of the code example here, with the understanding that since IMessage no longer exists, it is not required to implement it in the custom packet classes. (just create the required methods and register them through the registerMessage method).
The question I still have is whether I need to create a handler (or not) to spawn the Entity on the client. The docs say that it is handled in Forge, but don’t specify whether some method needs to be invoked (or event caught). A further question if Forge handles the client-side spawn is which data do I need to send.
TIA
/P
-
2 hours ago, superminerJG said:
Here is my procedure:
-
Extracted Forge MDK into ...\Mods\Fluxed Machinery
-
gradlew eclipse
-
gradlew genEclipseRuns
-
Imported to Eclipse as Gradle Project from ...\Mods
I don't know if it make a difference, but you should run 'gradlew eclipse' after 'gradlew genEclipseRuns'
Also, the root of the Eclipse project would be the same folder where you extracted the MDK (...\Mods\Fluxed Machinery)
- 1
-
Reading minecraft source code
in Modder Support
Posted
For many of the non-Minecraft libraries, there is no source code.
Minecraft source code in all in the Minecraft Forge library(ies) which usually are at the top of the list of referenced libraries in Eclipse.
MCP maps the deobfuscation of the Minecraft source code and is applied through Gradle directives. There are stable and daily exports depending on which version of MC you are working with. To update MCP mappings, edit the 'build.gradle' file and re-run gradlew.
Hope this helps.
/P