![]() Automatically detect vanilla parts so the process is opaque for the user. Embed base64 encoded skin parts in json files when saving.For windows users, the gzip format is also inconvenient, as they lack the default software to open gz files. Encoding/decoding gzip with zlib seems like a hassle so I didn't try.Base64 encoding adds around 33% overhead to the skin container file size, but it's easier to integrate as we already have json skin files.We would need to add a zip library dependency then, do you have one in mind? It would help with skin sharing though, I agree on that.īut the simplicity of just sharing a. We would have to make a skin editor, which would only add steps to skin creation. Similar to our maps, where we put the json(actual skin) and "external" skin parts used by that skin. For skins that use custom skin parts, we could add some kinda container. If you want to provide a skin, like in 0.6 times, you can provide the json when using standard parts. If you just want to share skin parts, providing the png's is already the simplest way. We could alleviate this issue by generating a hash from the part's pixel data, and name it that. Now if you mean that a specific part could be at a different location (and thus get a different name), but is the same as another part elsewhere, we had that problem before as well. If the image name is, let's say oy.png as an example, each part could be named oy_body1.png, oy_body2.png, oy_eyes1.png, etc. Well, that's not a simple task, every skin part has to provide a name so other players can see/use them. Once such a file is loaded, we could create a default skin combination using the first line of each item (this would help users test/equip their skins quicker).The file can have an X amount of lines (like a table).This should be relatively simple to implement, and help with the issue of 0.7 skin sharing. That way a file can only be composed of body, decoration, marking, for example. The file can omit columns starting from the end. I propose we implement a secondary way of loading skin parts, all in one file.Ĭolumns represent the different body parts : body, decoration, marking, eyes, feet, hands, in that exact order. One has to make and share several pngs and perhaps jsons, whereas before a simple png image would suffice. We gained deeper customisation with the new system but lost the ability to quickly share skin files. I was excited to download new 0.7 skins, and. The other day, published their new website for sharing teeworlds tee skins. ![]() This was a good decision I think, and most players love it. :-/Īs a mid term solution I think ill implement a questionbox to ask the uploader if he really want to upload a potential duplicate.0.7 introduced a new skin system, separating each body part to allow deeper customisation by combining them. The big companies may have one or working on one, but they probably wont share it for free. The best would probably be a AI that sees the difference of the eyecolor, but does not see the fragments caused by compression. īut sadly there are a lot of false positives e.g. Some have just a different eye color, but they look the same for the algorithm e.g. Some are actually duplicates (from human view and from algorithms view) e.g. I played around with but the result is *meh* : I reported the expired certificate, it will be fixed (some day).ī is a free php webhoster, that does not allow to install additional software. You can then compare the hash value with the values of the existing skins.Ĭonverting the image from png to pnm is needed to detect duplicates which have a different compression ratio. When a skin was uploaded, use pngtopnm to get a pnm image file, then use md5sum on the file to get a hash value. You could automatically detect duplicates: Hybrid Dog wrote:The link in helpfiles/about.html is broken: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |