Currently some structure overlays/slime chunk overlays dont work in multiplayer (vanilla as well) because it doesnt know the world seed. I may be missing something, but I'm suggesting a way to input a seed.

I made a small fabric mod for myself, to detect said spawn events and log them to the console once per chunk.

As I don't have any previous experience in MC modding: Do you, @maruohon, know if it's possible and feasible to check, if miniHUD is running (I think I know that part) and then inject new chunks into the data structure, that's used for the slime chunk overlay?
Is there anything, you can tell me to get something in that direction done?

@mmodrow Fabric loader has methods to check if a mod is loaded (by mod ID), or to get the mod info for a given mod. And MiniHUD currently doesn't have any data structure for slime chunks, when it does an update for the overlay it just iterates the chunks around the player and checks each one using the same check that vanilla has in the slime spawning code, and then adds a box for that chunk if the check returns true. So you'd need to just render your chunk boxes from your data separately.

So if you wanted to add your data to the same slime chunk overlay, then you'd need to inject to several methods in the OverlayRendererSlimeChunks class to allow the overlay to render without having a known world seed, and to add your boxes. It might be better if you just added a completely custom renderer instead for your "sniffed slime chunks". Unfortunately it looks like the required methods are currently private, but if you want to go that route, I could easily just push out a new version where I change the RenderContainer.addRenderer() method to be public so that you can use it from your extension mod. That way you could have a separate toggle option and color configs etc. for your overlay.

That sounds lovely! I think, I could handle that.

Pretty much yes. Some mods are also using the Curse maven to pull the released versions of the mods from, for example MasaGadget here: https://github.com/plusls/MasaGadget/blob/ba08e00f619d2814a917f77cc38fb5f71872eb71/build.gradle#L44-L48

But in either case I would still need to push that small change to make the method public, so that you don't need to add a Mixin for it. And if you want other people to also use your mod, then that change would need to be in a proper released version of MiniHUD on CurseForge anyway, so maybe I won't bother pushing it to my maven(?)

so that you can use it from your extension mod
@maruohon

As far as I understood from looking into your integration of malilib into minihud, I guess the proper path to use code from miniHUD in my mod would be to define modImplementation "fi.dy.masa.minihud:minihud-fabric-${project.minecraft_version}:${project.minihud_version}" as a dependency in my build.gradle and add maven { url 'https://masa.dy.fi/maven' } as a repository there, so that the buildDependents gradle task from the fabric example template can pull the code, correct? Then that modified version of MiniHUD would need to be pushed to that location as well. As far as I can tell, your latest version on there is 1.16.4-0.19.0-dev.20210607.010240 from mid of 2021.

That feels right. Thank you for linking the example.

I wasn't aware of the option to use dependencies {modImplementation("curse.maven:minihud-244260:${project.minihud_version}")} and repositories {maven {url = "https://www.cursemaven.com"}}. In that case I will wait for your next release and implement that then.

Wouldn't it be feasable to flag any chunk, that at any time spawned slimes deep underground with the player in reach, as slime chunk?
I'd guess that data should be available even on multiplayer without op.

@mmodrow Yes, and someone did make that as a change for themselves. I don't remember if it was just a modified version of MiniHUD, or an add-on mod for it. I might also add it to the base mod as an option.

I found this thread while trying to use the slime chunk info, and I was wondering if anybody knew if when I type the minihud-seed (seed number) in the chat as suggested, if that message will be sent to the general chat. As the its allowed to have the world seed on the server I play on, but it is not allowed to distribute the seed and I do not fancy getting banned.

As long as you don't make a typo in the first word, it will not get sent to the server.

I think it was in the 1.18.2 version or so where I also added the option to include a slash in the beginning, that way it should never end up in the chat, but in case there is a typo (or MiniHUD is not installed) it would then just end up as an attempted command execution on the server, and would just show up in the server console and logs, but not in chat.

the command is minihud-seed <your_seed>

Clarification: There are two ways to let MiniHUD know the seed in multiplayer:

1. You can use the vanilla /seed command if you have OP on the server, and MiniHUD will grab the seed from the response message
2. You can type minihud-seed 12345 in chat (not a command, just a message) to set the seed if you know it, but don't have permission to run the /seedcommand.

The seed is only used for the Slime Chunk Overlay. The Structure Bounding Boxes overlay needs the actual bounding box data to be sent by a mod on the server. Currently it works with Carpet mod on 1.12, and specifically QuickCarpet on 1.14. I have also started working on my own separate info provider mod, which will be used for all the features in my client-side mods that need something from the server.

I know that one mod allowed you to provide the level file in a config folder. Could you consider that feature in addition? Modding the server may not be preferable.

its not wokring minihub-seed

still showing world seed not know

edit: fixed need to switch dim to make it work
add this to disc or info tag.

The level.dat file only provides the seed, which in MiniHUD is only used for the slime chunk overlay. The structure bounding boxes overlay needs the actual structure data. In the 1.12 version MiniHUD can actually read that data from local structure files, such as the Temple.dat file for witch huts.

But in the 1.13+ versions that support was removed, as vanilla doesn't create those separate files anymore, because the structure data is now stored within the chunk data. So in 1.13+ really the only reasonable way to get the structure data is with a server-side mod.

If you are worried about making server-side changes and would like to run a vanilla server, then at least by only running my to-be server-side info provider mod there won't by any changes to any vanilla behavior, it's simply for providing data to the client mods via custom packets.

Also if you have access to the files from the server, then you must have access to the seed as well anyway. I made the change a couple of days ago in the 1.12 code, that MiniHUD now saves the seed per-world. So inputting the seed once shouldn't be an issue I would think.

That's interesting, I didn't know! I'm not sure how consistent bounding boxes are per world (even on the same seed.) So another suggestion I would have is the ability to apply structure data from a local world (with the same seed) to the multiplayer one? I'm just giving ideas, I hope I don't come off as if I'm telling you what to do.

Your clarification helps with the server side mod. I knew it wouldn't make any behavior changes, but now that I know about the custom packets it seems smarter than I thought it would've been.

Well the issue with simulating stuff based on a seed would be that then the client would have to run all the world generation code as well, and that is usually the slowest part of Minecraft code. AFAIK the structures should be identical on the same seed, if you generate it in the same game version. And there comes the first problem with long-lived worlds: you can get an incorrect result for an older world that was generated in a previous Minecraft versions if you try to client-side generate it in the current version. Nor would it take into account any possibly custom-added or fixed/modified bounding boxes. So in general I would rather not show any boxes, than show possibly incorrect boxes and cause players to spend potentially hundreds of hours working on a farm in the wrong location...

The local identical world (or I better say a copy of the actual server world) kind of is an option in the sense that it would basically be the same as just using the structure data files in 1.12 and before. Now the data just is in the chunks and thus the region files themselves. But I have to say that this still probably won't happen, due to the additional performance cost this would add, and also the above mentioned "rather nothing than possibly wrong data" argument (if the local world isn't actually a copy of the server world, but accidentally some completely different world, or just a world generated using the same seed).

A workaround to help with performance might be to use a method similar to what amidst does and find structures within an area(which amidst determines the area by what part of the world is shown on screen) around the player and then only generate once(total per server) the chunk associated with the structure, From there, it should be possible to read the data provided by structure blocks to see where buildings actually are iirc and determine bounding boxes.
That should help by quite a bit with performance and with a setting to turn it on and off, it would be active and harming performance by a bit only for people who want it on(and can turn it off after using)

But any kind of client-side generation will always have the problem that the data is just a would-be estimate. I believe this would be most noticeable with pre-1.13 worlds, where most (or all?) old witch huts would be in different places than what the current generation code would suggest.

Like I said, I'd rather the mod just not show anything at all, rather than the mod showing something like "okay I guess there might be a bounding box here maybe possibly if this area was generated in the current game version, otherwise I have no idea if there is or isn't anything in here, maybe I should just start flashing random boxes in random places trolololoo".

Hmm.. Haven't thought about updating old worlds, good catch..

2. You can type minihud-seed 12345 in chat (not a command, just a message) to set the seed if you know it, but don't have permission to run the /seedcommand.

Will this actually post it to the chat, or does MiniHUD stop the message and take the data from it?

It will not post it in the chat, so no one else will see it.

^ Correct. As long as the first word of the message is exactly minihud-seed, then MiniHUD will eat that message. You can try it first with a meaningless seed like 123.

There will also be another way to input the seed in the rewritten version of the mod, which doesn't have he "risk" of using chat messages/input.