Time Nick Message 12:57 ANAND !title https://youtu.be/0Ca7nEMiq_U 12:57 MinetestBot ANAND: MT Dev | "Bind mouse buttons" #7924 - YouTube 12:58 ANAND :D 16:02 VanessaE is it possible to store an image file in the world directory (by whatever means, inside or outside of Minetest), then during mod init, copy it to a suitable textures folder (Mod Security notwithstanding) and expect the server and clients to be able to use it later? 16:02 VanessaE particularly as a skin 16:02 rubenwardy not sure when resources are collected 16:03 rubenwardy could you use a bash script? 16:03 VanessaE I could, but the question is if a mod could do it and get away with ti 16:03 VanessaE it* 16:04 VanessaE I'm trying to think of a graceful solution to skinsdb having to download bplaced.net images directly to its mod textures dir. 16:04 VanessaE (see also https://github.com/minetest-mods/skinsdb/issues/31 ) 16:12 VanessaE I'm thinking images that are applied to objects only need to be on-hand when the file is requested. 16:12 VanessaE but idk. 16:18 ANAND VanessaE: There's no way to send new media to clients at runtime 16:18 VanessaE not at runtime. I mean during mod init. 16:19 ANAND Ah 16:19 sfan5 the client will only request media that the server advertises, and it will request all of it 16:19 DS-minetest there is a way, you can send pixel data and use texture modifiers 16:20 ANAND As rb said, that prolly depends on whether the media is parsed after executing init.lua or not. 16:20 VanessaE but at what point does the server decide that it has "all of it"? 16:20 sfan5 the question is here whether mod init runs before the server determining which media files to send 16:20 ANAND DS-minetest: That'd be an interesting POC :) 16:20 VanessaE can someone please investigate and document this (if it isn't already)? 16:23 DS-minetest found it 16:23 DS-minetest https://github.com/minetest/minetest/blob/05a7da627959afef2198f2036f4144e3d8abfbda/src/server.cpp#L355 16:23 DS-minetest mods are loaded first 16:26 VanessaE so a mod could copy or generate image files in its textures dir during init? 16:26 sfan5 yes 16:28 VanessaE will symlinks work? 16:28 VanessaE .minetest/worlds/blah/worldmods/foobar/foo.png -> .minetest/worlds/blah/foo.png 16:30 sfan5 probaly 16:30 VanessaE ok. 16:30 sfan5 probably*, there's no reason for the code to even check if something is a symlink 16:31 VanessaE I'm thinking in the case of Mod Security 16:31 VanessaE aside: it's too bad MT has no create-symlink function. :P 16:32 ANAND Ideally symlinks do work, but there's no guarantee 16:32 ANAND My 5+ MT instances all use the same mods and worlds folder via symlinks :D 16:34 VanessaE ok. 16:35 rubenwardy if MT had such a function it would break mod security 16:35 rubenwardy function meaning the ability for mods to create symlinks 16:36 VanessaE well, in this one instance, creating a link would only be usable with an insecure environment. 16:36 VanessaE https://github.com/minetest-mods/skinsdb/issues/31#issuecomment-533211972 16:39 VanessaE does my idea make sense 16:39 VanessaE ? 16:44 ANAND I don't see anything that actively stops that from happening (except for the mod-loading behaviour, but that has been eliminated), so I guess you could give it a shot :) 16:45 VanessaE well if bell07 wants to :P 16:46 sfan5 feedback wanted: https://github.com/minetest/minetest/pull/8959 16:50 ANAND sfan5: Interesting alternative 16:51 sfan5 to make that clear: the wear calculation is identical to the other PR 16:53 ANAND Oh ok, I assumed otherwise 18:33 Krock VanessaE: https://github.com/minetest-mods/skinsdb/issues/31#issuecomment-533240845 does it throw an error? 18:33 Krock like in: shut down the server? 18:33 Krock your wording is very unclear to me there 18:35 VanessaE the error already disappeared from my logs, but yes, it shut down the server. 18:37 VanessaE wording clarified. 18:37 VanessaE let me just try it again.... 18:38 Krock your branch seems to be outdated 18:38 Krock there was a commit that got rid of this forced shutdown 18:38 Krock https://github.com/minetest-mods/skinsdb/commit/a945db9de33 18:39 VanessaE outdated as of yesterday? 18:39 Krock master branch? 18:39 VanessaE aye. 18:39 Krock if so, please dump the error 18:40 Krock I have no plan how you're getting an error there from Minetest 18:40 VanessaE like I said, lemme just re-check it. 18:41 Krock oh sorry. no hurries :) 18:42 VanessaE strange 18:42 VanessaE now it's working. 18:42 Krock Issue Fixed By Itself 18:42 Krock !nextr 18:42 Krock !next 18:42 MinetestBot Another satisfied customer. Next! 18:42 VanessaE very funny. 18:42 VanessaE I'm not imagining it, it DID shut down with that demand... 18:42 VanessaE yesterday that is. 18:42 Krock no .conf chances in the meantime? 18:43 Krock *changes. can't spell 18:43 VanessaE nope. I even made sure to remove "skinsdb" from secure.trusted_mods just before trying it just now. 18:44 VanessaE ah I'm wrong. 18:44 VanessaE [09-19 14:44] VE-Basic: cmd skinsdb_download_skins 18:44 VanessaE Cannot run Lua Skins Updater: \n Insecure environment is required. Please add skinsdb to `secure.trusted_mods` in minetest.conf 18:44 VanessaE THAT is where I saw it 18:44 Krock lol 18:44 VanessaE I feel stupid. 18:44 Krock and you make me doubt of my well tested code 18:45 Krock glad there's nothing to fix 18:45 VanessaE let's you and I sweep those last two posts under the rug :) 18:45 VanessaE well, there still is -- see my other comments. 18:45 Krock burn it with FIRE 18:45 * VanessaE deletes her last comment from the thread 18:46 Krock yeah.. the workflow has never changed and the media was always dumped directly into the mod's directory 18:46 VanessaE yeah, this is wrong. 18:46 Krock would welcome a PR but I'm not a server owner to have an urgent need for this 18:46 Krock was always "works just fine" 18:47 VanessaE I'd make a PR but I have no knowledge of that mod's code. 18:48 Krock well, mine's also quite limited since the rewrite of bell 18:50 VanessaE well bottom line, if the above is true that a mod could copy images into its own textures dir, at init time, and have the server find them, then just as I suggested is the most appropriate solution. 18:50 VanessaE basically, act as if all mod's own folders are in a tmp filesystem, and can be deleted/rebuilt from scratch between restarts. 18:51 Krock thing is, the http API is based on callbacks, hence it'll finish only seconds after initializing everything 18:51 VanessaE that's okay 18:51 VanessaE you still have to reboot the server to get the new images into place anyway, even in the current setup 18:52 VanessaE says so in the readme :P 18:52 Krock yes, and with Minetest mods there's no workaround 18:52 VanessaE no 18:52 VanessaE I just told the workaround 18:52 Krock still needs a reboot 18:52 VanessaE that's okay. 18:52 VanessaE a reboot is fine. 18:52 Krock ??? 18:52 Krock reboot is fine but reboot needs a workaround?!? 18:52 VanessaE where did I say that? 18:53 Krock I just told the workaround 18:53 VanessaE sorry, ambiguous reference. :) 18:53 Krock oh 18:54 VanessaE I'm saying: downloading directly to the mod folder is not perimissable -- download to the *world* folder instead, then copy everything from there to the mod folder at the next startup, then since a copy of that kind would block until finished, Minetest will find the images (and meta) after the init stage is done. 18:56 VanessaE a reboot is still needed, but this way the master cache of images is out of reach of the script that rebuilds the mod tree every morning (I do that as an anti-malware act, and as a "let's just make sure everything is juuuuuust right" measure) 18:56 VanessaE think of it like reverting the whole mod tree to a snapshot every morning. 18:57 VanessaE ...and I should think you could speed up the copy-at-startup process if you check for the presence of an image in the target before copying, like manually implementing rsync 18:58 VanessaE that way routine server crashes/restarts other than the main daily one don't impose a potentially big startup penalty 19:00 Krock so you don't want to whitelist the textures/meta directories upon rebuild? 19:01 VanessaE eh? 19:01 Krock > this way the master cache of images is out of reach of the script that rebuilds the mod tree every morning 19:02 VanessaE yeah, 19:02 VanessaE s/the script/the part of the script/ 19:02 VanessaE there's another independent section of that script that handles skins 19:03 VanessaE (it's used with player_textures - the idea was to adapt that section to work with skinsdb) 19:14 VanessaE on another note, how does the private skins feature work? the readme implies I could just treat it like player_textures, and copy player_foo.png into the textures dir, but that didn't work (my skin, for example, did not apply). Is a preview file needed? 19:15 Krock it needs a meta file, IIRC 19:15 VanessaE blah 19:15 VanessaE that's excessive for private skins 19:16 Krock not if you can browse them 19:16 VanessaE then the mod should autogenerate preview images. 19:16 VanessaE it already has code to get the image resolution, so it would just be a bunch of [combine operations and maths. 19:17 Krock then it will need libpng, insecure env, or imagemagick, with insecure env 19:17 VanessaE why would it need that? 19:17 Krock bleh combine 19:17 Krock what about larger resolutions 19:18 VanessaE like I said, the mod already has code to read the resolution. if you know the resolution, the [combine coords are just math after that 19:19 VanessaE i.e. w*something, h*something_else gets you to, say, the upper left corner of the left arm front, etc... 19:21 VanessaE as long as something/something_else are proportions of the width and height, they'll always point to the right location, no matter what the image size is. 19:25 VanessaE like 0.5 times height (in a 1.0 skin) will always put you in the area where the body, arms, and legs are found, 0.828125 times width would get you to the left edge of the front of the left arm (so the two together would be the top left pixel of the left arm front) 19:25 VanessaE (that's (53,21) in a standard 64x32 px skin) 19:26 VanessaE (er, (52,20) ) 19:26 VanessaE you get it? 19:26 Krock yes, I wasn't aware the resolution is already known 19:26 VanessaE ok :) 19:27 VanessaE yeah, there's a function in one of the files that reads the resolution, uses it to decide 1.0 vs 1.8 skin format 19:27 sfan5 Krock: btw your wieldhand PR does not compile 19:27 VanessaE (I forget where, only noticed it while trying to work out the private skins thing) 19:27 sfan5 wait nvm 19:27 sfan5 thats my fault 19:28 Krock 9 travis jobs confirm that 20:08 Krock I wonder if I ever get through all of these notifications somewhen 21:16 tumeninodes sfan5: where do I add S() when rebasing? 21:16 sfan5 description = S("Steel Door or whatever the name was") 21:17 tumeninodes ohhhh, so within the code then 21:57 tumeninodes doh, I just hit enter with an incorrect command and borked the rebase and will have to close that PR and do a new one. But, I will only redo it if it is likely to be merged. paramat wants then reg in xpanes to avoid a soft dep on xpanes, but then xpanes will have a soft dep on doors. I prefer these steel bar doors to reside within the doors mod with a soft xpanes dep but input from other devs would be nice. 21:57 tumeninodes if it won;t be merged I'd like to know so I can release them as a 3rd party mod instead, and perhaps with some other types of barred doors to go along with them 21:58 sfan5 you can always reset the git state so that you don't need a new PR 21:58 tumeninodes such as iron bar doors and even rusted bar doors (n such) 21:58 sfan5 I'd prefer them to be registered in xpanes 21:58 tumeninodes reset? that would be nice 21:59 sfan5 git rebase --abort ; git reset origin/ --hard 21:59 sfan5 will lose your changes obviously 21:59 tumeninodes well if two devs are agreeing on xpanes reg I will do that. 22:00 tumeninodes ahhhh, so backup the changes and textures before a reset then... got it. Thank you I'll give that a try