Time |
Nick |
Message |
00:14 |
|
diemartin joined #luanti |
01:10 |
|
ireallyhateirc2 joined #luanti |
01:16 |
|
SwissalpS joined #luanti |
02:28 |
|
Glorfindel joined #luanti |
02:39 |
|
ShadowBot left #luanti |
02:39 |
|
ShadowBot joined #luanti |
02:53 |
|
lemonzest joined #luanti |
02:56 |
|
CRISPR joined #luanti |
03:00 |
|
SFENCE_arch joined #luanti |
03:36 |
|
CRISPR joined #luanti |
04:58 |
|
CRISPR joined #luanti |
05:00 |
|
MTDiscord joined #luanti |
05:21 |
|
bdju joined #luanti |
06:22 |
|
SFENCE_arch joined #luanti |
06:37 |
|
Oblomov joined #luanti |
06:39 |
|
Oblomov joined #luanti |
07:00 |
|
coconutdoggo joined #luanti |
07:28 |
|
tarsovbak joined #luanti |
07:31 |
|
gregon joined #luanti |
07:41 |
|
tarsovbak left #luanti |
07:41 |
|
GreenXenith joined #luanti |
07:42 |
|
MTDiscord joined #luanti |
08:22 |
f_ |
what are all these bans? |
08:22 |
f_ |
or is this just trying to mirror #minetest or? |
08:43 |
|
ireallyhateirc joined #luanti |
08:57 |
dudz |
why worry about it f_ :> |
08:57 |
f_ |
I'm not worried :p |
09:07 |
|
bodiccea joined #luanti |
09:24 |
MTDiscord |
<theidealist> lol more people confused by the bridge |
09:24 |
MTDiscord |
<theidealist> hello from discord |
09:25 |
MTDiscord |
<theidealist> honestly I thought IRC was a thing people used ten years ago, not nowadays |
09:28 |
MTDiscord |
<theidealist> actually more like twenty years ago |
09:30 |
Oblomov |
though to be fair the bridge on this side should also be renamed from MTDiscord |
09:31 |
MTDiscord |
<theidealist> on this side different usernames appear for the different people |
09:46 |
|
loggingbot_ joined #luanti |
09:46 |
|
Topic for #luanti is now The official Luanti (formerly Minetest) channel | General, player and modding discussion is on-topic. If in doubt, post here | Responses may take a while, be patient | Rules: https://dev.luanti.org/irc/#rules | Development: #luanti-dev | Server list: https://luanti.org/servers | IRC logs: https://irc.luanti.org/ |
09:47 |
|
SFENCE_arch joined #luanti |
09:57 |
|
jaca122 joined #luanti |
10:07 |
f_ |
@theidealist who is confused by the bridge? |
10:07 |
f_ |
ah, had to scroll up :p |
10:09 |
bdju |
minetest was easy to abbreviate. how are people shortening "luanti"? |
10:10 |
bdju |
LAT? |
10:10 |
|
SFENCE joined #luanti |
10:11 |
sfan5 |
LTI |
10:11 |
sfan5 |
maybe |
10:14 |
|
PoochInquisitor joined #luanti |
10:14 |
rubenwardy |
LT |
10:37 |
celeron55 |
in general, you're not supposed to shorten it |
10:38 |
celeron55 |
if you really need to, e.g. for a technical reason, then it's lt |
10:39 |
celeron55 |
(like if you're writing C and need to prefix every symbol or whatever) |
10:48 |
celeron55 |
it's easy to end up with "lt" if you start from nothing and start adding letters. "" = doesn't mean anything; "l" = could mean almost anything including lua, not good; "lt" = basically nobody uses this for anything gaming, engine or even computing related, it's perfect |
11:02 |
|
bodiccea joined #luanti |
11:03 |
|
wsor40355 joined #luanti |
11:10 |
|
SFENCE joined #luanti |
11:12 |
|
SFENCE joined #luanti |
11:18 |
|
Kimapr joined #luanti |
11:29 |
|
Kimapr_ joined #luanti |
11:36 |
|
wsor4035 joined #luanti |
11:38 |
|
SFENCE joined #luanti |
12:02 |
|
mrkubax10 joined #luanti |
12:03 |
|
PoochInquisitor joined #luanti |
12:11 |
|
mrkubax10 joined #luanti |
12:41 |
|
kimapr joined #luanti |
13:22 |
bdju |
"Lt." could be used in any military game. I was thinking take a letter from the start of each syllable to match MT's logic |
13:23 |
bdju |
LNT (removing the vowels) could work too |
13:27 |
|
SFENCE joined #luanti |
13:31 |
|
chilledfrogs joined #luanti |
13:38 |
|
Thermoriax_1 joined #luanti |
13:43 |
|
shaft joined #luanti |
13:44 |
shaft |
Is there an engine way to turn an object completely unmovable, so that set_pos velocity and accelleration become nullops? |
13:46 |
shaft |
There are situations where it would be best if I could do that. Like the entity of my target node which can be moved by Mineclonia now that they have a new redstone system and it was also able to be moved out of the node by that one bow mod before I forked it |
13:46 |
shaft |
Because it applied velocity which slowly moved it out of the node |
13:49 |
sfan5 |
attach it to something |
13:49 |
MTDiscord |
<luatic> but then the parent could be moved |
13:49 |
|
Kimapr_ joined #luanti |
13:49 |
MTDiscord |
<luatic> what i would do - but this is a hack - is to get the metatable of any objref, then hook these functions, test if the objref is marked as immovable and if so, do nothing |
13:50 |
MTDiscord |
<luatic> you can get the objref metatable ("method"table to be precise, the real metatable is hidden) for example from the first joined player |
13:50 |
MTDiscord |
<luatic> which is another hack. speaking of which, we should probably expose this methodtable. |
13:52 |
shaft |
So every unique objectref has its own metatable I can hook into? |
13:52 |
MTDiscord |
<luatic> no |
13:52 |
MTDiscord |
<luatic> they all share the same methodtable |
13:52 |
MTDiscord |
<luatic> including players |
13:52 |
MTDiscord |
<luatic> which is why you would need to check that the objref you're looking at is marked as immovable |
13:53 |
shaft |
If I do that in a couple mods it would stack up and slow down the game |
13:53 |
shaft |
And I can't do it in a game because I don't own any of these games |
13:54 |
MTDiscord |
<luatic> yes, adding logic to methods slows things down, but a single if immovable[self] then return end should be fine. |
13:54 |
shaft |
I could check if the hack has been applied with a global to only apply it once but I'd still be slowing things |
13:54 |
MTDiscord |
<luatic> of course you would only hook the method once. |
13:55 |
MTDiscord |
<luatic> anyways ultimately the proper solution would be to have a - game-side - API to mark objects as immovable. |
13:56 |
MTDiscord |
<luatic> eventually there might be a luanti API (because the engine could leverage knowing this to optimize some things), but it's not high priority since games and mods can already do something here themselves. |
13:58 |
|
Guest9 joined #luanti |
13:59 |
shaft |
Oh right. Falling nodes use an assertion that fails if you apply velocity to them. |
13:59 |
shaft |
That crashes the game |
13:59 |
MTDiscord |
<luatic> that's also a somewhat sane thing to do |
14:01 |
MTDiscord |
<luatic> disabling set_(pos|velocity|acceleration) is a dirty hack. essentially the precondition for all of these methods is that the object is not static. if the caller calls any of these methods, they (falsely) expect it to do something. if you call these on a static object, that's a bug. making it a no-op is essentially a workaround swapping one bug for another in the hopes that one is the more useful bug. |
14:01 |
sfan5 |
you can apply velocity to falling nodes just fine? |
14:03 |
MTDiscord |
<luatic> actually yeah, which falling nodes are you talking about? because this can't be the builtin one, there's only a single assert(moveresult) in the implementation. |
14:04 |
MTDiscord |
<luatic> thinking about it, i also vaguely recall being able to give falling nodes a velocity when i worked on some explosions some years back. |
14:04 |
shaft |
Ah no. That was parenting entities |
14:04 |
shaft |
I crashed the game when I parented a falling node to an entity |
14:04 |
shaft |
I mixed it up |
14:05 |
MTDiscord |
<luatic> parenting a falling node to an entity doesn't really make sense. falling nodes are physical entities, attachments are essentially visual. |
14:06 |
MTDiscord |
<luatic> but either way, if a static entity decides to be strict and asserts its static-ness, that's fine |
14:09 |
shaft |
But people don't like me crashing their game |
14:09 |
|
diemartin joined #luanti |
14:10 |
MTDiscord |
<luatic> people also don't like buggy games that make no sense and corrupt everything |
14:10 |
MTDiscord |
<luatic> to some extent you can try to workaround everything and appease everyone but it just doesn't compose well. you're building on shaky foundations. |
14:12 |
MTDiscord |
<luatic> that's how you end up with something like JS' type coercions, where you try to be "helpful" no matter how nonsensical the operation the programmer asks the language to perform, and end up being unhelpful |
14:14 |
shaft |
Crashing as a solution to a every problem is some idea from 50 years ago. Small nuisances shouldn't crash the server. If my target entity node combination comes apart. Unloading and loading the mapblock willc remove the entity and the node can be dug and placed and the world is whole again. It's not nice when it happens but not tragic either. |
14:15 |
shaft |
Lua has type coercion too and it works fine. |
14:17 |
MTDiscord |
<luatic> Lua has much more limited type coercion and I wouldn't rely on it at all; if anything I'd only rely on "..." .. 42 coercing 42 to a string (but even that isn't the best idea because you don't control the exact formatting). |
14:18 |
MTDiscord |
<luatic> I'm not saying crashing is the solution to every problem, that's sort of the opposite extreme. I don't litter my code with assertions. But yes, for many problems you want to crash, unless you know there is a good way to recover. |
14:22 |
shaft |
Lua has perfect and real type coercion whereas for Javascript it's some completely random shit depending on the type of the left operator, the right operator and the sign. |
14:22 |
shaft |
"1" + "1" = 11; 1..1 = "11" |
14:23 |
shaft |
The operator coerces the type to what it returns. Easy and predictable. No stupid overloading concentation |
14:23 |
shaft |
*concatenation |
14:31 |
shaft |
"..." .. 42 = "...42" |
14:33 |
shaft |
Yes for long numbers formatting can be important when converting to a string to not lose precision but in many cases it isn't. Often you're just going to show the string to the user as information. |
14:37 |
shaft |
std:out in C++ only prints 5 digits after the decimal sign. You'd lose information too. |
14:47 |
|
ireallyhateirc joined #luanti |
14:58 |
MTDiscord |
<luatic> I know how Lua type coercion works and it is better than JS, but still not ideal. Your "1" + "1" = 11 example is wrong by the way. "1" + "1" = 2 in Lua. |
14:59 |
shaft |
Yes that's what I meant |
14:59 |
MTDiscord |
<luatic> The problem is that type coercions are somewhat inconsistent with strong typing. 1 + a == 2, but a ~= 1 (and ({[1] = true})[a] == nil), because a == "1.0" is possible. |
15:00 |
|
SFENCE joined #luanti |
15:00 |
MTDiscord |
<luatic> It makes a string act like a number for some operations. But for other operations it's still a string and you get wrong and surprising results. It hides the fact that you're wrongly using a string as a number. |
15:02 |
shaft |
You having to be aware of the types you're handling is generally a thing with dynamically typed languages. |
15:02 |
MTDiscord |
<warr1024> The correct answer to "1" + "1" should really be "error: addition is not defined for string, string" |
15:02 |
shaft |
No, I think it's fine. |
15:03 |
MTDiscord |
<warr1024> Yeah, I mean, it's "wrong" but it's not horribly wrong. |
15:03 |
pgimeno |
erring out on the user doing something they shouldn't benefits everyone - the user corrects their code and the cost for the engine programmer was just the effort of adding an error condition. For the engine programmer, figuring out what can be done instead of erring out is costly, and it can lead to surprises for the user. |
15:03 |
MTDiscord |
<luatic> shaft: By that logic we can go right back to JS. |
15:04 |
MTDiscord |
<luatic> If you're fully aware of all types at all times, surely some quirky behavior for weird combinations of types wouldn't bother you, because you'd never run into it, because you're perfectly doing the static type checking in your head at all times. |
15:04 |
shaft |
That would be arguing for no type coercion but type coercion is useful. I'm putting numbers into strings all the time and it would be a real bitch without it. |
15:04 |
MTDiscord |
<warr1024> Ironically the sanest way to handle types in JS is to make like Perl and stringly-type everything. So ${x} + ${y} if you want concat, Number(${x}) + Number(${y}) if you want addition. Makes for a kinda cumbersome experience tho. |
15:05 |
MTDiscord |
<warr1024> oh nice, de-discordification ate the backticks |
15:05 |
shaft |
That makes your code unreadable. Why do you think people stop using Perl? |
15:06 |
shaft |
Just use === and always make sure of the types when you receive them |
15:07 |
MTDiscord |
<luatic> No type coercion is very much a fine solution frankly. If you do want to have coercion, it should not be one that can error, and it should ideally be unique. For example embedding smaller number types in larger ones is fine. Number to string is always doable (though it is debatable how it should be done). String to number isn't always doable. |
15:07 |
MTDiscord |
<luatic> As I've already said, I consider the exception for .. converting numbers to strings fine, the rest is problematic (though only mildly so) and Lua would be better off without it. |
15:08 |
jonadab |
Lua is an annoying language in so many ways. |
15:08 |
jonadab |
But I think it was chosen because it's easy to embed, rather than easy to write in. |
15:08 |
MTDiscord |
<warr1024> === only applies to checking equality. There's no type-sane version of + or most other operators. |
15:09 |
MTDiscord |
<luatic> shaft: "Always make sure of the types when you receive them" - ah yes, the good old TypeScript at home (at runtime). |
15:09 |
shaft |
Typescript sucks |
15:09 |
MTDiscord |
<warr1024> Lua chose annoyance as its stance on the annoyance/insanity trade-off. |
15:09 |
jonadab |
Sanity is overrated. |
15:10 |
MTDiscord |
<warr1024> Typescript is about being aware of what the types you expect are, not of what the types actually are 😏 |
15:10 |
jonadab |
If there's even any such thing as sanity, which is arguable :-) |
15:10 |
MTDiscord |
<warr1024> Sanity is indeed overrated but it can be very useful if you can get any into your code. |
15:10 |
jonadab |
I'm more concerned about clarity, honestly. |
15:11 |
jonadab |
I mean, sanity does also matter at some level. I don't want an O(n!) algorithm, for example. |
15:11 |
MTDiscord |
<warr1024> Making code that's clearly not sane is surprisingly feasible. |
15:11 |
jonadab |
No, I mean clarity as in, you look at the code and immediately understand, correctly, what it does. |
15:12 |
shaft |
Lua is a perfect language in so many ways. Just look at how it combined strings and symbols into one. Or arrays and hash tables. Then look at Ruby. Converting the symbols into strings and back is such a tedious bullshit. 99% I don't even care about string concentation performance and when I do putting them in an array I join is good enough. |
15:12 |
jonadab |
You can write *unclear* code in any language, of course. |
15:12 |
MTDiscord |
<luatic> Yep, it relies on the programmer's discipline, and Lua tends to force less of that. |
15:12 |
shaft |
And arrays and hash tables being different makes it harder to rewrite code. |
15:12 |
shaft |
Being easy to transform code is a good property for a language |
15:13 |
shaft |
*Making it easy |
15:13 |
MTDiscord |
<luatic> Lua unfortunately doesn't make that terribly easy |
15:13 |
jonadab |
I mean, conceptually, arrays and hash tables are both sets, but they're sets with very different organizational properties. |
15:13 |
MTDiscord |
<warr1024> I like clarity too, but I rarely worry about it at the code level. It's more important to be able to look at a program and say "oh, this takes the data from this thing, transforms it into this format, and sends it over there" rather than like "oh this is a sort algorithm" or "oh this deep-merges two objects" |
15:13 |
MTDiscord |
<luatic> Because it's so dynamic. But with the right discipline it can be easy again. |
15:13 |
MTDiscord |
<luatic> jonadab: I'd say they're both maps. |
15:13 |
MTDiscord |
<luatic> But you can map sets to maps and map maps to sets so whatever. |
15:14 |
jonadab |
Oh, you're thinking associative arrays then. |
15:14 |
jonadab |
Yes, those are basically the same as hash tables except for maintaining a certain order. |
15:14 |
MTDiscord |
<luatic> Associative array is such a clunky term for what has been known in mathematics as a map for like forever. |
15:14 |
shaft |
In Lua you can almost always add data to a table that is used for something else. |
15:15 |
MTDiscord |
<luatic> I don't consider any ordering part of the definition of map or associative array. |
15:15 |
MTDiscord |
<luatic> That would be an "ordered" or "sorted" map. |
15:15 |
MTDiscord |
<warr1024> "associative array" sounds like it should mean something like the property that [...[a, b], c] is the same as [a, ...[b, c]] or something, really. |
15:15 |
|
gregon joined #luanti |
15:15 |
MTDiscord |
<luatic> With "ordered" typically used for maps where the order doesn't depend on the keys (e.g., insertion order) and "sorted" used for maps that are sorted by the keys (e.g. C++'s map) |
15:16 |
MTDiscord |
<warr1024> Haha, for "unordered set" you could use the term "commutative array" ▶️ |
15:16 |
jonadab |
An associative array is just a list of pairs. But semantically, you expect to use it like a hash table or lookup table. |
15:17 |
jonadab |
Though you can also read off the pairs in order (i.e., in the order in which they were added to the list, unless some are inserted into the middle later for some reason). |
15:17 |
MTDiscord |
<warr1024> Referring to a map as a "hash" is a case of overgeneralization of implementation-specific terminology, but it probably stuck in many cases because it's nice and short. |
15:17 |
shaft |
Lua gives you flexibility and if you have strings you already know to be numbers you can do math with them. |
15:17 |
MTDiscord |
<warr1024> "Map" itself is a bit weird because it often refers to the operation of applying a function to each element in a sequence. |
15:18 |
jonadab |
Perl programmers have a tendency to think of "hash" as meaning essentially the same thing as "collection of data". |
15:18 |
jonadab |
Because the hash table is by far Perl's most flexible data structure, in terms of how you can use it, so it gets used for everything. |
15:18 |
MTDiscord |
<warr1024> A hash in perl is a map. |
15:20 |
MTDiscord |
<warr1024> C# uses the term "dictionary" for the same concept and it's one of the more awkward-sounding ones (though ironically that makes it one of the clearest) |
15:20 |
jonadab |
push @record, +{ id => $id, name => "Foo", quux => sub { fooquux(@_); }, ... }; |
15:21 |
jonadab |
There are other languages that use the word "dictionary" that way, but I've never worked much in any of them. |
15:21 |
jonadab |
I wanna say Python might be an example of that? Not sure, I might be mixing it up with another language. |
15:21 |
MTDiscord |
<warr1024> Using a term that nobody would sanely choose for anything is a good way to make sure the meaning isn't ambiguous 😄 |
15:22 |
jonadab |
I mean, you can always coin entirely new words, but you have to do a limited amount of that; if you do too much of it, nobody can keep them all straight. |
15:23 |
MTDiscord |
<warr1024> It makes you imagine data types like the "encyclopedia" where the values are stored externally and can be much heavier, or a "thesaurus" type where the values are sets of other keys inside the same dictionary. |
15:23 |
jonadab |
There's such a thing as taking analogies too far. |
15:24 |
MTDiscord |
<warr1024> A thesaurus is conceptually a directed graph with sorted key lookup 🤔 |
15:24 |
jonadab |
Next we're going to be asking, if a hash is a lookup table, what is a quiche? |
15:24 |
MTDiscord |
<warr1024> Indeed, taking an analogy too far is usually necessary to unlock its full humor potential. |
15:25 |
jonadab |
Fair enough. |
15:25 |
jonadab |
Maybe we should spell our new data type "keesh" so people know how to spell it, and don't get it confused with food. |
15:26 |
MTDiscord |
<warr1024> A quiche is basically "hash" inside a pie crust, right? So, a serializable hash of some sort. Maybe a compact data structure that uses relative addressing so it's always easily portable. |
15:26 |
jonadab |
I thought quiche was basically a baked omelette. |
15:27 |
MTDiscord |
<warr1024> The "knowing how to spell it" thing could be a real problem. You don't want somebody trying to invalidate the quiche after entries thyme out. |
15:30 |
jonadab |
That's very sage advice, thank you. |
15:37 |
|
SFENCE_arch joined #luanti |
15:42 |
shaft |
A quiche is Pascal. |
15:57 |
|
chilledfrogs joined #luanti |
16:05 |
|
SFENCE joined #luanti |
16:05 |
|
sys4_ joined #luanti |
16:12 |
|
jaca122 joined #luanti |
16:54 |
|
SFENCE joined #luanti |
16:59 |
|
Desour joined #luanti |
17:02 |
jonadab |
Hah. Pascal. The person who taught me Pascal, was so obsessed with elegant purity, that he insisted each procedure (or function, or whatever Pascal calls them; this was in the early nineties, so my memory is imprecise) should only ever be called from one location in the program. |
17:03 |
jonadab |
It could be called _conditionally_ but couldn't be called from more than one place. |
17:05 |
jonadab |
The assignments we did in class were all sufficiently simple that this wasn't a problem, but I'm sure you can imagine what it would be like to do anything complex under such a restraint. |
17:08 |
celeron55 |
that does seem silly |
17:20 |
jonadab |
He also constantly referred to the purity of the original Pascal creator's version of the language and bemoaned any extensions that anyone else had added. |
17:21 |
jonadab |
(The school computer lab at the time had Mac Plus systems, so we had Turbo Pascal. At least it wasn't the Borland product for DOS, I think he would have gone into conniptions.) |
17:23 |
|
SFENCE joined #luanti |
17:58 |
|
[MatrxMT] joined #luanti |
18:02 |
|
MisterE123 joined #luanti |
18:09 |
MisterE123 |
test |
18:09 |
[MatrxMT] |
<MisterE> test |
18:09 |
[MatrxMT] |
<MisterE> test |
18:10 |
|
SFENCE joined #luanti |
18:11 |
ireallyhateirc |
Minetest? your test! |
18:11 |
SwissalpS |
if any given function may only be called from one location, might as well put it in-line. The only benefit his method has, is adding some clarity to code |
18:17 |
|
Talkless joined #luanti |
18:21 |
Desour |
is it true that you need some sort of rank in discord to talk in the bridged luanti irc room? |
18:22 |
Desour |
( src: ROllerozxa, last paragraph of <https://forum.luanti.org/viewtopic.php?p=442124#p442124>) |
18:26 |
MTDiscord |
<mistere_123> It is true |
18:27 |
SwissalpS |
just don't use that app :p |
18:27 |
ROllerozxa |
from the #info channel in the discord server: |
18:27 |
ROllerozxa |
> You must be at least Members rank to chat in #luanti-irc, and at least Regular Members rank to chat in #luanti-dev-irc |
18:28 |
ROllerozxa |
(exceptions are also given for people who need to access IRC but aren't so active in the server of course) |
18:29 |
Desour |
how are these ranks defined? |
18:31 |
Desour |
I understand that one wants to limit spam in the dev channel. but the normal #luanti is meant for chit chat, so it should be open to anyone. (is there maybe some issue with being able to ban people in discord from irc?) |
18:33 |
ROllerozxa |
it's not possible to delete messages on IRC, so if someone's account on the discord server gets compromised (which is not very infrequent) and starts spamming it will be replicated across the bridge |
18:33 |
ROllerozxa |
the ranks represent a certain amount of mese shards (XP) that you gain through sending messages in the server |
18:37 |
MTDiscord |
<luatic> Yep, it's not a high or arbitrary bar to clear, essentially just another simple "verification" requirement to deal with spambots. |
18:37 |
Desour |
I see, thx for all the information! |
20:01 |
|
bodiccea joined #luanti |
20:13 |
|
gregon left #luanti |
20:24 |
|
chilledfrogs joined #luanti |
20:30 |
|
Verticen joined #luanti |
20:56 |
|
ineva joined #luanti |
21:49 |
|
lagash joined #luanti |
22:04 |
|
Kimapr joined #luanti |
22:10 |
|
illwieckz joined #luanti |
22:16 |
|
silverwolf73828 joined #luanti |
22:17 |
|
liceDibrarian joined #luanti |
22:23 |
|
diceLibrarian2 joined #luanti |
23:34 |
|
panwolfram joined #luanti |