Jump to content

felinoid

Members
  • Posts

    36
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

felinoid's Achievements

Tree Puncher

Tree Puncher (2/8)

5

Reputation

  1. Where is the src folder for the mod you are working on?
  2. What did the crash report say, and what does the code that crashes look like?
  3. Yeaahh... looks like the only way to have pretty code is to leave it be. I just wish users wouldn't assume that because it says "ERROR" it's responsible for whatever problem they're having. I'll leave it for now, but if it shows up in too many more bug reports I might try passing the builder an empty/nonsense string. Thank you Diesieben, good to have it confirmed that at least I don't need to register a data fixer.
  4. I have a mod that registers entities. Like every other 1.16 mod I have seen that registers entities, it prints the error "No data fixer registered for [entity]" every time it starts up. As far as I can tell, the lack of a data fixer is not causing any actual problems except for the error message. Loading from an older Minecraft version works fine. I do change the entity's save format occasionally, but that does not align neatly with Minecraft's version numbers so I write my own code logic to handle it. Mainly I just want it to not print an error. The message is coming from net.minecraft.util.Util: @Nullable public static Type<?> attemptDataFix(TypeReference type, String choiceName) { return !SharedConstants.useDatafixers ? null : attemptDataFixInternal(type, choiceName); } @Nullable private static Type<?> attemptDataFixInternal(TypeReference typeIn, String choiceName) { Type<?> type = null; try { type = DataFixesManager.getDataFixer().getSchema(DataFixUtils.makeKey(SharedConstants.getVersion().getWorldVersion())).getChoiceType(typeIn, choiceName); } catch (IllegalArgumentException illegalargumentexception) { LOGGER.error("No data fixer registered for {}", (Object)choiceName); if (SharedConstants.developmentMode) { throw illegalargumentexception; } } return type; } which is being called from net.minecraft.entity.EntityType.Builder.build: public EntityType<T> build(String id) { if (this.serializable) { Util.attemptDataFix(TypeReferences.ENTITY_TYPE, id); } return new EntityType<>(this.factory, this.classification, this.serializable, this.summonable, this.immuneToFire, this.field_225436_f, this.field_233603_c_, this.size, this.field_233604_h_, this.field_233605_i_, velocityUpdateSupplier, trackingRangeSupplier, updateIntervalSupplier, customClientFactory); } The most straightforward approach would probably be to register my own data fixer. I'm not sure how I would go about that or if it's even possible, as I can't find documentation for com.mojang.datafixers anywhere. I see a mention of it here, which doesn't look like it got resolved. Another possibility would be to pass the wrong argument in to the build method. For instance, if I passed it "minecraft:donkey" instead of my own donkey's ID, presumably that would get any data fixers registered for the donkey. This seems super sketchy. I know I don't need the HorseSaddle or HorseSplit fixes, what I don't know is whether it might also do something unexpected that could create a bug. This doesn't seem worth it. Oddly enough, SharedConstants.useDataFixers isn't final, which means in my entity registration method I could set it to false and then back to its previous value again. But if a lot of people do that, someday someone will forget to set it back to the previous value. That could potentially cause exactly the sort of corruption issues data fixers are supposed to prevent, all while being near impossible for a user to debug. The last option I see is to pass the build method a nonsense string such as "ignore this error". This is ugly, but at least it indicates to users that they should look elsewhere to find why they crashed. I don't like any of these, nor do I like leaving it be. Anyone have opinions on which is the least bad?
  5. Ah sorry, for some reason I was thinking X/Y. For X/Z your workaround is a decent idea, and I don't think the eye height will help you.
  6. First off, can you just set the size from the EntityType? If all entities of this type are that size, that is the best way to do it. The entity type builder has a method .size(width, height) to set the hitbox size. As for the suffocation hitbox not changing, I think that is a forge bug. See https://github.com/MinecraftForge/MinecraftForge/issues/7399. If you can't set the size for the EntityType, you could use reflection to change eyeHeight yourself (it's a private value).
  7. Suppose you have a mod for 1.15.x, which you're about to update to 1.16.x (or any other two versions, really), and after you update you intend to keep adding new features to 1.16.x while back porting them to 1.15.x. And presumably you're using git branches for the different versions, or a similar version control system. Then just after you update the mod to 1.16 but before you add anything new, merge the 1.16 branch back into the 1.15 branch and overwrite all the files with the previous 1.15 versions. That way in the future when you merge new features from 1.16, git will have at least some respect for the version differences instead of treating it as a fast forward. You'll still need to modify any new code, but at least you shouldn't have to undo all the 1.16 compatibility changes from existing code too. Maybe this should have been obvious, but if I missed it for so long others might have as well.
  8. I had the same issue, see here: for how to fix it. Edit: this thread is also helpful:
  9. If it's too long you can use this site: https://pastebin.com/
  10. https://github.com/tiffanyjager/horse-colors/blob/master/src/main/java/horse_colors/HorseReplacer.java The problem still happens when replaceHorses is reduced to @SubscribeEvent public static void replaceHorses(EntityJoinWorldEvent event) { // We don't want to replace subclasses of horses if (event.getEntity().getClass() == HorseEntity.class && !event.getWorld().isRemote) { HorseEntity horse = (HorseEntity)event.getEntity(); HorseGeneticEntity newHorse = ModEntities.HORSE_GENETIC.spawn(event.getWorld(), null, null, null, new BlockPos(horse), SpawnReason.CONVERSION, false, false); } }
  11. I'm trying to update my mod to 1.14, and I'm having trouble with the part where I replace Minecraft horses with my custom horses. I subscribe to OnEntityJoinWorld events, but when I try to spawn my custom horse in response, the game never loads the chunk. If it happens in the loading screen the game freezes at 100%, or if it happens when a chunk is generated as part of exploration the chunk never loads. My event subscribed code seems to be getting stuck on World.getChunk called from within EntityType.spawn, presumably because it's getting called when the chunk isn't fully loaded yet. Is there a way around this?
  12. My mod crashes with forge 1.14.4-28.0.105 (because of the persistant/persistent typo), so I'm trying to require forge 1.14.4-28.1.0 or above. My build.gradle file lists it in the dependencies: dependencies { minecraft 'net.minecraftforge:forge:1.14.4-28.1.0' } but when I install the earlier version, it still allows my mod to run. Do I need to specify the dependency differently? (Installing an earlier version of forge over a later one shouldn't make a difference, right?)
  13. I want to say thank you to everyone here who helps with modder support. Just having you around is really encouraging, so I always know there's someone to turn to if I get myself stuck. Three times now I've solved a problem I thought I couldn't fix on my own while writing a post to ask for help, and without y'all I'd probably just have given up. So, thank you for helping, even if you didn't know you were
×
×
  • Create New...

Important Information

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