| Time |
Nick |
Message |
| 00:28 |
|
smoke_fumus joined #minetest-dev |
| 00:43 |
|
us_0gb joined #minetest-dev |
| 00:55 |
|
ImQ009 joined #minetest-dev |
| 01:26 |
|
us{0gb joined #minetest-dev |
| 01:47 |
|
VanessaE joined #minetest-dev |
| 02:19 |
|
Miner_48er joined #minetest-dev |
| 02:30 |
|
Megaf joined #minetest-dev |
| 02:41 |
|
djdduty joined #minetest-dev |
| 03:29 |
|
VanessaE joined #minetest-dev |
| 03:30 |
|
OldCoder joined #minetest-dev |
| 04:24 |
|
us_0gb joined #minetest-dev |
| 04:28 |
|
us_0gb joined #minetest-dev |
| 04:29 |
|
salamanderrake joined #minetest-dev |
| 04:30 |
|
Miner_48er joined #minetest-dev |
| 04:37 |
|
OldCoder joined #minetest-dev |
| 05:37 |
|
rambomedic joined #minetest-dev |
| 06:00 |
|
DemonRaiser joined #minetest-dev |
| 06:18 |
|
mrtux joined #minetest-dev |
| 06:52 |
|
us_0gb joined #minetest-dev |
| 07:21 |
|
darkrose joined #minetest-dev |
| 07:42 |
|
mrtux_ joined #minetest-dev |
| 08:05 |
|
nyuszika7h joined #minetest-dev |
| 08:05 |
|
dzho joined #minetest-dev |
| 08:20 |
|
salamanderrake joined #minetest-dev |
| 09:02 |
thexyz |
Hello, |
| 09:02 |
thexyz |
Thanks for reaching out to us. Regarding the following application(s): |
| 09:02 |
thexyz |
[...] |
| 09:02 |
thexyz |
Can you please provide us with additional information regarding the terms of the license in question. It would be helpful if you could specify how the applications in question have violated the LGPL license. |
| 09:02 |
thexyz |
Regards, |
| 09:02 |
thexyz |
The Google Team |
| 09:15 |
RealBadAngel |
how long it took them to answer? |
| 09:18 |
RealBadAngel |
btw, i just thought it could be nice to have clickable buttons as HUD elements, dont you think so? |
| 09:27 |
thexyz |
now I need to cite some parts of LGPL |
| 09:28 |
RealBadAngel |
funny that they do ask for terms of the license |
| 09:28 |
RealBadAngel |
as if LGPL was kinda local law or something they dont know about |
| 09:30 |
|
kahrl joined #minetest-dev |
| 09:32 |
RealBadAngel |
what do you think about the idea to free the cursor (togleable) ingame and thus giving access to hud elements like buttons? |
| 09:33 |
RealBadAngel |
same way as pressing ESC ingame |
| 09:37 |
RealBadAngel |
any comments on above? |
| 09:40 |
VargaD |
How do you plan to use that feature? Any use cases? |
| 09:43 |
RealBadAngel |
show inventory, configure waypoints, change modes of tools, toggle fly/fast etc |
| 09:43 |
RealBadAngel |
whatever |
| 09:44 |
VargaD |
so it is just a feature for mods? |
| 09:44 |
RealBadAngel |
minetest_game is also a bunch of mods |
| 09:45 |
RealBadAngel |
i thought about it after seeing buildcraft on a tablet |
| 09:49 |
RealBadAngel |
and the touch buttons to toggle fly for example |
| 09:50 |
RealBadAngel |
i think this anyway has to be done for android port |
| 09:50 |
thexyz |
no |
| 09:51 |
thexyz |
this is different |
| 09:51 |
thexyz |
there's no concept of just moving your "pointer" without clicking |
| 09:51 |
RealBadAngel |
its already implemented ingame |
| 09:52 |
RealBadAngel |
just press ESC to see |
| 09:52 |
thexyz |
what is? |
| 09:52 |
thexyz |
I'm talking about touch input |
| 09:52 |
RealBadAngel |
moving pointer freely |
| 09:52 |
thexyz |
also check my android branch if interested in touch input |
| 09:53 |
RealBadAngel |
i will be interested soon, im going to buy a tablet soon |
| 09:53 |
RealBadAngel |
but this is not related in fact |
| 09:54 |
thexyz |
I see no connection between the need to move pointer freely in game and android port |
| 09:54 |
RealBadAngel |
it was just my guess |
| 09:55 |
thexyz |
I think we can just add buttons to inventory screen |
| 09:56 |
RealBadAngel |
my original idea was that mods could be able to add own buttons for own inventories, tools, armors, waypoints or whatever |
| 09:57 |
RealBadAngel |
and use hotkey to free/lock the cursor to point them |
| 09:59 |
RealBadAngel |
once user is able to click HUD defined button, formspec can be shown |
| 10:00 |
|
proller joined #minetest-dev |
| 10:02 |
VargaD |
it would be nice to improve connection speed, clients could cache files, it takes so much time to connect to a server with a bunch of mds |
| 11:16 |
|
ImQ009 joined #minetest-dev |
| 11:53 |
|
PilzAdam joined #minetest-dev |
| 12:08 |
|
VanessaE joined #minetest-dev |
| 12:27 |
|
iqualfragile joined #minetest-dev |
| 12:45 |
|
proller joined #minetest-dev |
| 12:45 |
|
smoke_fumus joined #minetest-dev |
| 13:02 |
thexyz |
VargaD: it already works this way |
| 13:16 |
|
bas080 joined #minetest-dev |
| 13:22 |
|
john_minetest joined #minetest-dev |
| 13:33 |
|
EvergreenTree joined #minetest-dev |
| 13:41 |
|
Jordach joined #minetest-dev |
| 13:49 |
|
dzho joined #minetest-dev |
| 13:51 |
|
Evolykane joined #minetest-dev |
| 14:08 |
|
Gethiox joined #minetest-dev |
| 14:10 |
|
bas080 joined #minetest-dev |
| 14:11 |
|
sapier joined #minetest-dev |
| 14:19 |
|
bas080 joined #minetest-dev |
| 14:35 |
|
PilzAdam joined #minetest-dev |
| 14:47 |
|
kaeza joined #minetest-dev |
| 14:48 |
|
NakedFury joined #minetest-dev |
| 15:17 |
|
zat joined #minetest-dev |
| 15:18 |
ShadowNinja |
VargaD: Or rather, xyz and sapìer have implemented separate solutions, neither of which have been added yet. |
| 15:18 |
VargaD |
some kind of client side caching? |
| 15:19 |
Exio4 |
that is already implemented |
| 15:21 |
VargaD |
oh I didn't know that, but it is still quite slow |
| 15:24 |
ShadowNinja |
I meant faster transfer nethods. But the client still has to check to make sure it has everything (the connection does this very slowly) and actually load the mfimes. |
| 15:24 |
ShadowNinja |
files* |
| 15:25 |
proller |
you can tune connection.cpp and get 4-6mbps |
| 15:26 |
|
hmmmm joined #minetest-dev |
| 15:27 |
VargaD |
client could cache the files, so the server just need to send checksums |
| 15:28 |
proller |
make pull about it |
| 15:29 |
VargaD |
it is a blocking issue for me... so I will sometime |
| 15:30 |
ShadowNinja |
VargaD: It does, but I think it checks them one-by-one. |
| 15:30 |
thexyz |
VargaD: it works exactly this way |
| 15:31 |
VargaD |
I haven't checked the source yet |
| 15:31 |
VargaD |
then we need to figure out why it is still slow |
| 15:32 |
VargaD |
at least slow on mycubieboard |
| 15:32 |
VargaD |
:) |
| 15:33 |
sapier |
VargaD you could try my server improvemnet branch it fixes a lot of transmission related problems ... and it's base for ongoing tcp implementation ;-) |
| 15:36 |
VargaD |
thanks sapier I have found it, you have quite a lot of brances :) |
| 15:37 |
sapier |
yes I usually don't delete anything ... guess I should create a new repository :-) |
| 15:46 |
|
Zeitgeist_ joined #minetest-dev |
| 16:26 |
|
blaaaaargh joined #minetest-dev |
| 16:32 |
|
jojoa1997 joined #minetest-dev |
| 16:32 |
|
jojoa1997 left #minetest-dev |
| 16:55 |
|
OWNSyouAll joined #minetest-dev |
| 17:07 |
|
rsiska joined #minetest-dev |
| 17:08 |
|
EvergreenTree joined #minetest-dev |
| 17:23 |
|
Gronx joined #minetest-dev |
| 17:26 |
Gronx |
Is anyone available to answer a question? |
| 17:26 |
celeron55 |
maybe |
| 17:34 |
kaeza |
O.o |
| 17:47 |
celeron55 |
that question was quite easy to answer |
| 17:49 |
proller |
42. |
| 18:08 |
|
Gronx joined #minetest-dev |
| 18:10 |
Gronx |
How do you get assigned to a bug on the github? I'd like to tackle the signs ${text} bug but I'm new to the github system and not entirely sure of the etiquette :-) |
| 18:12 |
celeron55 |
you don't need to get assigned to do it, but you can eg. comment to it that you're working on it |
| 18:12 |
celeron55 |
or just note here; there's no system for that |
| 18:17 |
ShadowNinja |
Gronx: GitHub doesn't seem to support assigning anyone that isn't a core dev unfortunately. |
| 18:18 |
ShadowNinja |
Noting it here is good. |
| 18:20 |
ShadowNinja |
A good implementation would support multiple includes without recursion beyond, say three levels and a limit of five includes and would allow the literal string ${text} and referring to metadata with } in it's name via escapes. |
| 18:22 |
|
Calinou joined #minetest-dev |
| 18:22 |
Gronx |
Cool, I'm going to have a crack at it if nobody minds, seems easy enough to fix. |
| 18:38 |
|
proller joined #minetest-dev |
| 19:07 |
|
iqualfragile joined #minetest-dev |
| 19:32 |
|
Gronx joined #minetest-dev |
| 20:04 |
kaeza |
Hmm... I don't know if a protocol version bump is really needed for #1075. Any insights? |
| 20:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/1075 |
| 20:12 |
hmmmm |
I think that whole fov thing is horrible |
| 20:13 |
hmmmm |
why does the server know about fov at all |
| 20:13 |
|
Calinou joined #minetest-dev |
| 20:14 |
kaeza |
hmmmm, because some mods may want to add some stuff (to e.g. HUD) when zoomed |
| 20:14 |
hmmmm |
so first off |
| 20:14 |
hmmmm |
I think that the fov is something that mods can't dick with |
| 20:14 |
Calinou |
fov as a factor |
| 20:15 |
Calinou |
mods should be able to change fov, as a factor |
| 20:15 |
Calinou |
eg, 0.5, halves fov |
| 20:15 |
kaeza |
Calinou, my pull does that |
| 20:15 |
hmmmm |
second, if you're modifying FOV, you forgot to change the hardcoded FOV setting on the server |
| 20:15 |
hmmmm |
in SendBlocks |
| 20:15 |
Calinou |
so that people using different fov than default don't see their FOV changed permanently |
| 20:15 |
Calinou |
that's only a real problem for higher-than-default FOVs |
| 20:15 |
Calinou |
(much higher than default ones) |
| 20:16 |
kaeza |
hmmmm, hardcoded FOV? |
| 20:18 |
kaeza |
all this pull does is let mods override FOV (with a value > 0) or factor it (< 0) |
| 20:18 |
kaeza |
the client-side FOV setting is untouched |
| 20:29 |
Calinou |
or just a /fov command for changing fov while playing :P |
| 20:30 |
thexyz |
letting mods change client's fov is a nice addition |
| 20:31 |
thexyz |
i.e. for drugs mod |
| 20:31 |
kaeza |
lol |
| 20:31 |
thexyz |
not sure how drugs work D: |
| 20:34 |
celeron55 |
hmm |
| 20:34 |
thexyz |
celeron55: btw, I've replied to google citing some parts of LGPL |
| 20:34 |
celeron55 |
some game code would probably want to set a strict fov for a non-shithead purpose |
| 20:35 |
thexyz |
hope all those apps get removed quick |
| 20:35 |
celeron55 |
oh, i completely forgot that thing; i think i'll reply something now |
| 20:36 |
|
proller joined #minetest-dev |
| 20:36 |
thexyz |
(there are 5 apps now it seems) |
| 20:38 |
thexyz |
what people? |
| 20:40 |
|
EvergreenTree joined #minetest-dev |
| 20:40 |
thexyz |
I think they just don't care |
| 20:41 |
thexyz |
because they're interested in earning money from this stuff it seems |
| 20:41 |
proller |
because they have money for it? |
| 20:41 |
thexyz |
otherwise they'd have provided the up-to-date sources |
| 20:44 |
|
sapier1 joined #minetest-dev |
| 20:55 |
celeron55 |
thexyz: where's the file listing? i think including the relevant part of it to this would be useful |
| 20:55 |
celeron55 |
i tried to search it in my logs for like 15 minutes already but couldn't find it |
| 20:56 |
celeron55 |
i'm sure it was said somewhere on IRC... |
| 20:59 |
thexyz |
http://pastebin.com/ceDanFSb |
| 20:59 |
thexyz |
what do you need it for though? |
| 21:01 |
thexyz |
they openly state it's based on Minetest |
| 21:02 |
thexyz |
in description of every app |
| 21:02 |
celeron55 |
hmm well, i guess i don't then |
| 21:02 |
celeron55 |
(and that listing is useless, it doesn't even show the .so) |
| 21:03 |
thexyz |
how would that be helpful |
| 21:07 |
PilzAdam |
john_minetest, its formspec table |
| 21:09 |
thexyz |
no, I wanted to ask celeron55 how would the full listing of files be helpful |
| 21:09 |
thexyz |
but meh, just citing their description page is enough |
| 21:09 |
thexyz |
I too think formspec table should be merged; I didn't review the code but since it's written by kahrl it can't be bad |
| 21:12 |
thexyz |
that's true |
| 21:12 |
thexyz |
you can fix it and send a pull request |
| 21:12 |
thexyz |
just changing html/css stuff isn't hard |
| 21:13 |
|
proller joined #minetest-dev |
| 21:22 |
|
Calinou_ joined #minetest-dev |
| 21:26 |
|
VanessaE joined #minetest-dev |
| 21:30 |
proller |
400 ppls online... |
| 21:31 |
|
zat1 joined #minetest-dev |
| 21:32 |
VanessaE |
proller: but how much memory did it take and what was the average distance between "players"? |
| 21:33 |
proller |
no problem with mempty |
| 21:33 |
proller |
memory |
| 21:33 |
VanessaE |
define "no problem" |
| 21:34 |
proller |
even if you spend 1mb per user |
| 21:34 |
proller |
now you can buy 32gb per 200$ |
| 21:35 |
VanessaE |
um, no. |
| 21:35 |
proller |
250? |
| 21:35 |
VanessaE |
I just paid $90 for 8GB and that was the best I could find. |
| 21:35 |
proller |
main problem is bandwidth |
| 21:35 |
VanessaE |
and that doesn't work so well when talking about VPS's |
| 21:35 |
VanessaE |
so again, define "no problem" |
| 21:36 |
Calinou |
70 euros for 8GB here... used to be 35-40 euros 1 year ago |
| 21:37 |
VanessaE |
( 70 euros == $96 ) |
| 21:40 |
proller |
if you want to host server for 1000 ppls - buy server for 60$/month |
| 21:40 |
VanessaE |
answer the damn question. define "no problem" |
| 21:41 |
proller |
i can do it from my notebook |
| 21:41 |
VanessaE |
how much memory did that 400- user test require and what was the average distribution distance? |
| 21:41 |
proller |
okay? ;) |
| 21:41 |
thexyz |
just buy this http://www.hetzner.de/en/hosting/produkte_rootserver/ex40 if you need a cheap server |
| 21:42 |
proller |
to reach 400 ppls we must switch to enet and remove all locks, make more threads |
| 21:42 |
proller |
i think 2-4gb of memory then |
| 21:43 |
VanessaE |
and the average distribution of the bots? |
| 21:44 |
proller |
no problem with abm and bots, they just will have slower reaction |
| 21:44 |
VanessaE |
that's not the point. |
| 21:44 |
thexyz |
what do you mean by "average distribution"? |
| 21:44 |
VanessaE |
the point is that if they're all clustered together in the same few mapblocks around the spawn point, the server isn't going to load up that much of the map. |
| 21:45 |
proller |
and 100mbps net maybe can take 1000-3000 clients |
| 21:45 |
VanessaE |
they need to be spread out around the map as widely as possible. |
| 21:45 |
thexyz |
true |
| 21:45 |
proller |
no problem to load 10gb of map to memory |
| 21:50 |
|
iqualfragile joined #minetest-dev |
| 21:51 |
VanessaE |
... |
| 21:52 |
thexyz |
I don't understand why're you asking about memory? memory is cheap and easy to upgrade and is rarely a problem |
| 21:53 |
proller |
i think good and hard goal is 10000 ppls on one server with 1gbps net and good hardware |
| 21:53 |
proller |
(possible) |
| 21:54 |
sapier |
you can't have as much memory as minetest will eat if you connect simultaneously ;-) |
| 21:54 |
thexyz |
why? |
| 21:55 |
VanessaE |
thexyz: are you the one paying for the server?> |
| 21:55 |
sapier |
because minetest will allocate size of textures * some overhead factor for each connect |
| 21:55 |
VanessaE |
it WHAT? |
| 21:56 |
thexyz |
sapier: if your goal is to break it then you for sure can break it |
| 21:56 |
thexyz |
but if your goal is to host many players then you'll have a fast cdn |
| 21:56 |
thexyz |
and media requests will be ignored by such server |
| 21:56 |
sapier |
it will happen no matter what you want there's no prevention included |
| 21:57 |
proller |
or it can be served from shared memory |
| 21:57 |
sapier |
there are plenty of ways to avoid it but for now none is implemented |
| 21:57 |
thexyz |
as I said, if you want to break it you can |
| 21:58 |
thexyz |
there was a patch |
| 21:58 |
thexyz |
and it's a one-line change or so |
| 21:59 |
sapier |
I don't see how you could fix this with a one line change but I'd be glad if this was true |
| 21:59 |
thexyz |
okay, not one line |
| 21:59 |
thexyz |
you just comment it out, problem solved |
| 21:59 |
sapier |
just don't start it ... problem solved ... |
| 22:00 |
thexyz |
are you sure you're getting the point? |
| 22:00 |
sapier |
it's not a fix thexyz at best it's a workaround |
| 22:00 |
thexyz |
we're talking about high load, of course to achieve somethig pretty we'll have to disable things that don't work or work in an awful way |
| 22:00 |
sapier |
but I don't wanna discuss this point as it's useless |
| 22:00 |
thexyz |
indeed so |
| 22:00 |
thexyz |
how's it going with your protocol rewrite? |
| 22:01 |
sapier |
I don't rewrite the protocol I just add tcp support ...about 20% |
| 22:01 |
thexyz |
is the source available? |
| 22:02 |
sapier |
not yet ready for release, but you know I usually release early dev states |
| 22:02 |
thexyz |
I know, it's not ready; but is the source available? |
| 22:02 |
proller |
sapier, dont forgot remove json support |
| 22:02 |
ShadowNinja |
The tcp_connection branch on my fork may be helpful. It doesn't actually work though... |
| 22:03 |
sapier |
I don't remove anything |
| 22:03 |
sapier |
I'm not the one breaking compatibility with every second change ;-P |
| 22:03 |
sapier |
not even if it's crap like json ;-P |
| 22:05 |
ShadowNinja |
My vote's for enet, I heard that TCP and UDP could fight each other for bandwidth. But if you can make it fast, reliable, and efficient... |
| 22:05 |
ShadowNinja |
(And into a well-documented library) |
| 22:05 |
sapier |
and you think enet can do wonders? |
| 22:06 |
sapier |
lol |
| 22:06 |
ShadowNinja |
Hmmm? No, but from what I've heard it does pretty well. |
| 22:06 |
sapier |
enet wont be able to transfere 10 gbps through a 1gbps link too |
| 22:06 |
ShadowNinja |
? |
| 22:07 |
ShadowNinja |
And TCP+UDP will? |
| 22:07 |
sapier |
if you saturate your network link with reliable packets it's gonna be saturated no matter what protocol you drive |
| 22:07 |
ShadowNinja |
Yes, of course. |
| 22:08 |
ShadowNinja |
Read what I said. |
| 22:08 |
sapier |
no you said tcp and udp will strugle for bandwith while enet wont ;-) so I'd exepect enet to find some magic bandwidth for other things ;-) |
| 22:09 |
ShadowNinja |
I meant that when you want to eg send a UDP packet TCP might be using the connection. enet won't get in it's own way. BBL. |
| 22:10 |
sapier |
I don't understand this argument, sorry can you try to explain it to me? |
| 22:10 |
celeron55 |
i think i originally made that argument |
| 22:12 |
celeron55 |
the thing is that if you saturate a TCP link over the same physical connection as a UDP one, the UDP one is going to see more packet loss than it optimally should |
| 22:12 |
sapier |
I still don't see how udp and tcp will have problems? of course if you saturate your link with a channel it'll be saturated |
| 22:12 |
sapier |
yes but packet loss increases per definition as link utilization is maxed out |
| 22:13 |
sapier |
I don't know the exact sweet spot of each single protocol but I remember the 80% number as rough guideline |
| 22:22 |
proller |
why to use tcp if current code can transfer 5+ mbps? |
| 22:33 |
|
Gronx joined #minetest-dev |
| 22:36 |
|
Yepoleb joined #minetest-dev |
| 22:37 |
sapier |
maybe because tcp is proven for myriads of connections to be reliable for a timeframe of about 2 decades now ... guess enet will take some time to be that marture ;-) |
| 22:39 |
sapier |
I'm not sure about it but I'd assume that amount of testing to be close to a proof |
| 22:46 |
|
john_minetest left #minetest-dev |
| 23:02 |
|
djdduty joined #minetest-dev |
| 23:02 |
|
djdduty joined #minetest-dev |
| 23:06 |
|
robmyers joined #minetest-dev |
| 23:10 |
|
robmyers joined #minetest-dev |
| 23:10 |
|
robmyers joined #minetest-dev |
| 23:33 |
|
Miner_48er joined #minetest-dev |
| 23:47 |
hmmmm |
my final say about that... |
| 23:47 |
hmmmm |
TCP is clearly an unoptimal protocol for minetest |
| 23:47 |
hmmmm |
but it's unoptimal for most applications |
| 23:48 |
hmmmm |
UDP isn't very good either, but at least we can tack on what we need - the thing is, we probably won't do a very good job at reinventing the wheel |
| 23:48 |
hmmmm |
enet would be our best bet if it were able to fit in with our code better |
| 23:49 |
hmmmm |
I don't really like 3rd party dependencies because in order for it to fit our use case we usually need to modify a thing or two |
| 23:49 |
hmmmm |
so it's NIH syndrome somewhat, but for better reasons other than "it's not ours" |
| 23:50 |
hmmmm |
also we don't know how optimal enet would be |
| 23:50 |
|
iqualfragile_ joined #minetest-dev |
| 23:50 |
hmmmm |
and we already know enet isn't threadsafe (somebody said that iirc?) so we'd definitely need to modify things to get it to work the way we want it |
| 23:51 |
hmmmm |
either that or add some sort of kludgy mechanism on top |
| 23:56 |
VanessaE |
hmmmm: note that sapier is actively trying to fix the underlying UDP stuff, at least to a point where enet is less necessary |
| 23:56 |
VanessaE |
as we speak, in fact. |
| 23:56 |
hmmmm |
yea |
| 23:56 |
hmmmm |
that would be great if it works out |
| 23:56 |
hmmmm |
I have a feeling we're still going to need tcp though |
| 23:57 |
VanessaE |
he and iqualfragile_ and I have been doing tests to this end. not entirely successful, but the code *does* work |
| 23:57 |
sapier |
I'm working on tcp in parallel |
| 23:57 |
iqualfragile_ |
VanessaE: on _my_ server it works without a flaw :D |
| 23:57 |
VanessaE |
iqualfragile_: well isn't that just special ;) |
| 23:57 |
sapier |
while I haven't completed tcp I think I can do a backward compatible tcp/udp client |
| 23:57 |
VanessaE |
iqualfragile_: you don't have enough outgoing media to trigger the bug, I think |
| 23:58 |
VanessaE |
we're now down to some intermittent hang while receiving item defs |
| 23:58 |
iqualfragile_ |
i do not distribute texturepacks but i do have ambiance mesecons, pipeworks, mobf and some other mods installed |
| 23:58 |
iqualfragile_ |
i think that should be enought |
| 23:59 |
VanessaE |
(I have OVER 7000! items defined, so it takes quite some number of packets to send them all) |
| 23:59 |
iqualfragile_ |
ah, ok, well thats a different dimension i guess |
