How to cutomize your minetest skin without downloads

Skins should be server side, but the ability to add new skins without restart would be good. You could then make a website to allow uploading of skins, and then a moderator could approve them. WSDguy The point nerzhul is trying to drive is that people will try to use nude skins, and simply making the rule 'no nude skins' isn't going to do much about people who deliberately break the rules.

Fortunately, in the small space that I can draw my skin in, it's hard to draw offensive or obscene things. Unless high resolution skins are allowed. Also, it's hard, but not impossible. This could be why Minecraft doesn't allow people to have high-definition skins. At least, as far as I can know. If several thousand people wanted to update their skins, the moderator would have a lot of work to do.

The moderator will be the server owner, just like currently. And it's unlikely that several thousand people would want to do that. Which has the advantage of showing your skin to you in singleplayer. But I suppose this fixes the problem with having different skins for different subgames.

Apart from the ability to load new skins on the fly I don't see much that the engine needs to do here. Even if there was a central skin server I probably wouldn't use it. Wasn't this already implemented? I mean, the ability to load custom skins. Not the "reload on the fly" which is not really the focus of the original request.

Though the request seems to imply that the skin should be provided client-side. I'm leaning towards won't add on this, skins should be specified on a website. There could be a centralized but optional gravitar style interface for this. Perhaps skins could be placed on a media server, then people only need reconnect or download the new file to get the new skin.

Maybe, but skins are one thing for which I am a firm believer in client-provided data. Although I'd be happy for an official API for server-provided skins, the feature simply would not be complete without the ability for clients to provide their own skins. One could simply have a configuration option to disable client sending skins on the server-side. And seriously, if you're worried about inappropriate skins, throughout the 2 years I played MC, I never ever saw someone using an inappropriate skin, unless you consider a skin that's all skin-colour with no detail inappropriate.

For that matter, you can't create a particularly inappropriate skin with such a small canvas. The few inappropriate skins that did pop up, could easily be dealt with by simply banning the player, or providing an API to force a specific server-provided skin for a specific player.

I really hope this is considered, although I'll be happy with better skins, either way, no support for client-provided skins just wouldn't be right. This seems like an abuse to me, just use SSM to select a skin. Shouldn't this be doable already without any new Lua API? I can see this being useful for other things as well. Kind of a simplified version of It doesn't need to be synchronous. Were you planning to implement the skin list synchronously?

CSM can consult local table as a single consumer to list model and so something with them. Maybe I misunderstood when you said "synchronize". Though I fail to see how it's any different when it's a list of skins and not a generic list. If sending a lua table means "synchronizing" a lua table, then sending a list of skins means "synchronizing" the list of skins as well. It's so much simpler just to keep things where they belong.

If you do skin selection server side, all you'd need to do is add the ability to add new textures at run time minetest.

Also, skin selection should be a MTG feature not an engine feature. Different subgames may want different skin selection mechanism, eg: character creator other a skin maker, so it is subgame specific. However, core support is needed for new textures at runtime. It cannot be altered later, there is no runtime addition for those textures.

Only one packet is sufficient to manage the skins list client see, see the player list packet it's a similar packet. I'm in favour having correct communication between server and client instead of bullshit generic interfaces uncontrolled. Skin selection should be an engine flavour, maybe with a setting sent to client to permit seing the CSM formspec. So if there's no runtime addition of textures, what even is the point of moving things client side?

It doesn't solve any issues here at all. Otherwise HTTP would have been an overly complex protocol bloated with way too many little verbs for very particular and use-case specific functionality, ever-growing interface, very uncomfortable to maintain, imho. XMLHttpRequest is a browser generic interface because browser doesn't know apps. What do you mean? Obviously javascript runs in a sandbox, as CSM should, imho.

CSM should not be allowed to do things like cross-server requests or any sort of manipulation in the client filesystem except maybe inside a protected directory, if at all. Or anything that could be a potential threat. Otherwise no matter if you have generic methods or not, there will be ways to exploit it or bugs in any of the multiple use-case specific implementations you are gonna have to keep safe and check for exploits every time there's a change on any of them.

CSM will not do cross server request, i never said that, CSM in the future can publish over mod channels some messages like a websocket event communication , but it's out of the current issue subject. I know CSM is not currently allowed to do cross-server, I was just saying that it should be like javascript that can do generic requests just as long as they are not cross-server well..

And that javascript is still safe as long as it's sandboxed, and even if it's sandboxed it is indeed very powerful. So I think it's a good idea for CSM to follow the example. Otherwise, CSM is gonna become very complex, if you really want to add a specific new packet and additional engine logic for every little thing requiring communication that comes to the mind, things that even not everyone might want to use. Is MT engine really a game? I though the idea was to be a game engine. You can also get the latest development version of Minetest from builds made by community members.

These builds are more recent than the officially released builds and contain new features at the cost of stability. Alternatively, download the APK. Note: We advise not to use unofficial builds commonly found on the Play Store. They may contain excessive advertisements or spyware, or be distributed under proprietary terms. On FreeBSD 9. Get the latest stable or development source code from GitHub. You will probably want Minetest Game as well.

Put the game in your games directory. Downloads Getting started Are you a new user? Windows Works on Windows 8, 8. Minetest 5. Android Android 4.