Time |
Nick |
Message |
00:00 |
MTDiscord |
<greenxenith> Mind you* |
00:11 |
|
YuGiOhJCJ joined #minetest |
00:13 |
|
Lesha_Vel joined #minetest |
01:22 |
|
TheSilentLink joined #minetest |
01:24 |
|
smk joined #minetest |
01:25 |
|
amfl2 joined #minetest |
02:43 |
|
liceDibrarian joined #minetest |
04:00 |
|
MTDiscord joined #minetest |
04:09 |
|
y5nw joined #minetest |
06:34 |
|
calcul0n__ joined #minetest |
06:45 |
|
jluc joined #minetest |
06:55 |
|
grouinos joined #minetest |
06:57 |
|
grouinos joined #minetest |
07:03 |
|
grouinos joined #minetest |
07:12 |
|
vampirefrog joined #minetest |
08:04 |
|
Lesha_Vel joined #minetest |
10:06 |
|
lemonzest joined #minetest |
10:09 |
|
vampirefrog joined #minetest |
10:11 |
|
Thelie joined #minetest |
10:21 |
|
TomTom_ joined #minetest |
10:45 |
|
syxi joined #minetest |
10:58 |
|
mrkubax10 joined #minetest |
11:07 |
|
Sobinec joined #minetest |
11:43 |
|
Sobinec joined #minetest |
11:57 |
|
appguru joined #minetest |
12:06 |
|
behalebabo joined #minetest |
12:11 |
|
s20 joined #minetest |
12:58 |
|
Lunatrius joined #minetest |
13:14 |
|
s20 joined #minetest |
13:16 |
|
rod_tout_court joined #minetest |
14:23 |
copygirl |
How would one get the current selection box of a node? |
14:24 |
copygirl |
This is for "facedir" nodes that should only have a single box. |
14:24 |
copygirl |
(But may be rotated.) |
14:28 |
copygirl |
I find this node using a raycast, so I believe I have access to a box_id. |
14:31 |
MTDiscord |
<luatic> copygirl: see https://github.com/appgurueu/modlib/blob/master/minetest/boxes.lua. this solves a more general problem, so strip as you see fit. |
14:32 |
|
appguru joined #minetest |
14:34 |
copygirl |
There's no builtin? T_T |
14:37 |
copygirl |
In typical Lua fashion, haha |
14:37 |
copygirl |
Thank you. |
14:41 |
|
jaca122 joined #minetest |
14:54 |
|
fluxionary joined #minetest |
15:00 |
|
calcul0n_ joined #minetest |
15:12 |
|
appguru joined #minetest |
15:15 |
copygirl |
I can assume these two are equivalent? |
15:15 |
copygirl |
for off = 0, 3, 3 do |
15:15 |
copygirl |
for _, off in ipairs({ 0, 3 }) do |
15:16 |
copygirl |
I find the latter easier to read so I might use that instead. |
15:17 |
copygirl |
I picked what I needed but it seems to break for when the node points up or down. |
15:19 |
|
definitelya joined #minetest |
15:26 |
copygirl |
Here is the code if anyone can spot any obvious mistakes. |
15:26 |
copygirl |
https://gist.github.com/copygirl/607ed2d28bb26d7e21dcd1b1b9e0ede6 |
15:27 |
copygirl |
But yeah for param2 = 4 or 6, and equivalent facedirs (in the case of NodeCore lenses), it gives me incorrect values. |
15:27 |
copygirl |
https://imgur.com/GnM1XIs.png Here's a screenshot, if that helps in any way. |
15:28 |
|
fluxionary joined #minetest |
15:30 |
copygirl |
I'm writing a rotation mod and need to find the edge closest to the cursor. |
15:54 |
copygirl |
@luatic: Any idea if that's my fault or the source not working for this usecase? |
16:03 |
|
mrkubax10 joined #minetest |
16:29 |
MTDiscord |
<luatic> copygirl: it is possible that i have a bug in my code. i did test this manually with some facedir nodes (stairs and slabs, iirc), but that was a while ago so i don't remember how thorough i was. have you tried visualizing the boxes it gives you e.g. using https://github.com/appgurueu/disable_build_where_they_stand/blob/master/test.lua ? |
16:33 |
|
s20 joined #minetest |
16:33 |
copygirl |
Honestly the code looks like forbidden magic so I'll try to write something that'll make more sense to me. |
16:38 |
erle |
luatic copygirl have you considered the wisdom of TDD |
16:40 |
copygirl |
TDD? Please enlighten me. |
16:46 |
jonadab |
That's where you write a series of tests first, before you write the actual code. |
16:47 |
jonadab |
It works reasonably well for data-handling code but falls over pretty hard for UI work. |
16:47 |
jonadab |
Because users are really hard to automate. |
16:47 |
copygirl |
Ooh, test driven development. |
16:47 |
copygirl |
Yeah I know that but I'm laaazy. |
16:48 |
jonadab |
Heh. |
16:48 |
jonadab |
Just be sure that you harness your laziness correctly, along with suitable amounts of impatience and hubris. |
16:48 |
jonadab |
Great things can be accomplished. |
16:49 |
copygirl |
@luatic: Oh and the values I was getting back from the rotated boxes where offset by an amount that made it seem like it didn't rotate the box to point upwards. |
16:49 |
copygirl |
I didn't need to visualize it explicitly because it was offset by a number of texels I could count. |
16:51 |
rubenwardy |
You only write one test first, make it pass, and then repeat |
16:52 |
MTDiscord |
<luatic> erle: have you considered the wisdom of i'm not getting paid enough to TDD everything minetest i do :^) |
16:53 |
jonadab |
Theoretically, automated tests are supposed to save time, by finding bugs as soon as they go into the code, so you don't end up having to do a git bisect later. |
16:54 |
jonadab |
The extent to which this works in practice, is a matter of some debate. |
16:54 |
jonadab |
And probably depends on the nature of the codebase. |
16:54 |
|
definitelya_ joined #minetest |
16:56 |
|
sometalgoo joined #minetest |
16:56 |
copygirl |
They can be incredibly useful, but also, in my case, I'd have to generate the expected values to test against. Then it's a chicken and egg problem, in a way. |
16:56 |
copygirl |
Unless I hand-calculate them and I could make a mistake too. |
16:57 |
copygirl |
Or I could misunderstand the docs, and think it should work differently. |
17:06 |
copygirl |
https://github.com/minetest/minetest/blob/12e98678f64a798f1ad38a50b820e60f96eca321/src/client/mesh.cpp#L301 |
17:06 |
copygirl |
This actually helps a bunch. |
17:10 |
|
Thelie joined #minetest |
17:16 |
muurkha |
I feel like Hypothesis helps a lot with improving the cost/benefit tradeoff of automated tests. I don't remember if there's a Minithesis for Lua |
17:20 |
jonadab |
I tend to write somewhat paranoid code, e.g., functions check whether their inputs are the kind of thing they're supposed to be and complain bitterly if not, etc. |
17:21 |
jonadab |
And then when the code calls a function, it'll check whether the returned result is the right sort, as well. |
17:22 |
jonadab |
Although I'm not as good about that in lua, probably because I'm not as familiar with the language and don't really know what I'm doing yet. |
17:22 |
|
sometalgoo left #minetest |
17:30 |
muurkha |
it sounds like you wish you were using a statically typed language ;) |
17:30 |
copygirl |
I too wish I was. |
17:37 |
muurkha |
my wife was suffering a bit from trying to understand the API the other day in a way that I think a statically typed language might have helped with |
17:37 |
muurkha |
she was getting a node with get_node inside the on_use function for the teapot in our mod (mostly hers by now) |
17:38 |
muurkha |
and couldn't figure out how to get the position of that node so she could spawn some particles |
17:39 |
copygirl |
This looks a lot cleaner. I do use {min,max} boxes with vectors instead of the array based ones, because they are easier to work with. https://gist.github.com/copygirl/4eba97936dd02182e6eb1af155b1943a |
17:40 |
muurkha |
well, but of course the position is the argument to get_node, but there isn't a local way to see that that object has .x, .y, and .z |
17:40 |
muurkha |
statically, I mean |
18:04 |
|
sparky4 joined #minetest |
18:20 |
MTDiscord |
<warr1024> copygirl: if you're specifically interested in selectionboxes in NodeCore, for nodes that can be rotated, I really try to make them invariant with rotation, so you shouldn't have to account for rotation. If rotating a node caused its selectionbox to move, that would create a big annoyance when you tried to right-click again and the box had moved and now you were pointing at a different node. |
18:21 |
copygirl |
@warr1024: Lenses have selection boxes based on rotation. |
18:21 |
|
mrkubax10 joined #minetest |
18:22 |
MTDiscord |
<warr1024> Oh interesting, it looks like they're close to stable but not quite. Well, that's a bug, anyway. |
18:23 |
MTDiscord |
<warr1024> yeah, prisms are right, lenses were apparently just close enough to right that I didn't notice they were wrong. |
18:25 |
copygirl |
So, what you're telling me is I wasted a couple of hours of debugging this? |
18:25 |
muurkha |
in a sense debugging is always "wasted" |
18:26 |
muurkha |
because you could have guessed what the bug was at the beginning of the whole process |
18:26 |
MTDiscord |
<warr1024> I couldn't tell you that. If you want a solution that's going to work with multiple games, or even all possible mod content for nodecore, you might need the general solution. If you only care about vanilla mechanics, then it could be. |
18:26 |
MTDiscord |
<warr1024> Debugging is also in some sense never wasted, because you always learn things in the process, usually more useful things that you are even aware of... |
18:27 |
muurkha |
agreed, I think that perspective is equally valid and more productive :) |
18:29 |
MTDiscord |
<warr1024> Hmm, interesting: at one point, lenses and prisms both had selectionboxes that were "snug." I must have fixed the prism one at one point because it wobbled around too much, but I missed the fact that lenses did too because they only move by like 1 pixel worth. Not only should their selection boxes have been invariant in rotation, but apparently they should have had the same selection boxes as each other too. |
18:32 |
copygirl |
(My code doesn't work 100%.) |
18:33 |
copygirl |
Okay the issue is just having switched the rotation order. |
18:33 |
copygirl |
I did it the same as the Minetest code I linked earlier, but that's apparently not it. |
18:44 |
MTDiscord |
<warr1024> Heh, I kept hearing you say "lua is a bad language" on the stream but never actually managed to ask what you meant by that ... so I guess you just mean "it's not statically typed?" Yeah, it definitely isn't. |
18:45 |
MTDiscord |
<warr1024> I spent a lot of my early years, once I got into languages with complex types, with static typing, and it was a huge liberation to discover natively-dynamically-typed languages. Probably a good sign that you've been looking for dynamic types all along is when you look back at old code where you "invented" dynamic data structures using static ones. |
18:46 |
copygirl |
Dynamically typed, lack of useful standard library, differences between different runtimes, a bunch of weird and annoying language decisions. |
18:46 |
MTDiscord |
<warr1024> If you long for static types and are stuck in dynamic land, about all you can really do is document your structures well, and do a lot of testing. |
18:46 |
MTDiscord |
<warr1024> Static typed langauges tend to rely on compile-time type checking, dynamic ones tend to rely on tests. |
18:47 |
copygirl |
For example, why does `"Vector: " .. vec` not invoke the __tostring metatable function? |
18:47 |
MTDiscord |
<warr1024> that's not a lack of a useful standard library, that's a lacking on minetest's part. |
18:47 |
copygirl |
Maybe it's just age. Also, indexing arrays at 1 was a silly decision. |
18:47 |
MTDiscord |
<warr1024> Indexing arrays at 1 was the main silly decision that lua made. |
18:48 |
MTDiscord |
<warr1024> setfenv was also a mistake, which they mitigated and eventually corrected in later versions, but there are a few people who are still in love with that one. |
18:48 |
copygirl |
`~=` instead of `!=` is another |
18:49 |
copygirl |
Maybe not as big of an impact but .. why, y'know? |
18:49 |
MTDiscord |
<warr1024> That's more of a nitpick than a serious flaw. I mean, SQL ANSI NULLs are a bigger mess than that... |
18:49 |
MTDiscord |
<warr1024> Compared to something like JS, Lua avoided a LOT of the pitfalls that JS is still paying for. |
18:49 |
copygirl |
I always found metatables to be a sort of additional meta-language put on top of Lua. |
18:49 |
MTDiscord |
<warr1024> metatables are weird in lua, but not as bad as they are in JS. |
18:50 |
copygirl |
JS is another horrible language. |
18:50 |
MTDiscord |
<warr1024> If these things make lua a "bad" language then "bad" is tautologically meaningless. |
18:51 |
MTDiscord |
<warr1024> JS is a very good language that was turned into a bad language by a few bad decisions, and they've spent a lot of time trying to compensate for it. They've actually succeeded and turned it into a good language, but only IF you know to avoid the bad parts. Luckily there are enough people out there who will tell you what to avoid 😆 |
18:51 |
copygirl |
I mean I'm no expert so I will not claim this as an objective fact, but I sure subjectively dislike Lua. |
18:52 |
copygirl |
JS was thrown together in two weeks. |
18:52 |
copygirl |
That's not how you language design. |
18:52 |
MTDiscord |
<warr1024> The "thrown together in 2 weeks" part of JS is actually all the best stuff. It was the shit that happened afterwards that was bad. |
18:52 |
MTDiscord |
<warr1024> It turns out that "just copy from a language that was already really elegantly designed" was a pretty good design approach and only took like 2 weeks. |
18:53 |
MTDiscord |
<warr1024> Just take Scheme and make it look like C. |
18:53 |
MTDiscord |
<warr1024> Ultimately it seems like there's a "law of conservation of shittiness" for languages. The more elegant you make the core language, the shittier you make the ecosystem, and the more extensive the ecosystem, the worse the core language. |
18:54 |
MTDiscord |
<warr1024> You can have an amazing langauge with a terrible ecosystem like Lua or Scheme, or you can have a huge ecosystem with a shitty core language like Perl5 or Java, or you just have to pick a good compromise somewhere between. |
19:00 |
copygirl |
I was pretty happy with C# but unhappy with M$'s handling of open source. |
19:02 |
MTDiscord |
<warr1024> I was happy with C# back when I used to use it for work. It was a good "pragmatic" language where they made a ton of compromises so you weren't locked into any one paradigm, and that "hybrid" approach made it very flexible and versatile. |
19:03 |
MTDiscord |
<warr1024> The one weakness I found with it was that it was very originally steeped in static-typing and their dynamic typing primitives were still very kludgey at the time, and it wasn't easy to do mixed typing. |
19:04 |
MTDiscord |
<warr1024> To be fair I'm always kinda trying to push the boundaries in certain areas, like mixing static and dynamic typing (a data type should have these known properties, but can also have additional unknown ones) or dealing with crazy concurrency, or massive metaprogramming (meta C# in T4 templates got very messy very fast). |
19:09 |
MTDiscord |
<warr1024> I went deep down the dynamic rabbit hole with JS since then, and it wasn't the dynamic typing that really killed it (though I've run into the limits of pure dynamic types too), it's the concurrency stuff. JS has pretty good robust concurrency in terms of async dispatch, but it's the dependency management and rejoining threads that really kills it: needing to remember whether you need to await, and awaiting not being the default. |
19:10 |
MTDiscord |
<warr1024> I think C# at the time copied the same mistakes, but in C#'s case its static typing actually helps compensate for it a bit. |
19:21 |
|
appguru joined #minetest |
19:29 |
erle |
luatic the interesting observation i made about TDD and applying LANGSEC principles and a bunch of other practices (e.g. religiously follow REST instead of making some some stateful mess with session IDs and so on) is that overall, you save time – but only if you have a long-term view. |
19:30 |
erle |
luatic e.g. it is way harder for someone to design a shitty API if they have to test it, because it means the tests will look gnarly. |
19:31 |
erle |
one of my favourite examples of that is apenwarr redo, which does not actually function properly when called recursively. since the test cases do call it recursively, there is some unholy magic in them. |
19:33 |
erle |
case in point: a coworker wondered how to write a simple config file parser today and wondered if regexes with capture groups work for his case. they do – and are much more obviously correct than the spaghetti config parser he showed me. |
19:34 |
erle |
last night i encountered a memoization primitive in some lua code. luatic warr1024 do you have any idea if this makes sense in most of minetest or not? |
19:34 |
erle |
like do mods actually contain pure functions? |
19:34 |
erle |
at first glance, it seemed to me as if everything important is a side effect |
19:36 |
erle |
copygirl the house in which i live is on an inclined street. depending on which entry you take, the lowest floor is zero- or one-indexed. it is infuriating. |
19:44 |
MTDiscord |
<warr1024> I'm not sure what you mean by "makes sense" |
19:44 |
MTDiscord |
<luatic> erle: yes, but maybe i often don't have, and in hindsight may not even regret not having had, the "long term view" |
19:44 |
MTDiscord |
<warr1024> like that somebody would do memoization in lua? |
19:45 |
MTDiscord |
<warr1024> I rarely take a purely long-term view. It's just as short-sighted to assume that long-term views will come to fruition as it is to ignore the long time. Some projects only make it into the medium term realistically, so you have to balance between short, mid, and long term needs. |
19:45 |
MTDiscord |
<luatic> modlib contains a helper for memoization. so i'm pretty sure i used that at least twice. |
19:45 |
muurkha |
copygirl: .. doesn't implicitly coerce its arguments to strings because type coercions is an area where Lua errs more in the direction of monomorphism and explicitness |
19:45 |
copygirl |
But it works with numbers. |
19:45 |
MTDiscord |
<warr1024> muurkha, heh, I hadn't really thought about it, but it's almost like Lua is trying super hard to avoid JS's mistake there :0) |
19:46 |
muurkha |
you have the same situation in Python; "Vector: " + [] says TypeError: can only concatenate str (not "list") to str |
19:46 |
muurkha |
when I was first moving from Perl to Python I found this annoying, but came to like it\ |
19:46 |
muurkha |
I agree that indexing arrays at 1 was a mistake. not sure about setfenv |
19:47 |
MTDiscord |
<warr1024> coercing numbers to strings when concatenated into a string makes some sense, yeah. JS went off the rails by coercing strings into numbers. Lua arguably is TOO cautious here ... but there's no one exact correct place to land, it's going to depend on the varying expectations of programmers. |
19:47 |
muurkha |
a lot of the stuff that JS started out with was copied from Perl and kind of regrettable |
19:49 |
muurkha |
having tests often saves time even on a fairly short timescale, like a day, especially if you're using Hypothesis; but it depends a lot on what you're writing |
19:49 |
muurkha |
TDD may or may not be beneficial; it's certainly psychologically helpful sometimes, but psychologically counterproductive other times |
19:49 |
MTDiscord |
<warr1024> Well, the regrettability of any decision is of course dependent on your personal regretting skill, so it's hard to say anything definite about one language or another that's not a matter of taste. |
19:50 |
muurkha |
it does help with API design IME |
19:50 |
MTDiscord |
<warr1024> I've found a lot of languages that are very distatesteful when taken as a whole to nevertheless be really good for doing practical work, as long as you're able to constrain yourself to a useful subset. |
19:50 |
MTDiscord |
<warr1024> The key thing is that it's YOU who's doing the constraining, so you get to pick a sane subset that works for you rather than having one dictated. |
19:50 |
muurkha |
I'm reluctant to say that a regex is ever obviously correct |
19:51 |
muurkha |
I've seen far too many regexen that appear obviously correct but actually contain subtle pitfalls |
19:51 |
MTDiscord |
<warr1024> Any solution that's obviously correct must be to a problem that's too trivial to really worry about, so I'm not sure if the ability to be obviously correct is a really useful property. |
19:52 |
muurkha |
yes, it's true that Lua does coerce numbers to strings in .. (and Python doesn't) |
19:53 |
MTDiscord |
<warr1024> The coercion thing is a consistency/convenience trade-off. If Lua didn't coerce numbers, it would be more consistent, but it'd probably be way more annoying. |
19:53 |
muurkha |
JS coercing strings into numbers was just imitating the four successful scripting languages at the time: sh, awk, Perl, and Tcl, all of which allow you to add "3" to "4" without complaint |
19:54 |
MTDiscord |
<warr1024> Those languages existed in a somewhat different context though where all incoming data was inherently stringly typed and you never got a 3 that wasn't a "3" |
19:54 |
muurkha |
arguably that's not true of Perl or Tcl |
19:55 |
muurkha |
and arguably it was true of JS |
19:55 |
MTDiscord |
<warr1024> It actually seems weird to imitate them even knowing the precedents it was based on because of the difference in context. |
19:55 |
MTDiscord |
<warr1024> Perl cut its teeth as a text processing language. Tcl might have been a different case... |
19:55 |
muurkha |
sometimes it can be hard to tell what circumstances made a good decision good |
19:56 |
MTDiscord |
<warr1024> Well, a decision isn't really necessarily good or bad in itself; it depends on when you're asking. |
19:56 |
muurkha |
3 |
19:56 |
muurkha |
that's true too |
19:56 |
muurkha |
but Perl was clearly wildly successful |
19:58 |
MTDiscord |
<warr1024> I've written a lot of useful stuff in Perl. It had some big advantages as a "system" language, e.g. for admin scripts and stuff, in being available on the most platforms, and being saner than sh when it came to handling data. The key was to stick to some actually sane subset of it, and the problems with "readability" are that different people stick to different subsets of it. |
19:58 |
muurkha |
well, also the switch to Perl 5 helped |
19:59 |
MTDiscord |
<warr1024> Of course, introducing Python was supposed to solve that but it just xkcd 927'd things in a way: my knowledge of my own personal subset of perl didn't help me read somebody else's perl, but it sure as hell didn't help me read somebody else's python either. |
19:59 |
muurkha |
but in 01994 if you departed from imitating Perl and Tcl without great insight, you were more likely to make your scripting language worse than to make it better |
19:59 |
muurkha |
which I think was when Brendan designed JS? |
20:00 |
MTDiscord |
<warr1024> The base of 01994 can only be described as "garden path octal" |
20:00 |
muurkha |
haha |
20:00 |
muurkha |
I read a lot of other people's Perl, even Abigail's |
20:01 |
muurkha |
It wasn't that bad. Bug-prone but far from write-only |
20:01 |
erle |
my long-term-view is usually “try to avoid useless path dependencies” |
20:01 |
MTDiscord |
<warr1024> Perl lets you write some pretty horrible stuff but it doesn't make you. By the same token, I guess, there's no language that will stop a sufficiently determined person to write horrible code, and it's really pretty trivially easy to completely misthink a problem... |
20:01 |
erle |
bad programmers can write PHP in any language? |
20:01 |
muurkha |
erle: yet you unaccountably wrote that sentence in Roman letters |
20:02 |
erle |
muurkha we live in a society! curious! |
20:02 |
muurkha |
are you engaging in satire? |
20:02 |
erle |
indeed |
20:02 |
erle |
the latin script is already a path i am on |
20:03 |
erle |
i don't want to make new path dependencies |
20:03 |
muurkha |
oh, I see |
20:03 |
MTDiscord |
<warr1024> "path dependencies" as in "I don't want to add any more dependencies along the path"? |
20:03 |
muurkha |
no |
20:03 |
MTDiscord |
<warr1024> or do you just mean you want to keep your $PATH var as short as possible |
20:03 |
erle |
so my long-term view is “if i don't know the territory, chose whatever looks like it keeps my option open until i do” |
20:03 |
muurkha |
a path-dependent outcome is one that depends on the path you took |
20:04 |
MTDiscord |
<warr1024> Hmm, that's not really my long term view then, that's my short/medium term view. |
20:04 |
erle |
Warr1024 a path dependency is a choice that reduces the solution space in the future |
20:04 |
muurkha |
like arguably Dvorak is a better keyboard layout but we all use qwerty or minor variations because Sholes was first |
20:04 |
MTDiscord |
<warr1024> Flexibility is less important in the long run because by the time the long run happens, you'll have a good idea of the scope of the problem. It's in the short term that you need to keep your options open. |
20:04 |
erle |
for example, i have read (but not confirmed) that the standard gauge in europe is not optimal. however, it is individually rational to build more standard gauge tracks, because trains exist that run on it and there is a network of those tracks already. |
20:04 |
muurkha |
erle: that's also a definition of "progresss toward a solution" |
20:05 |
MTDiscord |
<warr1024> In the long run, I'll make it optimal. In the medium run, I'll make it maintainable. In the short run, I'll make it easily repleacable. |
20:05 |
erle |
muurkha it can only be progress if i have a goal |
20:05 |
muurkha |
most design choices are somewhat free |
20:05 |
muurkha |
but if you don't make them arbitrarily you don't get a working design |
20:06 |
erle |
i have seen enough refucktorings that were marketed as progress but actually had negative value because a) new dependencies b) lock-in into a specific solution space c) new bugs the old solution did not have |
20:06 |
erle |
muurkha well, not always the choices are arbitrary. |
20:07 |
erle |
usually i do have constraints |
20:19 |
|
clavi joined #minetest |
20:19 |
|
clavi joined #minetest |
20:35 |
erle |
warr1024 do you have a comprehensive design document regarding nodecore, i.e. a thesis or so? |
20:38 |
|
diceLibrarian2 joined #minetest |
20:59 |
|
sparky4 joined #minetest |
21:16 |
|
Trifton joined #minetest |
21:53 |
|
sparky4 joined #minetest |
22:02 |
MTDiscord |
<warr1024> I had attempted to make one, but I was unable to maintain it. |
22:03 |
MTDiscord |
<warr1024> I kept discovering principles that had exceptions and exceptions that turned out to be principles. |
22:04 |
MTDiscord |
<warr1024> In a way right now rather than following a specific document I mostly just follow the example of the game itself. |
22:06 |
|
Mc- joined #minetest |
22:34 |
|
panwolfram joined #minetest |
22:46 |
|
Izaya left #minetest |
22:57 |
|
sparky4 joined #minetest |
23:27 |
erle |
Warr1024 even a broad outline that does not address exceptions would be helpful for me to understand the process though. like the idea with battle for wesnoth that no game mechanic or UX should be more complicated than a board game. |
23:32 |
MTDiscord |
<warr1024> The original core idea was basically no popup GUIs in game, though that turned out to be more like a simple constraint than a guiding philosophy. It tells me what I need to not do but offers little direction on what to do. |
23:35 |
MTDiscord |
<warr1024> There are other principles like interactions being driven by local circumstances only and general symmetries, but those are not that experientially focused. |
23:36 |
MTDiscord |
<warr1024> Though, granted, having a universe that makes sense according to a lot of symmetries and consistent patterns ends up making a lot of difference for the players. |
23:36 |
erle |
it does indeed |
23:37 |
erle |
similar to how with wesnoth i never need to look for hidden information (because there isn't any) |
23:37 |
MTDiscord |
<warr1024> There's a lot of superficial differences, like the fact that you need to learn a new system to reach another tool tier each time, but where it counts deep down there is a sort of logical sense binding the world together that some players seem to intuitively get and some don't, but seems hard for anyone to define in words. |
23:37 |
erle |
did you ever play cataclysm dark days ahead? |
23:38 |
erle |
the crafting system is not realistic, but believable. thus, no manual is necessary for everyday tasks. |
23:38 |
erle |
it also hilariously trips people up who believe video game logic tropes apply everywhere |
23:39 |
MTDiscord |
<warr1024> Heh, I always feel a bit torn between leveraging video game logic tropes for player expectations vs subverting them for the surprise factor. |
23:39 |
erle |
case in point: my first player character in CDDA died of smoke inhalation, after i decided that to warm the room i could make a fire. |
23:39 |
erle |
later i found out that drinking out of the toilet before boiling water is unhealthy |
23:40 |
erle |
those two things were enough to convince me that if it is a bad idea IRL i better not try it in the game |
23:40 |
erle |
that rule obviously can only be stretched so much for a game full of fantasy creatures |
23:40 |
erle |
so it's not a realistic game |
23:40 |
erle |
but it is a naturalistic game, it has some inner logic |
23:40 |
MTDiscord |
<warr1024> That sounds kinda neat, but what's bad IRL is often less clear cut, and you can fall into the simulation trap.. |
23:41 |
erle |
what's the simulation trap? |
23:41 |
erle |
well, if it's not clear then you are taking risks obviuosly |
23:41 |
erle |
the question is, is this risk a risk you want to take? |
23:42 |
MTDiscord |
<warr1024> Rubenwardy has a good article about it somewhere. People get tempted in designing games to try to simulate real life mechanics more and more precisely and richly and just let interesting things emerge from all that depth, but it's a pretty inefficient way to make a game actually fun. |
23:42 |
erle |
oh, that's realism |
23:42 |
erle |
but i want naturalism |
23:42 |
MTDiscord |
<warr1024> All that "naturalism" means to me is a lot of leafy green textures. |
23:42 |
erle |
as a counter point, harry potter is neither realistic nor naturalistic, because it has no clear rules for magic and nothing bad happens when you give an 8th grader a time machine |
23:43 |
MTDiscord |
<warr1024> Okay, so you want a universe that has rules, they just don't have to be our rules. |
23:43 |
erle |
not only that |
23:43 |
erle |
it has to be believable in some way |
23:44 |
MTDiscord |
<warr1024> Yeah, that might be a good central thread under NodeCore's design. I wouldn't have identified it because I can't really imagine designing something any differently. |
23:44 |
erle |
good scifi authors manage this btw |
23:44 |
erle |
even when they write some gimmicky story |
23:45 |
erle |
battlestar galactica is … weird. but it has some very clear rules that it never really spells out. |
23:46 |
erle |
they hover in the background and i think they are designed to make the viewer uncomfortable in a way |
23:46 |
MTDiscord |
<warr1024> Like I saw a video by Tale Foundry recently where they seemed to be criticizing magic systems for taking the magic out of them by making them systems, but honestly magic without a system feels like I can't really interact with the story, I'm just a passive observer. Even for a book that kinda thing is not good, and for a game it'd be bonkers. |
23:47 |
MTDiscord |
<warr1024> Heh, well, the rule that there should be a limit to one's understanding is not just naturalistic but kinda realistic too... |
23:47 |
MTDiscord |
<warr1024> Like, you can approach predictability but you always have to account for some chance |
23:48 |
erle |
IIRC discrimination in battlestar galactica happens on the human/machine axis and on the monotheism/polytheism axis – and not by skin color or sexual orientation or which god people subcsribe to. it feels consistent, but slightly off. |
23:48 |
MTDiscord |
<warr1024> I actually refuse to correct some jank in NC partly because it's just too difficult and I'm getting diminishing returns on effort, but I also justify it in part that players should never expect perfection, accounting for imperfection is their responsibility. The errors can be reasonably bounded but not eliminated. |
23:49 |
erle |
what would magic without a system even be? |
23:49 |
erle |
in a game, i mean |
23:50 |
MTDiscord |
<warr1024> Monotheists agreeing on one god but not caring too much which one seems a bit weird. Human/machine relationships being contentious seems sort of oddly appropriate in the era of emerging AI. |
23:50 |
MTDiscord |
<warr1024> Magic without a system in a game would probably be just a series of disconnected pre-scripted events that would end up feeling very deus ex machina. |
23:51 |
erle |
regarding accounting for chance, i like how xcom does it: even with a perfect hit, the damage from a non-area-damage projectile is rolled between 0% and 200% of its base damage. this keeps you from making risky moves because those *will* blow up in your face. |
23:52 |
erle |
Warr1024 in battlestar galactica the monotheists do indeed agree i think, but they are discriminated against by the polytheists, who for some strange reason are uncomfortable with someone having only one god. |
23:52 |
erle |
i mean, it does not really make too much sense |
23:52 |
erle |
it just feels like it |
23:52 |
MTDiscord |
<warr1024> An element of chance can add a lot of suspense to situations in the short run, but having predictable average outcomes makes things sane and balanceable in the longer run. I had some fun with some of the probability functions I used in NodeCore... |
23:52 |
erle |
well, with xcom i always have to plan for my perfectly timed assault to go sideways |
23:53 |
erle |
it would be a very boring game if i could just calculate what would happen in my head |
23:54 |
erle |
either i need massive overkill or very good armor or area weapons … as you said, it adds suspense |
23:54 |
MTDiscord |
<warr1024> Heh, that "could always fail" thing isn't something I've been able to make fit everywhere in NodeCore. Once you stop setting yourself on fire, you don't always have to worry about your machines breaking spectacularly. |
23:54 |
erle |
well some things never fail in xcom either |
23:54 |
erle |
applying a medipack never fails |
23:54 |
MTDiscord |
<warr1024> Thankfully having a high skill ceiling means that even if it's possible to get in a technic-like "totally won and now bored" state, nobody actually has yet. |
23:55 |
erle |
or activating a grenade. throwing it, however … if your skill is not too great, it might not get too far! |
23:55 |
erle |
yes, that state is the fun-killer |
23:56 |
erle |
in mineclone2 it was very easy to reach that state with duplication bugs, since it is basically a big grind. so we set ourselves new challenges. the biggest one was flooding the nether (the hell dimension), which entailed a) getting water there b) making a hole in the roof to flood it from above. |
23:56 |
erle |
in the end we settled for a canal (water is illegal in the nether) |
23:56 |
MTDiscord |
<warr1024> Having played both MC technic and MC better than wolves, the amount that the "fun phase of gameplay" was stretched by the challenge level in BTW really inspired my approach to balance in NC. |
23:56 |
erle |
what is better than wolves? |
23:57 |
MTDiscord |
<warr1024> Technic always felt like they wanted you to do something once the hard way, then they just gave you a machine that would make that a thing you no longer needed to care about, and you could move onto the next challenge. Laudable in some ways, but very impractical when the developers were unable to provide a constant stream of new challenges indefinitely. |
23:58 |
MTDiscord |
<warr1024> Better than Wolves was an expansive MC mod (now it's in a mature maintenance-kinda state) that ended up adding a lot of "hardcore/challenge" features during the time I played. |
23:59 |
MTDiscord |
<warr1024> Like, buckets no longer transported water, only a little splash at a time, so if you wanted water higher up than the ocean, you had to pump it up with pumps that required a power supply system and moved water up 1 block each. |