Jump to content

PhilipChonacky

Members
  • Posts

    76
  • Joined

  • Last visited

Everything posted by PhilipChonacky

  1. 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
  2. I would suggest trying the following: 1) use "if (world.remote)" to call FireParticleEffect 2) Preface the FireParticleEffect method with @SideOnly(Side.Client)
  3. Can you post a repository of your code? It's still not clear which class FireParticleEffect belongs to
  4. 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.
  5. That was it! Thanks! [so simple] If only that had been mentioned before, I would have had to try and reinvent the wheel.
  6. 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.
  7. 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).
  8. 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.
  9. Same result. The client entity disappears while the server entity still exists
  10. 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' . Updated Code ...so close
  11. 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
  12. 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 Repo Updated ...I think I need to make sure the handler code runs only on the Client
  13. Which version of MC are you using? I'm using 1.14.3 [Forge 27.0.25] and that overload isn't available
  14. 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
  15. 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
  16. 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
  17. 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.
  18. https://mcforge.readthedocs.io/en/1.13.x/networking/entities/#entities
  19. 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
  20. 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
  21. 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?
  22. 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
  23. 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
  24. 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
  25. 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)
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.