| Time |
Nick |
Message |
| 00:00 |
celeron55 |
rarkenin wrote this: http://dev.minetest.net/Rarkenin/Proposal_System |
| 00:01 |
|
Jordach joined #minetest-dev |
| 00:01 |
StrayBytes |
Just as heads-up, instead of rarkenin I now use StrayBytes on IRC. |
| 00:03 |
Jordach |
RealBadAngel, are you making connected textures |
| 00:04 |
RealBadAngel |
Jordach, not really, im makin glass nodes that autoconnects to form surfaces |
| 00:04 |
StrayBytes |
Comments on the proposal proposal? |
| 00:05 |
hmmmm |
have you proposed the proposal system under the new proposal system? |
| 00:06 |
StrayBytes |
Not yes, since the proposal proposal is still a proposal, and not policy yet. |
| 00:06 |
hmmmm |
realbadangel, for now i think what we can do is just make it a config option.... we should call it solid_glass perhaps? |
| 00:06 |
hmmmm |
we'll deal with the drawtype thing later because i'm sure right away people would appreciate that |
| 00:07 |
RealBadAngel |
im adding now scratches to glass surfaces |
| 00:07 |
hmmmm |
ahhhhhh |
| 00:07 |
RealBadAngel |
about the name, im not sure |
| 00:07 |
RealBadAngel |
maybe some other ideas? |
| 00:08 |
hmmmm |
dunno, but i agree with you on not liking the scratches or streaks or whatever those are |
| 00:08 |
Jordach |
RealBadAngel, i'd consider calling it: connectable blocks |
| 00:08 |
hmmmm |
:3 |
| 00:08 |
RealBadAngel |
Jordach, this affects only glasslike nodes |
| 00:08 |
RealBadAngel |
it is very specific |
| 00:08 |
VanessaE |
hmmmm: I consider them equivalent to the streaks normally used to suggest glass in cartoons and technical drawings |
| 00:08 |
hmmmm |
maybe someday we'll be able to expand this idea |
| 00:09 |
Jordach |
RealBadAngel, some blocks such as bookcases would benefit from such |
| 00:09 |
hmmmm |
and then procedurally generate a texture for each face of the connected blocks |
| 00:09 |
Jordach |
because they never magically end do they |
| 00:09 |
hmmmm |
vanessa, same here |
| 00:09 |
VanessaE |
(if we had proper alpha support, I'd be drawing them as a mild, subtle glare, like a reflection or some kind) |
| 00:09 |
hmmmm |
indeed |
| 00:09 |
hmmmm |
see, that's another thing i'd like to do, proper alpha support |
| 00:09 |
Jordach |
like irrlicht will ever support that |
| 00:10 |
StrayBytes |
That's a start towardnice graphics... |
| 00:10 |
Exio |
i would like reflection |
| 00:10 |
hmmmm |
so many things, so little time |
| 00:10 |
Exio |
but i have no f* idea how to code it :D |
| 00:10 |
celeron55 |
StrayBytes: it does have the problem of possibly being prone to heavy compromises in game content / mechanics which lead to zero innovation |
| 00:10 |
hmmmm |
see |
| 00:10 |
Jordach |
hmmmm, focus a one at a time agenda |
| 00:10 |
hmmmm |
people who want these things and use irrlicht just expand irrlicht |
| 00:10 |
hmmmm |
(like Build A World for instance) |
| 00:10 |
StrayBytes |
That's a fair point. |
| 00:11 |
hmmmm |
i don't think it'd be horrible if one of us adds it to irrlicht and have minetest support it that way |
| 00:11 |
celeron55 |
StrayBytes: as for the engine, it could work; i think the proposal proposal is somewhat unclear on how actual code is accepted or rejected |
| 00:11 |
StrayBytes |
I'll work on clearing that up soon. |
| 00:12 |
celeron55 |
i'm not sure if this differs at all in practice from what we have now, though |
| 00:13 |
hmmmm |
just reading that thread now... "Hmmm designed it, he can fix it. Just like we are being asked to implement our own colored lighting." <---- i did not design it, that was blue42u |
| 00:13 |
hmmmm |
i just polished it up a lot |
| 00:13 |
hmmmm |
again, i am NOT interested in maintaining the lua hud |
| 00:14 |
celeron55 |
i answered it there already, you have no need to repeat the discussion in here :P |
| 00:14 |
hmmmm |
responsibility creep at its finest |
| 00:14 |
celeron55 |
everybody knows the facts except mauvebic |
| 00:16 |
StrayBytes |
Proposal updated a bit. |
| 00:17 |
hmmmm |
so hold on a minute, minecraft has colored lighting? |
| 00:17 |
StrayBytes |
And it's a wiki for a reason, feel free to submit edits. |
| 00:17 |
celeron55 |
hmmmm: i think it doesn't |
| 00:17 |
hmmmm |
figured as much... these people are full of shit |
| 00:17 |
celeron55 |
it has similar coloring of light as MT has, except that MT does it right |
| 00:17 |
celeron55 |
8) |
| 00:18 |
hmmmm |
it's easier to add into minecraft because their MapNode structure is already 8 bytes and they don't use much of it from what i understand |
| 00:18 |
VanessaE |
so tell me something: |
| 00:18 |
hmmmm |
still a gross hack though |
| 00:19 |
VanessaE |
why the apparent opposition to adding two more bytes per exotically-colored node? |
| 00:19 |
hmmmm |
i have a feeling this is going to end with me putting my own things off to the side again and adding hardware lighting support and doing colored lighting properly |
| 00:19 |
VanessaE |
(when a node already takes a few dozen bytes anyway I mean) |
| 00:19 |
hmmmm |
two more bytes? |
| 00:19 |
hmmmm |
and no, it doesn't take "a few dozen bytes" |
| 00:19 |
hmmmm |
it's 4 |
| 00:20 |
celeron55 |
"per exotically-colored node" |
| 00:20 |
celeron55 |
you can't add something to some nodes only |
| 00:20 |
celeron55 |
the node structure is static for each node |
| 00:21 |
Exio |
it is just 2 bytes, we already have 42cores cpus and 64gb of ram!!!!!111! </user> |
| 00:21 |
RealBadAngel |
http://i.imgur.com/tNkUdKT.png |
| 00:21 |
celeron55 |
it's not as much about 2 bytes than about the 20 bytes that adding stuff without serious consideration will lead to |
| 00:22 |
hmmmm |
i assume you did that by making a separate connected glass node? |
| 00:22 |
VanessaE |
hmmmm: each node takes four bytes in the map/network? |
| 00:22 |
hmmmm |
less, because of compression, but in memory yes it takes 4 bytes |
| 00:22 |
celeron55 |
over network and on disk much less because they are compressed, but laoded into RAM they are 4 |
| 00:22 |
StrayBytes |
Are packets culled/grouped before being sent out? |
| 00:23 |
StrayBytes |
It seems like there's a ton of overhead for the many small packets which are used in client-server interaction. |
| 00:23 |
hmmmm |
there seems to be a bunch of misconceptions about all this |
| 00:23 |
hmmmm |
i wonder if i should bother explaining exactly what's going on in the forums |
| 00:23 |
RealBadAngel |
hmmmm, scratches are visible only if neighbour node is air or water |
| 00:23 |
VanessaE |
it seems like there should be a lot more than that, but I'll take your word for it. Still, two more bytes and only applied to nodes that have exotic light shouldn't be very heavy in practice. |
| 00:23 |
celeron55 |
also on average a MapBlock's mesh takes multiple times the space of the nodes in it, but the problem here really isn't clients but servers |
| 00:24 |
Exio |
i just added a rand in that "function" where they say they add that stuff |
| 00:24 |
Exio |
and saw it blink |
| 00:24 |
Jordach |
RealBadAngel, that looks like nodeboxy glass |
| 00:24 |
Jordach |
nice. |
| 00:24 |
Exio |
i know how to implement it now, now? |
| 00:24 |
hmmmm |
huh, add what stuff? |
| 00:24 |
celeron55 |
StrayBytes: the MT protocol basically sucks all-around, that isn't a particularly large problem 8) |
| 00:24 |
hmmmm |
yeah, celeron, you really overengineered the protocol |
| 00:24 |
Exio |
hmmmm: the "colored lighting" in the mapblock_mesh |
| 00:25 |
hmmmm |
those things are best left to the tier below application |
| 00:25 |
Exio |
what maudevic (i can't recall his nick) did for changing/tweaking the colors |
| 00:25 |
StrayBytes |
Maybe it's time to rework the protocol from near-scratch, first on paper before diving into code? |
| 00:25 |
Jordach |
mauvebic* |
| 00:25 |
hmmmm |
oh |
| 00:25 |
hmmmm |
mauvebic didn't really do anything of substance there |
| 00:25 |
hmmmm |
he just changed some colors around |
| 00:25 |
Exio |
i was being sarcastic |
| 00:25 |
Exio |
he only changed that and now he is saying that is the "way" to implement that |
| 00:25 |
hmmmm |
:| |
| 00:25 |
celeron55 |
StrayBytes: a new TCP based protocol would probably be a good idea, if somebody has the time to design and implement such |
| 00:26 |
StrayBytes |
I could try to design it, but I suck at C++. |
| 00:26 |
StrayBytes |
I've done a lot with transmission of data, though, at this level and lower levels as well. |
| 00:26 |
Jordach |
or we could implement a more p2p protocol where chat isnt sent to the server exept / commands |
| 00:27 |
celeron55 |
and in fact there's probably not much at all to design; just send the current stuff in a TCP stream |
| 00:27 |
StrayBytes |
And block sends could live in the cloud. No servers at all. |
| 00:27 |
StrayBytes |
And in-game-currency is real bitcoin. |
| 00:27 |
StrayBytes |
:P |
| 00:27 |
|
[Ristovski] joined #minetest-dev |
| 00:28 |
celeron55 |
i once thought after a workday that i could implement some kind of a REST/HTTP voxel server that would do nothing else, and then announce it and wait for somebody to make some part of a client for it 8) |
| 00:30 |
Exio |
well, a random thing, what do you think about https://github.com/minetest/minetest/pull/653? |
| 00:30 |
hmmmm |
oh |
| 00:31 |
Exio |
it is not "compatible" with the actual code, but hm |
| 00:31 |
VanessaE |
I thought that was already in. Obviously not. |
| 00:31 |
hmmmm |
yeah you don't need to do that with the HUD api now |
| 00:31 |
hmmmm |
just set the crosshair_alpha=0 |
| 00:31 |
hmmmm |
and then place your image in the hud api in the center |
| 00:32 |
Exio |
is it possible to 'apply colors' to that? |
| 00:32 |
Exio |
i mean, a white-crosshair-image with a blue/whatever/line, plus you being able to changing that in the client |
| 00:32 |
hmmmm |
you can do all that yeah |
| 00:32 |
celeron55 |
lua hud is kind of not fully useful for that |
| 00:33 |
hmmmm |
why, because it can't be centered? |
| 00:33 |
StrayBytes |
I'll take a few weeks to think and plan out a TCP-based protocol, not that it would necessarily be implemented. |
| 00:33 |
celeron55 |
part of the idea of the custom crosshair is that the player can set any crosshair that he wants on his local client |
| 00:33 |
hmmmm |
if the mods had access to each clients' dimensions, they can do all that on their own and more |
| 00:33 |
hmmmm |
oh. |
| 00:33 |
hmmmm |
alright, i'll add an image override then |
| 00:33 |
celeron55 |
but dunno |
| 00:33 |
StrayBytes |
The server could be used for TCP holepunching reasons, fallback to UDP holepunch, and fall bakc to relaying via the server |
| 00:34 |
Exio |
hmmmm: how do you make the client "colorize" some luahud image? |
| 00:34 |
celeron55 |
StrayBytes: in minetest, the server is authoritative of most things and none of other clients simulate other client's worlds, so that is kind of far fetched |
| 00:35 |
hmmmm |
the client? you can't |
| 00:35 |
Exio |
hm |
| 00:36 |
StrayBytes |
No, what I'm thinking is that player movement and interaction could be done over p2p so the server doesn't have to relay it all. |
| 00:36 |
celeron55 |
StrayBytes: i think the (quite humble) goal for it should be just to make a simple protocol that works because TCP works well |
| 00:37 |
StrayBytes |
Yeah, I probably went too far. |
| 00:37 |
StrayBytes |
But hey, can't I imagine a lag-free world? |
| 00:37 |
kaeza |
misc: a ^tint[R,G,B,A] tex transform or smth like that would be useful, at least to reduce the amount of textures in mods like unified(dyes|bricks), coloredwoods, etc |
| 00:37 |
Exio |
you can imagine whatever you want |
| 00:39 |
hmmmm |
kaeza, that fits in with my colorlike drawtype |
| 00:39 |
StrayBytes |
I'm thinking someday chunks could hop between players so the server would simply keep the clients up to date with simple changes and worry more about the important stuff. |
| 00:39 |
celeron55 |
i do think we should work towards making minetest a bit more network protocol agnostic |
| 00:39 |
hmmmm |
which hasn't been coded yet |
| 00:39 |
RealBadAngel |
http://i.imgur.com/sr48Fwh.png |
| 00:39 |
RealBadAngel |
looks almost good imho |
| 00:39 |
hmmmm |
what's still wrong with it? |
| 00:39 |
VanessaE |
almost? |
| 00:39 |
VanessaE |
it looks very good |
| 00:39 |
StrayBytes |
It would be shortest-path problem all over again :/ |
| 00:39 |
VanessaE |
one thing: don't put blank pixels in the frame. that makes it look like ass |
| 00:40 |
VanessaE |
:) |
| 00:40 |
RealBadAngel |
me? |
| 00:40 |
RealBadAngel |
thats default texture |
| 00:40 |
VanessaE |
I assumed. |
| 00:41 |
celeron55 |
it's not a frame, it's just the edge of bare glass! |
| 00:41 |
VanessaE |
oh I see what's "wrong", the backside streaks are still visible. |
| 00:41 |
VanessaE |
celeron55: maybe not, but to most people I'm sure it looks like a frame. |
| 00:41 |
VanessaE |
and it *still* looks like ass :D |
| 00:42 |
StrayBytes |
http://dev.minetest.net/Rarkenin/Draft_TCP_network_protocol |
| 00:42 |
StrayBytes |
I'll work on it when I can. |
| 00:42 |
StrayBytes |
Which means, unfortunately, not at the moment, |
| 00:43 |
StrayBytes |
Do you think TCP holepunch could be implemented? |
| 00:43 |
celeron55 |
StrayBytes: please leave out all p2p and other unnecessary things, especially if you can't implement it - nobody will have time or interest to actually make it |
| 00:44 |
StrayBytes |
OK. |
| 00:44 |
StrayBytes |
I'll just stick to basics. |
| 00:44 |
StrayBytes |
Thoughif I ever learn C++, that may be my goal for improvement. |
| 00:44 |
celeron55 |
make it the most KISS thing you have ever done |
| 00:45 |
StrayBytes |
Understood. |
| 00:45 |
StrayBytes |
I'll try to keep as much of the existing stuff in place/ |
| 00:45 |
celeron55 |
i do predict you have too little knowledge of MT's serialization things to make anything final though (which makes me think you even starting that is kind of odd, but anyways) |
| 00:46 |
StrayBytes |
I've actually already partially reimplemented part of the serialization in PHP for a bot that I ended up abandoning due to time constraints/ |
| 00:47 |
celeron55 |
also i think just sending "message id" + "data length" + "data" triples will work just fine, so the only thing to define is how many bits to use for each :D |
| 00:48 |
StrayBytes |
Staying in UDP? Or are you talking about TCP already? |
| 00:48 |
celeron55 |
i mean, that'd be just putting the current UDP packets as messages with ids in the TCP stream |
| 00:49 |
celeron55 |
do you think there would be need for anything else? |
| 00:49 |
StrayBytes |
Packet aggregation would be very important when it won't cause more delay for time-sensetive packets. |
| 00:49 |
celeron55 |
of course clean up stuff all-around, but generally otherwise |
| 00:50 |
celeron55 |
doesn't common TCP implementations do somewhat reasonable amount of that automatically? |
| 00:50 |
StrayBytes |
Why would we need message ids in the first place? TCP is already ordered, and length is enough as long as the code doesn't accidentally lose track of the data. |
| 00:51 |
celeron55 |
StrayBytes: id = message name, or command or whatever you'd call it |
| 00:51 |
StrayBytes |
Oh, I thought you were referring to packet ids. |
| 00:51 |
celeron55 |
the title of the data, see clientserver.h |
| 00:51 |
StrayBytes |
I'm aware. I just had the terminology backwards. |
| 00:52 |
celeron55 |
i think they're called commands in the current implementation |
| 00:53 |
|
EduardeCalibal joined #minetest-dev |
| 00:54 |
hmmmm |
[08:47 PM] <celeron55> also i think just sending "message id" + "data length" + "data" triples will work just fine, so the only thing to define is how many bits to use for each :D indeed, sounds like a protocol i worked on for quite some time, except it started each packet with a sanity byte in the header:) |
| 00:54 |
hmmmm |
well that's sufficient for a TCP protocol anyway |
| 00:54 |
StrayBytes |
I'm thinking that the magic numbers should only be sent at the start of a session. |
| 00:55 |
hmmmm |
magic numbers? |
| 00:56 |
hmmmm |
anyway how about this: 1 byte for the packet id, 3 bytes for the length |
| 00:56 |
hmmmm |
in that order |
| 00:56 |
StrayBytes |
0x4f457403 arethe magic numbers. |
| 00:57 |
hmmmm |
erm where is that? |
| 00:57 |
StrayBytes |
clientserver.h line 110 |
| 00:57 |
StrayBytes |
Used at the start of each old packet. |
| 00:57 |
hmmmm |
ew |
| 00:57 |
StrayBytes |
Now should be at the beginning of a session. |
| 00:57 |
hmmmm |
also that number looks odd, can't really read it |
| 00:58 |
StrayBytes |
Should long packets be split by IP fragmentation, or should we use application-level chunking? |
| 00:58 |
hmmmm |
if you're going to put a magic number in, it ought to mean something |
| 00:58 |
hmmmm |
i vote for 'mine' or the like |
| 00:58 |
hmmmm |
application level chunking obviously |
| 00:58 |
hmmmm |
here's how it should work: |
| 00:59 |
Jordach |
*yawn* |
| 00:59 |
hmmmm |
retrieve header, see the data length, expect that many bytes and don't trigger any packet handlers before all the bytes arrive |
| 00:59 |
StrayBytes |
I'm thinking any non-time-sensetive packets are queued until either they've waited a certain amount oftime, a time-sensetive packet is due to be sent, or the queue reaches a certain size. Then they're sent as one to minimize overhead. |
| 00:59 |
VanessaE |
three bytes for a packet length...isn't that a bit excessive? |
| 00:59 |
hmmmm |
vanessae, from what i understand, packets can already be larger than 65536 in minetest |
| 01:00 |
hmmmm |
or am i mistaken? |
| 01:00 |
StrayBytes |
What about having packet length be preset for the commands for which that can be done? |
| 01:00 |
VanessaE |
hmmmm: I would hope not given the average TCP packet is only ~1500 bytes.....shouldn't a new protocol consider that? |
| 01:00 |
hmmmm |
StrayBytes, that adds a lot more complication... |
| 01:00 |
hmmmm |
besides, if you're using TCP, it's assumed that your packet isn't very time sensitive in the first place :p |
| 01:00 |
VanessaE |
(I know we aren't using TCP now, just saying) |
| 01:01 |
hmmmm |
erm |
| 01:01 |
hmmmm |
1500 bytes is the frame size |
| 01:01 |
StrayBytes |
What about making a TCP=UDP hybrid? |
| 01:01 |
hmmmm |
and that's below our application level |
| 01:01 |
hmmmm |
TCP/UDP hybrid? that's what the current protocol already is |
| 01:02 |
VanessaE |
hmmmm: well even when that's the case, a 64k packet is a recipe for horribly latency issues, I think |
| 01:02 |
StrayBytes |
Where's the TCP already in use? Just outsourced to cURL for media ftching, IIRC. |
| 01:02 |
VanessaE |
s/ly/le/ |
| 01:02 |
|
Deivan joined #minetest-dev |
| 01:03 |
hmmmm |
vanessae, no you're not understanding, we send them as they are sent, not all in 65536 byte batches |
| 01:03 |
VanessaE |
OH |
| 01:03 |
VanessaE |
ok |
| 01:03 |
hmmmm |
it's just that the maximum size could be that |
| 01:03 |
hmmmm |
straybytes, yeah, TCP is just used for those things. my idea is that we use TCP for bulk transfers too, such as mapblock transfers |
| 01:04 |
StrayBytes |
A lot of Minetest's packets are horribly small. Not culling them is a true recipe for lag. |
| 01:04 |
StrayBytes |
Mapblocks, that's a start. |
| 01:04 |
VanessaE |
StrayBytes: I think I'd be careful to distinguish lag from latency (even though one will cause the other) |
| 01:04 |
hmmmm |
i know i'm probably getting annoying with using starcraft as an example but it's very well done |
| 01:04 |
StrayBytes |
*latency then. |
| 01:05 |
hmmmm |
starcraft buffers up all the packets to be sent in 250ms intervals |
| 01:05 |
VanessaE |
hmmmm: so? if they did it right, they did it right - so let that program be MT's role model |
| 01:05 |
VanessaE |
(so to speak) |
| 01:05 |
Jordach |
for the networking part |
| 01:05 |
VanessaE |
Jordach: natch |
| 01:06 |
StrayBytes |
That's what I was thinking, except a time-sensetive packet can force the current buffer to be sent. |
| 01:06 |
hmmmm |
sounds fair enough |
| 01:06 |
Jordach |
go look at red eclipses, or openarena's networking code: they are flawless |
| 01:06 |
Jordach |
and highly polished |
| 01:06 |
Exio |
if a FPS doesn't have that plus a lot of client-side prediction |
| 01:07 |
Exio |
it can't be called an actual FPS ;) |
| 01:07 |
StrayBytes |
We'd want to set TCP_NODELAY if we're going to do our own packet culling. |
| 01:07 |
hmmmm |
it'd be more helpful if someone just told us the gist of what they do rather than having us readin git all |
| 01:07 |
hmmmm |
oh, no.... |
| 01:07 |
hmmmm |
don't disable the nagle |
| 01:07 |
hmmmm |
seriously for that stuff we use udp, for bulk transfers we use tcp |
| 01:09 |
VanessaE |
Jordach: how hard do you think it would it be to port openarena's networking model to MT? |
| 01:09 |
Jordach |
depends on the programmer's networking skill |
| 01:09 |
hmmmm |
we don't need their networking model at all |
| 01:10 |
Jordach |
hmmmm, most isps dont like people uploading tcp afaik |
| 01:10 |
hmmmm |
.... |
| 01:10 |
hmmmm |
that's stupid |
| 01:10 |
VanessaE |
Jordach: so I can't send files to my website? um.... |
| 01:10 |
Jordach |
hmmmm, torrenting is tcp |
| 01:10 |
hmmmm |
and |
| 01:10 |
VanessaE |
(I'm pretty sure rsync operates over TCP) |
| 01:10 |
hmmmm |
practically everything else uses tcp |
| 01:10 |
VanessaE |
exactly. |
| 01:10 |
Jordach |
hmmmm, you do realise that tcp is a realy bad ide |
| 01:10 |
Jordach |
idea* |
| 01:10 |
hmmmm |
i do? |
| 01:11 |
hmmmm |
you don't have any idea of what you're talking about, sorry |
| 01:11 |
hmmmm |
TCP is great |
| 01:11 |
hmmmm |
there's nothing wrong with TCP |
| 01:11 |
Jordach |
because: isp willt think youre torrenting |
| 01:11 |
VanessaE |
Jordach: you misunderstand. |
| 01:11 |
hmmmm |
torrenting happens at the application level |
| 01:11 |
VanessaE |
torrents may use TCP, but so does *everything* else nearly. |
| 01:11 |
hmmmm |
everything you can possibly think of uses TCP |
| 01:12 |
hmmmm |
websites, IRC, email, chat programs, etc. |
| 01:12 |
VanessaE |
Jordach: the issue isn't what underlying protocol you use - it's what you DO with it. MT isn't going to be opening hundreds of inbound/outbound connections from a single machine. |
| 01:12 |
hmmmm |
by your logic, your ISP thinks you're torrenting right now by using IRC |
| 01:12 |
Jordach |
hmmmm, maybe |
| 01:12 |
hmmmm |
sit back and think about that for a moment |
| 01:12 |
Jordach |
but then again these days |
| 01:12 |
hmmmm |
"these days" what? |
| 01:12 |
hmmmm |
everything uses TCP |
| 01:12 |
Jordach |
youre isp is paranoid about anything you do |
| 01:12 |
hmmmm |
and it's not going anywhere |
| 01:13 |
VanessaE |
Jordach: simple solution (not suitable for MT): SSL. |
| 01:13 |
Jordach |
VanessaE, does it look like every website has https? |
| 01:13 |
hmmmm |
i'm telling YOU as an expert on the topic that merely using a TCP connection does not flag anything as being a torrent |
| 01:14 |
hmmmm |
i am not going to speak of this silly topic any further, go educate yourself by reading things on the internet if you still don't believe me for whatever reason |
| 01:14 |
VanessaE |
Jordach: any website that values the security of their transmitted data uses https or ssl or some other method of encryption. |
| 01:14 |
Jordach |
youre still going to get slowed down by the isp mechanically. |
| 01:14 |
VanessaE |
mechanically? wtf? |
| 01:15 |
Jordach |
VanessaE, someof them have computers to limit your usage |
| 01:15 |
Jordach |
despite being unlimited |
| 01:16 |
VanessaE |
Jordach: an average MT server only draws between 1kB/sec and 10 kB/sec per user that's playing. you're honestly trying to say that pushing 200 kB/sec (for 20 users, which is around half what my particular connection is capable of btw) is gonna get you flagged as an abusive customer? |
| 01:17 |
Jordach |
VanessaE, depends on the time of length it happens for |
| 01:17 |
Jordach |
isps will jump to conclusions based on high bandwitdh usage |
| 01:17 |
VanessaE |
yeah, and you're not going to be pushing that sort of speed 24/7. |
| 01:17 |
VanessaE |
you |
| 01:17 |
VanessaE |
you're being paranoid now. |
| 01:17 |
VanessaE |
put away your torrent client. |
| 01:17 |
Jordach |
VanessaE, im not torrenting |
| 01:18 |
Jordach |
my uncle runs a server, and he gets buffered by his isp despite being 100mb fibre |
| 01:19 |
VanessaE |
buffered? or throttled? |
| 01:19 |
Jordach |
throttled. |
| 01:19 |
Jordach |
yet he only uses a 1/10th of full power |
| 01:20 |
VanessaE |
1/10 full power = 10 mbps = a constant 1 MByte/sec stream. THAT could get flagged as abusive especially if he's paying only for a "home" connection. |
| 01:20 |
Jordach |
VanessaE, he runs a small home based server farm |
| 01:21 |
Jordach |
6 nodes in total |
| 01:21 |
|
EduardeCalibal joined #minetest-dev |
| 01:21 |
VanessaE |
that's why he's getting throttled. DUH |
| 01:22 |
Jordach |
that;s why he makes the cash to pay for the 100mb line |
| 01:22 |
Jordach |
most isps lie when they say about your speed |
| 01:22 |
Jordach |
and i dont trust speedtest.net |
| 01:23 |
Jordach |
i swear they use UDP |
| 01:23 |
VanessaE |
el wrong-o. |
| 01:24 |
VanessaE |
NO ONE uses UDP for anything serious except for MT and maybe some old voice chat programs |
| 01:24 |
Jordach |
VanessaE, 10kb/s up on http, 0.7mb speedtest.net |
| 01:24 |
VanessaE |
literally 99% of everything going across the Internet is TCP-based. |
| 01:24 |
VanessaE |
there's a reason the root protocol is called TCP/IP. |
| 01:24 |
Jordach |
bull. |
| 01:24 |
VanessaE |
no bull. |
| 01:25 |
hmmmm |
this is an unproductive conversation |
| 01:25 |
VanessaE |
agreed. |
| 01:25 |
Jordach |
i know all current generation video games consoles are udp |
| 01:25 |
hmmmm |
jordach is denying simple truths about how the internet works and it has nothing to do with minetest development |
| 01:25 |
StrayBytes |
Why don't we just have all players run dedicated fibre lines between them and the server? :P |
| 01:25 |
hmmmm |
should probably stop spamming the channel |
| 01:25 |
hmmmm |
what if i started going around and telling people that the water they drink is actually H4O2 and not H2O |
| 01:26 |
StrayBytes |
It's all DHMO anyway. |
| 01:26 |
hmmmm |
"only 10% of water is H2O actually, the water company mechanically limits you if you use H2O" |
| 01:26 |
VanessaE |
Oh G*D anything but DHMO! BAN IT! |
| 01:27 |
Jordach |
hmmmm, there are many people who would believe that |
| 01:27 |
|
kahrl joined #minetest-dev |
| 01:27 |
VanessaE |
hmmmm: ok, the description for water in the default game shall be renamed to "DHMO Source" et.al :D |
| 01:27 |
hmmmm |
lol |
| 01:27 |
StrayBytes |
I got my swim team tovote on not using DHMO during practices. Go figure. |
| 01:27 |
VanessaE |
StrayBytes: no shit? |
| 01:27 |
StrayBytes |
Really. |
| 01:27 |
VanessaE |
*facepalm* |
| 01:27 |
StrayBytes |
That's how stupid everyone is. |
| 01:27 |
kahrl |
speedtest is unrealistically fast because isps prioritize traffic to and from there |
| 01:28 |
kahrl |
not because of UDP or TCP |
| 01:28 |
VanessaE |
ah, the prodigal son returns |
| 01:28 |
StrayBytes |
And to consider I am on that team... |
| 01:28 |
* StrayBytes |
shudders |
| 01:28 |
StrayBytes |
Now can we get back on topic? |
| 01:28 |
VanessaE |
no. :) |
| 01:28 |
StrayBytes |
"Chit-chat goes to #minetest.¨¨ |
| 01:29 |
StrayBytes |
Yeah... I love for these people to jump in off the starting block and land on tiled, rock-hard, rock-dry pool bottom. |
| 01:29 |
Jordach |
kahrl, its their little way of lying to the customer |
| 01:31 |
VanessaE |
Jordach: ok ok enough of this subject. |
| 01:31 |
* VanessaE |
hands StrayBytes a spatula so he can spread those umlauts downward into full quote marks. |
| 01:31 |
Exio |
is there any typedef for core::rect<s32>? |
| 01:32 |
Exio |
nevermind |
| 01:34 |
kahrl |
a protocol idea: someone mentioned leaving out the size field for small fixed commands, maybe the server could send a map<u16, u16> from command ids to command lengths (after TOCLIENT_INIT) |
| 01:35 |
kahrl |
commands that aren't included in this map are dynamic and need a size field |
| 01:36 |
kahrl |
it would obviously be better than hardcoding the commands lengths in the server and client |
| 01:36 |
hmmmm |
a size field is practically nothing in comparison to the beefy header that's already sent |
| 01:36 |
hmmmm |
aggregating commands would be better |
| 01:36 |
kahrl |
there would be no need for the header in the TCP stream |
| 01:37 |
hmmmm |
except for the command id |
| 01:37 |
hmmmm |
you can do that, sure, i don't really think it'll help much though |
| 01:38 |
kahrl |
even the UDP header can be reduced, a lot of the stuff (like pings, split packets and so on) can probably be moved to the TCP side |
| 01:40 |
Exio |
- https://github.com/EXio4/minetest/commit/b5e7d9bd419f96706006247ff6c74d2c34317061 |
| 01:44 |
|
Pentium44 joined #minetest-dev |
| 01:44 |
|
Pentium44 joined #minetest-dev |
| 01:47 |
|
ecube_ joined #minetest-dev |
| 01:47 |
|
Deivan joined #minetest-dev |
| 02:03 |
hmmmm |
alright |
| 02:03 |
hmmmm |
i should tell you guys what i've been up to |
| 02:03 |
hmmmm |
so what i've been working on primarily is the caves |
| 02:03 |
Jordach |
watching ponies? |
| 02:03 |
|
EduardeCalibal joined #minetest-dev |
| 02:04 |
hmmmm |
what i accomplished was making caves into its own self-contained class and it makes many things neater, and i divided up the pieces of the code into neat functions |
| 02:05 |
hmmmm |
defineCave() was removed, what it does is implemented in the constructor |
| 02:05 |
hmmmm |
to define your own defineCave(), then, you need to define your new constructor, override generateCaves(), and make sure it uses your derived cave class |
| 02:05 |
hmmmm |
some other obvious benefits to this is that you can override each individual piece of the cave code |
| 02:06 |
hmmmm |
it's easier to understand |
| 02:06 |
hmmmm |
etc. |
| 02:06 |
hmmmm |
unfortunately i can't do much with code reuse |
| 02:07 |
hmmmm |
the cave class is named "CaveV6" which shall not be modified functionally (if you want to use it in your own mapgen, you need to make a derived class from it) |
| 02:07 |
hmmmm |
modifying cave generation means modifying the terrain features, which is not allowed for v6 |
| 02:09 |
hmmmm |
however, for the V7 cave system, i am modifying V6 much more extensively and it doesn't seem like i can just override a couple functions to get the cleanness and functionality i want |
| 02:10 |
hmmmm |
an unfortunate side effect of this is, effectively, having to duplicate what seems like a lot of functionality (but not code) |
| 02:10 |
hmmmm |
before i start committing things, how many people believe i should move this off into its own file, cavegen.cpp (like dungeongen.cpp)? |
| 02:11 |
Jordach |
yeah |
| 03:33 |
|
VanessaE joined #minetest-dev |
| 04:25 |
hmmmm |
uhh, interesting? |
| 04:25 |
hmmmm |
i kinda figured the caves didn't match up 100% after i did this |
| 04:26 |
hmmmm |
i seemed to have fixed the walled-in-cave problem somehow |
| 04:26 |
Exio |
walled-in-cave? |
| 04:26 |
hmmmm |
s/seemed/seem/ |
| 04:26 |
hmmmm |
yeah, up against a chunk boundary, you'll sometimes get a solid, flat wall of stone where you'd expect the other half of the cave hole |
| 04:27 |
Exio |
ah |
| 04:27 |
hmmmm |
this walled in cave problem isn't the same as the one that i completely understand that happens when multithreading is enabled |
| 05:06 |
hmmmm |
https://github.com/kwolekr/minetest/commit/03868ff8e1bcdcc831b8bd845b8ea7961f7ea1c8 |
| 06:03 |
|
salamanderrake joined #minetest-dev |
| 06:25 |
|
proller joined #minetest-dev |
| 06:30 |
|
ImQ009 joined #minetest-dev |
| 06:35 |
|
ShadowNinja joined #minetest-dev |
| 07:01 |
|
Guest43496 joined #minetest-dev |
| 08:17 |
|
iqualfragile joined #minetest-dev |
| 08:30 |
|
Zeg9 joined #minetest-dev |
| 09:32 |
|
darkrose joined #minetest-dev |
| 09:34 |
|
Jordach joined #minetest-dev |
| 09:37 |
|
VanessaE joined #minetest-dev |
| 09:41 |
iqualfragile |
i know that the average minetest server does not have such problems but: when the uptime is high |
| 09:43 |
iqualfragile |
it does not show a sane uptime on join anymore but sth like 1.71587e+06 |
| 09:45 |
Jordach |
1.71587e+06 is just sanely compressing the amount of time to a smaller number. |
| 09:48 |
|
PilzAdam joined #minetest-dev |
| 09:49 |
iqualfragile |
but 1.71587e+06 does just not look good |
| 09:51 |
sfan5 |
1.71587e+06 equals 1715870 so thats just stupid |
| 09:51 |
VanessaE |
*nod* |
| 09:51 |
iqualfragile |
is the uptime in minutes? |
| 09:52 |
VanessaE |
don't use scientific notation at all (seconds, btw) |
| 09:52 |
VanessaE |
expand it to minutes, hours, days, etc. |
| 09:52 |
iqualfragile |
yeah, that fits |
| 09:52 |
iqualfragile |
because that are only 20 days of uptime |
| 09:53 |
iqualfragile |
and its allready _realy_ outdated… minetest develops too fast |
| 09:53 |
VanessaE |
I was about to say...20 days old, you may as well be running 0.3.x |
| 09:53 |
VanessaE |
:) |
| 09:54 |
iqualfragile |
but i can still connect with git clients |
| 10:01 |
Jordach |
at least were developing and not being still |
| 10:02 |
iqualfragile |
that was ironic |
| 10:02 |
Jordach |
like Minecraft most of the time |
| 10:10 |
|
Jordach left #minetest-dev |
| 10:36 |
|
Jordach2 joined #minetest-dev |
| 10:40 |
|
Jordach2 joined #minetest-dev |
| 10:41 |
celeron55 |
>minetest develops too fast |
| 10:41 |
celeron55 |
some people say exactly the opposite |
| 10:42 |
|
darkrose joined #minetest-dev |
| 10:42 |
|
darkrose joined #minetest-dev |
| 11:09 |
|
Deivan joined #minetest-dev |
| 11:37 |
|
iqualfragile joined #minetest-dev |
| 12:02 |
Deivan |
I have a big amount of the "teleport incident" here... |
| 12:02 |
Deivan |
When my char is teleported to the "(inf, 0,0)" or similar position... :-/ |
| 12:07 |
Deivan |
About the new api, now is possible change a texture at running time? |
| 12:10 |
|
Jordach joined #minetest-dev |
| 12:26 |
sfan5 |
Deivan: i also experienced the teleport bug |
| 12:28 |
Deivan |
Is strange, don't happen in the minimal game, only in my main game... I experienced 5 times in 20 minutes... |
| 12:28 |
Deivan |
:-o |
| 12:28 |
sfan5 |
it happend to me once on jordachs server |
| 12:29 |
Deivan |
:-/ |
| 12:29 |
Deivan |
Well, I have RL work to do... |
| 12:29 |
Deivan |
Someone is writing a FAQ to the API? |
| 12:29 |
Deivan |
I think is very necessary. :) |
| 12:29 |
Deivan |
Well, cya. AFK |
| 12:40 |
|
PilzAdam joined #minetest-dev |
| 12:51 |
|
darkrose joined #minetest-dev |
| 12:51 |
|
darkrose joined #minetest-dev |
| 13:01 |
|
Jordach joined #minetest-dev |
| 13:02 |
|
Jordach joined #minetest-dev |
| 13:16 |
|
NotAidan joined #minetest-dev |
| 13:56 |
|
jojoa1997|Tablet joined #minetest-dev |
| 13:57 |
|
sapier joined #minetest-dev |
| 13:57 |
jojoa1997|Tablet |
i am just wondering if allowing ingame texture switching will ever be on the todo list? |
| 13:57 |
sapier |
https://github.com/minetest/minetest/pull/673 reduce cpu power required to get free object id |
| 13:58 |
sapier |
maybe this reduces object duplication problem too |
| 14:01 |
celeron55 |
"reducing" a bug is exactly what one does not want to do; it is not fixing but will rather make fixing harder |
| 14:01 |
celeron55 |
disclaimer: i don't know what this duplication problem you are talking is about |
| 14:02 |
|
IceCraft joined #minetest-dev |
| 14:03 |
|
IceCraft joined #minetest-dev |
| 14:05 |
sapier |
it's not reducing the bug its removing a silly search algorithm starting at index 1 to get a new id everytime |
| 14:06 |
sapier |
after looking at 200 objects for object 201 it'll look for 201 objects for object 202 ... |
| 14:08 |
sapier |
new algorithm takes next free id thus reusing id's only after 65k have been used thus if the duplication was result of id collision (not prooven to be) this bug would be reduced |
| 14:10 |
|
IceCraft joined #minetest-dev |
| 14:10 |
sapier |
so if you don't want to fix a bug because this may reduce frequency of another bug to happen this shouldn't be added |
| 14:15 |
celeron55 |
i am not arguing against the algorithm |
| 14:16 |
celeron55 |
i am arguing about the questionable secondary benefits you seem to advertise it to have |
| 14:17 |
sapier |
sometimes I feel making anythin right isn't possible if I don't tell possible side effects I get blamed for not telling if I tell I get blamed for not fixing the other thing ;-) |
| 14:19 |
sapier |
but true I was looking for the duplication glitch when discovering this slow oid generation algorithm ... if I find out why objects are duplicated I'll fix that one too :-) |
| 14:25 |
|
Calinou joined #minetest-dev |
| 14:27 |
|
hmmmm joined #minetest-dev |
| 14:31 |
RealBadAngel |
hi hmmmm |
| 14:31 |
RealBadAngel |
http://i.imgur.com/AfERhKw.png |
| 14:32 |
RealBadAngel |
here's where i am atm |
| 14:34 |
hmmmm |
awesome |
| 14:35 |
RealBadAngel |
ive decided not to replace current drawtype but add new one |
| 14:35 |
RealBadAngel |
glasslike_framed |
| 14:36 |
RealBadAngel |
so if you want framed glass, you can craft it with some glass and sticks for example |
| 14:36 |
hmmmm |
sounds good |
| 14:36 |
sapier |
duplication still happens with improved id handling so you don't have to worry about a partly bugfix |
| 14:37 |
RealBadAngel |
this way we have old and new drawtype |
| 14:37 |
RealBadAngel |
and new extra content |
| 14:38 |
hmmmm |
oh my god |
| 14:38 |
hmmmm |
seriously? that's how new items were added? |
| 14:38 |
sapier |
are you talking to me hmmmm? |
| 14:38 |
hmmmm |
why is it that so many things in minetest iterate over several thousands of items in order to accomplish something |
| 14:39 |
hmmmm |
i wonder how much more of this type of code there is hiding |
| 14:39 |
sapier |
yes I was astonished too maybe this didn't matter while there were next to no objects I have about 100 atm |
| 14:39 |
sapier |
singleplayer |
| 14:39 |
hmmmm |
hrm |
| 14:40 |
hmmmm |
your optimization helps but still isn't ideal |
| 14:40 |
hmmmm |
what if we used a bitmap for this |
| 14:40 |
sapier |
driving with my monotail about 50 blocks results in unloading 90 and reloading them when driving back ... while those objects are loaded sometimes my cart is duplicated |
| 14:41 |
sapier |
I don't know how a bitmap would be any faster? |
| 14:41 |
hmmmm |
it'd be 64, 128, or 256 times faster |
| 14:41 |
sapier |
oh to check if it's free |
| 14:42 |
hmmmm |
also |
| 14:42 |
hmmmm |
maybe skip lists would work |
| 14:43 |
sapier |
lot of things can be improved but you may add additional overhead, I'n not sure how optimized stl already is |
| 14:44 |
sapier |
atm regular case will be 1 find operation to get a new id |
| 14:45 |
sapier |
way better than before where common case was number of objects +1 find :-) |
| 14:46 |
sapier |
I've got about 20 carts by now ... and have only crafted 1 |
| 15:06 |
hmmmm |
ridges are tough to deal with :( |
| 15:07 |
hmmmm |
i'm just screwing around underground in v7, and now i have grass growing inside of caverns.. :( |
| 15:07 |
thexyz |
you can as well use stack, fill it with 65536 elements, pop IDs from it when you need a new ID, push ID to it back when it's freed |
| 15:08 |
hmmmm |
that's pretty much how my skip list would work except it's a list instead of a stack and you don't need to add thousands of elements |
| 15:09 |
thexyz |
isn't skip list O(log n)? |
| 15:09 |
thexyz |
average |
| 15:09 |
hmmmm |
perhaps O(1).... |
| 15:09 |
hmmmm |
i wouldn't recommend something that i knew was log n |
| 15:10 |
hmmmm |
the only way things get to be log n is if they deal with a tree structure |
| 15:10 |
hmmmm |
welp |
| 15:10 |
thexyz |
well, according to both my knowledge and wikipedia it's O(log N) |
| 15:10 |
hmmmm |
nevermind |
| 15:10 |
thexyz |
or maybe you're talking about something else |
| 15:10 |
hmmmm |
i was |
| 15:11 |
hmmmm |
hrmmm |
| 15:12 |
hmmmm |
i am not finding the data structure i am thinking of on wikipedia |
| 15:12 |
thexyz |
what is it capable of? |
| 15:12 |
hmmmm |
not sure |
| 15:12 |
hmmmm |
let me just describe it; |
| 15:13 |
|
troller joined #minetest-dev |
| 15:15 |
hmmmm |
you have a linked list of free IDs, every time you get a new ID you grab the first ID from the top of the list and then increment the lower bound of that link. when you go to free it, you just add that ID into the gap where it should be in order, if the ID you're re-adding to the free list connects the adjacent links, then you merge it all into one link |
| 15:15 |
hmmmm |
hm |
| 15:15 |
hmmmm |
that probably wasn't clear at all |
| 15:16 |
sapier |
current algorithm is O(1) for normal case and O(n) for worst case |
| 15:16 |
hmmmm |
wait, actually, is it necessary for new IDs to be the numerically lowest free ID? |
| 15:16 |
sapier |
no it isn't |
| 15:17 |
thexyz |
how's that different from what I was suggesting? |
| 15:17 |
hmmmm |
then WTF, this is trivial |
| 15:17 |
sapier |
my solution is already trivial ;-) |
| 15:17 |
hmmmm |
thexyz, it's different because you suggested we fill a stack with several thousands of elements, here i am making them number ranges stored in links |
| 15:17 |
thexyz |
oh, I see |
| 15:18 |
hmmmm |
well if sapier says his is already decent, i guess that's good enough for me |
| 15:18 |
* hmmmm |
is curious about what his algorithm is called |
| 15:18 |
Jordach |
cant you use binary flags |
| 15:18 |
Jordach |
if one is free, make it usable |
| 15:18 |
hmmmm |
a bitmap? yes, i suggested that |
| 15:18 |
hmmmm |
but it's still O(n) average case |
| 15:18 |
sapier |
it's taking next id everytime checking if it's free in case there is some long time object beeing present after 65k objects have been created it'll have to skip it |
| 15:19 |
sapier |
no |
| 15:19 |
sapier |
my suggestion is O(1) in average case |
| 15:19 |
hmmmm |
i was responding to jordach just now |
| 15:19 |
sapier |
sorry |
| 15:19 |
thexyz |
sapier's is actually O(n) worst case |
| 15:19 |
thexyz |
well, not like it matters |
| 15:19 |
Jordach |
hmmmm, common sensically, you would ensure any empty slots would have their ram freed |
| 15:19 |
Jordach |
and ready to be used at any time |
| 15:20 |
sapier |
yes O(n) in case there have been 65k objects and only recently used object has been freed |
| 15:20 |
hmmmm |
yes, that's called a 'naive' way |
| 15:20 |
hmmmm |
we are not naive people though, we're more clever than that |
| 15:20 |
hmmmm |
so common sense isn't good enough |
| 15:20 |
thexyz |
hmmmm: the problem is "you just add that ID into the gap where it should be in order", if I got this correctly, it's O(n) |
| 15:20 |
sapier |
sorry using any overcomplicated way just to make it complicated sounds insane to me |
| 15:21 |
hmmmm |
ah yeah, thexyz, that is true, freeing would take O(n)... |
| 15:21 |
thexyz |
non-asymptotically sapier's modification is sane enough |
| 15:21 |
thexyz |
I guess we should just put it in |
| 15:21 |
thexyz |
and forget about IDs for a while |
| 15:22 |
hmmmm |
sapier, I mean in reference to what jordach was just saying.. what was already being used is indeed the naive way to get a free number like that, your version is not complicated, but it isn't the naive solution |
| 15:22 |
sapier |
oh I see ... I'd even call the old method "the stupid way" ;) |
| 15:23 |
hmmmm |
naive is just a kinder way of saying stupid |
| 15:23 |
Jordach |
a even simpler approach would be a 2d array, where the flag is stored in the second array co-ordinate |
| 15:23 |
Jordach |
and have the id as the first |
| 15:23 |
sapier |
jordach keeping multiple data structures in sync isn't simple :-) |
| 15:23 |
hmmmm |
and i don't even see how that'd work |
| 15:24 |
sapier |
creating a bitmap marking used ids ... still I assume keeping this in sync is way more risky than any benefit we would get of it |
| 15:25 |
hmmmm |
why do programs use ~/.cache and not /tmp |
| 15:25 |
hmmmm |
ugh |
| 15:26 |
thexyz |
> $XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used. |
| 15:26 |
thexyz |
standards! |
| 15:27 |
sapier |
"standards are linke women ... the other one is always better :-)" ... not quite sure who did say this |
| 15:28 |
|
proller joined #minetest-dev |
| 15:40 |
sapier |
LOL "infostream<<"ServerEnv: WARNING: Performing hack #83274" |
| 15:40 |
sapier |
does anyone know what hack #83274 actually does? :-) |
| 15:40 |
Exio |
seems legit, 83274 hacks in MT source |
| 15:40 |
Exio |
sapier: 1/0=2! |
| 15:41 |
sapier |
seams someone tried to fix this problem and made it worse :-) |
| 15:49 |
|
troller joined #minetest-dev |
| 15:51 |
|
proller joined #minetest-dev |
| 15:51 |
|
Jordach joined #minetest-dev |
| 15:58 |
|
Jordach2 joined #minetest-dev |
| 16:05 |
hmmmm |
[screams internally] |
| 16:06 |
|
WInterspoon joined #minetest-dev |
| 16:06 |
Jordach2 |
btw, WInterspoon is LandMine |
| 16:06 |
WInterspoon |
goood goood |
| 16:06 |
WInterspoon |
booo hooo |
| 16:06 |
Jordach2 |
thexyz, ^ |
| 16:06 |
WInterspoon |
whats wrong kangaroo fucker? cant handle your own? |
| 16:07 |
|
WInterspoon was kicked by thexyz: WInterspoon |
| 16:07 |
Jordach2 |
thexyz, keep operator engaged, he'll be back |
| 16:07 |
Jordach^2 |
nick change again to avoid discovery |
| 16:08 |
thexyz |
who's that? |
| 16:08 |
sapier |
<< wonders what hmmmm discovered |
| 16:08 |
thexyz |
oh, I see |
| 16:09 |
hmmmm |
god damn caves overcomplicate everything |
| 16:10 |
sapier |
strange ... someone thought it'd be a good idea to make "insert" remove something in case of id is 0 :-/ |
| 16:10 |
hmmmm |
the thing i'm experiencing is also a bug in mapgen v6 |
| 16:11 |
hmmmm |
except it's more noticable and annoying here because i just place grass and not grow it |
| 16:11 |
hmmmm |
oh my god. |
| 16:11 |
hmmmm |
so annoying. |
| 16:12 |
hmmmm |
all of our problems would be fixed if we steal a bit from the mapnode structure somewhere and reserve it for "was this placed by caves?" |
| 16:12 |
hmmmm |
but i'm avoiding that |
| 16:12 |
sapier |
btw is luahud merged to an extent starting update of scriptapi split makes sense? |
| 16:12 |
celeron55 |
that's not a good idea because there are many things like caves that might need similar flags |
| 16:13 |
celeron55 |
or, i predict there can be |
| 16:13 |
hmmmm |
luahud is completely merged |
| 16:13 |
sapier |
or someone digging ceiling off a cave |
| 16:13 |
celeron55 |
yes, do the update now; nobody is working on any scriptapi stuff at the moment |
| 16:13 |
celeron55 |
and get it ready before somebody starts to |
| 16:13 |
sapier |
ok then I'm gonna start to update the split changeset |
| 16:14 |
sapier |
adding a folder for scriptapi is common consens? |
| 16:14 |
hmmmm |
yes and modapi too |
| 16:15 |
sapier |
ok just wanted to be sure |
| 16:15 |
hmmmm |
well this sucks |
| 16:16 |
hmmmm |
it is literally impossible to differentiate between air placed by a cave and air placed by 3d noise when carving ridges |
| 16:16 |
hmmmm |
i can solve this by adding a check if below water level, but that's so hackish... |
| 16:19 |
hmmmm |
well, having dirt underneath underwater ridges is something people probably won't miss, and it certainly is better than having bits of grass inside of lava caves |
| 16:22 |
|
Jordach joined #minetest-dev |
| 16:24 |
hmmmm |
neat, naturally occuring obsidian |
| 16:32 |
|
BlockMen joined #minetest-dev |
| 16:32 |
|
proller joined #minetest-dev |
| 16:40 |
BlockMen |
i think i found a bug in HUD api: when i use 'player:hud_change(hudid, "text", "whatever") ' it shows no effect. changing the color works fine 'player:hud_change(hudid, number, 0xFFFFFF)' |
| 16:41 |
BlockMen |
*"number" |
| 16:45 |
hmmmm |
uh oh |
| 16:45 |
hmmmm |
erm for the time being, encase that parameter in {} |
| 16:45 |
hmmmm |
thank you |
| 16:49 |
celeron55 |
that has been reported a couple of times i believe |
| 16:51 |
BlockMen |
celeron55, where? |
| 16:51 |
BlockMen |
hmmmm, you mean here or at my code? |
| 16:52 |
hmmmm |
nevermind, i'll push a fix within the next couple of minutes |
| 16:53 |
BlockMen |
hmmmm, ok, thx |
| 16:56 |
hmmmm |
https://github.com/minetest/minetest/commit/14ba94ad6a0e2176106af08e41d99ad81b03e9e4 |
| 17:03 |
|
StrayBytes joined #minetest-dev |
| 17:12 |
BlockMen |
hmmmm, works fine. thx |
| 17:18 |
PilzAdam |
celeron55, what happened to the "community release" thread? |
| 17:30 |
|
proller joined #minetest-dev |
| 17:37 |
|
emptty joined #minetest-dev |
| 17:44 |
thexyz |
PilzAdam: it's trashed |
| 17:44 |
thexyz |
no idea who did that |
| 17:45 |
hmmmm |
could've been celeron, he didn't like that thread too much |
| 17:46 |
thexyz |
> tl;dr: mito551/minetest is a liberal experimental fork, where your commits are much more likely to be added than in minetest/minetest |
| 17:46 |
thexyz |
well, initially minetest/minetest was aimed to be "a liberal experimental fork, where your commits are much more likely to be added than in celeron55/minetest" |
| 17:46 |
Calinou |
thexyz: I trashed it, because these kinds of dicussion make us look like 4channers |
| 17:47 |
Calinou |
feel free to put it back if you want |
| 17:47 |
Calinou |
don't forget at how new players will look at us. |
| 17:47 |
thexyz |
oh yes |
| 17:47 |
thexyz |
let's suppose it hit bump limit |
| 17:47 |
thexyz |
with all those shitty meme faces |
| 17:48 |
Calinou |
people started using memes in that thread already |
| 17:48 |
Calinou |
:P |
| 17:48 |
thexyz |
so, did mauvebic burn out? |
| 17:49 |
RealBadAngel |
i doubt it, hes too addicted |
| 17:51 |
BlockMen |
Calinou, on the other side discussions like that are typical for a community |
| 17:53 |
Exio |
just a random thing, about -delta, why not redirecting it to here? |
| 17:54 |
|
StrayBytes joined #minetest-dev |
| 17:54 |
sfan5 |
good idea |
| 17:54 |
hmmmm |
i know this is off-topic, but it's simply amazing how much it helped to make dungeons have more rooms and some bigger rooms |
| 17:54 |
sfan5 |
-delta feels like dead |
| 17:55 |
hmmmm |
freakin' epic |
| 17:55 |
Exio |
just +if #minetest-dev mlock and "work done" in that - just saying |
| 17:59 |
celeron55 |
i don't approve censorship of things like that thread |
| 17:59 |
celeron55 |
locking it is fine, but putting it in trash isn't a good thing |
| 18:00 |
sfan5 |
I moved it back and closed it |
| 18:02 |
hmmmm |
i guess the underlying problem is that we call it community-based development but it's really not |
| 18:02 |
celeron55 |
free speech gives a better chance for disagreeing people to fix things that auhtorities can't fix |
| 18:02 |
celeron55 |
it's better in the long run; if we just plain suck, then it's better that we get put out of power by a fork |
| 18:02 |
celeron55 |
not depending on however unlikely it might seem |
| 18:02 |
PilzAdam |
hmmmm, depends how you define community |
| 18:03 |
hmmmm |
other FOSS projects aren't afraid to come out and just say "the <X> team" |
| 18:03 |
hmmmm |
i think it's because of how minetest development is advertised to be completely open, people expect to poop on a .diff and have us merge it |
| 18:03 |
hmmmm |
"can you come up with a reason why it SHOULDN'T be added?" |
| 18:04 |
celeron55 |
uhm |
| 18:04 |
hmmmm |
oh how many times do i hear that |
| 18:04 |
celeron55 |
can you point at any official page that says anything about being completely open or something like that? |
| 18:04 |
hmmmm |
and then look at other projects, where people are actually grateful to the developers and not resentful like the community is to us |
| 18:04 |
hmmmm |
official page? no, i can't |
| 18:06 |
celeron55 |
then we can't do much about it and we'll just let it be - it's worth mentioning that outside contributions are taken in at a steady-ish pace anyway |
| 18:06 |
celeron55 |
as long as the pace isn't 0, we don't have a large problem |
| 18:07 |
|
emptty joined #minetest-dev |
| 18:08 |
hmmmm |
so i guess the best we can do is discourage people from using the phrase "community based" |
| 18:09 |
|
kaeza joined #minetest-dev |
| 18:09 |
hmmmm |
i know i'm guilty of saying that a few times, but i won't anymore |
| 18:09 |
celeron55 |
upstream development is not particularly community driven, because of practical reasons; i think it should be kind of obvious though |
| 18:10 |
celeron55 |
nevertheless i think it is unfair that the people complaining most also will do the least for making things the way they see best |
| 18:11 |
hmmmm |
there seems to be a lot of information about colored lighting in particular... i was toying with the idea of completely explaining what would have to be done precisely and why it's bad and all other things, but then i remembered they probably don't care and/or aren't technical minded enough to understand |
| 18:11 |
PilzAdam |
"This is the first completely community-made release" – http://c55.me/blog/?p=1436 |
| 18:11 |
hmmmm |
s/information/misinformation/ |
| 18:12 |
celeron55 |
it's way more community-made from the standpoint of how previous releases were made |
| 18:12 |
Exio |
PilzAdam: community-made = not-99%commits-by-celeron55 |
| 18:12 |
hmmmm |
hahh |
| 18:12 |
hmmmm |
>Thanks c55 for kicking off this project. It is great to see a productive online community like this. |
| 18:12 |
hmmmm |
"yeah, look at how horrible he is, he ruined minetest!" |
| 18:12 |
celeron55 |
it just seems that for some people "community" means "random people" rather than "people who can be relied on making stuff that is good for the project" |
| 18:13 |
hmmmm |
oh, i misread that |
| 18:13 |
hmmmm |
for some reason i thought it said thanks for kicking c55 off this project |
| 18:14 |
BlockMen |
i think the main problem is, that they dont accept that someone (or a few ppl) have to give the whole thing a direction. if everone put in everthing it just crashes... |
| 18:14 |
celeron55 |
the blog comments are always interesting, the people who talk there tend to be different than those who talk on the forum, or in IRC |
| 18:14 |
PilzAdam |
BlockMen ++ |
| 18:15 |
|
EduardeCalibal joined #minetest-dev |
| 18:16 |
celeron55 |
i do think the core team could be more transparent in what direction it is taking and what modders can expect from their mods being taken upstream and so |
| 18:16 |
PilzAdam |
I see 2 communities here (or "groups" would be a better name): devs and players |
| 18:16 |
celeron55 |
i see three: in addition to those, modders are a really strong one |
| 18:16 |
sapier |
and dev's rarely play at all ;-) |
| 18:17 |
hmmmm |
why on earth do we develop minetest |
| 18:17 |
PilzAdam |
modders are inbetween the players and devs |
| 18:17 |
hmmmm |
this makes no sense |
| 18:17 |
hmmmm |
we never play the game |
| 18:17 |
Jordach |
i think everyone should have a break |
| 18:17 |
hmmmm |
we don't get any money off of it |
| 18:17 |
hmmmm |
it's super time consuming |
| 18:17 |
celeron55 |
maybe stop developing for a month or so and see what people think? 8) |
| 18:17 |
hmmmm |
the pull requests would be in the stratosphere |
| 18:17 |
Jordach |
i think the devs are just too wound up about things |
| 18:18 |
sapier |
I don't have any idea hmmmm ;-) |
| 18:18 |
celeron55 |
they already are, that's not much of a concern |
| 18:18 |
Exio |
celeron55: 50% of the stuff will get ported to lua |
| 18:18 |
Jordach |
Exio, they said that about oregen |
| 18:18 |
Jordach |
did it? |
| 18:18 |
hmmmm |
oregon |
| 18:18 |
hmmmm |
every time i see that, that's what i think of |
| 18:18 |
BlockMen |
im absolutly against a break. minetest is going to be really popular. i a break would throw minetest kinda back |
| 18:19 |
hmmmm |
using the name "oregen" implies that it's something bigger than it really is |
| 18:19 |
PilzAdam |
people of the player community tend to "attack" the core dev that is doing stuff ATM |
| 18:19 |
PilzAdam |
remembet the shitstorm about lava, or obisidian? |
| 18:19 |
PilzAdam |
*remember |
| 18:19 |
celeron55 |
it's a bit like most teenagers hate their parents |
| 18:19 |
BlockMen |
lol |
| 18:19 |
Exio |
hahaha |
| 18:20 |
celeron55 |
or much like |
| 18:20 |
hmmmm |
2edgy4me |
| 18:20 |
BlockMen |
PilzAdam, but that are just a few ppl who do that. i think the main part of the community is ok with the current way of development |
| 18:21 |
PilzAdam |
BlockMen, the main part of the actual players isnt on the forum, IRC or somewhere else |
| 18:21 |
celeron55 |
but really, the atmosphere on this channel is fine, and also the modders are doing fine, and players are too; then just some people start some kind of wars in unreasonable ways |
| 18:21 |
thexyz |
those who are ok are usually silent |
| 18:21 |
PilzAdam |
so we can only guess what they want |
| 18:22 |
celeron55 |
thexyz: that is very true and should be understood by everyone |
| 18:22 |
sapier |
does anyone understand why a activeobjects data is stored in the mapblock where it originally spawned? if that block gets unloaded objects static data is stored while object itself may still active |
| 18:23 |
sapier |
this if this object finaly gets unloaded it will be duplicated |
| 18:23 |
celeron55 |
sapier: the design there is that the static version is always stored somewhere |
| 18:23 |
celeron55 |
and it should work so that when the block in which the active object is unloaded, it will load the old block, erase it from there and write it to the new one |
| 18:24 |
celeron55 |
because if the static data is removed for the time when it is active, any crash would delete the object completely |
| 18:24 |
sapier |
so it's either duplicate or loose :-/ there has to be a better way |
| 18:24 |
celeron55 |
s/in which the active object is unloaded/in which the active object is is unloaded/ |
| 18:25 |
celeron55 |
sapier: there's no duplicate in the way i said |
| 18:25 |
celeron55 |
if it works |
| 18:25 |
celeron55 |
i guess it doesn't work in the current implementation |
| 18:26 |
sapier |
no it doesn't seam to work my current working hypothesis is a block where static data really is stored can't be loaded for some reason this objects static data isn't deleted -> duplication |
| 18:27 |
celeron55 |
maybe it has broken in some of the emergethread/whatever stuff |
| 18:27 |
sapier |
sorry missing some , in this sentence |
| 18:28 |
sapier |
I'm gona try to move static data to block where object is on the fly ... imho not best solution but worth a try |
| 18:29 |
celeron55 |
what kind of items have even been reported to be duplicated? |
| 18:29 |
sapier |
any moving entity |
| 18:29 |
celeron55 |
ok; that makes sense |
| 18:31 |
Jordach |
i have had that bug |
| 18:31 |
Jordach |
i dropped a mese pick and i got two |
| 18:31 |
sapier |
feels like the faster an entity moves the more likely to be duplicated as well as the more lag the more duplication too |
| 18:33 |
PilzAdam |
unrelated: someone should fix the not loading entities bug |
| 18:34 |
sapier |
define "not loading entities"? |
| 18:34 |
PilzAdam |
you move away from one, then come back and it isnt there |
| 18:35 |
sapier |
sometimes I feel I'm the only one fixing the strange bugs while all others only add new bugs(features) ;-) |
| 18:35 |
PilzAdam |
move away again and come back some times and it sometimes appears, sometimes not |
| 18:36 |
sapier |
that one :-) |
| 18:36 |
sapier |
if I find it while looking for the other one I wont tell anyone :-) |
| 18:37 |
|
Ukrainian_Reaper joined #minetest-dev |
| 18:38 |
BlockMen |
i have a question: wouldnt it make sense to change the current way of adding mods? if i want use a mod at build aswell in minetest i have to store it 2 times. |
| 18:39 |
BlockMen |
it would be better to make it like at textures, so "global" using |
| 18:39 |
|
kaeza joined #minetest-dev |
| 18:39 |
Jordach |
"global" mods would be nice |
| 18:40 |
BlockMen |
and after watching a few videos of mintest newbies i noticed that there are a few who had problems with the game selection, and then with the mods too |
| 18:43 |
sapier |
isn't that what common mods are for? |
| 18:43 |
PilzAdam |
sapier, no |
| 18:43 |
PilzAdam |
common mods are for game creators |
| 18:44 |
sapier |
still you could use it that way |
| 18:44 |
PilzAdam |
no, not really |
| 18:44 |
BlockMen |
sapier, but then the mods folder is senseless |
| 18:45 |
kaeza |
I think this would be useful for that https://github.com/minetest/minetest/pull/599 |
| 18:46 |
kaeza |
I don't know about the implementation, but the basuc udea is good IMHO |
| 18:46 |
PilzAdam |
no, common mods are something completly different |
| 18:46 |
kaeza |
-u+i |
| 18:47 |
PilzAdam |
just add something like mods/all/ for game independent mods |
| 18:47 |
kaeza |
in fact, I was thinking about something like what c55 suggested in that pull |
| 18:47 |
BlockMen |
PilzAdam, that would be enough i gues |
| 18:47 |
BlockMen |
*guess |
| 18:48 |
PilzAdam |
why do people still not get the idea of common? |
| 18:50 |
kaeza |
PilzAdam, can you explain exactly what is the idea behind common? |
| 18:50 |
PilzAdam |
it contains mods, that games can load |
| 18:51 |
PilzAdam |
so a copy of "default" in all games is not needed |
| 18:51 |
StrayBytes |
I request a channel op in #minetgest |
| 18:54 |
|
emptty joined #minetest-dev |
| 18:55 |
kaeza |
PilzAdam, what #599 proposes is to add more "common mod dirs" (or rather, the ability to "import" mods from any game) |
| 18:57 |
kaeza |
some people (imcluding myself) do not like modifying things like minetest_game and common |
| 18:57 |
PilzAdam |
yes, people shouldnt do that |
| 18:58 |
PilzAdam |
common mods are just for game creators, to not copy mods from the default game(s) |
| 18:59 |
|
proller joined #minetest-dev |
| 19:11 |
|
kaeza joined #minetest-dev |
| 19:11 |
|
john_minetest joined #minetest-dev |
| 19:14 |
celeron55 |
installing mods is kind of hard for newbies now though |
| 19:14 |
celeron55 |
i mean |
| 19:14 |
celeron55 |
i actually didn't even think of this aspect |
| 19:15 |
celeron55 |
there is only mods/minetest pre-created, but if they use some other game they need to put them into mods/build or so |
| 19:16 |
PilzAdam |
IMO we should install all mods simply in mods/ and they are for all games |
| 19:16 |
kaeza |
maybe in mods/all |
| 19:16 |
PilzAdam |
if people want the for some games only, they can disable them in the GUI |
| 19:16 |
hmmmm |
erm celeron, just curious, is it possible that emergePlayer is called before map is generated when starting a new map? |
| 19:16 |
hmmmm |
actually it's not just possible, it's the only way that it can happen |
| 19:16 |
celeron55 |
hmmmm: umm... i think that is the common case especially in singleplayer |
| 19:16 |
hmmmm |
..which explains why findSpawnPos() never freaking works |
| 19:17 |
kaeza |
also, a recurring problem in mods, is that people who download from github get a "foomod-master" dir, while the game expects "foomod" |
| 19:18 |
PilzAdam |
kaeza, the -master can be ignored by the engine |
| 19:18 |
kaeza |
can the game just ignore the "-master"/whatever part? |
| 19:18 |
hmmmm |
don't you see? no spot it looks at will ever be good because it's always content_ignore because it hasn't even been generated yet |
| 19:18 |
kaeza |
ah |
| 19:18 |
celeron55 |
ignoring it isn't implemented |
| 19:18 |
PilzAdam |
someone just needs to code it |
| 19:18 |
hmmmm |
so it _always_ iterates 1000 times and it _always_ gives up on a good spot |
| 19:18 |
celeron55 |
hmmmm: i don't know, just fix it :P |
| 19:19 |
hmmmm |
this is the true cause of the spawning too high bug |
| 19:19 |
celeron55 |
no need to find anyone to blame |
| 19:19 |
hmmmm |
but the thing is, it can't work by design |
| 19:19 |
celeron55 |
it probably originally had some code for loading blocks for it or so |
| 19:19 |
hmmmm |
unless you'd like it to just guess |
| 19:20 |
hmmmm |
what? it didn't |
| 19:20 |
celeron55 |
i mean, that code comes from the very original versions of MT |
| 19:20 |
celeron55 |
it's way older than your work here |
| 19:20 |
hmmmm |
it uses Map::getNodeNoEx() which calls getBlockNoCreateNoEx() |
| 19:20 |
hmmmm |
so it's never created |
| 19:20 |
celeron55 |
do you insist that i go look up on some 2010 versions to see what they did? |
| 19:20 |
hmmmm |
no.... |
| 19:20 |
celeron55 |
or shall we rather be productive |
| 19:21 |
hmmmm |
i'm just saying that it's likely that it never really worked properly in the first place unless you modified Map::getNodeNoEx() within the time that it did work and then stopped working |
| 19:22 |
celeron55 |
i'm not going to say anything about likeliness without actually looking up stuff |
| 19:24 |
celeron55 |
i will say that it has probably been broken for a long time |
| 19:24 |
celeron55 |
(which is obvious) |
| 19:24 |
hmmmm |
yeah because people were blaming it on me for a time |
| 19:25 |
hmmmm |
anyway what i figure i'll do is if it returns content_ignore, i'll assume that the current point is good to spawn at since nobody evidently built there yet or otherwise modified the land |
| 19:29 |
hmmmm |
oh i'm sorry |
| 19:29 |
hmmmm |
it was my fault |
| 19:30 |
hmmmm |
i have selective vision it seems |
| 19:38 |
|
john_minetest left #minetest-dev |
| 19:39 |
hmmmm |
https://github.com/minetest/minetest/commit/daddd3770663655c3723ff9a4f4aba6010b1645c |
| 19:41 |
|
salamanderrake joined #minetest-dev |
| 19:42 |
PilzAdam |
finally |
| 19:44 |
Exio |
:D |
| 19:50 |
hmmmm |
well pilzadam, there are two very long-time bugs that were fixed like you wanted to see... black trees, spawning too high |
| 19:50 |
hmmmm |
the thing is, this doesn't happen all the time because there was a reason why they weren't fixed quickly |
| 20:18 |
|
serengeor joined #minetest-dev |
| 20:23 |
|
StrayBytes joined #minetest-dev |
| 20:41 |
|
EduardeCalibal joined #minetest-dev |
| 20:53 |
emptty |
PilzAdam: do you plan to tag your mods repos at some point or you prefer to go with a rolling release? (just out of curiosity) |
| 20:54 |
PilzAdam |
I prefer rolling release |
| 20:54 |
PilzAdam |
I dont work on most mods anymore |
| 20:54 |
PilzAdam |
so I mostly push bugfixes |
| 20:54 |
|
jojoa1997|Tablet joined #minetest-dev |
| 20:54 |
PilzAdam |
(or random suggestions by users) |
| 20:55 |
emptty |
someone should implement a popularity contest in minetest, where the usage of some given mods is reported to a server that can run stats |
| 20:56 |
emptty |
something like http://qa.debian.org/popcon.php?package=minetest |
| 20:57 |
|
iqualfragile joined #minetest-dev |
| 20:58 |
|
BlockMen left #minetest-dev |
| 21:02 |
|
sapier1 joined #minetest-dev |
| 21:11 |
|
Guest56729 joined #minetest-dev |
| 21:22 |
RealBadAngel |
http://i.imgur.com/5d6sNvO.jpg |
| 21:22 |
jojoa1997|Tablet |
nice |
| 21:23 |
proller |
btw ubuntu prescie - minetest 0.3.1+dfsg-2 |
| 21:25 |
iqualfragile |
proller: yeah, thats a *bit* outdated but there is a ppa |
| 21:25 |
iqualfragile |
-.- … i guess you already knew that |
| 21:26 |
proller |
yes, 2-3 years old soft is normal for ubuntu and debian 8) |
| 21:26 |
emptty |
this will propagate from debian automatically. I was too late for the last round of integration, so minetest will not be uptodate for the next stable of ubuntu (nor for the one of debian) |
| 21:26 |
emptty |
but only servers are using the stable versions |
| 21:27 |
emptty |
most debian users are on the rolling release (testing) |
| 21:27 |
Exio |
hey, i'm on squeeze, still! :P |
| 21:27 |
emptty |
and minetest will migrate as soon as the next stable comes out |
| 21:27 |
emptty |
Exio: this explains why you feel the need to install some soft from the source :-P |
| 21:28 |
Exio |
(being annoying other time to the core devs) what about https://github.com/minetest/minetest/pull/657 - https://github.com/minetest/minetest/issues/517 ? |
| 21:29 |
Exio |
emptty: hm, :P |
| 21:42 |
|
Tracerneo joined #minetest-dev |
| 21:42 |
Tracerneo |
Hi |
| 21:43 |
emptty |
I tried to install a mod in /usr/share/games/minetest/mods under linux; it gets detected and can be activated, but the textures are not found when starting the game |
| 21:43 |
emptty |
it seems that only the lua is found in this location |
| 21:48 |
Exio |
any op? |
| 21:52 |
|
OWNSyouAll joined #minetest-dev |
| 22:07 |
|
kaeza joined #minetest-dev |
| 22:09 |
sapier1 |
https://github.com/minetest/minetest/pull/674 |
| 22:09 |
PilzAdam |
sapier1, capital letter at the beginning of commit messages |
| 22:09 |
sapier1 |
this seams to fix duplication glitch too, at least did now dupplication happen since I aded it but I don't understand why |
| 22:13 |
sapier1 |
so if someone understands why I'm really curious about it |
| 22:27 |
|
kaeza joined #minetest-dev |
| 22:31 |
|
salamanderrake joined #minetest-dev |
| 22:44 |
VanessaE |
who cares about capital letters in a commit message? |
| 22:44 |
sapier1 |
PilzAdam ;-) |
| 22:44 |
VanessaE |
evidently ;) |
| 22:45 |
sapier1 |
it'd be great if someone tested this changeset I'm not sure if it's only working in my case as I don't completely understand it ... the comment in there didn't help either |
| 23:02 |
|
VanessaE joined #minetest-dev |
| 23:10 |
|
sapier1 left #minetest-dev |
| 23:20 |
|
dexter0 joined #minetest-dev |
