| Time |
Nick |
Message |
| 03:22 |
|
KaylebJay joined #minetest-hub |
| 03:40 |
|
calcul0n joined #minetest-hub |
| 04:34 |
|
ssieb joined #minetest-hub |
| 04:36 |
|
calcul0n joined #minetest-hub |
| 05:08 |
|
calcul0n joined #minetest-hub |
| 05:24 |
|
calcul0n joined #minetest-hub |
| 06:01 |
|
calcul0n joined #minetest-hub |
| 06:46 |
|
twoelk left #minetest-hub |
| 07:06 |
|
calcul0n joined #minetest-hub |
| 07:34 |
|
ANAND joined #minetest-hub |
| 08:18 |
|
calcul0n joined #minetest-hub |
| 08:36 |
|
ShadowNinja joined #minetest-hub |
| 09:08 |
|
Fixer joined #minetest-hub |
| 10:17 |
|
calcul0n joined #minetest-hub |
| 10:26 |
|
T4im joined #minetest-hub |
| 10:43 |
|
tomraceror joined #minetest-hub |
| 11:08 |
|
BuckarooBanzai joined #minetest-hub |
| 11:32 |
|
Fixer joined #minetest-hub |
| 11:57 |
|
calcul0n joined #minetest-hub |
| 12:32 |
|
HDMI_STECKDOSE joined #minetest-hub |
| 12:57 |
ANAND |
!title https://youtu.be/0Ca7nEMiq_U |
| 12:57 |
MinetestBot |
ANAND: MT Dev | "Bind mouse buttons" #7924 - YouTube |
| 12:58 |
ANAND |
:D |
| 15:26 |
|
tomraceror joined #minetest-hub |
| 15:40 |
|
HDMI_STECKDOSE joined #minetest-hub |
| 15:57 |
|
DS-minetest joined #minetest-hub |
| 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:16 |
|
tomraceror joined #minetest-hub |
| 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 |
|
HDMI_STECKDOSE joined #minetest-hub |
| 16:26 |
VanessaE |
so a mod could copy or generate image files in its textures dir during init? |
| 16:26 |
sfan5 |
yes |
| 16:27 |
|
Krock joined #minetest-hub |
| 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 |
| 16:58 |
|
tomraceror joined #minetest-hub |
| 17:26 |
|
jas_ joined #minetest-hub |
| 17:32 |
|
tomraceror joined #minetest-hub |
| 17:48 |
|
lumberJ joined #minetest-hub |
| 18:19 |
|
T4im joined #minetest-hub |
| 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:34 |
|
ssieb joined #minetest-hub |
| 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] <VanessaE> VE-Basic: cmd skinsdb_download_skins |
| 18:44 |
VanessaE |
<VE-Basic> 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 |
<VanessaE> 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:05 |
|
lumberJ left #minetest-hub |
| 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 |
| 19:47 |
|
Ruslan1 joined #minetest-hub |
| 20:08 |
Krock |
I wonder if I ever get through all of these notifications somewhen |
| 20:16 |
|
longerstaff13 joined #minetest-hub |
| 21:10 |
|
fluxflux joined #minetest-hub |
| 21:15 |
|
tumeninodes joined #minetest-hub |
| 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/<name of your branch> --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 |
| 22:54 |
|
Fixer joined #minetest-hub |
