Time |
Nick |
Message |
00:00 |
|
v-rob joined #minetest |
00:10 |
|
SFENCE joined #minetest |
00:15 |
|
proller joined #minetest |
01:00 |
|
SFENCE joined #minetest |
01:24 |
|
smk joined #minetest |
01:49 |
|
YuGiOhJCJ joined #minetest |
01:55 |
Mantar |
hephaestus: did you set the beerchat settings in minetest.conf? "beerchat.matterbridge_url = http://127.0.0.1:4242" and "beerchat.matterbridge_token = <token_name>" like I use "LoC-token" for Land of Catastrophe |
01:56 |
Mantar |
port number on matterbridge_url should match the one in the toml. Like: |
01:56 |
Mantar |
[api.minetest] |
01:56 |
Mantar |
BindAddress="0.0.0.0:4242" |
01:56 |
Mantar |
oh wait, he's gone :/ |
01:57 |
Mantar |
somehow I got hide join/part messages enabled for this channel in my Hexchat |
02:27 |
|
proller joined #minetest |
03:19 |
|
Alias joined #minetest |
03:53 |
|
Alias joined #minetest |
03:56 |
|
AliasAlreadyTake joined #minetest |
05:00 |
|
MTDiscord joined #minetest |
05:30 |
|
SFENCE joined #minetest |
05:32 |
|
v-rob joined #minetest |
06:16 |
|
SFENCE joined #minetest |
06:42 |
|
lemonzest joined #minetest |
07:19 |
|
Trifton joined #minetest |
07:31 |
|
calcul0n joined #minetest |
07:35 |
|
illwieckz joined #minetest |
08:17 |
|
gregon joined #minetest |
08:20 |
|
tarsovbak joined #minetest |
10:08 |
|
cranez joined #minetest |
10:40 |
|
s20 joined #minetest |
10:52 |
|
Boingo joined #minetest |
11:32 |
* mtvisitor_utc8 |
reviewed the irc chat logs of 3 minetest channels. |
11:34 |
MTDiscord |
<jordan4ibanez> I like that their icon is an M |
11:36 |
* mtvisitor_utc8 |
is also looking for some good teachers from europe and usa(Continental America). |
11:37 |
MTDiscord |
<jordan4ibanez> Wait, I'm the USA |
11:37 |
MTDiscord |
<jordan4ibanez> https://tenor.com/view/ron-swanson-america-patriot-patriotic-gif-3457325 |
11:37 |
s20 |
how do you that? (* <your name>)? |
11:38 |
MTDiscord |
<jordan4ibanez> How do you name? |
11:39 |
MTDiscord |
<jordan4ibanez> My name is coming up weird on irc? |
11:40 |
s20 |
I meant mtvisitor_utc8's |
11:40 |
mtvisitor_utc8 |
i could not open the tenor.com. |
11:41 |
mtvisitor_utc8 |
s20: you could use(type) /me your action. |
11:41 |
s20 |
Ah, /me. Ty. I didn't know that existed on irc too |
11:42 |
celeron55_ |
irc invented that |
11:42 |
celeron55_ |
you're late to the party |
11:42 |
* mtvisitor_utc8 |
thank you very much. ;-) |
11:42 |
s20 |
hehe |
11:42 |
mtvisitor_utc8 |
celeron55_: good afternoon. ;-) |
11:42 |
MTDiscord |
<jordan4ibanez> Wait let me try |
11:43 |
MTDiscord |
<jordan4ibanez> /me is testing me |
11:43 |
MTDiscord |
<jordan4ibanez> test |
11:45 |
mtvisitor_utc8 |
ok, no problem. talk to you later. |
11:45 |
MTDiscord |
<jordan4ibanez> Wait I thought you wanted someone to teach you something |
11:46 |
cranezhou |
teach me programing. |
11:46 |
cranezhou |
;-) |
11:49 |
MTDiscord |
<jordan4ibanez> Okay, we'll start at the assembly and move up |
11:49 |
MTDiscord |
<jordan4ibanez> Well what language are you trying to learn? |
11:51 |
cranezhou |
jordan4ibanez:i have something else to handle currently, i will let you know later. |
11:52 |
MTDiscord |
<jordan4ibanez> I failed to teach two people an unknown programming language |
12:47 |
|
proller joined #minetest |
13:29 |
|
comrad joined #minetest |
13:29 |
|
sknebel joined #minetest |
13:29 |
|
meldrian joined #minetest |
13:30 |
|
clavi joined #minetest |
13:30 |
|
clavi joined #minetest |
13:48 |
|
meldrian joined #minetest |
13:48 |
|
comrad_ joined #minetest |
14:02 |
|
comrad joined #minetest |
14:03 |
|
meldrian joined #minetest |
14:03 |
|
meldrian joined #minetest |
14:05 |
|
clavi joined #minetest |
14:05 |
|
clavi joined #minetest |
14:12 |
|
appguru joined #minetest |
14:13 |
|
clavi joined #minetest |
14:13 |
|
clavi joined #minetest |
14:14 |
|
fling joined #minetest |
14:24 |
|
Lunatrius joined #minetest |
14:54 |
|
fling joined #minetest |
16:06 |
|
calcul0n_ joined #minetest |
16:23 |
|
definitelya_ joined #minetest |
16:29 |
|
jaca122 joined #minetest |
16:34 |
|
Yonle joined #minetest |
16:55 |
|
SFENCE joined #minetest |
17:31 |
|
bodiccea joined #minetest |
17:36 |
|
SFENCE joined #minetest |
17:52 |
|
acarrico joined #minetest |
18:13 |
|
Talkless joined #minetest |
18:31 |
|
calcul0n joined #minetest |
18:56 |
|
v-rob joined #minetest |
19:54 |
|
Desour joined #minetest |
20:17 |
Sokomine |
is there a way to check if a texture currently exists/is available? |
20:18 |
sfan5 |
from lua? not really |
20:18 |
jonadab |
Use it, and see if players report a missing texture or not ;-) |
20:20 |
MTDiscord |
<warr1024> I've run into that issue with skins mods, and the "solution" I found involves minetest.get_dir_list, and the assumption that said media will ONLY be present in a specific location inside the mod that's asking, if at all. Having the ability to list all media found from ALL mods could actually be really convenient for that sort of application, and might be worth an issue/PR. |
20:21 |
Sokomine |
hmm. "use it" was my usual approach as well, but...with combining textures it gets complicated: ERROR[Main]: generateImage(): baseimg is NULL (attempted to create texture "") |
20:21 |
MTDiscord |
<warr1024> A big problem with having to add media inside the mod is that I have to modify the mod between checkout and deployment, making updates more complex. Adding media would be better by building a side mod. Having to have that side mod both supply the skin AND call other_mod.register_media_exists(filename) could work around this, but it'd be pretty annoying to keep the code and media files in sync. |
20:21 |
Sokomine |
or ERROR[Main]: generateImagePart(): Failed to load image "" for [combine |
20:22 |
Sokomine |
warr1024: you're right - this is about skins as well |
20:23 |
Sokomine |
i can't really pinpoint the source of potential images at runtime. may be a texture from any mod that's using my mod for its npcs. and the npc can wield things. which may have become unavailable in the meantime |
20:24 |
Sokomine |
it's possible to figure out what's going on and which textures are broken, but...that's nothing a user could be expected to do |
20:24 |
sfan5 |
if it says failed to load image "" then either the logging is broken (unlikely) or you are literally trying to use an empty name |
20:25 |
MTDiscord |
<warr1024> It might be possible to detect every texture that was ever used, including inside modifiers, and for entities, particles, etc, with some pretty deep magic, given the current mod API, but that neither proves that those textures actually exist, nor detects unused textures if present. |
20:25 |
sfan5 |
you should be able to track down the latter in mod cde |
20:25 |
sfan5 |
code* |
20:25 |
MTDiscord |
<warr1024> Was it literally "" or did you just redact the content for privacy or brevity? 😄 |
20:26 |
Sokomine |
it would be really helpful if those error messages could quote the texture string that they report to be wrong. i've added debug messages in the mod for now but that's no real long-term solution |
20:28 |
Sokomine |
the report was literally "" |
20:29 |
Sokomine |
maybe i ought to rewrite that part anyway. no point in storing the texture mask in the npc data. but still... |
20:37 |
MTDiscord |
<warr1024> How sure are you that the reported string isn't actually correct, i.e. your texture is wrong because it's blank? |
20:37 |
MTDiscord |
<warr1024> I could swear I've seen non-blank strings for missing textures in the past... |
20:40 |
Sokomine |
not very. the debug output of the combined strings i've added is hopefully printed at the right time so that i see the right string...the error message doesn't tell me after all |
20:41 |
MTDiscord |
<warr1024> sfan5 asserts that it's unlikely that the logging is broken ... so it would be nice to be able to prove it one way or another (either find that the strings really ARE blank, or fix the logging to show what the strings really should have been). |
20:41 |
Sokomine |
meaning: even with a minetest.debug right before setting the texture i get many debug messages - and eventually these error messages. in some cases they include part of the combined texture string and so it's possible to find out which combined texture they belong to. this is sadly not always the case |
20:42 |
MTDiscord |
<warr1024> You can't really prove that logging function A is broken by adding a logging function B that's supposed to display the same string and show that B displays what you expect, because that doesn't preclude there being an error in the implementation or use of B, or a race condition or other intervening event that swaps out the values. |
20:43 |
MTDiscord |
<warr1024> Either way, if there's an empty string in there, something is not right. Either the mod is not right and setting an empty string, or the engine is not right and pulling an empty string out of its ass somehow. |
20:44 |
Sokomine |
that's right, that's all possible. my problem with the error message is not that it may be wrong - my problem is that it doesn't provide me with enough context |
20:44 |
MTDiscord |
<warr1024> The engine should not be pulling empty strings out of its ass, and any that are pulled out should be shoved back in |
20:45 |
MTDiscord |
<warr1024> Ah, okay. Well, I'm also sort of used to error messages not providing much context, and being expected to figure out the context myslf. It's quite possible this is a very generic component that can't tell you why a value is missing because it's used by dozens of other components and there could be hundreds of reasons. |
20:45 |
Sokomine |
*g* i don't think it's the engine that's wrong here. the textures are complex combined textures for npc - complete with wielded items and capes. and with a development world where things changed over time and might well have been broken once in the meantime |
20:45 |
MTDiscord |
<warr1024> If you can get a backtrace out of it or something, that might help |
20:47 |
Sokomine |
hm. yes. definiely sometimes a problem to get enough context. but in this case it might be enough to print out the input string that was combined. hope that at least is available somewhere? |
20:47 |
MTDiscord |
<warr1024> If you might have bad data that's persisted in a database (like mod storage or entity staticdata or something) and you don't have any kind of "self healing" logic to detect and correct those cases ... then yeah, there's no way to tell if there's even a bug in any code at all. |
20:48 |
Sokomine |
yes. i'd like to have some more help from the engine to identify those locations. "empty string" isn't particulary helpful :/ |
20:48 |
MTDiscord |
<warr1024> If you're e.g. setting the textures on an entity with set_properties, then you can read the texture strings back out with get_properties. Or you can do some black magic to intercept set_properties (like NodeCore does) and that will give you a chance to inspect the values right before they're sent to the engine. |
20:50 |
Sokomine |
i do have such a place (function called after on_activate - where the textures are set). still, there are a lot of npc standing around in my test world, and figuring out which one of these has a problem - is a problem |
20:51 |
Sokomine |
and a wielded texture going missing is something that can always happen |
20:51 |
Sokomine |
it'd help me a lot to get the entire combined string that failed. not just a "" part. because that might be anywhere |
20:54 |
|
SFENCE joined #minetest |
20:57 |
MTDiscord |
<warr1024> If you can detect that you're getting the problematic "" string at some point, then what I'd probably do then is dump as much info about the entity as I can to log, like its exact location (so you can find which one), static data, any relevant luaentity fields, etc. Usually when I do that, something interesting pops out at me in the object state that points me in a better direction. |
21:01 |
Sokomine |
hm, yes. something intresting...in a way that popped up already: kind of pointless to store that entire string there. just the cape etc. ought to be enough - and then combine it on the fly |
21:02 |
Sokomine |
still, such textures can always break. and then it's really tiresome to find out what's broken where |
21:08 |
|
ROllerozxa joined #minetest |
21:11 |
|
proller joined #minetest |
21:31 |
MTDiscord |
<luatic> The problem here is that the server does absolutely zero texture modified validation. It just passes the strings on to clients verbatim, which are then left with the errors. |
21:31 |
MTDiscord |
<luatic> texture modifier* |
21:31 |
MTDiscord |
<luatic> I suppose we could make an effort to log the offending texture string, though. |
21:32 |
MTDiscord |
<luatic> (rather than just the offending part) |
21:33 |
MTDiscord |
<luatic> You could also try to use modlib's texture modifier parser (https://github.com/appgurueu/modlib/blob/master/minetest/texmod/read.lua) to validate textures serverside (if you have an idea of which texture modifiers might be the culprit). That will give you a proper server-side stacktrace. |
21:44 |
|
appguru joined #minetest |
21:49 |
|
v-rob joined #minetest |
21:56 |
|
witsie joined #minetest |
21:56 |
Sokomine |
luatic: that would be very helpful and make identifying the offending texture (and thus fixing the problem) way easier |
22:35 |
|
proller joined #minetest |
23:27 |
|
v-rob joined #minetest |
23:32 |
|
panwolfram joined #minetest |
23:46 |
MTDiscord |
<warr1024> Using string concatenation to build texture modifier strings is an antipattern, just like building SQL statements using string concatenation. While there's no underlying "parameterization" system that can fundamentally improve that, you can at least use a library that does the string concat for you so that you only have to track down bad escaping and the like once. |