Time |
Nick |
Message |
00:08 |
|
LipkeGu joined #minetest-dev |
00:08 |
LipkeGu |
hi |
00:09 |
|
LipkeGu left #minetest-dev |
00:25 |
|
crazyR joined #minetest-dev |
00:33 |
|
chchjesus joined #minetest-dev |
01:47 |
|
OldCoder joined #minetest-dev |
01:51 |
|
alexxs joined #minetest-dev |
02:54 |
|
Wuzzy2 joined #minetest-dev |
03:46 |
|
compunerd joined #minetest-dev |
04:06 |
|
FR^3 joined #minetest-dev |
04:13 |
|
FR^3 joined #minetest-dev |
04:14 |
|
alexxs joined #minetest-dev |
04:23 |
|
FR^3 joined #minetest-dev |
04:40 |
|
Hunterz joined #minetest-dev |
05:00 |
|
Zeno` joined #minetest-dev |
05:30 |
|
Kalabasa joined #minetest-dev |
05:37 |
|
chchjesus joined #minetest-dev |
05:59 |
|
Miner_48er joined #minetest-dev |
06:04 |
|
Megaf joined #minetest-dev |
06:20 |
|
book` joined #minetest-dev |
06:41 |
|
Hunterz joined #minetest-dev |
06:46 |
|
book` joined #minetest-dev |
07:12 |
|
leat joined #minetest-dev |
07:34 |
|
T4im joined #minetest-dev |
07:36 |
|
jin_xi joined #minetest-dev |
08:29 |
|
FR^2 joined #minetest-dev |
08:30 |
|
cib0 joined #minetest-dev |
08:41 |
|
ImQ009 joined #minetest-dev |
08:43 |
|
Calinou joined #minetest-dev |
08:46 |
|
Krock joined #minetest-dev |
09:03 |
|
kilbith joined #minetest-dev |
09:03 |
|
nrzkt joined #minetest-dev |
09:15 |
|
DFeniks joined #minetest-dev |
09:34 |
|
ImQ009 joined #minetest-dev |
10:17 |
|
cib0 joined #minetest-dev |
10:43 |
|
Kalabasa joined #minetest-dev |
11:17 |
Calinou |
http://minetest.net/old_releases |
11:17 |
Calinou |
Ubuntu One is shut down, there is a dead link |
11:17 |
Calinou |
(the installer ones) |
11:30 |
|
DFeniks joined #minetest-dev |
11:32 |
|
Player_2 joined #minetest-dev |
11:55 |
|
crazyR joined #minetest-dev |
11:59 |
|
deltib joined #minetest-dev |
12:01 |
|
chchjesus joined #minetest-dev |
12:04 |
|
Kalabasa joined #minetest-dev |
12:20 |
|
Hunterz1 joined #minetest-dev |
12:20 |
|
daswort joined #minetest-dev |
12:20 |
|
mrtux joined #minetest-dev |
12:21 |
|
JZTech103 joined #minetest-dev |
12:29 |
|
cib0 joined #minetest-dev |
12:35 |
|
MinetestForFun joined #minetest-dev |
12:43 |
|
SopaXorzTaker joined #minetest-dev |
12:48 |
|
B joined #minetest-dev |
12:50 |
|
Zeno` joined #minetest-dev |
13:00 |
Zeno` |
will apply https://gist.github.com/Zeno-/e7e28439f396ee7a70df in a few minutes (trivial fix) |
13:04 |
|
book` joined #minetest-dev |
13:39 |
|
shadowzone joined #minetest-dev |
13:54 |
|
ImQ009 joined #minetest-dev |
14:01 |
|
Amaz joined #minetest-dev |
14:16 |
|
ElectronLibre joined #minetest-dev |
14:23 |
|
MinetestForFun joined #minetest-dev |
14:42 |
|
SopaXorzTaker joined #minetest-dev |
14:42 |
|
PilzAdam joined #minetest-dev |
14:44 |
|
cib0 joined #minetest-dev |
14:55 |
|
twoelk joined #minetest-dev |
14:55 |
|
CraigyDavi joined #minetest-dev |
15:04 |
|
hmmmm joined #minetest-dev |
15:21 |
|
SudoAptGetPlay joined #minetest-dev |
15:22 |
SudoAptGetPlay |
Settings(path):remove(key) always returns true even if it's not deleting the key (I didn't forgot Settings(path):write() ) |
15:23 |
Zeno` |
maybe it's a bug |
15:24 |
T4im |
hm given that I found another method that had the same problem, maybe there's a general lua api problem with returning success? ;) |
15:25 |
T4im |
#2015 that is |
15:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/2015 -- minetest.dig_node(test_position) does not fail when expected -- always returning true |
15:26 |
SudoAptGetPlay |
In my case I try to remove "default:sword_diamond" from a items.conf and remove hapilly returns true but the key 's still there :/ |
15:27 |
T4im |
should I try to reproduce? |
15:28 |
T4im |
hm.. wait.. do you call write after remove? |
15:29 |
T4im |
ah |
15:29 |
T4im |
you wrote that already :D |
15:29 |
T4im |
sorry |
15:29 |
SudoAptGetPlay |
http://pastebin.com/Fbs7WDcQ |
15:39 |
SudoAptGetPlay |
Should I create a github issue ? |
15:39 |
T4im |
sure |
15:40 |
|
blaze joined #minetest-dev |
15:41 |
T4im |
yea, I can reproduce this |
15:42 |
SudoAptGetPlay |
#2264 |
15:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/2264 -- Settings(path):remove(key) always returns true |
15:43 |
T4im |
well actually, the problem seems to be one earlier |
15:43 |
T4im |
the fact that it doesn't persist the removal |
15:44 |
|
kilbith joined #minetest-dev |
15:47 |
T4im |
https://github.com/t4im/mtt/blob/master/api_test/data_handling.lua#L37 <-- fails here |
15:48 |
T4im |
the removal happens correctly in ram |
15:48 |
T4im |
apparently |
15:51 |
T4im |
I'd say :write() is the one that should not return true |
15:51 |
SudoAptGetPlay |
But I don't test it |
15:51 |
T4im |
I did ;) |
15:53 |
SudoAptGetPlay |
oh I see now |
15:53 |
T4im |
as you see it does not fail the assertion after the remove, both to_table and get correctly show the removal |
15:54 |
SudoAptGetPlay |
indeed, write is guilty |
15:55 |
T4im |
ha actually |
15:55 |
T4im |
the last segment fails too |
15:55 |
T4im |
so that's the third function returning true that shouldn't |
15:56 |
SudoAptGetPlay |
So Issue shall become 'Settings(path):write() still saves removed keys' or something ? |
15:56 |
T4im |
no you can actually keep it |
15:56 |
T4im |
settings:remove("cobble") should have failed, but din' |
15:56 |
T4im |
didn't |
15:57 |
SudoAptGetPlay |
Only certain strings are a problem then ? |
15:57 |
T4im |
no… :D |
15:57 |
T4im |
cobble was a key that didn't exist |
15:57 |
T4im |
and it STILL returned true |
15:57 |
T4im |
when else but then should it fail? |
15:58 |
SudoAptGetPlay |
Yeah pretty meesed up |
15:58 |
SudoAptGetPlay |
*messed |
16:01 |
T4im |
its more likely that it fails to actually write… so that might be 2 different problems there… the one of failing to communicate fail and then to fail to write to the file |
16:10 |
|
shadowzone joined #minetest-dev |
16:12 |
|
SopaXorzTaker joined #minetest-dev |
16:19 |
|
roniz joined #minetest-dev |
16:21 |
|
Amaz joined #minetest-dev |
16:26 |
|
nrzkt joined #minetest-dev |
16:33 |
Zeno` |
#2265 |
16:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/2265 -- Increase MapBlock::actuallyUpdateDayNightDiff() performance by 2-8x by Zeno- |
16:34 |
Zeno` |
night |
16:34 |
Zeno` |
haha! that's almost a pun considering the function I was looking at |
16:34 |
kilbith |
not 50000% :( i'm disapointed |
16:34 |
Zeno` |
no, not 50000% :( |
16:36 |
|
ImQ009 joined #minetest-dev |
16:36 |
Zeno` |
oops! |
16:36 |
* Zeno` |
amends |
16:37 |
nrzkt |
Zeno can you commit #2214 and #2209 please ? |
16:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/2214 -- Performance improvement -> Craftdef.cpp: Improve loop and mathematics for CraftDefinitionShaped::check by nerzhul |
16:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul |
16:38 |
Zeno` |
I agree with both of those PRs |
16:38 |
Zeno` |
I can't merge them (including my own) until the feature freeze is over, though :/ |
16:39 |
nrzkt |
erf |
16:39 |
Zeno` |
hmmmm, are you here? |
16:40 |
Zeno` |
The problem is that I think Wayward_One and others are still having problems with simplesingleplayer mode |
16:40 |
Zeno` |
despite yesterday's advances |
16:40 |
hmmmm |
hello |
16:40 |
Zeno` |
So I'm not really sure what's happening |
16:40 |
Zeno` |
hi, hmmmm |
16:40 |
hmmmm |
i'm here but not quite here |
16:41 |
hmmmm |
cool performance increase |
16:41 |
hmmmm |
I think the day/night system is whack and that's the first thing to change when refactoring lighting |
16:41 |
hmmmm |
also expireDayNightDiff is useless iirc |
16:44 |
|
Selah joined #minetest-dev |
16:50 |
Zeno` |
yeah I was looking at that function as well |
16:50 |
kilbith |
guys, Gettext did not worked on the latest ubuntu 14.04 build |
16:51 |
kilbith |
^ Tesseract |
16:51 |
Zeno` |
nrzkt, I want this performance thing with simple singleplayer fixed as much as you do so we can move forward |
16:51 |
|
Eivel joined #minetest-dev |
16:52 |
|
disablec1 joined #minetest-dev |
16:53 |
Zeno` |
but I'm out of ideas. The only thing I can think of (suspect) is the mesh update thread |
16:53 |
Zeno` |
kahrl discussed the possibility of reducing that thread's priority the other day but I'm unsure if it makes much difference |
16:54 |
Zeno` |
it makes a difference for me, but... |
16:54 |
* Zeno` |
cries |
16:59 |
|
ottodachshund joined #minetest-dev |
16:59 |
|
blaze joined #minetest-dev |
16:59 |
|
ImQ009 joined #minetest-dev |
17:01 |
nrzkt |
okay Zeno, |
17:01 |
nrzkt |
i hope this release will be available soon |
17:02 |
Zeno` |
can I have a tissue? |
17:06 |
|
JakubVanek joined #minetest-dev |
17:06 |
|
blaze` joined #minetest-dev |
17:08 |
|
rubenwardy joined #minetest-dev |
17:10 |
|
darkwing_duck joined #minetest-dev |
17:14 |
JakubVanek |
hello, I think client-server communication protocol should be reviewed in next release |
17:15 |
JakubVanek |
for example there is s16 in sao damage but u8 in player damage |
17:16 |
Krock |
there can be mobs with more than 255 hp |
17:23 |
|
book` joined #minetest-dev |
17:24 |
|
JakubVanek joined #minetest-dev |
17:33 |
|
ElectronLibre left #minetest-dev |
17:33 |
VanessaE |
mod profiler apparently needs to use wider datatypes for some fields :-) --> http://pastebin.ubuntu.com/10094757/ (lines 78 and 80) |
17:37 |
VanessaE |
(and yeah, we're working on solving the cause of the ridiculous times that exposed this bug) |
17:43 |
Krock |
VanessaE: total | | -4294829465 |
17:48 |
|
Hunterz joined #minetest-dev |
17:55 |
|
ImQ009 joined #minetest-dev |
18:01 |
|
younishd joined #minetest-dev |
18:12 |
|
SopaXorzTaker joined #minetest-dev |
18:15 |
nrzkt |
JakuVanek |
18:16 |
nrzkt |
JakubVanek, i'm working on protocol rework, on next release we need a protocol breakup for: fix some wrong packets |
18:16 |
nrzkt |
if you tell the damage packet is wrong i think it will be fixed |
18:32 |
|
cib0 joined #minetest-dev |
18:36 |
|
selat joined #minetest-dev |
18:48 |
|
book` joined #minetest-dev |
19:13 |
|
ImQ009 joined #minetest-dev |
19:21 |
|
ImQ009 joined #minetest-dev |
19:22 |
|
shadowzone joined #minetest-dev |
19:24 |
|
Wayward_One joined #minetest-dev |
19:25 |
est31 |
nrzkt: will the issue that when the client recieves packets in wrong order crashes be fixed? |
19:26 |
Krock |
wrong order? |
19:26 |
|
Player_2 joined #minetest-dev |
19:26 |
nrzkt |
no because i don't care about this network layer. It will be rewriten for future release (it's in progress), and use a proper TCP connection with proper sessions instead of this ugly layer |
19:27 |
est31 |
good. |
19:27 |
est31 |
so nothing speaks against the switch to tcp, great |
19:28 |
Krock |
why TCP? |
19:28 |
nrzkt |
in fact est31 i look at packets which need to be sure, and it's 95% of MT packets, then TCP is a good option |
19:28 |
Krock |
I thought UDP never was a problem for the engine |
19:28 |
nrzkt |
please look at the code |
19:28 |
nrzkt |
and show me |
19:29 |
est31 |
95 % are sent reliable? thought less |
19:29 |
nrzkt |
ofc |
19:29 |
T4im |
most are probably chat messages/notifications, inventory operations |
19:30 |
est31 |
SAO moves |
19:30 |
nrzkt |
in fact only movement doesn't need reliability |
19:30 |
est31 |
every player knows every time the position of every other player |
19:30 |
nrzkt |
i think we can use both TCP and UDP |
19:30 |
T4im |
yea, but you can correct positiopn, est31 |
19:30 |
est31 |
lol |
19:30 |
nrzkt |
no but at this time movement is setn as unreliable |
19:30 |
T4im |
if you loose one movement/positional change, you update it the next tick |
19:30 |
T4im |
lose* |
19:30 |
|
Player-2 joined #minetest-dev |
19:31 |
est31 |
yea |
19:32 |
T4im |
nrzkt: how about map updates? do they need to be reliable? |
19:33 |
nrzkt |
i don't study this event in fact, i'm working on pure network layer at this time |
19:33 |
T4im |
ah |
19:33 |
nrzkt |
i rewrite packet read/write and it's finished, it tell me which packet is reliable or not in a table (from source) |
19:36 |
nrzkt |
and tcp permit to secure protocol, like authentication and in the future add encryption |
19:37 |
Calinou |
we could try making less stuff reliable |
19:37 |
|
cib0 joined #minetest-dev |
19:37 |
est31 |
for udp, there is dtls |
19:37 |
Calinou |
kilbith, I think the translation issue is fixed. it is in latest Git |
19:37 |
nrzkt |
network isn't a problem in MT, it's the engine itself. |
19:38 |
est31 |
? |
19:38 |
nrzkt |
using UDP doesn't improve performance. nobody uses RNIS or satellite connections. |
19:38 |
T4im |
you can get udp reliable too, its just a lot more work ;) and we don't have the latency requirements of a fps, so why not tcp? ;) |
19:38 |
nrzkt |
and we don't need the latency gain offered by UDP |
19:38 |
T4im |
^^ ;) |
19:38 |
nrzkt |
UDP reliable = TCP over UDP. |
19:38 |
est31 |
yea |
19:38 |
nrzkt |
why rewrite TCP over udp, kernel does it properly. |
19:39 |
est31 |
with udp you always have to watch out, dont rewrite tcp |
19:39 |
jin_xi |
nrzkt: are you nerzhul on github? |
19:39 |
nrzkt |
ofc |
19:45 |
nrzkt |
why ? :) |
19:46 |
jin_xi |
anyways, rebased pull #1700, wip particles if anyone wants to help |
19:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/1700 -- wip irrlicht particles by obneq |
19:46 |
nrzkt |
jin_xi i tested it |
19:46 |
nrzkt |
performance are ugly on intel GPU |
19:46 |
nrzkt |
and there are bugs in collision calculs, some particles fly with high speed |
19:47 |
jin_xi |
yes, there are many problems and i am an inadequate programmer ;) |
19:48 |
nrzkt |
i rebased RBA water shader and it works perfect and fix water issues |
19:49 |
VanessaE |
did you fix the flowing glitches? |
19:49 |
nrzkt |
flowing glitches ? |
19:49 |
VanessaE |
it doesn't stretch the texture properly on vertical flow, and the movement of the water does not follow how the water moves without the shader. |
19:49 |
VanessaE |
or it didn't when I tried it last. |
19:50 |
|
book` joined #minetest-dev |
19:53 |
VanessaE |
(in fact as I recall, "flowing" water didn't appear to actually flow at all :) ) |
20:06 |
|
book` joined #minetest-dev |
20:19 |
|
book` joined #minetest-dev |
20:25 |
|
book` joined #minetest-dev |
20:31 |
|
acerspyro joined #minetest-dev |
20:41 |
|
Wayward_One joined #minetest-dev |
20:46 |
|
roniz_ joined #minetest-dev |
20:59 |
|
Amaz joined #minetest-dev |
21:10 |
|
Wayward_One joined #minetest-dev |
21:10 |
|
shadowzone_ joined #minetest-dev |
21:37 |
|
Player_2 joined #minetest-dev |
21:57 |
Calinou |
I don't understand what nrzkt wants to do; first, he rewrote the Minetest networking system, and now he wants to switch to TCP? |
21:57 |
Calinou |
nrzkt> why rewrite TCP over udp, kernel does it properly. |
21:57 |
Calinou |
because it lags more… |
21:57 |
Calinou |
try writing a FPS that uses TCP (hint: this was Cube in its early days) |
21:57 |
Calinou |
and was the reason eihrul wrote enet |
22:09 |
|
blaze joined #minetest-dev |
22:13 |
|
SmugLeaf joined #minetest-dev |
22:17 |
|
SmugLeaf joined #minetest-dev |
22:34 |
|
Wuzzy joined #minetest-dev |
22:36 |
Wuzzy |
Hi! Is Minetest using Lua 5.1, Lua 5.2 or whatever Lua the system ships with? |
22:37 |
Calinou |
5.1, Wuzzy |
22:37 |
Calinou |
update to 5.2 is not planned AFAIK (there is an issue on GitHub) |
22:37 |
Wuzzy |
ok thanks |
22:37 |
Calinou |
most systems supply 5.1 anyway, so do Windows builds |
22:37 |
Calinou |
5.3 was recently released, too |
23:19 |
|
roniz joined #minetest-dev |
23:30 |
|
shadowzone joined #minetest-dev |
23:36 |
|
roniz_ joined #minetest-dev |
23:50 |
|
shadowzone_ joined #minetest-dev |