Concept: Custom Player Models

[r543]

Hello, I hope this isn't unwanted, but I just came up with a little concept on how we could have custom player models:

In the Options, or under Skin Customization you'd have a new menu called "Skins" . In said Menu, you see the following list(with scroll bar and preview on the right) : Default (your default MC Model+Skin from Mojang) Steve (default Steve Model + Steve Skin from the Texture Pack) Alex (default Alex Model + Alex Skin from the Texture Pack)

Steve and Alex are there to help texture pack artists, those can have some good use there to quickly switch and test skins instead of using the Mojang site(which seems to not update skins if the texture file has the same name or has even further delays due to cache)

Models in Pack Order(or Alphabetical) Here is where the fun stuff starts, the custom models(which I guess could be defined in some .properties files, having their display name and model file name, maybe a tiny bit of lore text, one line or so) from the resource packs get listed, in resource pack order or Alphabetical(maybe we can also have a toggle for that but this doesn't need to be in the original implementation) In said properties file, there's also following flags: Use Default Skin (useful if you have a slightly altered model that's compatible with the default skin, like for example a smaller player model like the Child Zombies, and want to allow the player to continue using their skin) Use Default Model (useful if you have "just" a retextured skin in the pack so you don't need to have copies of the default player model, this might need a Steve/Alex toggle) The way this is supposed to work would be the following: Player Joins the Server, on join the info of the other skins gets requested and your info sent(I guess this is also how the Mojang Skin system works, your skin gets sent to the other Clients who "download" it while you "download" the other skins): If the other player(s) has/have the resource pack, your picked player model gets displayed. If the other player(s) doesn't/don't have the resource pack, your regular Skin and Model gets displayed

This is the Concept I came up with, should work in theory, not sure how difficult the implementation of the Netcode would be but I do imagine that it would work, in a way this would also be similar to the skins available in the console edition(as far as I know, every game copy does have those stored locally) working in a similar way and probably make it the easiest way to implement those than to have players download player models and animations.

[zubiden]

I think that Custom Player Models (CPM?) can be used for cheating on PvP servers, but I really like this concept.

P.S. Is there any documentation about CPM?

[SetantaLP]

Interesting idea. And because optifine is only a client mod, it can't change hitboxes and similar things (server side-stuff), so that won't allow cheating.

But the only way to change skins at the moment is to upload them on mojang's skin-server. So if you are on a server and another player comes inside your view-range the server notifies your client and sends you the playerinfo-packet, with the data it got from mojang during the login of this player. If your client receives this data, it request the skin form mojang's skin-server.

So if you want to enable custom player models here, optifine has to host all the skins/models (and the client request the data like it does for capes) and that would need a certain amount of storage, so it might be necessary to restrict uploading models similar to capes.

Sending the model to a server while joining is a very bad idea:

1. it would reduce your ping, especially when your upload speed is very low.
2. it would mean a lot of traffic for the model-server, because every time you join a server, you sent the model-information and it would also need a certain amount of space because as long as you are on a server, the model-data has to be stored, because maybe you come into the range of another player who doesn't have your model-data. The server you play on can't be used for temporally storing the data, because optifine is only a client mod.

And sending the data directly to the other players is also a bad idea, because you probably have to send the model stuff very often, which is bad for the ping. And you have to know the IP-adress of these clients, which is a bad idea because of privacy and safety. So you need a server that delivers the data.

[sp614x]

The Custom Player Models could be used for cheating in PvP. The simplest example is a fully transparent model or a very small (1cm) model. Even making a very big model would also be cheating as the hitbox wiould stay normal and it would be hidden somewhere inside the big model. Any significant deviation from the hitbox could be used for cheating.

[MadMooAU]

The Custom Player Models could be used for cheating in PvP.

Well, the other players would have to be partisan to the cheating, as the only way for them to see the model would be to also have the pack loaded, otherwise they would only see Vanilla models. There is no way for the cheater to force any other user to load their pack. It would actually put them (The "cheaters") at a disadvantage to have the pack loaded over vanilla.

[sp614x]

Even when other players don't use the models, they can still be used for cheating. For example make all other players wear very long hats (10m or more). Then the player can track all other players even when they are underground. If the hats are different colors, then he can also identify who is who and where he is hiding.

[zubiden]

That's what I mean. Maybe changing scale to fit 3-4 blocks will fix some possible cheats. So, is it possible right now to change player model, or it will be implemented in future version?

[r543]

Hello, first of all I'd like to thank for all the replies(unfortunatley still had the default Github notification settings, but that should be fixed now). Regarding the addressed points: PVP Originally I thought that since those are addons, there's no need to modifiy the default Steve/Alex model, so that one would be unmodified. However I later thought it would be nice if people could do this so that people who have the pack can see that. While I do agree that we shouldn't encourage PVP cheating like that, I do think that people could do the same with mods or modifiying the default Steve model(how difficult is that anyways?) so I wonder if this should really be our worry, then again Optifine would make that step much easier, and unless Servers force everyone to only use the default texture pack(which I guess players would dislike) or have a whitelist, once again this method having issues, it would be bad. I am fine if the default steve/alex model stays unmodified, but in a way I wonder if we should worry about that. It's not PVP, but you can currently cheat with custom NPC models or giving the Silverfish Monster Eggs(which do take longer to remove through) a different texture and so on... That's the issue with giving people freedom and creativity, however I do believe that we should continue this and go the creativity route instead of restricting things, you can share your thoughts on this.

MC does always paint the head texture black, does limit some creativity(anyone thought about doing a kirby skin by only using the body and no head? kinda difficult without a hat now) it's done against pvp cheating I guess.

@Coolboy21 Thanks, regarding CPM, I don't know if it exists, been curious about custom models in general and would like to have custom wing models and animations(Vex like Wings anyone? or having them move like Bird instead of "insect" wings or having butterfly wings? just many possibilities)

@SetantaLP yeah, even if hitbox changing would be nice for some things(like if you wanted the players to specifically use the child or maybe ant size models) that's more the job of a player customization mod and not something that should be done by optifine, so I'm fine with that, sorry for going to this side topic.

Regarding skins, was this a reply in general or the models that do allow the default player skin? The idea is that those player models(which come with their own skin) don't require the player skin, unless they are set to use the skin, in which case we'd load the regular player model and then apply the skin like usual to it, that shouldn't be a problem?

That's the part I'd like to do differently, only players that have the Resource Pack would be able to see the skin you picked while everyone else gets to see the default one, does require a bit of network code, but similar to the Mojang code this would be "sent" to all players on join, something like(in words, not code) "Rendner player_xyz with model_xyz" which would of course only be "understood" by Optifine and it would only do that if model_xyz is there, else use the default model/skin from Mojang as a fallback. This way Optifine doesn't need to host them, no server costs or anything and Resource Pack Creators can just include all the stuff they want and easily modify it. In a way I do believe it's very similar how the Remix Packs and Model Packs on Console get done, each console version does have those Skins and Models saved locally, they aren't "unlocked" for everyone but can still be viewed(DLC of games gets done similarly most of the time).

Hope what I said in the original post wasn't confusing, but no models or skins(minus the default MC skins done by MC) get sent around and nothing gets hosted by optifine for this concept, optifine simply sends a "please rendner me(this player) with this model if you have it in your optifine, else use the default Mojang Model and Skin", with all players that want to see the model, requiring optifine and the resource pack. (one thing I forgot mentioning in the model .properties file is some kind of UIID, which I guess the creator could do creatorname_modelname_version_somethingextra? for example, this is the name that gets sent over)

@MadMooAU Exactly, however there's the issue that @sp614x mentioned(hats would need to be very large through to stay visible), unless, we don't allow changing the default steve/alex model, which is fine by me(even if there would be some uses for it)(this is discussed in my post a bit further upwards ;))

@Coolboy21 I respect the idea, however to not limit creativity(being giants for a tiny bit or for certain animations could be really nice concept) I think it's better to make it so that the default models can't be changed, that way you can't "force" anyone to have a skin that they don't want to, giving us the situation @MadMooAU (Hope I'm not using too many mentions) said, with Cheaters having no way, outside of modding stuff themself. Think it's unfortunately not possible to currently do that, do hope it gets implemented sometime in the future and that the custom colors(like for armor, kinda need it for a custom project but I don't want to sound demanding) get added again soon.

[SetantaLP]

@r543 unfortunately the java edition is not able to say "Rendner player_xyz with model_xyz", because the protocol doesn't contain packet or field inside a packet that can do that. And because optifine is only a client mod, you can't simply add a packet or packet-field for that. And a plugin-channel is not an option, because the server will ignore this channel as long as it doesn't know what to do with the data, sent through this channel. So at the moment the only way to do that, is using an external server that would manage this info: If a player with a custom model joins a mc-server the client has to notify the external server and everytime a player comes in the range of another player the client has to ask the external server if this player uses a custom model (similar to the way the player request the skin in vanilla).

[zubiden]

Xaero's minimap have a plugin that can disable some features. That would be cool if Optifine have same plugin, or even better. For example: disable edited player (or mob) models on server (if pvp server), get player resourcepacks names (not necessarily), or even give server ability to set multiple server resourcepacks.

[r543]

@ SetantaLP I can understand it being difficult if not impossible to implement client side(even if it should be possible in theory and I think a few mods like the player changing one have done that?) as for the server I do believe a server plugin would work or why not?

[SetantaLP]

@r543 if the server uses a plugin/mod, it would be possible to do that, but this means, that

1. someone has to develop and to maintain the plugin (for bukkit/spigot servers) and the mod (for forge-servers)
2. optifine is no longer completely indipendant form specific server side modifications, because of this feature. All other features are either completely client-side (e.g. Custom Entity Models (CEM), Dynamic Ligths) or are using data, that can be modified in vanilla (e.g. NBT-Data/Damage-Values in Custom Item-Textures (CIT)).

Probably there has been a mod, that was able to do similar things, but I'm quite sure, that this mod also had a server-side component or it used a 3rd party server for exchanging data.

[r543]

@SetantaLP I see, I checked the More Player Models 2 mod(which goes into the right direction but doesn't really allow this, it's more for adding extra predefined parts and changing body sizes) for servers it does require the mod(for Forge) or the Bukkit Plugin(guess having Bukkit and Forge at the same time is not possible?) just like you said.

I did understand the part about the protocol(kinda sucks that we can't do this, when you're programming a game yourself this would be of course possible but I'm sure you're aware of that) as well as the server not knowing what to do with this data and dropping it(sad that it can't be broadcasted to other players), so unless Mojang does something specifically for that(which I heavily doubt, especially since this is a selling point of the Bedrock/Win10 Edition) We'll need to rely on plugins and mods.

The one part I didn't understand before was the :

And a plugin-channel is not an option, because the server will ignore this channel as long as it doesn't know what to do with the data, sent through this channel.

Unless you meant plugin, as in mod or something like that, while having nothing on the server? And the part about the external server.

I can understand that having a external server would be prefered, however I don't want to strain Optifine and would prefer if this stuff was done by the players themselves(so to say) so we can just have as many models as we want and do this on our own space instead of Optifine's servers, also makes sure that this would still work for the future. I was going to ask if updating it wouldn't cause issues as well, but I guess the External Server wouldn't need to have changes, where plugins and mods would(wonder what through, does a mod need to be updated by that much for every new MC version?)

I was originally going to say that it would still be good if we had this as a server addon if possible, even if it's a pain, do have two new ideas now through which might work.

The simpler of the two features would be to have some sort of local list which is configured with the client(since optifine can save a config file it should be possible), this idea only really works for a "private server" environment, not a huge pvp server, basically, the player would configure the skin for himself and other players himself and it would be client side only. Not the prettiest solution, but it doesn't require any external things(afaik it should be possible to "translate" the player name into a ID and render the models that way locally?) and is probably the easiest to implement, it would be nice to have player models.

The second features a server tool: Basically you'd run this alongside your server(on a different port, or could also be on a different host) and optifine does have a field for the IP of the "model server" in the options, entering it there makes optifine communicate and ask with that server. This should be like the external server idea, except that the players get to host it=we aren't straining Optifine or using up Optifine's Server Space but our own instead, probably the more elegant solution and this would make sure that even if Optifine is down, we can still use it.

What are your thoughts to this? Hope I don't sound stubborn with this.

[SetantaLP]

Local Player-Models are available as of 1.12 HD U C5 and I think they are based on the player uuid. A server tool would be also a good idea, but that might be difficult because the server-list is stored as an nbt-file, so you either have to store these data separately (which might be difficult, if the player removes/edits an entry without optifine installed) or you store it inside the servers.dat, but that means that the data is lost, if you use the file without optifine.

Bukkit and Forge together is possible in theory, see KCauldron/Thermos, but it's a quite difficult task, because the deobfuscation is different. But there at least one tool that exist as mod and plugin (see WorldEdit), but this tool is build on top of a self created API, which wraps around bukkit/forge.

The problem about the protocol and the packets is, that a packet (that arrives on server/client) is nothing more than a sequence of bytes, which reduces the amount of data, that has to be sent, but if you want have the information, you have to know exactly how to read the data. So the recipient (server/client) reads the first few bytes, uses them as packet-ID and searches the id in the packet-registry. If it finds a match, it calls the read-method of the packet-class. If there is no match or if the data can't be read (due to changes in the packet structure), the game might crash or react unexpected. To prevent that, dinnerbone introduced the plugin-channel, which is also used in vanilla (Trading-Inventory, Commandblock-Gui, ...). A plugin-channel is basicly a packet with only 2 fields. One is for the name of the channel (e.g. "MC|TrList" for the Trading-Inventory, others are listed here), the other is a space for a sequence of bytes with a limited length, so it can be used for all kinds of data. Which information this sequence contains, is determined later based on the channel name. If the recipient doesn't know the channel-name, the sequence will not be handled.

I think mojang will implement something like custom player models (that are uploaded like skins on a mojang-server and json-based like block-models), but I'm sure they will implement custom entity-models first (probably in 1.13 or 1.14, probably in the way they implemented custom recipes (first switching to json, then implementing a way to load customized ones, which might happen in the same version if there is enough time to test)).

[r543]

@SetantaLP I see, didn't know if it's available, will check it out I guess, no way to set it for certain player UUIDs like I described in multiplayer through?(the local setup) Also I won't promise this since I do lack time and all, but IF I get around it, I'll try to do a Optifine tutorial series on how to use various features of it. Server tool would basically allow us to do the external server ourself(and if someone wants to support Optifine, a "official or main" server would quickly rise, do prefer in general if we also get our tools to that, which is quite nice, glad to hear that you support this. I would store it separately in a file just for optifine, I mean Optifine has it's own biome colors and stuff in the mcpatcher folder so I think a similar approach instead of "modding" the MC folders and files should be done.

I see, deobfuscation? wonder why that's required?

I see, so the server would need to support that "plugin" first meant you meant server plugins but it didn't seem like you meant that. Thanks for clearing this up as it's been a while since I last played MC(after getting it recently like a few months ago) did understand the base concept of "Server doesn't know what to do with this "nonsense" of data(from the server point of view), -> drop that info.)

I see, it would be nice as Java still seems to be Mojang's doing while Bedrock is Microsoft's? Although I think it will still take a long while. Ah, I did see the recipe files, can't currently change it but it would be quite nice if we could do that(even if there's people that would sadly use it for cheating), same for entity models, was surprised about custom block models, but of course entities were a completely different beast, would also love custom player models like that. I wonder through, how are you so sure that this is soon? I remember hearing it takes a while until we get 1.13 and that it's mostly a technical update? hope I didn't get that wrong. Good to hear that through and it sounds like my reply didn't come over in a bad way ;P

[SetantaLP]

I only saw in the changelog that changing player models localy is now supported, so I don't know how that works. So if you want to know details ask @sp614x. A tutorial-series would be cool, but it would require a lot of time to create, because there are a lot of features you can use. A server tool would not be quite easy to create, because you only need an http-server with a database for storing the data and some php (or similar) scripts that manage the requests and sends the responses. And it would be very useful for rpg-servers. The server address has to be stored in a file in the base-directory (where the servers.dat, the options.txt, and optionsof.txt (optifines settings-file) are stored). The MCPatcher-Directory can't be used for that, because it's either part of a resourcepack or inside the optifine.jar, which will change when you switch to another optifine version. So i would probably prefer a file namens serversof.txt/.dat for storing the address (in optionsof.txt, the data might will be lost if you switch to an older version of optifine), but you there has to be a safe way to identify to which server the address belongs, because the user might remove a server or edit the info when optifine is not enabled. Deobfuscation is required that people can easily create mods/plugins that are built ontop of minecraft, because the vanilla minecraft.jar uses obfuscated code. That means that all classes, methods and fields are named a, b, c, d and so on, so that nobody can easily steal code, because he doesn't know which class is responsible for which things. With "plugin" I mean a server plugin (mostly a bukkit-plugin). A "plugin channel" is related to plugins, because it was "invented" by dinnerbone who was one of the founders of bukkit, and I think bukkit was the first api that was able to use this packet (see the post i linked above). Yea the Bedrock-Edition is mostly Microsoft (Microsoft Studios to be exact) while Java is still Mojang. Initially it was planned to switch the recipes to json and allow the player to edit them. But as far as I know after switching the recipes to json and implementing all the other stuff for 1.12, dinnerbone recognized, that there won't be enough time to implement and test the recipe-customisation, so he decided to move that feature to 1.13, which will be a technical update (see his twitter post). And because crafting (and the whole inventory-management) is done server side, you can't load recipes in a resourcepack. The only way to load a recipe is put it into a data pack (like loottables and structures) which is loaded server-side, and because of the recipe-book feature the server might send the recipes to the client. So cheating should not be possible. In contrast to block-models entity-models are a way more difficult. Blocks are based on simple faces that are placed somehow inside a specific boundary and then textured and additionally most blocks are based on the default cubic blockmodel. Entities are completely different. They simply don't have a common model. They consist of different parts that are often animated (more or less independent from each other). And depending on the time they are added and the type of entity the parts may be named and animated completely different. So it the first thing they have to to is to find a common concept for entities. And yea, 1.13 will a mostly technical update. The main parts will be: the change to the block-id system, custom crafting recipes, some command-enhancements (syntax-highlighting/checking), data-packs (something like resource packs but for the server, which will contain loot tables, advancements, functions, structures and custom recipes) and probably custom furnace recipes (see official wiki), so i don't know if there will be enough time to implement a stable custom entity-model system.

[r543]

Thanks for the reply, alright. Haven't seen something in the documentation so far but I'll attempt custom animations soon. Yeah, there's lots of stuff, I just thought covering what I come across/use, so that has a easier tutorial to get into. Excuse me to ask but I had a question regarding this:

A server tool would not be quite easy to create not? The not seems misplaced given the rest of the sentence, did you mean to say not only?

Yeah, the base directory, I didn't exactly mean the mcpatcher folder, I meant it having it's own file and "component" so to say, separate from Vanilla, similar to how the mcpatcher folder is for resource packs.

I see, so Mojang did that, there's still ways to deobfuscate and get the source afaik, but I won't be discussing this here, haven't done it myself and generally think that this is unwanted.

Yeah, did get what you meant with Plugin after you said that in the previous comment, thanks for making it clear. Didn't know the details about Bukkit so I didn't know this was done by Dinnerbone, quite nice through.

Ah I see, so that's why the recipe files are currently laying around, would be good for resource packs and custom maps(even if players could use this for bad purposes), remember reading that 1.13 will be a technical update. I see. I thought more of "local cheating" but I doubt people would mind that, so overall, quite nice.

Can't block models be made similar like entities, basically out of small cubes like all the json models? Entities do consist of multiple parts, did get that from reading(as well as 3d modelling myself in the past) and have animation as well, hope this all gets changeable for us. I see, so this would all need to be updated which would explain a long time for this, it's nice that they plan to implement this, now if we can only change hardcoded texture pack things easier in Vanilla...

I did read about the block ID system, it's to make it easier suited for adding new blocks from what I've heard? Sweet, looking forward to this, especially data packs. So it's still planned to have the custom entities at a later point? do like how we're getting that support as well as the block properties that one can set.

[SetantaLP]

Oh yea, thanks for finding the "not", it just disappeared form another spot.... Ah okay, sometimes communication is a difficult thing. Yea it's possible to deobfuscate the code but there is no completely deofuscated version (because minecraft consist of more than 3.300 class-files) and there is no way to find out how the classes, methods and field are named in the original code, so the original code is protected quite good. Yea Bukkit was developed by Dinnerbone, Grum and some others. Custom recipes will be quite useful for maps and similar stuff (like everything that is part of a data-pack). And the only place where you can cheat, is a singleplayer-world but that wouldn't matter because there you can also use the creative-mode to get items. I think entity-models will be changeable one day (as well as you will be able to add blocks/items without mods) but all that stuff needs a lot of time to implement and test, so that the change doesn't break some entity-models or the animations. Because the most difficult/painful part is often to change a running system, so that was probably the reason for replacing the achievements with advancements, instead of just moving the achievements to a json-based-system. And that might also been a reason for completely removing numeric block- and item-ids. Because just expanding the id-space would only solve the problem of space for a limited time and moving around the ids would cause additional bugs in map-conversion. So they introduced the id-names in 1.7, block states in 1.8, a version-string in the level.dat in 1.10 and now they completely remove the numeric ids. That makes adding blocks not directly easier, but the system is more flexible because you no longer have hardcoded numeric ids and a maximum of 16 Sub-IDs. That means you are more flexible in adding blocks, because you don't need to worry about the limit, every single type of block has now its own id (minecraft:stone is now only stone, andesite is no longer a subtype of stone but a sepeate id (minecraft:andesite)) and you can now use as many states as you want (quite useful for things like flowerpots, because there are more than 16 flowers), so it might be possible, that some blocks, that are using block-entities for rendering because of the state limit, now use states for rendering, which will save performance, because block-entity rendering (And entity-rendering in general) is much slower than block-rendering (as you can see when you have a lot of entities on a map (or a lot of players in a server lobby) or when you are using a lot of item frames, or signs, or chest ....) Using cubes for entitiy-models would be a bad idea, because that would take a lot of time to create entities that way (just defining 8 vertices for a cuboid is a lot easier), and that would not solve the problem of very different models, as Ryan Holtz described it on reddit. I don't know which of all these problems he solved until he left mojang in 2015, and if parts of his work (e.g. the restructuring) were included in 1.8 or later updates, but a data-driven model system was neither introduced in 1.8 (where it was originally planned) nor in 1.9/1.10/1.11/1.12. I think it's planned to allow custom models, but there is no statement if someone is currently working on it, because after Ryan Holtz left mojang there were no more news concerning the model-system, so it's unclear when this will be implemented. Maybe RazzleberryFox or Maria Lemón‏ work on the new model-sytem but I don't know.

Wow that is a wall of text. I hope you enjoyed reading..... :-)

[r543]

Hey, thanks for the reply, will reply only to the "relevant" parts, I mean certain ones are already solved like the creator of Bukkit and so on. Heh I see, also "form" :P but I understand, don't worry, hope it wasn't bad from my part.

Yeah, I'm also not one that minds cheating, if people really want to do that instead of enjoying the game the way it was made or have legit reasons, I don't mind, I think creativity and openness for creators should be prioritized, even if it means cheating options for people(if I'm ever making a game, I'll ship it with a inventory editor preincluded ;P if people want to cheat than enjoy the game in the way it was meant, they can do that, but it's also there in case anything goes wrong and the player data gets corrupt/items lost)

I see, it's good to hear that this is planned, I remember when, way back in the day, "mod support" was announced, we never really got it but I bet that something like forge or modloader was planned, however it was just a pain to implement and back in that day, might have been a early thought, but now it should be possible to do that, looking forward to it and basically having "built in" mod support one day, even if advanced resource packs by itself are already awesome(that together with Optifine's CIT adds a lot)

Really? I was wondering if it was more of a move to the console based achievements(or how they're called) as they had some more advanced things, and MC cutting some things away(unfortunately this meant that "getting wood" "hehe" was also removed, but I don't mnid it that much) that were not really too important/already happen with progression. I guess since it's planned that we can add them, one could add all the old ones and, what's even better and it's intended use, custom achievements for mapmakers, awesome. Really love how Mojang "acknowledged" the Mapmaking community so to say and started adding such things, they can also Spice up the Regular Survival and Creative.

Item IDs were also kind of a pain to memorize, but yeah, names(although I guess item IDs, if we have a big enough variable, would also work) are a great addition, guess they also thought that making commands based on this makes it user friendlier, if you're already going to rewrite it, might as well do that. Or are the items still ids down below in the system? could somewhat imagine so but in a way I can also imagine it working without that. Hope with no sub ID limits we can also have some stuff a bit optimized, like colored blocks or things like Shulker Boxes and Wood Planks using Subids instead of the main ID, or well we can make everything main IDs, as long as it just runs well, because I've heard it was more wasteful to give them main IDs.

Flowerpots were 16 Main IDs before? and I see, I understand, think that's what was mentioned above, looking forward to the performance improvements and I understand the model part. I meant the way how the json format currently works, basically using cubes, don't mind if we have verticles and faces through(is the plan to go to that? just wanting to be sure that I understood)

Yeah it was quite big to read(my posts are quite big as well) but I'm used to reading that. Usually add spaces or line breaks and separators to keep it user friendly to read, but reading yours wasn't impossible to read so to say, then again I don't think I've ever had something that was impossible to read, not counting translating binary texts were one character was missing and threw everything into chaos :P

[SetantaLP]

Yea, the only place where cheating is a problem is in multiplayer. So as long as you prevent cheating there, everything everything should be fine. In singelplayer the new techniques may make cheating easier (you don't need mods to do that), but also give a lot of possibilities for mapmakers and also server-owners.

Oh the mod support. That was announced very early, but i think after forge came along (and was quite like what they wanted as an api), they moved the api itself at the end of the todo list, and thought about, what they can do to make changing things easier in a way that is less error-prone than the whole modding thing (where you can change nearly everything, but you can also break everything). And so they began they added commands and expanded what commands can change. And they added a way to change textures, sounds, texts, and later block-/item-models simply by using resource packs, which is quite fail-safe. Same for loottables, structures, and now recipes. You simply don't need mods, because everything is data-driven.

Yea, according to the wiki the advancements are similar to the console-edition achievements. And yea you can add everything you want, as long as there is a trigger for the corresponding event. And yea it's a great feature for mapmakers (like everything that allows you to change things without mods, so every json-file, every command, the structure block, redstone, ...), because you don't need mods.

As far as I know hardcoded numeric id's will be completely gone in 1.13, so everything will only use names (except from chunk saving, where each state used in this chunk will get a unique id, that is used inside the save-data). It also would not make sense to keep item-ids because some blocks (which won't use hardcoded numeric ids) also exist as items, so that would be very chaotic.

ID-names will be used for everything that is a clearly different block. So stone will use minecraft:stone, andesite will use minecraft:andesite, similar to the block models. Block states will be used for everything that is not clearly a different block (log that is orientated on different axes, furnaces/pumpkins with different facings, slabs on the upper/lower part of a block, redstone with different power, different tunes of a note block).

Flowerpots are currently one id with a block-entity and they might be separated but that is still uncertain according to an unofficial list called "the flattening" (see also: MC-105922). And they used a block entity for a very long time, because we have 13 different types of things that can be placed inside a flowerpot where minecraft:red_flower has 9 different subtypes and minecraft:sapling has 6 different subtypes. I don't know how much that influences the performance but I'm quite sure, that using a block-state/separate id would speed that up a little bit (especially if you have a lot of flowerpots). In my opinion some kind of dynamic block state (that allows everything as input-argument, that meets a certain criteria) would be very helpful for flowerpots because if you use a separate ID for each flowerpot, you would have to add a flowerpot for each flower (or any in a flowerpot-placable plant) you implement in a mod.

Wood-planks will be separated, so that each wood-type gets his own id for sapling, logs, bark (the log with only side-textures), planks, slabs and leaves (e.g: minecraft:oak_sapling, minecraft:oak_log, minecraft:oak_bark, minecraft:oak_planks, minecraft:oak_slabs and minecraft:oak_leaves).

The current json-model system uses cubes defined by two opposite vertices. But you can also define a 0-thicknes cube (which is basically a plane/ single face). I thought minecraft uses faces but as I looked into a model-file, I found out that I was wrong.

Yea I used some empty lines to add some structure to the text. The most difficult thing about long text is (in my opinion), that it takes a long time to answer, and that is sometimes a little bit annoying, because you need so much time. And I think I should suggest the dynamic-blockstate idea on reddit.

[r543]

I've read your reply yesterday but didn't get to comment on it, not that much to say and the line breaks did help 👍 .

Regarding Block States, I thought that this would be the implementation but it's not. I wonder if resource packs will get some kind of "tag" system, so you can say "canbeplaced=0/1" or if stuff can be placed in Flower Pots, takes damage, is "used" upon use and so on.

One question regarding Resource Packs, it looks like we have Schemas as well but I don't think those are implemented yet? So will it be possible to basically have our own Schemas, first replacing the existing ones, later probably adding more, later on? Another nice thing for adventure maps, or well more like custom survival and texture packs, after all I doubt a Space texture pack would have wood villages like that :P

Yeah, Cheating is only a issue in multiplayer and should be protected there. New Possiblities > Ability to cheat more. People will cheat, be that for whatever reason(does include legit ones at times), and I'd say that we should leave that up to each person by themselves on how they want to play the game, or as you could say "As long as they get to enjoy the game in some way". Multiplayer is a different story of course, and there it makes sense that the Server Owner controls what's possible.

Thought that the Mod Support was scrapped and that MCpatcher would be our best hope regarding Resource(back then Texture) Pack customization, Mojang then started with Resource Packs "out of nowhere" and did a really good job, minus them stopping later and not doing stuff against hardcoded colors(Swamplands for example or Leather Armor, the former is why I finally got around reporting a Optifine issue now, the issue that initially got me here) Like how Resource Packs are going, maybe one day we'll also have different items on base of one.

Having Mod Independant stuff is always great(plenty of Optifine stuff should honestly be in the game already, heard that there was once a deal but Mojang sadly didn't want to port over everything). I see, I thought the numeric ID's were kept for Legacy Support but from what I've heard from Dinnerbone it looks like we'll have a few things "break" but so that we'll never have to worry about breaking stuff again.

I see, regarding the "many blocks" issue, I think I figured out what it was, Shulker Boxes all being a mix of Block and Entity, and lots of Entities(Item Frames for example, Chests might be as well?) around would cause lag and is generally unoptimized. Regarding Block States, nice, I wasn't sure if such a wood log exists, hope those as well as Mushroom Blocks get obtainable in Survival(I mean all the variations of Mushroom Blocks) one day.

Been working a bit with MC 3d models in the past week so I was a bit surprised when I heard that and was wondering if all those would be outdated soon, yeah faces work that way, although to keep most of things in style, I'm building them in "blocky" ways as well.

Yeah, it does take time to answer, I don't think reading through it is really that much of a issue, alright, thanks for all this, been nice to read.

[SetantaLP]

Placing and block states is a server-side thing, so there won't be a way to influence that with a resourcepack. The only thing that you can do in a resourcepack is react on available tags (e.g. the tags "damage" and "damaged" that work together with "overrides" for items that can have damage.)

What do you mean by schemas?

Yea, but as a server owner you can't control everything, e.g. the usage of x-ray resourcepacks, which give you an advantage when you are searching ores. But yea it is possible to detect if someone has more ores than usual, so cheating is limited.

The colors are a little bit tricky but I think, that there will be a way to change the colors. "Different items based on one" is partially possible with the "overrides"-tag for item-models, but I don't think there will be more ways to change the model (maybe except from using nbt-data), because there will be a way to simply add new Items. I don't know when, but It's only a matter of time. And I think that will be done with some json-files (and probably additional classes if the item should be able to do special things) on the server and the same files (plus the model-data and the texture), so more ways to change that via a resourcepack would not really make sense. It can be done so simple because an Item (and also a block) is nothing more than an instance of a specific class (often ItemBlock (in case of Block-Items) and Item (in case of normal Items)), which is connected to the ID via a map.

Numeric ID's are deprecated (marked as "out of date and might be removed in the future") since 1.8 (which was released in 2014) and (except form the subids) only available for tools that directly access the code (mods and plugins), so there is no reason to keep them and normal things should not break because the numeric IDs are removed. The reason why these things will break is because some of the names will change and some blocks will be split up into separate blocks (which is planned since 14w27a, according to the History-section in the model-article. Okay, the block-ids won't disappear completely for the beginning because they are needed for map-conversion (I think there will be a mapping between the old ids and the new block states in the converter, similar to the mapping that will be part of every chunk) and the old names will also be kept at some place for inventory-conversion. But they won't be usable outside the converter.

The problem is, that you can't simply replace every block that is rendered as entity by a normally rendered block, even with the new ID-System. Removing the block-entity rendering from a flowerpot or an itemframe might work because these are static blocks so you place a flower in a flower pot or an item in an itemframe and it will stay there until you take it back or break the block. But removing the entity rendering from a chest or a shulkerbox won't work, because these are blocks that change their appearance many times between in the moment you open them and the moment they are open, so every time you (or any other player) opens it, the server has to notify the client that it should update the blockstate and that would require to rebuild the whole chunk-model, so it's a really bad idea. So at least for the animated part it is required that you use an entity (like for a piston), because it can be simply rotated around or moved along an axis. And besides that, blocks like chest or item frames require a block-entity because they need to store additional data, but like you can see it on furnaces not all block-entities are used for rendering. The problem of entity-rendering is, that every entity is rendered separately, because it can be moved independent from each other. Blocks in contrast are not rendered separately, because they are part of a chunk and static, so if a chunk should be rendered the engine creates one big model for the whole chunk based on the models of the blocks used in this chunk.

And yea these logs exist, but they were only obtainable via setblock and world-edit commands and not used in vanilla minecraft, which probably lead to the decision to not implement them as items. And the variations of mushroom blocks were obtainable as items until 1.7.10 but in 1.8 they were removed for an unknown reason (probably because of the newly introduced blockstates).

As far as I know there are no plans to change the model-system (except from some minor changes to the names and probably the introduction of some additional tags). And besides that, building non blocky models is quite difficult because that would require a lot of faces and rotations and textures and stuff.

Oh yea, answering takes a lot of time but it's also quite interesting. So thanks for answering.

[r543]

Sorry that I didn't get to this until now, did see it a few days ago but couldn't reply back then. I see, yeah, that's sadly the limit of resource packs, unless we do that with the data based ones like recipes?

Schemas exist in the MC folder, they're basically the structures like Dungeons, Fortresses, Igloos and all that.

Yeah, I remember Xray packs and just wanting to do one for SP out for fun/to see if it actaully works, do prefer to get my ores legit and explore, maybe it was to see how common diamonds really are., afaik that wouldn't fully work out but with Specator Mode and the Culling option that's now possible. Client Mods for Xray always existed, not much we can do against that and that shouldn't be our worry, let's just let people play the way they want to, if they want to "ruin" their game experience they can do that. Luck, Dungeon/Mineshaft Loot and other things can add to that, so detecting it that way would just be a bit counterintuitive and I feel it would be too hellbent on "anti cheating", however you probably just said this regarding methods against it.

Hope we get color support, sadly currently broken and seems to be a bit difficult to implement again in Optifine. Overrides tag? And with that I meant further modified items, like changing a bow to shoot automatically, maybe use something else as ammo and so on, might work and would more be something that goes into server data packs. A way to add new items would be good through, would be the best but Resource Packs are the next best until then. Yeah, I do think that such a implementation would be good, the part that worries me through is that Mojang might not implement something like that for now, or at least not for a good while, but who knows. First it would be best to have full customization in Resource Packs, then that can be done I guess.

Alright I see, wasn't sure if they were kept for legacy maps. I see, nice that we have mapping like that, would most likely also be used if we have crossplay with the other versions one day, but I kinda doubt that this will happen, at least not until Microsoft changes or someone else owns Minecraft.

I understand, entities for anything that's animated in special ways/actually "moves" so to say, while blocks don't have block animation outside of textures? Maybe what was meant was all the Shulker Boxes having a separate ID instead of SubID but I'm not sure and we'll see how it is in the end, do think that performance will get a bit optimized even if it has a long way to go compared to Optifine. Do understand that(each entity being rendnered separetely), regarding blocks, it would only rendner the surface and of multiple blocks? or one big model that works, said model gets altered on mining? Or is it that the geometry for each block(the model) gets copied over due to being the same and then stored as a full model once the chunk is loaded?

Were they really obtainable in Survival? Hope we can get those Mushroom blocks as well.

No need to change blocks and the blocky look is alright ;) that was just a comment to the misunderstanding when you thought that the model system would change soon.

Alright, thanks for replying and your patience with waiting.

[SetantaLP]

The data-stuff is also server side (no matter if it's a normal server or just the internal single-player server), so you can't change that with a normal resource pack (which is entirely client side, so it only changes the appearance, which makes cheating more difficult). Maybe there will be some kind of mixed pack (like mods currently do) if it comes to custom blocks/item/entities because their data-part is also needed on the client, but quite sure not in the next update.

Ah, you mean structure-files. These are also part of the data-packs, because they are part of the world-generation (which happens on the server), and yea they will be changeable in 1.13.

X-Ray Packs are an interesting thing. I once tested one on a server to find some more ores, but I found out that it was not very helpful, because you see all the ores, but you can't take all of them, because that would say: "Hello admins, I use X-Ray." So I decided not to use X-Ray.

I think there will be color-support in the future (because as far as I know everything should be modifiable), but I don't know what/how much has changed since the last version where color-support worked, maybe it changed in a way, that it need a complete reimplementation. Yea the ovverides-tag allows you to define a list of cases where a different model should be used. A case consist of a predicate that hold the condition (e.g. the damage (for Items with damage) or if it's cast or not (for a fishing-rod), all available tags are listed in the minecraft-wiki), and a reference to the model, that should be used when the predicate is fulfilled. So maybe there will be a tag for nbt-data, but I'm quite sure there won't be more options to customize items. Item-modifications that do more than just changing the appearance of an item have to be done on the server, which means you can't (only) use a resource-pack for that. And yea I think custom items will come. I'm quite sure that they won't come in 1.13 (because they need a lot of time to be implemented) and they probably won't come in 1.14 (because they are more a technical thing and 1.14 will definitely focus on non technical stuff.)

What do you mean by "crossplay with the other versions"? Do you mean crossplay with older versions or with other editions (like the PE/Win10 Edition).

Yep, the only animation for blocks is an animated texture, or the pseudo-animation like flowing lava/water (which is done by technical blocks, so that it sometimes causes lag). A block that really moves is not possible, because blocks are rendered together with the other blocks. I don't understand exactly how that works (the code is very complex), but as far as I understand, it works on one of the following way (depending on what info the client gets):

1. the network handler a. the network handler of the client receives a chunk creates a chunk-object, fills this object with the received data and tells the client world-instance to mark the range of this chunk for a render-update -> 2a b. the network handler of the client receives block-update-packet and tells the client-world-instance to change this block -> 2b c. the network handler of the client receives multi-block-update-packet (min 1 block, max 64 blocks per chunk), and tells the client-world-instance for every block to change this block. -> 2b 2) the client world a. the client world tells the rendering engine that this range needs a render update -> 3a b. the client world determines the chunk and then updates the block state for this specific block. ->3b 3) the rendering engine a. the rendering engine increases the range by one block for each direction by one and handles the call to the ViewFrustum, which detects which render-chunks (some kind of container for the chunk-model) are affected, and marks them as "needsUpdate". -> 4. b. based on the BlockPos Object the rendering engine determines the location, increases the range .... (see 3a) 4) In the next rendering-cycle this "marker" causes the the rendering engine to rebuild the RenderChunks either immediately during the terrain setup (if it is in a certain range (or (if optifine is installed) it's is updated by the player)) or to queue the chunk for an update during the superior cycle (which calls the terrain setup and updates the queued chunks after that.)

ID's only matter for data management and don't have an influence on the performance (only the model and how it is rendered matters), and because many things will get separate ID's (beds, wool, wood, ...) I don't think shulker-boxes will be merged into one ID. And besides that, they won't be any sub-id's only states (and I think color is not a state).

Yea the mushroom-blocks were available with silk-touch, these logs were not obtainable (and not used in vanilla)

Ah okay.

And yea thanks for waiting for my reply. It took a little bit longer, but yea also the text is a little bit longer, and it took some time to understand how the rendering works, and to find out what I have to do that Markdown shows the list in the way I want (which lead to the headlines).

[r543]

I see you replied a day ago, this time I can respond without much delay :P I meant data packs as in server side data packs just like for custom recipes.

Yeah, alright I see, how does this work out in SP through, can you toggle the data packs of a resource pack or do you set those somewhere in world settings?

I see, personally for me it was just in SP, since back then people were trying to find all sorts of glitches, like with Pistons and Sand to see Ores and all that, wouldn't really want to cheat in any multiplayer games, as for regular multiplayer survival, I wouldn't be one to do it but I don't think I'd mind too much if a few people used xrays at times, unless they just robbed everyone out of ores(which kinda happens in multiplayer over time, another reason why I rather run multiplayer with a few close friends)

Hoping to have color support soon, kinda counterintutive to allow grass colors via foilage but make the Roofed Forests and other things hardcoded later on. I wonder what changed as well @sp614x did talk about it in a different topic and how all colors seem to be decided by one value without being separated, not sure what's up now and why we can't change that color, doesn't matter to me if it temporary adjusts banner and/or sheep wool color as well(although I guess it's just banner+armor) as having that, even if not seperated, is better than nothing for now and red is supposed to give the same color on banners and armor.

I understand, already used Overrides a bit with CIT, glad to hear that CEM also supports it, even if that's currently harder to use(I do wonder why things like the Zombie Head do need to be upside down, probably just Mojang's original odd implementation?)

Yeah, for items the idea would be to use data packs to modify them that way, but in a "simplified" way for the beginning, like changing attributes. Do understand that it won't be anytime soon, did expect that, but it's still good if it sounds like that's planned.

Other Editions, sorry with Versions I meant "Bedrock/whatever the Console Version is/Java Version" so to say, confusing term. I see, would think that moving blocks are just "pushed" on the grid while falling ones are entities in that state. Did read through it, not much to say, do understand most of it, but, first due to certain terms and thinking further, and also it being late, I can't really fully say it/explain it in my own words.

I see, did think so, not sure what the original person's complaint was, maybe the fact that MC had limited IDs, but that's getting changed now from what I know.

Hope we can get those mushroom blocks legit one day(or maybe that would be a neat optifine feature to rendner that specific "full" mushroom block in a specific way)

Alright, thanks, been nice chatting with you. Think I did have trouble with wanting a list but getting headlines as well, if that's what you meant.

[SirCodalot]

I was sent here by a moderator from discord. After suggesting the same thing, the moderator told me why it hasn't been added yet. I suggested the solution of calculating the model's size and then not rendering it if it is too big, that way players won't be able to cheat with the feature but he told me that this is very difficult to do so because of the animations. I was wondering: @sp614x if I create an algorithm that can calculate the size of a model (including animations), would you use it? Because I'm more than willing to.

[JustCat80]

SetantaLP said

Local Player-Models are available as of 1.12 HD U C5

and there is some (very little) but some evidence in then documentation, so its almost like it exists, but isnt fully implemented

[AliahX]

Why is everyone concerned about cheating? You can just as easily use Xray if you want to find people (which was also made possible by optifine).

[Dracotyoshi]

uhh custom player models are in optifine how do i make a cpm?

[YkVox]

hello, after reading a few threads about this concept it seems like a lot of people are still waiting for it, any plans to implement it aside from the cheating issue ?

[ODHG1]

Hello, I hope this isn't unwanted, but I just came up with a little concept on how we could have custom player models:

In the Options, or under Skin Customization you'd have a new menu called "Skins" . In said Menu, you see the following list(with scroll bar and preview on the right) : Default (your default MC Model+Skin from Mojang) Steve (default Steve Model + Steve Skin from the Texture Pack) Alex (default Alex Model + Alex Skin from the Texture Pack)

Steve and Alex are there to help texture pack artists, those can have some good use there to quickly switch and test skins instead of using the Mojang site(which seems to not update skins if the texture file has the same name or has even further delays due to cache)

Models in Pack Order(or Alphabetical) Here is where the fun stuff starts, the custom models(which I guess could be defined in some .properties files, having their display name and model file name, maybe a tiny bit of lore text, one line or so) from the resource packs get listed, in resource pack order or Alphabetical(maybe we can also have a toggle for that but this doesn't need to be in the original implementation) In said properties file, there's also following flags: Use Default Skin (useful if you have a slightly altered model that's compatible with the default skin, like for example a smaller player model like the Child Zombies, and want to allow the player to continue using their skin) Use Default Model (useful if you have "just" a retextured skin in the pack so you don't need to have copies of the default player model, this might need a Steve/Alex toggle) The way this is supposed to work would be the following: Player Joins the Server, on join the info of the other skins gets requested and your info sent(I guess this is also how the Mojang Skin system works, your skin gets sent to the other Clients who "download" it while you "download" the other skins): If the other player(s) has/have the resource pack, your picked player model gets displayed. If the other player(s) doesn't/don't have the resource pack, your regular Skin and Model gets displayed

This is the Concept I came up with, should work in theory, not sure how difficult the implementation of the Netcode would be but I do imagine that it would work, in a way this would also be similar to the skins available in the console edition(as far as I know, every game copy does have those stored locally) working in a similar way and probably make it the easiest way to implement those than to have players download player models and animations.

Genius, but i seriously think this should be implemented in a beta, for example: Badlion client has a freeview thing that is flagged as cheating but doesn't stop people from using Badlion, you should just tag this option as "we're not responsible bla bla bla"