Geyser
Geyser copied to clipboard
GeyserMC
Add support for server resource packs
What feature do you want? If there is a custom server resource pack on the Java Server, let the Bedrock Edition download it and apply it.
Alternatives? Make the same resource pack for Bedrock Edition yourself.
This probably won’t happen soon because it’s not that important, but it should eventually
This is quite complicated probably since Bedrock doesn't use same resource pack format as Java does. You'd need external tool to convert it ...
Maybe a resourcepack could be specified in Geyser that it would then send to players when the server tries to send one. This way server owners could specify one for the bedrock players, without Geyser having to have some crazy complicated resourcepack traslation module.
The bedrock client only accepts resource packs during the login sequence. It would be necessary to implement a server transfer using the transfer packet or somehow cache the resource pack before the player even joins geyser.
Its a tricky one.
@Heath123 @lukeeey this, https://github.com/ozelot379/ConvertJavaTextureToBedrock, may help with implementing the said feature.
I've tested it with a few resource packs and seems to work quite well. It is also maintained and up-to-date.
Yea we have started writing our own library for it using that as a base, thanks for the heads up though.
I am also in favor of separate resource packs instead of requiring a Java Edition one and converting it. Or at least a config option to choose which mode to use.
I would be happy with initially requiring the conversion of the resource pack then later on down the line separate ones because at least you can get something early our and people can start testing with it.
Currently, the resources branch will load in a valid bedrock resource pack and send it to the clients, we plan on expanding this to auto-convert java packs and offer the client the opportunity to use it.
https://github.com/GeyserMC/Geyser/pull/1076#issuecomment-671391655 a missing feature which is needed to add support for https://github.com/GeyserMC/Geyser/issues/1114
#1076 (comment) a missing feature which is needed to add support for #1114
Hello! Is there any news on the CustomModelData feature? Thanks! :D
@LoneDev6 Hello! I assume CustomModelData requires resource packs, yes? I am not well-versed with resource packs at all but this may require Java resource pack translation first. Alternatively, once the API branch is merged in, it could be possible to create a stepping stone extension.
Yes it's handled by resourcepacks. Basically client renders a different texture/model based on CustomModelData NBT attribute of the item. Idk if there is a similar feature in Bedrock clients and resourcepacks. We could fake the Bedrock equivalent attribute in order to show the right texture/model to the client.
Maybe someone has experience on this.
OK, so: 1: CustomModelData is a Java native thing (I did not know this!) 2: It's literally a tag called CustomModelData. 3: The CustomModelData items are defined through the resource pack.
The final point is a very, very good thing. It means that the work we have to do for Java -> Bedrock resource packs can be more or less used to get custom items - likely an internal cache of Java item + NBT to Bedrock ID. Now, I'm not sure about 3D items in Bedrock, ~~but this GIF of Lucky Islands on CubeCraft Bedrock is promising: https://cdn.discordapp.com/attachments/206325275733131264/752897050689011731/lucky_uwu.gif~~ EDIT: that might be a Java screenshot, oops.
Yea it's just an int NBT attribute which the client recognizes and allows the game to replace the item with a custom model/extruded texture. If I recall there is an equivalent thing in Bedrock but it's better as you can specify a literally new item in the game with its own namespace and id + custom model, but I'm not experienced with Bedrock so I don't know.
Anyway, you can join my test server and see Java CustomModelData in action: test.plugin.ga (1.16.3)
https://bedrock.dev/ is an excellent site for learning about Bedrock behavior/resource packs (though I believe behavior packs tell the server how to control item/block/etc behavior, so we don't need to worry about that). So the only hurdle is that Java resource packs can be prompted at any time, more or less, but Bedrock needs the resource packs at the start of the game.
@LoneDev6 I did get CustomModelData-to-Bedrock work started, so it is possible! Just needs some work: https://cdn.discordapp.com/attachments/605540865103888395/766000214728507432/Screenshot_from_2020-10-14_14-10-49.png
3D items appear to be possible, but difficult. https://wiki.bedrock.dev/tutorials/custom-item-models.html#3d-item-models Doing that programmatically, as well as any possible conversion between Java model format to Bedrock model format, is not something I'm desiring to do, so I'm just focusing on getting the 2D texture to work. Is there a guaranteed way to determine the 2D texture that should be used for items? Is it always layer0?
The conversion code is here and you can see the code implemented into Geyser on my personal resourcepackconversion branch (this part should mostly be done. For anyone who likes to try branches out early: this is not ready; there is no cleanup/caching of resource packs).
(There is still more work to be done on CustomModelData if it doesn't work when joining your server! That is a tomorrow project)
That's amazing, very good job! Maybe you can check BlockBench code which loads .json Minecraft Java models and saves them into Minecraft Bedrock compatible models and port it to your converter :D https://blockbench.net/
@DoctorMacc Sorry for the ping! Is there any news over this conversion feature? Thanks! :D
DoctorMacc Sorry for the ping! Is there any news over this conversion feature? Thanks! :D
@LoneDev6 Last I checked we are waiting on 1.16.100 to release for bedrock to continue this due to some features it adds
Curious if you guys would be willing to add durability onto this as well. I assume the strategy being taken is just passing it off as a custom item as far as the bedrock client is concerned? This would be quite helpful for servers that still use durability based models due to backwards compatibility with older versions (Pre 1.14). Durability is simply passed in NBT as the "Damage" tag on the same level as "CustomModelData". I will also note one minor complication here is that as of the 100 betas an icon can no longer be defined for a custom item in a resource pack, as this now all seems to take place at the behavior pack level, so I think the proxy would also have to pass that as well.
@DoctorMacc
3D items appear to be possible, but difficult. https://wiki.bedrock.dev/tutorials/custom-item-models.html#3d-item-models Doing that programmatically, as well as any possible conversion between Java model format to Bedrock model format, is not something I'm desiring to do, so I'm just focusing on getting the 2D texture to work. Is there a guaranteed way to determine the 2D texture that should be used for items? Is it always
layer0?
Not sure you ever found an answer to this but just wanted to clarify in the case that you did not. Since you are only tackling items then yes this is a reasonable assumption as there will, at minimum, always be a layer0 for any item using a parent path that ultimately leads back to builtin/generated. Since you are only tackling texture-based changes here this makes sense as anything that is just texture based for the model (referring to when there is no actual model, so the game just creates it by extrusion of the texture) is going to ultimately lead to builtin/generated.
That said, the only caveat is cases in which multiple layers exist. This really only occurs for leather clothing, filled maps, tipped arrows, potions, firework stars, and spawn eggs. In this case, you would have one layer which determines the shape of the item, and one layer that determines the overlay... trouble is that these are, for some inexplicable reason, not consistent. For leather clothing, filled maps, firework stars, and spawn eggs, layer1 is the overlay and layer0 is the base. For potions and tipped arrows, however, layer0 is the overlay and layer 1 is the base... So for true all purpose conversion of any item, you'd have to deal with these special cases somehow, but honestly it may not even be worth it as they're fairly niche...
If it weren't for leather armor I probably would not bother, but thanks for the heads-up and information!
To answer your previous question, durability is planned to be translated, as well as if the item is a food source.
Thanks for the answer on durability. I was also wondering if there will be any option to still manually upload the pack that is sent to the bedrock client in the case that one wanted to just deal with the custom item model situation manually (referring mainly to implementing pseudo 3D items through attaching to the player geo).
Though it will require more discussion internally, I'm suspecting there will be an option for this.
Item properties now show up correctly! Work resumes.
How did you do that please ? ( I'm using ItemsAdder but I don't have custom textures on Bedrock )
Very nice, did anyone try if ItemsAdder works with current builds of GeyserMC Spigot plugin?
Very nice, did anyone try if ItemsAdder works with current builds of GeyserMC Spigot plugin?
Do you have a test server? If so I can fire up a build and grab a screenshot.
Edit: I found it but its not 1.16.4 so I cannot join.
@LoneDev6 if you have a chance to update your test server or install ViaVersion (I did attempt to join but the server is still on 1.16.4) I'll be happy to try it out!
Very nice, did anyone try if ItemsAdder works with current builds of GeyserMC Spigot plugin?
Do not work
Yes, the current master builds will not work. Resource pack conversion is only in my branch for the time being as it is still unfinished.
Yes, the current master builds will not work. Resource pack conversion is only in my branch for the time being as it is still unfinished.
there is multiple resource packs branch on your account , wich one is it please ?
I would not recommend attempting to compile and use it yet. That being said, the branch is titled resourcepackconversion, but you won't get assistance for trying to run it.
I would not recommend attempting to compile and use it yet. That being said, the branch is titled
resourcepackconversion, but you won't get assistance for trying to run it.
I just want to try , I don't want to use it for now , I'll wait the release but is the itemsadder version updated ?
Sorry guys currently I have no time to test this in detail @DoctorMacc if you want you can send me a PM on SpigotMC.org so I can gift you a copy of the plugin. Obviously you have to write down your SpigotMc account name here on this Github ticket to avoid people faking your identity to get a free copy XD https://www.spigotmc.org/resources/73355/
Sorry guys currently I have no time to test this in detail @DoctorMacc if you want you can send me a PM on SpigotMC.org so I can gift you a copy of the plugin. Obviously you have to write down your SpigotMc account name here on this Github ticket to avoid people faking your identity to get a free copy XD https://www.spigotmc.org/resources/73355/
@LoneDev6 It should be https://www.spigotmc.org/members/camotoy.6153/ unless he got a new account or something.
@LoneDev6 I have sent you a message on SpigotMC verifying that I am https://www.spigotmc.org/members/camotoy.6153/. Thank you so much for your assistance!
@DoctorMacc Perfect :D Added you, you can now download it: https://www.spigotmc.org/resources/73355/ Be sure to follow the how to install guide: https://itemsadder.plugin.ga/first-install
Looking at some resource packs generated by that plugin, the main thing that stands out to me is that it seems to make use of namespaces, which I don't believe the converter handles at the moment (it interprets the namespaces as simply a file path with a colon in it). So for example, a vanilla item with custom model data under the minecraft namespace of the pack, say a diamond sword, referencing itemsadder:item/school_chair in one of its predicates should then look for that model in the pack at assets/itemsadder/item/school_chair. It currently looks under assets/minecraft/models/itemsadder:item/school_chair. If this were dealt with, the stuff that's just simple texture replacement should work fine from what I see.
Sadly a lot of resourcepacks uses namespaces so it won't be only an issue with itemsadder, I hope there's an easy way to integrate that in the converter or won't work with every pack
To be fair, that isn't really the case from what I've seen... namespace use in resource packs wasn't even documented on the wiki til around 1.15, though it was always something you could do. I had never even noticed until they started including the minecraft namespace in the default assets around then. That said, obviously it's something that would make sense to add from a compatibility standpoint. That said, I don't have this plugin myself... I just joined the Discord and downloaded the first pack I could find a link to in the support channel, so there could be other issues I'm not aware of on first glance.
I can likely just convert the colon into an underscore where relevant, or just use that as the identifier instead of geysercmd (Geyser CustomModelData). I will likely do the former to prevent odd conflicts (will am item try to use the minecraft namespace? I dunno).
I can likely just convert the colon into an underscore where relevant, or just use that as the identifier instead of
geysercmd(Geyser CustomModelData). I will likely do the former to prevent odd conflicts (will am item try to use theminecraftnamespace? I dunno).
If I recall I added a check to avoid people from adding items to the minecraft namespace, which would be stupid xd
That's good! But it doesn't mean other plugins/datapacks won't try to do that. :P I'll see what the best way to deal with it is once I start playing with ItemsAdder.
Regarding the pack converter, should I open a separate issue on that repo (https://github.com/GeyserMC/PackConverter) for namespaces or is just mentioning it here sufficient?
Just Bumping this thread to ask if / when we can expect the resource pack converter to include functionality for namespaces other than the base minecraft one!
Idk if i would be able to complete it, but i am working on it. I am using geyser pack convertor, but it turned out it only converts textures, so i am finding a way to deal with models.
@RedSmarty
Idk if i would be able to complete it, but i am working on it. I am using geyser pack convertor, but it turned out it only converts textures, so i am finding a way to deal with models.
Assuming you are the person who came on the Blockbench Discord asking about this... anyways, I'll explain best how it would be done, but I honestly doubt it's something you'd reasonably want to do programmatically anyways.
Firstly, you need to ensure you are making a single texture atlas for every model. So you'll need to incorporate some image editing library to stitch the textures together, and edit all of the UV values in the given JSON accordingly, add the new texture atlas, and remove the extraneous textures. Best way to deal with this is probably stitching in most cases, so basically just fit every texture into a single image as best you can, and shift any UV values accordingly.
Secondly, you'll need to convert the model not only to the bedrock format, but also ensure it contains all the same groups (referred to as bones in bedrock) as the player model. The cubes of the converted item model will need to be placed within the rigtItem or leftItem group, depending on the desired hand slot. If you desired to allow the player to use either, you'd need to make a different model for each, as well as a separate model for the hat slot. Also keep in mind there are subtle differences in the JSON file in terms of how bones are defined, how many keys value pairs UV is split into, and how things are named. Rather than explain all these differences here, I would encourage you to simply take a look at the differences yourself.
Thirdly, as item models do not really exist on bedrock, neither do display settings. You can fake this with an animation, but you'll need to find the mathematical relationship between scale, rotation, and position in java display settings and in a bedrock animation. While I know there is a relationship, I've never bothered to figure out what it is, but I know it can be done. You'd need to create one for right hand first person, right hand third person, left hand first person, left hand third person, and head slot.
Fourthly, you'd need to add to the player entity definition file (and armor stand definition as well if desired) and set a query for each item to check if the item is in the appropriate slot, and play an animation, displaying that item appended to the player geometry when it is in the appropriate slot. These queries will also correspond to the animations you created in the previous step, and you'll need one for each possible pseudo display setting. You'll also need to define the texture for the given model (as a path), as well as the geometry to this file. Furthermore, you'll need to add a render controller, which I'll expound on in the next step.
Fifthly, you'll need to create a render controller that defines the materials used by this model, as well as the texture used (in short name form). This will require a corresponding entry in item_texture.json in the textures folder to define the actual path for this short name.
Sixthly, you'll need to create an icon with will be used to show the model in inventory. Currently, there isn't a good way to do this in 3D... I suppose you could try implementing this as a custom block rather than a custom item to get around that... but that would have other implications, and custom blocks are still very much a mess at the moment anyways. The icon file you create should essentially be a rendering of the model from a side view. You also need to make sure to set the alpha channel visibility to something like 1/255 to prevent this icon from getting in the way of third person views... one consequence of this is it would prevent the item sprite from being visible on item drops and in item frames... not really much of a way around this, other than conceding 3D for the third person view and just using the icon instead. This icon will be passed by geyser in short name form, so it will need a corresponding entry in item_textures.json for the actual path.
And if you do all those things successfully, I suppose it would work...
Thanks for your response. I have studied the model files for both java and bedrock models by converting the same model to different editions, but the bedrock edition seems to have another concept of Bones. The values arent same tho. It shows the same position values in the editor, but however it is different in the exported model file(i am talking about bedrock one) but it isnt a big deal because if i just add 16(which is my texture and grid size iirc) its then same as java model values. But if i then import it to blockbench, the values the previous one, before adding 16, is shown in the editor. I just cant get past this because i am not sure whether this is intentional or a bug. Please reply whether this is a bug. Thanks.
@RedSmarty
Thanks for your response. I have studied the model files for both java and bedrock models by converting the same model to different editions, but the bedrock edition seems to have another concept of Bones [...]
Very well, I will try to do a post where I explain the specific differences when I get some free time. I've just been quite busy with exams these past couple weeks.
@RedSmarty As promised, I have made an example of mapping a Java model to a Bedrock model. This assumes the input java model already has a single texture:
https://gist.github.com/Kas-tle/e2fae70f9e18eadc32b7ce2f01d275ea
I wrote my mappings in the same format as JQ, which you may reference at https://stedolan.github.io/jq/manual/ if you are unfamiliar. Hope this helps out.
Sorry guys i know i am taking so much time but its bcoz i have exams and other projects so pls forgive me
Hi, very long thread. Could I ask @Camotoy , will it be soon merged into main branch, or should I try your branch https://github.com/GeyserMC/PackConverter? But there aren't any steps how it works...
For anyone else wanting to get a better understanding of the mappings with regards to 3D model conversion, I have made a jq filter that takes an input java model and outputs something that can be eventually used as a bedrock model, including the required player geo groups. This could be incorporated into a shell script with jq fairly easily, and I believe there is also a library to integrate jq filters into java. I still have not cracked texture stitching (bedrock models must use a single texture for the moment) and display setting implementation (this will need to take the java display settings and convert them to an animation). One other minor limitation is that UV per face rotation has no equivalency in bedrock, so anyone creating models with the intent to eventually convert them may want to consider this.
You can play with the filter I created here. Feel free to paste in your own model on the left column, or use the provided one.
@bobhenl I can probably get it merged into GeyserMC's branch, but this is a lower priority since I'm not sure how I want to handle this (for example, bows we may not be able to get working - we might just have to ignore CustomModelData for that so they still work functionally). @Kas-tle, thank you so much for the filter! I'm not familiar with JQ, but I wonder if it's possible to simply convert that code into Java.
[...] @Kas-tle, thank you so much for the filter! I'm not familiar with JQ, but I wonder if it's possible to simply convert that code into Java.
@Camotoy there are indeed a couple of JQ implementations in Java (see eiiches/jackson-jq or arakelian/java-jq), though I assume its not exactly common. From what I've seen in the past, most resource converters seem to just use the GSON library to parse whatever JSON input and standard java functions for the rest, though admittedly this is referring to Java resource pack conversion, which in the past has never really had to deal with as stark a difference as an input java model and an output bedrock model in the specific configuration required for what we'd need here. The solution I've come up with is likely not the most efficient way to deal with this of course. I tend to use JQ because, likely due to its intended purpose for dealing exclusively as JSON data, it tends to be easier to visualize my end goal, and the fact that it is CLI based allows me to test whatever I'm working on fairly quickly, and the existence of jqterm.com makes it extremely easy to share and demonstrate in cases like this.
I will try to work on a filter for dealing with pre-UV translation to place all the defined textures into a single texture. This particular process will present a decision problem among client performance, fidelity to the input, and ease of implementation:
- In terms of easiest to implement, creating a single texture that simply places all the textures for the model in a line would be the easiest. There is a plugin for Blockbench, for example, that currently does this. The main issue with this approach is it requires up-scaling/down-scaling of the input images in order to ensure the new UV values work properly. The downside here is fidelity will either need to be decreased to create smaller textures, or client performance will decreased since once-smaller textures will need to be up-scaled. This is the easiest to implement because it only requires a simple translation of UV values by a fixed number, dependent on the position of the face's original texture in the newly generated stitched texture.
- In terms of fidelity to the input, creating a single texture that fits every face on the combined texture would produce the closest result. Blockbench also has an implementation of this, though this particular version of this implementation should not be used as a rubric for fidelity as it will actually produce a result that is less true to the input than the method described above. To be true to the original, this would need to take into account rotations and differences in input texture resolution. The result of this would be quite inefficient in terms of texture size, unless some effort was made to match overlaps in faces... though this would be quite complex in and of itself. Dealing with UVs here is also quite a mess as everything would need to be remapped.
- A potential middle ground is using the first method described, but attempting to pack the input textures as tightly as possible rather than up-scaling/down-scaling to fit everything in a single line. This will help with client performance by preventing unneeded up-scaling of smaller textures, but preserve detail on larger textures (the only real fidelity difference with the above method is this will not preserve UV rotation). Like the above method however, it suffers from the problem of having to keep track of the new UV locations and update them for each face.
Given that I'll just be writing a JQ filter, I'll likely opt for method 1 for my purposes, basing the texture width on the largest texture in the model. For the vast majority of users who are using textures of similar resolution (namely mostly default textures), this method should work just fine.
I have not yet looked into display setting equivalencies, but that should be easy enough to do with JQ. I will just need to find the relationship between the units used in Java display settings and Bedrock animations. These can then be split into separate animations depending on the model placement (main hand, off hand, and head are all we'll have in this case). Limitations regarding loss of item drop visibility and item frame visibility still stand here unless something changes with regards to either the level to which item frames, dropped items, and inventory item display are data driven, or custom block implementation improves. If custom block implementation were to become more stable, I suppose just using a custom block in the instance of item frames and drops would be an option. In the case of inventory, a lot would need to change to display the 3D item there... so sprites will have to work for now.
Finished the filter for dealing with UV. You may access it here. If anyone wants to test this, I'd recommend use of something like ImageMagick's montage feature. Something like this would allow you to automate it, then combine with the other filters:
texture_width=($(jq '.texture_size[1] // 16' ${file}))
montage *.png -background transparent -geometry x${texture_width}+0+0 -tile 1x stitched_texture.png
Note the textures must be in the same order as they appear in the model JSON. You could automate this as well by using JQ to derive these as an array with something like texture_array=($(jq -r '.textures[]' ${file})). I believe ImageMagick does have a Java equivalency as well, but really any image manipulation system that allows simple stitching will do here.
@Camotoy Okiedokie, I have completed filters for conversion of UV, display settings, and geometry. I've had to make some minor modifications to the converter that makes the actual geometry to give me more groups to work with to create animations from the display settings, so I'll post all those filters here:
These seem to work well enough and should be able to solve the bulk of problems associated with 3D conversion. I haven't really done a large scale test with these, so if anyone with experience implementing custom item models would like to try that with these, that would be nice. All that needs to be done in addition to this is adding everything to the player entity definition file (and armor stand definition file as well if that's desired), as well as creating the stitched texture, defining a render controller referencing the texture and geometry, and defining the shortname for the texture in item_textures.json. I'll try to make some filters to automate these more minor tasks soon. Also keep in mind if one would like to use all three slots (head, right hand, and left hand), then three geometry files would be required as the cubes must be placed in the appropriate group of the player geometry file (though admittedly I am not even sure one can place an item in the head slot at the moment for bedrock). I'll attach some screenshots of an example model I ran through all these filters, and how it appears in Blockbench versus bedrock edition.
Looking further into head slot stuff, I am not sure this is something that I would be able to do resource pack side only unfortunately. One option is passing something on the server side that can be queried from the RP. For example, variant and mark variant could be used. These are how entities like villagers display different textures, with variant being used to pick the village biome style and mark variant being used to pick the profession. A system could be implemented in which armor stands and players are assigned variants and mark variants based on the item in the head slot. Though this seems a bit convoluted, I can't really think of a way to deal with headgear client side only, which I imagine would be a bit of a deal breaker for those hoping to implement full on 3D cosmetics with this system. If Mojang were to at some point expand the scope of query.get_equipped_item_name to accept the head slot as well, then this could all be done on the RP side. Mark Variant Description Variant Description
Want to update from my last post regarding mark variants. After having a discussion regarding the implementation of custom heads, I think attachables might also be suitable here as an alternative to the head slot. The pro to this would be its arguably a more native way to accomplish this, and geometry from one of the hand slot models could likely be reused. One potential con, however, is this would require a decision with regards to what is and is not wearable, as we would have to pass the component minecraft:wearable on all items. Also, attachables seem to be in a constant state of broken/not broken with successive updates, as I saw some complaints that stuff was breaking in the 1.16.200 format... for the moment you can obviously specify any format, but this makes me think Mojang is currently making changes with regards to how attachables work. (Also want to make clear, though the bow is an attachable, this still acts as non-data driven, and there is no way to place an attachable in non armor slots for the time being)
Just an update on my progress with filters:
- Display Settings Filter
- UV Stitching Filter
- Geometry Filter
- Player Entity Definition Filter
- Render Controller Filter
- Generic Attachable Filter
- Player Attachable Filter
- Icon Texture Filter
If it would help, I could also make the filters that would be needed to make an entity to replace the item entity, as these will show up as invisible at the moment due to the editing of the alpha channel on the inventory sprite. This would, however, probably require quite a bit of translation work on Geyser's part, as any instance of the item drop entity would need to be sent to the client as this custom entity. Also note that the attachables filters are very much a work in progress, and I have yet to test them in game.
@LoneDev6 Hello, do u have discord? If yes, can u pls add me? I need to ask some questions regarding this. My ID is RedSmarty#1437
@LoneDev6 Hello, do u have discord? If yes, can u pls add me? I need to ask some questions regarding this. My ID is RedSmarty#1437
I'm sorry, currently I'm not actively working on this project and I have a lot of support requests accumulated during the holidays about my other projects. I hope you understand, thanks
@LoneDev6 ItemsAdder support has been added!
Oh yea boi, that's dope. Is there any particular tutorial we have to follow in order to make this working?
Btw most of the people complain about the security risk of issuing the premium credentials into the Geyser login form, which I think is real since server admins can steal the info, right? That's the only reason why I don't use Geyser for now. Am I wrong?
Btw most of the people complain about the security risk of issuing the premium credentials into the Geyser login form, which I think is real since server admins can steal the info, right? That's the only reason why I don't use Geyser for now. Am I wrong?
@LoneDev6 You can use floodgate which allows the server to stay in online mode and let bedrock players join without needing a java account. https://github.com/GeyserMC/Geyser/wiki/Floodgate
For online mode, we have also implemented a way to log into Microsoft-backed Java accounts through the web browser, so that will be less of a concern once all accounts have migrated.
Right now, you'd have to compile my behaviorpack branch of my PackConverter repository, and then compile my resourcepackconversion Geyser branch. There is still a lot of work to be done, mainly involving caching and saving translating resource packs so we don't need to translate on every player joining.
Thanks for the info :D
Anyway: Is there any particular tutorial we have to follow in order to make Geyser working with ItemsAdder? I want to provide my users a tutorial
Right now, this is unimplemented in main Geyser (working with files in this way feels dirty to me, and resource pack caching is nonexistent). Once it is implemented, it will be as simple as installing Geyser normally and having Bedrock players join. They will then be given a resource pack prompt.
Very good, thanks! I wait for the resourcepack caching system (you could just check the remote file last edit to know if it's the same as your cached pack, so you don't need to reconvert everytime)
I guess i am late, because of studies. But this looks very good. Are blocks supported too? And armor? And emojis? And hud?...
P.S :- i deleted mine repo bcoz this is better.
I guess i am late, because of studies. But this looks very good. Are blocks supported too? And armor? And emojis? And hud?...
P.S :- i deleted mine repo bcoz this is better.
I highly doubt that HUDs and emojis can be ported to bedrock edition due to how this hacky thing works in ItemsAdder sadly
I guess i am late, because of studies. But this looks very good. Are blocks supported too? And armor? And emojis? And hud?... P.S :- i deleted mine repo bcoz this is better.
I highly doubt that HUDs and emojis can be ported to bedrock edition due to how this hacky thing works in ItemsAdder sadly
My Geyser server uses “ Harbor - A Sleep Enhancement Plugin!” and a HUD does appear for both bedrock and java player when someone heads to bed. I believe it the same HUD for the Ender Dragon health bar though. I’m not sure if that can be helpful in any way.
Either way, I brought ItemsAdder just to provide extra items on the server so even if HUD don’t display properly, I will just disable it in the config. I’m hoping the GUI for the custom interactive block work for Bedrock players though.
I’m very excited for this to come out and thankful for everyone who work on this.
I guess i am late, because of studies. But this looks very good. Are blocks supported too? And armor? And emojis? And hud?... P.S :- i deleted mine repo bcoz this is better.
I highly doubt that HUDs and emojis can be ported to bedrock edition due to how this hacky thing works in ItemsAdder sadly
My Geyser server uses “ Harbor - A Sleep Enhancement Plugin!” and a HUD does appear for both bedrock and java player when someone heads to bed. I believe it the same HUD for the Ender Dragon health bar though. I’m not sure if that can be helpful in any way.
Either way, I brought ItemsAdder just to provide extra items on the server so even if HUD don’t display properly, I will just disable it in the config. I’m hoping the GUI for the custom interactive block work for Bedrock players though.
I’m very excited for this to come out and thankful for everyone who work on this.
I wish it was that simple, ItemsAdder HUDS are like this (refer to the red circles) and I doubt it would be easy to convert the resourcepack to be compatible with Bedrock clients.
I suspect we can at least translate the icons, but I'm going to assume that right-side GUI is not going to translate over well.
@LoneDev6 ItemsAdder support has been added!
Anyway to remove these ???????? (they should be the hud icons) you have to disable huds feature in config.yml of IA
Anyway to remove these ???????? (they should be the hud icons) you have to disable huds feature in config.yml of IA
We maybe able to fix them, what unicode character space do you use for them? We maybe able to render them to a texture that bedrock uses to display or if we are lucky just get it to render them anyway.
https://unicodes.jessetane.com/%EE%80%80
I appreciate the dedication but I don't think it's possible to apply the same hacks I applied to the Minecraft Java edition. Basically I can retexture these characters to make them of negative width and height to shift other symbols and move the HUDs and stuff around the screen. This may be doable with builtin Bedrock edition stuff to create custom GUIs and similar, but I don't think it's easy to integrate without insane conversion logic
Ah I dont think negatives would be possible but we can retexture them, these are the defaults in bedrock https://github.com/TwistedAsylumMC/bedrock-unicode-characters
Ah I dont think negatives would be possible but we can retexture them, these are the defaults in bedrock https://github.com/TwistedAsylumMC/bedrock-unicode-characters
Very cool! I noticed it uses the private area characters, interesting. Minecraft Java edition doesn't use these characters at all.
The negative shifting in X and Y axis may be possible but sincerly I have no idea on what are the limitations of Bedrock resourcepacks. Also keep in mind that ItemsAdder allows you to create as much as custom HUDs (emojis, GUIs...) as you want, using all the private area characters
It is possible to modify bedrock HUD. Take a look at thirst addon. It does the same thing as itemsadder, and it also updates over time.
There u go, https://mcpedl.com/thirst-bar-add-on/?cookie_check=1 There is a file called hud.json, but i guess its very hard to implement this conversion, as predicting how java will see it, then make the same as bedrock, it will be a lil hard. Alternatively, @LoneDev6 can implement a way to convert Hud, but then it will be limited to Itemsadder only.