Jump to content

Choonster

Moderators
  • Posts

    5117
  • Joined

  • Last visited

  • Days Won

    75

Everything posted by Choonster

  1. Entity#getEntityId is completely unrelated to global entity IDs. It's a unique entity ID specifically designed to be sent over the network.
  2. You can either generate the random number on the server and send it in the packet or generate it on the client. You need to send the entity's ID (Entity#getEntityId) in the packet and then get the client-side entity from the client World using World#getEntityByID.
  3. The two WorldServer#spawnParticle overloads without an EntityPlayerMP argument loop through all of the WorldServer's player entities and call WorldServer#sendPacketWithinDistance to send the packet to them if they're in range of the specified coordinates. I believe any packet sent through SimpleNetworkWrapper by a mod that's not present on the client will simply be ignored. If a mod present on both sides sends a packet that hasn't been registered on the client, an exception will be thrown.
  4. Yes, call World#spawnParticles on the client World in the packet's handler to spawn the particles.
  5. If you look at the method that handles the particle packet (NetHandlerPlayClient#handleParticles), you'll see that it generates random x, y and z speeds based on the speed you specified in the WorldServer method. If you need more control than the WorldServer methods give you, you can create your own packet to spawn the particles.
  6. You have Recurrent Complex installed on the server but not on the client. It needs to be installed on both sides.
  7. To spawn particles from the logical server, use one of the spawnParticle overloads defined in WorldServer rather than the ones defined in World. These send a packet to players within range of the specified coordinates (or just the specified player if using the overload with an EntityPlayerMP argument) that tells their clients to spawn the specified number and type of particles.
  8. Minecraft has a built-in cooldown system (CooldownTracker) that it uses for Ender Pearls, Chorus Fruit and Shields (after a player has theirs disabled).
  9. The documentation explains the commands here.
  10. What is a "World2Screen method?"
  11. You're using Java 9, which Forge doesn't support. Uninstall it and install Java 8 instead.
  12. You can specify item transformations using Forge's blockstates format, but this requires them to be specified as TRSRTransformations (or one of Forge's built-in transformations: "forge:default-block", "forge:default-item" and "forge:default-tool") rather than the Vanilla ItemTransformVec3f format. I explain how to do this here.
  13. That's what Entity#getShadowSize returned, but that method no longer exists; if you compare the 1.7.10 and 1.12.2 implementations of Render#renderShadow, you'll see that they're fairly similar but the entity's shadow size is no longer used. The Render#shadowSize field is 0.5 for RenderDragon in both 1.7.10 and 1.12.2.
  14. RegistryEvent.MissingMappings<T> is fired when there are missing mappings for a registry and can be used to remap them to new names.
  15. They won't be empty if there are mods that have used the RenderingRegistry methods, but they'll never have the Vanilla instances and the Render instances you create from the IRenderFactory instances won't be the same ones that are used to render the entities during gameplay. It's best to use the ones stored in RenderManager. Mods that use the non-deprecated IRenderFactory registration method of RenderingRegistry will have their Render instances added to the RenderManager instance when it's created between preInit and init. Mods that use the deprecated Render registration method of RenderingRegistry will have their Render instances added to the RenderManager instance after postInit. If you really want to support the mods that are still using the deprecated method two years after it was replaced (it was deprecated with this commit and meant to be removed in 1.9), you could lazy-load the shadow sizes for each class when they're required rather than loading them all at startup.
  16. ContainerWorkbench (the Crafting Table's Container) does this in its onContainerClosed method. If you're using IItemHandler for your inventories (which you should be), you'll need to replicate the logic in Container#clearContainer rather than calling it directly.
  17. You need to create an IItemColor implementation that gets the colour from BlockColors and then register that with ItemColors. You can see an example of this here.
  18. It's probably worth noting that you can use LootEntryTable to generate loot from another loot table.
  19. RenderingRegistry is just temporary storage for mod entity renderers/factories during the startup process, RenderManager#entityRenderMap stores the actual instances used to render entities during gameplay.
  20. The code you posted doesn't compile, because entry1 is declared inside the if statement but referenced outside of it (because it doesn't have braces). Please post a working Git repository of your mod so I can debug this. See my mod and its .gitignore file for an example of the repository structure to use and which files to include. This .gitingore file tells Git to ignore everything (the first line) except the files that are actually required (the lines starting with an exclamation mark).
  21. The first paragraph ("None of these three method actually do anything") was describing what your code currently does, the second paragraph ("The field initialisers should only create the ResourceLocations") was describing what your code should do. What you need to do is as follows: In the field initialisers: Create the ResourceLocation for each loot table In a method called from your @Mod class in preInit: Call LootTableList.register for each ResourceLocation You seem to have two classes (LootTableRegistry and GlistreLootTables) that store and register your loot tables, you should only have one.
  22. You didn't post the full error. Those are the loot pools. The loot table I want to see is glistremod:glistre_chest_gold. None of these three methods actually do anything. It's only the initialiser of the Custom_Chest_Loot field that registers the loot table. The field initialisers should only create the ResourceLocations, the actual registration of the loot table names should be done in preInit. There's no need to have separate init and register methods.
  23. Post your latest loot table file (the one you're adding this entry to), loot table event handler and the full error.
  24. As I said before, you never add p1 to the event's LootTable; so LootTable#getPool will return null when called with "p1". You're already adding entry1 to p1 in the LootPool constructor, so there's no need to add it again on the next line. You need to call LootTable#addPool to add p1 to the event's LootTable. That said, are you sure you want to have the same entry for the ancient book in both the "main" pool and the "p1" pool?
  25. How did you build your mod? You need to build it using the build Gradle task, which reobfuscates your mod to SRG names (the names used by Forge outside of the development environment) after building it.
×
×
  • Create New...

Important Information

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