Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Drosophila

Members
  • Posts

    8
  • Joined

  • Last visited

Drosophila's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. For anyone else that finds this thread, I submitted a PR request and the discussion has moved there: https://github.com/MinecraftForge/MinecraftForge/pull/8334
  2. No because there is no way of knowing what the original name was. In the case of forge, mappings are already present. Here's some more info on the process: https://forge.gemwire.uk/wiki/Toolchain/Retro/2.1
  3. Those are arbitrary prefixes created by the process of obfuscation. The naming convention refers to functions and fields. They could just have easily been foo_ and bar_.
  4. [EDIT] Sorry I misread your post. This isn't possible for other mods unless you have specific mappings for them. Many are open source, and you can find the source code on curseforge. Many mods that don't list their source on curseforge still have public github repos you can search for. If you want to build off of a mod that doesn't provide source it's a good idea to check the license first to make sure the author permits what you're trying to do. If they do or you reach out and get permission you'll have to figure out what methods mean contextually, or ask the mod dev for source.
  5. I've been working on adding hearing target selection logic to zombies. I see that ServerWorld#playSound fires a forge PlaySoundAtEntityEvent, but this event doesn't necessarily contain a location. The PlayerEntity passed into ServerWorld#playSound as the first parameter can be (and, in fact, usually is) null because some sounds are not created by a player. The only data encapsulated by PlaySoundAtEntityEvent are the (nullable) PlayerEntity that is the sound source, the MC SoundEvent, the SoundCategory, and two floats corresponding to volume and pitch. This means that when a sound event is not player-generated, it is not possible to determine the sound location. Is there a workaround for this? I'm currently using a mixin to inject code into ServerWorld#playSound but modifying bytecode just to intercept sound events feels kinda hacky.
  6. Will the TickDelayedTask not execute until the junk has loaded? Or do I still need extra logic to queue up entities and periodically check to see if their positions are finished loading?
  7. Ah, because goalSelector and targetSelector are both public. The clean way to do this would be to update them in the spawn event handler? It shouldn't be. I did that because I was confused by the concurrent modification exception and new to forge. I wanted to confirm that the handlers were not somehow firing in parallel. Ah yep I should probably just keep reusing the same block position object and updating its coordinates, then it could just be a List of entity objects that have a much longer lifetime. Oops. Thanks. That was pretty silly. So actually I should be submitting the task to the work queue that corresponds to the logical side calling the event handler like this? ThreadTaskExecutor<Runnable> executor = LogicalSidedProvider.WORKQUEUE.get(event.getWorld().isClientSide ? LogicalSide.CLIENT : LogicalSide.SERVER); executor.tell(new TickDelayedTask(0, () -> event.getWorld().addFreshEntity(newEntity))); Does that mean that an EntityJoinWorldEvent will never fire for an entity in a chunk that hasn't loaded yet?
  8. Mappings: official mojang mappings, version 1.16.5 Forge version: 1.16.5-36.2.0 I've been trying to replace vanilla zombies with a custom class to play around with their AI. I've experienced a couple strange issues so far: First, simply trying to replace zombies that spawn with a new zombie produces a strange classpath error. I have the following utility functions: I wrote them to avoid attempting to spawn in entities in chunks that aren't finished loading. Then I use the following logic to override vanilla spawn behavior: Here is the tail of the log file when the client crashes: This seemed strange to me, stranger still is that swapping the zombie out for a pig (changing EntityZombie to EntityPig) produces an entirely different issue- a ConcurrentModificationException. Code change: Exception: I tried synchronizing the addZombieIfReady method (even knowing the event handlers will be run within the same thread) and that didn't change the result. What are the causes of the two exceptions and why does swapping the zombie out for a pig change behavior so much?
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.