| Time |
Nick |
Message |
| 00:00 |
erlehmann |
MisterE ok. but if i can not contribute stuff to it that has been useful to debug things, i'll just treat it as if it was. |
| 00:02 |
erlehmann |
(i.e. if i get this merged, i make more devtest stuff. if not, i do not.) |
| 00:09 |
rubenwardy |
Has been doesn't mean will be |
| 00:10 |
rubenwardy |
Just pointing out the flaw in that logic, I haven't actually looked into that PR |
| 00:10 |
|
v-rob joined #minetest-dev |
| 00:23 |
|
AliasAlreadyTake joined #minetest-dev |
| 00:34 |
erlehmann |
rubenwardy if you have any questions about my PR, pls ask. the only improvement i could think of right now is actually generating the textures in the engine and that would mean a) consolidating all the tga_encoder mod variants into one that can do all kinds of textures b) convincing ppl it is a good idea (which i'd like to avoid rn) |
| 00:35 |
erlehmann |
s/in the engine/in devtest/g |
| 00:46 |
MTDiscord |
<LandarVargan> Is it possible for updateAnimation() to get called twice here? https://github.com/minetest/minetest/blob/be05c9022d8b6eff63f477bc8ca52efd7d631cb6/src/client/content_cao.cpp#L1070-L1088 |
| 00:48 |
MTDiscord |
<LandarVargan> Ah I guess not |
| 00:53 |
MTDiscord |
<LandarVargan> I think I'm having an issue with updateAnimation() not being called because I force set a non-local animation but still trigger the local animation in the background, and keep triggering it until after my alien animation finishes, so things like frame_loop persist across and mess the local animation up |
| 00:53 |
MTDiscord |
<LandarVargan> Relevant(?) c++: https://github.com/minetest/minetest/blob/be05c9022d8b6eff63f477bc8ca52efd7d631cb6/src/client/content_cao.cpp#L1070-L1088 |
| 00:54 |
MTDiscord |
<Jonathon> just set the local animations to empty tables to use only serverside ones |
| 00:54 |
MTDiscord |
<LandarVargan> This is what I mean by 'force-set' https://github.com/minetest/minetest_game/blob/a840ac0a4d3db935b20ce6c6259795fbe263fefe/mods/player_api/api.lua#L134-L135 |
| 00:54 |
MTDiscord |
<LandarVargan> It would be nice if I could switch between serverside and local animations |
| 00:55 |
MTDiscord |
<Jonathon> i really dont see why you need local ones at all given how limiting they are |
| 00:56 |
MTDiscord |
<LandarVargan> No clientside delay when playing animations that do fit the local limits |
| 00:56 |
MTDiscord |
<Jonathon> i mean, you could switch back and forth by disabling and enabling them, but thats a massive hack |
| 00:57 |
MTDiscord |
<LandarVargan> That is what I am doing, and it has a problem as described above |
| 00:57 |
MTDiscord |
<Jonathon> personally i dont think animations client side is that big of a deal given everything there reacting to is serverside anyways, but ? |
| 00:58 |
|
v-rob joined #minetest-dev |
| 01:05 |
erlehmann |
Jonathon having some stuff predicted clientside is a massive boon to ppl playing with lag. game authors often underestimate how playable minetest can be under lag conditions if a game gets a few things right. |
| 01:06 |
erlehmann |
(this is btw why i want nodes with associated formspecs in the meta, and i believe wuzzy mentioned those as well once) |
| 01:08 |
MTDiscord |
<Jonathon> formspec meta can burn in its current implementation |
| 01:08 |
MTDiscord |
<Jonathon> formspecs in the node def would be a much better idea |
| 01:11 |
erlehmann |
oh yeah sorry |
| 01:11 |
erlehmann |
node def |
| 01:12 |
erlehmann |
i have been making formspec meta stuff and it sucks |
| 01:13 |
MTDiscord |
<MisterE> Well, the node def can't change, and I think that some nodes need formspecs to be able to change |
| 01:13 |
MTDiscord |
<Jonathon> yes, a node def can change |
| 01:13 |
MTDiscord |
<MisterE> For all nodes |
| 01:14 |
MTDiscord |
<Jonathon> there still is show_formspec, and formspec in node def is way better than meta trash because you dont have to waste abm/lbm overhead to update it |
| 01:14 |
MTDiscord |
<MisterE> But if I need one store node to change its formspec, while all the other remain the same id need a workaround.with your implementation |
| 01:15 |
MTDiscord |
<MisterE> Also theres node time |
| 01:15 |
erlehmann |
to give a real life example: in mineclonia we had some chests and ideally they should not be able to open if something blocks the top. |
| 01:16 |
erlehmann |
if i could just switch chest for chest_blocked and not do meta stuff, i'd be happier |
| 01:16 |
erlehmann |
especially since those formspecs sometimes need updating |
| 01:16 |
MTDiscord |
<MisterE> You could... but meta makes the most sense |
| 01:16 |
MTDiscord |
<Jonathon> swapping the node is terrible, but yeah, formspec meta updating is terible |
| 01:16 |
MTDiscord |
<MisterE> Ibk why |
| 01:17 |
MTDiscord |
<MisterE> Node meta is a reasonable system |
| 01:17 |
MTDiscord |
<Jonathon> no, it doesnt, given its trash to update, trash to handle recieve fields, etc |
| 01:17 |
erlehmann |
you can end up with crap meta. we had chests of those types that were not opening anymore because some fun-hater removed the meta. |
| 01:17 |
MTDiscord |
<MisterE> Check your meta |
| 01:17 |
erlehmann |
also everything involving swap_node becomes weird |
| 01:18 |
erlehmann |
like i have made water with inventory |
| 01:18 |
MTDiscord |
<Jonathon> node meta concept is fine, using it for formspecs is terrible |
| 01:18 |
MTDiscord |
<Jonathon> sounds like you cant read documentation erlehmann |
| 01:18 |
MTDiscord |
<MisterE> You enjoy saying this type o thing :P |
| 01:18 |
MTDiscord |
<Jonathon> * `minetest.swap_node(pos, node)` * Set node at position, but don't remove metadata |
| 01:18 |
erlehmann |
that's exactly what i'm getting at |
| 01:19 |
MTDiscord |
<Jonathon> yeah, you cant read |
| 01:19 |
erlehmann |
i read that and this is how i made water with inventory |
| 01:19 |
MTDiscord |
<Jonathon> great, then stop complaining |
| 01:19 |
erlehmann |
i think your mistake is assuming i made it in my own mod or something |
| 01:20 |
MTDiscord |
<Jonathon> "also everything involving swap_node becomes weird" && "like i have made water with inventory" sounds like complaints |
| 01:20 |
erlehmann |
also stop being rude pls |
| 01:20 |
erlehmann |
the thing is that if i had formspec in node def, i could do swapping without thinking of meta formspecs |
| 01:21 |
erlehmann |
also, just to spell it out: corrupting metadata leads to fun stuff, of which most of it is crashes or dupes |
| 01:21 |
MTDiscord |
<Jonathon> sounds like misbehaving mods, which really isnt mte fault |
| 01:21 |
MTDiscord |
<MisterE> That sounds like its time to fork the mod then :| |
| 01:22 |
erlehmann |
MisterE i may have already done so ^^ |
| 01:22 |
MTDiscord |
<Jonathon> also, this is really #minetest content |
| 01:22 |
erlehmann |
look, this is about formspec in node def. |
| 01:22 |
erlehmann |
which is an engine thing, bc it does not yet exist, right? |
| 01:22 |
MTDiscord |
<Jonathon> if where back on topic, than yeah |
| 01:23 |
erlehmann |
yeah let's do topic instead of going the “oh all the mods you manage to glitch are crap” |
| 01:23 |
erlehmann |
so what drawbacks would it have to switch nodes? you said that |
| 01:23 |
erlehmann |
i mean it's super easy |
| 01:23 |
erlehmann |
but how is it terrible |
| 01:23 |
MTDiscord |
<Jonathon> anyways, node def based formspecs are in sfan 5 todo |
| 01:23 |
erlehmann |
good! |
| 01:23 |
MTDiscord |
<Jonathon> or so they have said |
| 01:23 |
erlehmann |
i'll just wait and shut up then |
| 01:24 |
erlehmann |
good night |
| 01:24 |
MTDiscord |
<Jonathon> niht |
| 01:24 |
MTDiscord |
<Jonathon> *night |
| 01:56 |
|
Yad joined #minetest-dev |
| 02:30 |
|
Noisytoot joined #minetest-dev |
| 03:28 |
|
queria joined #minetest-dev |
| 03:33 |
|
queria joined #minetest-dev |
| 04:54 |
|
v-rob joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 07:01 |
|
v-rob joined #minetest-dev |
| 07:09 |
|
tekakutli joined #minetest-dev |
| 07:28 |
|
calcul0n joined #minetest-dev |
| 08:12 |
|
appguru joined #minetest-dev |
| 08:17 |
|
v-rob joined #minetest-dev |
| 08:29 |
MTDiscord |
<luatic> please reopen #11694 |
| 08:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/11694 -- View bobbing breaks get_look_dir while walking |
| 08:34 |
erlehmann |
oof this should really have been separate commits, whoever squashed this? o.0 https://github.com/minetest/minetest/commit/0d345dc1bd56068b8d40f8ff712a9263c6ff7517 |
| 08:35 |
erlehmann |
well, doesn't matter who |
| 08:35 |
erlehmann |
but oof |
| 08:37 |
MTDiscord |
<luatic> Why separate commits? It's a single, simple fix. |
| 08:37 |
MTDiscord |
<luatic> ah, you mean the cleanup |
| 08:37 |
erlehmann |
because you have 1 line of fix and like >90% of distracting dead code removal |
| 08:38 |
MTDiscord |
<luatic> True |
| 08:38 |
erlehmann |
ok i saw it, it originally was 2 commits. squash merge is trash again. |
| 08:38 |
erlehmann |
not your fault ig, sorry for bringing it up |
| 09:34 |
rubenwardy |
Luatic: don't include "fixes #“ if it doesn't fix it, even if prefixed by partially, because GitHub will still close it |
| 09:34 |
MTDiscord |
<luatic> oh |
| 09:39 |
erlehmann |
gitea has the same thing and it can be disabled |
| 09:39 |
erlehmann |
i strongly suggest to disable it wherever i see it, bc i have seen too many issues closed accidentally |
| 10:11 |
rubenwardy |
nah, it's super useful |
| 10:11 |
rubenwardy |
just need to take care to check the issues |
| 10:12 |
erlehmann |
oh, i think it can't be disabled anyway |
| 10:13 |
|
calcul0n joined #minetest-dev |
| 10:13 |
erlehmann |
also “note that this commit does not fix #1234” commit messages, cursed |
| 10:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/1234 -- Client side caching of mapblocks |
| 10:19 |
rubenwardy |
Try "Partial fix for #1234" in future |
| 10:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/1234 -- Client side caching of mapblocks |
| 10:19 |
rubenwardy |
or "Part of #1234" |
| 10:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/1234 -- Client side caching of mapblocks |
| 10:28 |
|
calcul0n joined #minetest-dev |
| 10:36 |
|
HuguesRoss joined #minetest-dev |
| 10:57 |
|
calcul0n joined #minetest-dev |
| 11:30 |
|
proller joined #minetest-dev |
| 13:31 |
|
Baytuch_2 joined #minetest-dev |
| 15:00 |
|
hallowarniemalsh joined #minetest-dev |
| 15:02 |
hallowarniemalsh |
does anyone know an easy way to detect block/node updates? (For a node to change if the conditions are given, register_abm is too slow for me) |
| 15:05 |
|
hallowarniemalsh left #minetest-dev |
| 15:31 |
|
erlehmann joined #minetest-dev |
| 15:44 |
|
olliy joined #minetest-dev |
| 15:55 |
|
Fixer joined #minetest-dev |
| 16:16 |
MTDiscord |
<exe_virus> Rubenwardy has brought up the need for a markdown parsing ability to be brought to minetest engine to support CDB in the main menu, and for general in game documentation. I'm looking at a performant C library with a single header and c source file. If I do all the work to integrate this into MTE so that the main menu and in game lua API can call a single function: parse_markdown(string, table_of_function_callbacks) which returns a |
| 16:16 |
MTDiscord |
valid hypertext element body string for a formspec to render, does that have a decent likelihood of getting merged? |
| 16:21 |
|
tekakutli left #minetest-dev |
| 16:22 |
|
tekakutli joined #minetest-dev |
| 16:42 |
|
Taoki joined #minetest-dev |
| 16:43 |
Calinou |
#JustMinetestThings :( |
| 16:46 |
rubenwardy |
I'd support such a PR |
| 17:12 |
|
Taoki joined #minetest-dev |
| 17:31 |
|
v-rob joined #minetest-dev |
| 17:32 |
|
Taoki joined #minetest-dev |
| 17:44 |
MTDiscord |
<exe_virus> V-Rob or v-rob, would you also support such a PR? |
| 17:46 |
erlehmann |
exe_virus why a c library when you could write it in lua and not risk that much additional attack surface? |
| 17:47 |
rubenwardy |
because you'd have to write it |
| 17:47 |
erlehmann |
i am talking out of my ass here obv, but i am pretty sune pure lua markdown parsing libraries exist |
| 17:48 |
rubenwardy |
with lots of deps and... C code |
| 17:49 |
rubenwardy |
lpeg, for example, has C code |
| 17:49 |
erlehmann |
i will now figure out which deps this have that i do not see https://github.com/mpeterv/markdown |
| 17:50 |
rubenwardy |
only supports outputting to HTML |
| 17:50 |
erlehmann |
uh, markdown in general is a search-replace to html. it does not have an AST. |
| 17:50 |
rubenwardy |
you could modify that though |
| 17:51 |
erlehmann |
it's only about 1200 lines, i bet that's manageable |
| 17:51 |
rubenwardy |
well, something to look into exe_virus |
| 17:51 |
rubenwardy |
I personally haven't looked at the options |
| 17:51 |
erlehmann |
> Does a simple tokenization of html data. Returns the data as a list of tokens. Each token is a table with a type field (which is either "tag" or "text") and a text field (which contains the original token data). |
| 17:52 |
erlehmann |
hey, you can turn that into whatever you want pretty easily |
| 17:52 |
rubenwardy |
that sounds good |
| 17:52 |
rubenwardy |
exe_virus: what Lua libraries did you consider? |
| 17:53 |
erlehmann |
rubenwardy i do not know exactly how you think markdown should work for your use case, but since md is defined in terms of search-replace via HTML, ig HTML is always in intermediate step btw |
| 17:53 |
rubenwardy |
yeah, I know how markdown works |
| 17:54 |
erlehmann |
yeah but maybe cdb flavored markdown is different |
| 17:54 |
erlehmann |
or should be different, i am not designing the feature after all |
| 17:54 |
erlehmann |
(you are ig) |
| 17:54 |
rubenwardy |
we'll either need to convert straight to hypertext, or with HTML as an intermediary. I'm not against not allowing HTML in markdown, if that makes it easier |
| 17:55 |
rubenwardy |
HTML as an intermediary is much more correct, but requires an XML parser |
| 17:55 |
erlehmann |
tbh letting cdb return hypertext for minetest consumption is not an option? |
| 17:55 |
erlehmann |
(if so, why?) |
| 17:55 |
rubenwardy |
I wondered this, but work needs to be done in any case and having a Minetest API would be nice |
| 17:58 |
erlehmann |
from a flexibility POV you have less options if you directly put it in minetest |
| 17:59 |
erlehmann |
but i am ofc biased, coming from a backend dev standpoint |
| 18:04 |
sfan5 |
just because cdb could use it doesn't mean the engine should have native markdown support |
| 18:08 |
MTDiscord |
<Warr1024> The main menu, at least, needs some way to be able to display the same formatting, structure, emphasis, etc as is used in CDB long-descriptions, in order to be able to make the main menu content browser more useful for users without having to run a separate browser on the side, which really breaks the workflow. |
| 18:08 |
MTDiscord |
<Warr1024> Being able to parse the markdown seems like ONE possible way to achieve that. |
| 18:10 |
sfan5 |
sure, I'm just questioning the need to add this to the API |
| 18:12 |
erlehmann |
yeah, me too. especially since there are *probably* other constraints for literally everything that is not cdb. |
| 18:14 |
sfan5 |
merging #12037, #12052, #12050, #12055 soon |
| 18:14 |
MTDiscord |
<Warr1024> tbh sometimes I wonder if it would make more sense to just build a main menu / launcher type thing as a completely separate program from minetest and reduce our reliance on the whole main menu formspec thing... |
| 18:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/12037 -- Send HUD flags only if changed by appgurueu |
| 18:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/12052 -- Noise params serialization fixup by Gael-de-Sailly |
| 18:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/12050 -- (no squash) Update MinGW toolchain by sfan5 |
| 18:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/12055 -- Increase max objects per block defaults by appgurueu |
| 18:14 |
MTDiscord |
<Warr1024> only major problem I see with the "external launcher" thing is the mess that it would be on mobile platform(s). |
| 18:16 |
Pexin |
isnt the point of the in-menu mod descriptions to be brief, and provide a weblink for users who want an expanded description? |
| 18:16 |
erlehmann |
that reminds me that i wanted to extend https://github.com/minetest/minetest/issues/12037 so that in debug compilation mode there are warnings for duplicate HUD flags (because in many cases these are not only sent often, but the calculation can be skipped entirely). anyone interested in that? |
| 18:16 |
erlehmann |
i mean i'll obv make a separate PR |
| 18:19 |
MTDiscord |
<Warr1024> We want brief descriptions, yes. The weblink option though is sort of a hack, since we lose a lot of control over the UX at that point, and whether opening up a browser for a user is a smooth experience or a train wreck is something that we'll end up getting blamed for regardless of whether there's anything we can actually do about it. |
| 18:20 |
MTDiscord |
<Warr1024> We could make it just reliably and directly show the user a "detail" page with more detail right in the content screens without breaking them out of the MT menu workflow. I guess it's just a question of how complicated that has to be to make it work. |
| 18:23 |
MTDiscord |
<Warr1024> If we need to lock things down to only a smallish subset of features, I could accept that. Structured things, like bulleted/numbered lists and headings I'd want. Also some emphasis like bold/italics preferably. |
| 18:24 |
|
Fixer joined #minetest-dev |
| 18:26 |
erlehmann |
most other things i know (pango markup, xmpp etc.) solve this with a *very* limited html subset, not markdown |
| 18:32 |
MTDiscord |
<Warr1024> IIRC we used to have an XML parser that could be used to parse limited-subset xhtml, but that went away, and we'd have to reintroduce it to go that route ... but it might not be a problem to have CDB just convert MD to HTML before sending it to MT... |
| 18:32 |
MTDiscord |
<Jonathon> except core devs in the past have been anti html in the engine, see formspecs |
| 18:33 |
rubenwardy |
we'd use hypertext |
| 18:34 |
rubenwardy |
well, If the consensus is to not have markdown support in the engine just for CDB, then it'll have to be implemented in the backend |
| 18:34 |
rubenwardy |
at least you wouldn't have to find a markdown parser, just a library to do tree walking |
| 18:34 |
sfan5 |
just to be clear my opinion is that it shouldn't be part of the api |
| 18:34 |
rubenwardy |
ok |
| 18:34 |
sfan5 |
putting some lua code in builtin/mainmenu is totally fine |
| 18:34 |
rubenwardy |
ah |
| 18:35 |
rubenwardy |
idk, if the code exists in minetest then it's nice to make it available |
| 18:35 |
MTDiscord |
<Jonathon> so locking away more things in the main menu? |
| 18:36 |
rubenwardy |
minetest.convert_markdown_to_hypertext(md) -- Returns a best-effort representation of the markdown in hypertext format. Exact output may change between versions |
| 18:37 |
sfan5 |
I don't want to deal with feature requests or backward compat whining for that hypothetical API |
| 18:37 |
sfan5 |
maybe you do |
| 18:37 |
MTDiscord |
<Jonathon> fair point |
| 18:39 |
rubenwardy |
well, hypertext is already experimental and broken |
| 18:44 |
erlehmann |
“if the code exists in minetest then it's nice to make it available” true, but only if it is useful and does not create headaches. |
| 18:44 |
erlehmann |
for once i fully agree with sfan5 here. there is exactly one (1) prospective API user. |
| 18:45 |
erlehmann |
(yet) |
| 18:45 |
rubenwardy |
I'd have used in in conquer |
| 18:45 |
erlehmann |
elaborate? |
| 18:45 |
rubenwardy |
Conquer has help documentation. Currently it's duplicated in markdown and hypertext |
| 18:46 |
rubenwardy |
honestly, I think I'm just learning towards the backend rendering it |
| 18:46 |
rubenwardy |
less hassle |
| 18:46 |
erlehmann |
at the risk of having that discussion again (please not), don't chose markdown if you want something that you want to support for more use cases than your own. |
| 18:46 |
erlehmann |
yes |
| 18:46 |
erlehmann |
also that way you can do upgrades |
| 18:46 |
erlehmann |
like render it differently |
| 18:48 |
rubenwardy |
and you don't have to replicate all the same markdown extensions, you just need to deal with HTML -> Hypertext |
| 19:10 |
erlehmann |
anyone knows how much memory minetest actually leaks when you join a world repeatedly? i do that in testing and i can only do it a few times before the OOM killer kicks in and murders the process. |
| 19:11 |
erlehmann |
(i use earlyoom to make my computer not slow to a crawl) |
| 19:28 |
|
Baytuch joined #minetest-dev |
| 19:29 |
|
proller joined #minetest-dev |
| 19:53 |
|
Noisytoot joined #minetest-dev |
| 20:13 |
|
proller joined #minetest-dev |
| 20:23 |
|
Yad joined #minetest-dev |
| 20:26 |
|
Yad joined #minetest-dev |
| 20:43 |
MTDiscord |
<exe_virus> So on the subject of other libraries, the most compliant was lunamark |
| 20:43 |
MTDiscord |
<exe_virus> For markdown parsing. |
| 20:44 |
MTDiscord |
<exe_virus> I tried other smaller ones that go straight to html, and all were woefully untested and mediocre implementations. No better than my direct markdown to formspec hypertext mod |
| 20:44 |
MTDiscord |
<exe_virus> When I used lunamark, it wanted to use lpeg, so I found a Lua only lpeg, but that needed utf-8, so I found a Lua only utf-8 polyfill for Lua 5.1 |
| 20:45 |
sfan5 |
is markdown actually that hard? you have links, bullet points, headings, images maybe and what else? |
| 20:45 |
MTDiscord |
<exe_virus> But all those combined, while they work, create all sorts of bugs, because of course they're not as good as the real thing. |
| 20:45 |
MTDiscord |
<exe_virus> Yeah markdown is about 500 example corner cases. |
| 20:45 |
sfan5 |
well markdown is also a bad format |
| 20:45 |
sfan5 |
but the basics should be simple |
| 20:45 |
MTDiscord |
<exe_virus> Commonmark has a spec nowadays, but it's hard. Especially when you bring in GitHub tables. |
| 20:46 |
MTDiscord |
<exe_virus> That's why I'm trying to use md4c, which is a small header + single source file implementation |
| 20:46 |
MTDiscord |
<exe_virus> That's my goal right now because it's the least buggy, fastest parsing, and allows us to extend the output with Lua in built-in |
| 20:47 |
|
v-rob joined #minetest-dev |
| 20:47 |
MTDiscord |
<exe_virus> I.e. no html middle man, and no ast construction |
| 20:48 |
MTDiscord |
<exe_virus> Either way, if you all don't want to go the most supported route that's fine, but seeing as it has no dependencies and I know I can work this into our codebase in a straightforward sane way, that is where I'd like to out my efforts. |
| 20:49 |
erlehmann |
sfan5 that markdown is “one” “simple” format is propaganda by ppl who use whatever dialect they favor (usually github markdown, gitlab markdown, pandoc markdown or SO markdown) |
| 20:49 |
erlehmann |
SO = stack overflow btw |
| 20:51 |
erlehmann |
does anyone have any idea how to track memory allocations in minetest at runtime? i have encountered a pretty allocation behaviour case, where minetest allocates memory until it either can't (then it frees it or, sometimes, crashes) or is killed by earlyoom |
| 20:51 |
sfan5 |
you know valgrind right |
| 20:51 |
erlehmann |
i do not, but is it the right tool? |
| 20:52 |
erlehmann |
i basically wanna know what the mod does to provoke the engine into this |
| 20:52 |
erlehmann |
i'll look into valgrind |
| 20:52 |
erlehmann |
thx |
| 20:54 |
v-rob |
The two problems I see with including markdown in the engine is a) Markdown has as many flavors as Linux has distros and b) hypertext kind of really sucks in its current form, and I want to downplay it rather than cement it further into our API. |
| 20:55 |
v-rob |
If we do add some Markdown API at some point, please make sure the parser understands UTF-8. |
| 20:55 |
MTDiscord |
<Jonathon> how is your "superior formspec replacement" coming along anyways? |
| 20:56 |
v-rob |
I didn't say plan to plan a Markdown API for the replacement, just not to plan it for hypertext |
| 20:57 |
v-rob |
There is a note in the docs stating that everything in hypertext is experimental and subject to change |
| 20:57 |
v-rob |
But to answer the question, slow but progressing |
| 20:57 |
erlehmann |
can we look at your progress somewhere? |
| 20:58 |
|
proller joined #minetest-dev |
| 20:58 |
v-rob |
I haven't put it on GitHub yet. There's nothing to see but code anyway. |
| 20:58 |
erlehmann |
well, i am interested in the code |
| 20:59 |
v-rob |
Mostly Unicode stuff, and I have no guarantee if it's working properly yet until I write code for displaying it to the screen. |
| 21:01 |
v-rob |
I'll try to hack the code into a state where it actually compiles, and then I'll dump it on GitHub for your enjoyment. |
| 21:29 |
|
MTDiscord joined #minetest-dev |
| 21:37 |
MTDiscord |
<luatic> v-rob: I'd say the main problem is not leveraging Lua here, but instead forcing the modders to do the string building themselves |
| 21:38 |
MTDiscord |
<luatic> A Lua/JSON-ish data structure - perhaps paired with some sugar - should be used to represent formspecs, but that'll require a FS revamp, or at least engine-provided string builders |
| 21:38 |
MTDiscord |
<luatic> Texture modifiers need the same |
| 21:39 |
v-rob |
Nope, formspecs are getting trashed. |
| 21:39 |
v-rob |
It's going to be a whole different backend and frontend, with formspecs existing via a compatibility parser. |
| 21:40 |
v-rob |
Formspecs are entirely unsalvageable, as I discovered in the past when trying to refactor the code. |
| 21:43 |
v-rob |
Irrlicht + build-as-you-parse formspec making + totally garbage code + everything intertwined with everything else = It's better to rewrite than try to salvage, and probably easier as well. |
| 21:45 |
MTDiscord |
<luatic> Hmm indeed, but that rewrite might take a while |
| 21:46 |
MTDiscord |
<luatic> It'll also smoothen the transition if we get a string building API out and deprecate doing the string building yourself before we have a full new backend ready |
| 21:56 |
erlehmann |
build-as-you-parse is garbage most of the time |
| 21:56 |
erlehmann |
full recognition before processing! |
| 21:57 |
MTDiscord |
<luatic> meh, building on the go can be fine as long as your parser is still formal enough |
| 21:57 |
erlehmann |
luatic what exactly would a string building API be? |
| 21:57 |
erlehmann |
luatic true, but it is unsafe at any speed *most* of the time. |
| 21:57 |
MTDiscord |
<luatic> many options, but basically you pass it a table structure (AST) and you get out a string |
| 21:58 |
erlehmann |
did you build something like that for one of your mods? |
| 21:58 |
erlehmann |
(if not, why not? if yes, pls show) |
| 21:59 |
MTDiscord |
<luatic> so something like fs = minetest.formspec and then fs(fs.Container{fs.Button{pos = {...}, size = {...}, label = {}}}) |
| 21:59 |
MTDiscord |
<luatic> erlehmann: I usually do separate parsing and processing, but I'm pretty sure Lua emits bytecode in one go |
| 22:07 |
MTDiscord |
<exe_virus> right, lua doesn't care. v-rob: yeah the idea here is to bring in a markdown parser (that absolutely supports utf-8), that is adjustable to different flavors (you can toggle on table support, latex support, or about 15 others, but we really only need tables I suspect), and then feed all of it's "begin header, end header, start paragraph, end paragraph, etc" callbacks to lua for adjutable output. The idea is for now to expect a |
| 22:07 |
MTDiscord |
lua-side table of function callbacks, and each would return the resulting string to concat together to generate the formatted output. Then we can override those callbacks as needed to support whatever gui backend/frontend we want |
| 22:08 |
|
MTDiscord1 joined #minetest-dev |
| 22:08 |
MTDiscord1 |
<luatic> the current Lua-only options at least seem rather messy to me, especially if they are made to use polyfills like lulpeg |
| 22:09 |
MTDiscord1 |
<luatic> I also agree with erlehmann's overall criticism of MD |
| 22:09 |
MTDiscord1 |
<luatic> on the other hand, CDB does use it and we do want to be able to display the readmes |
| 22:09 |
MTDiscord1 |
<luatic> what would be wrong with CDB sending hypertext to MT clients? |
| 22:10 |
MTDiscord1 |
<luatic> (or HTML, or any other easily parsable non-MD format) |
| 22:10 |
MTDiscord1 |
<exe_virus> a lot of people like using markdown, that's the thinking, and no a lua only solution in 5.1 is unlikely to succeed due to non-native utf-8 support |
| 22:10 |
MTDiscord1 |
<exe_virus> we can't render html with minetest, that's why |
| 22:11 |
MTDiscord1 |
<luatic> then those people can see for themselves which parser to drag in |
| 22:11 |
MTDiscord1 |
<exe_virus> those people? I am one of those, there are about 20 others that like markdown2formspec |
| 22:11 |
MTDiscord1 |
<luatic> we can convert HTML to hypertext though |
| 22:11 |
MTDiscord1 |
<exe_virus> medicore, prone to breakage |
| 22:12 |
MTDiscord1 |
<exe_virus> same problem as parsing markdown |
| 22:12 |
MTDiscord1 |
<luatic> and that's perfectly fine, I'm not criticizing md2fs |
| 22:12 |
MTDiscord1 |
<exe_virus> I am, it sucks |
| 22:12 |
MTDiscord1 |
<exe_virus> I want to use a good lib |
| 22:12 |
MTDiscord1 |
<luatic> heh |
| 22:12 |
MTDiscord |
<luatic> the real issue is the poor lib support overall |
| 22:12 |
MTDiscord |
<luatic> modders have to constantly rewrite everything in Lua |
| 22:12 |
MTDiscord |
<luatic> I mean, I do like rewriting stuff in Lua |
| 22:12 |
MTDiscord |
<exe_virus> ? |
| 22:12 |
MTDiscord |
<luatic> but sometimes having a lib would be neat |
| 22:13 |
MTDiscord |
<luatic> yet bundling all libs with MT is even worse than bloating modlib |
| 22:13 |
MTDiscord |
<exe_virus> still my favorite lib, I've done this a few times in c++, and have seen some really bad parser. https://github.com/mity/md4c |
| 22:13 |
MTDiscord |
<exe_virus> ideally, an engine should** have a lot of libs |
| 22:14 |
MTDiscord |
<exe_virus> support for lots of 3d formats, texure formats, etc. |
| 22:14 |
MTDiscord |
<exe_virus> gdal for heightmaps even haha |
| 22:15 |
MTDiscord |
<exe_virus> opus, midi, libmodplug |
| 22:15 |
MTDiscord |
<exe_virus> various shader styles ; ) |
| 22:16 |
MTDiscord |
<exe_virus> input device libs |
| 22:16 |
|
v-rob joined #minetest-dev |
| 22:29 |
v-rob |
exe_virus: A genericized Markdown parser that can apply to more than just hypertext sounds much better |
| 22:30 |
erlehmann |
<exe_virus> support for lots of 3d formats, texure formats, etc. |
| 22:30 |
erlehmann |
hahaha, that ship has sailed (for good measure, parsers are attack surface) |
| 22:31 |
erlehmann |
format support should be extended, but based on needs, not on “throw in a random format” |
| 22:32 |
erlehmann |
same for API support, btw. |
| 22:32 |
erlehmann |
knee-jerk reactions to people's demands rarely make for a good API |
| 22:33 |
MTDiscord |
<Jonathon> so your implying to not listen to you? |
| 22:34 |
MTDiscord |
<exe_virus> lol, don't start that conversation. No there's been decent desire for markdown support |
| 22:34 |
MTDiscord |
<exe_virus> technically it could be handled completely server side with insecure mods, but that's a horrible route to go |
| 22:35 |
MTDiscord |
<exe_virus> parsers are absolutely an attack surface and we have some of the worst parsers and formats already, so might as well get modern if we're going to be mediocre about security |
| 22:37 |
MTDiscord |
<exe_virus> I agree random format is bad, but I also agree that our entire codebase is currently well acquainted with markdown, via lua_api.txt, via every readme.md, our use of git, github, gitlab, notabug, etc. 99% of our current documentation lives in markdown land, I bet even the modding book is markdown on the backend. |
| 22:43 |
MTDiscord |
<exe_virus> anyways, thanks for the support v-rob, I will work on that PR and see if I can get that made this week. Heck, might even record it and make a "how to contribute to Minetest Engine" video, so people on windows are less daunted by it. First, though, I gotta talk to Josiah about how we prefer to include two files.... |
| 22:43 |
|
SOMBRIO joined #minetest-dev |
| 23:56 |
erlehmann |
engine question: if i change a mapblock a lot, could it cause runaway memory issues? |
| 23:56 |
erlehmann |
in particular, i am having lots of fire and after like 20 or 30 minutes, minetest eats RAM like candy and starts lagging |
| 23:56 |
erlehmann |
even in singlenode world where the fire can't go anywhere |
| 23:57 |
rubenwardy |
v-rob: I'm not convinced on formspecs as a compatibility parser, would be better to just keep the formspec around, frozen |
| 23:57 |
v-rob |
It may turn out that way. A compatibility parser would be a nightmare to get right after all. |
| 23:58 |
rubenwardy |
exe_virus: if markdown isn't being added to the API, then it makes more sense for the ContentDB backend to do it - as you can use the exact same markdown flavour |
| 23:58 |
v-rob |
And if the slightest backwards compatibility got broken, I'd get a bunch of erlehmanns yelling at me :) |
| 23:58 |
rubenwardy |
v-rob: yeah exactly, writing compat code to emulate on a new GUI system will be a huge pain |
| 23:59 |
erlehmann |
v-rob just tell them to use a cheat client to show their own formspecs ^^ |
| 23:59 |
rubenwardy |
I mean, you could do this in stages if you wanted to completely remove the Irr GUI |
| 23:59 |
rubenwardy |
so start by freezing formspecs, and keeping the old code |
| 23:59 |
erlehmann |
i think it is limiting to have to map everything from formspec anyway |
| 23:59 |
rubenwardy |
then in 6.0, replace with a compat/emulation layer which uses the new GUI |
| 23:59 |
erlehmann |
what if you can not do it, bc the new layout system is different |
| 23:59 |
erlehmann |
constraint based for example |
