| Time |
Nick |
Message |
| 00:03 |
TBC_x |
est31: I'm refactoring ClientInterface but I need to know when are the SRP packets supposed to be handled |
| 00:04 |
TBC_x |
I want to move all the handshake stuff out of RemoteClient |
| 00:04 |
est31 |
well, they are at init time. |
| 00:04 |
TBC_x |
only at Init? |
| 00:04 |
est31 |
and afterwards too |
| 00:05 |
est31 |
there are three occasions we can have authentication packets floating around |
| 00:05 |
est31 |
1. for init, the usual login |
| 00:05 |
est31 |
2. to authenticate for sudo mode |
| 00:05 |
est31 |
3. to change the password once inside sudo mode |
| 00:05 |
est31 |
3. is only one auth mech for now |
| 00:06 |
est31 |
but 2. and 1. are multiple mechs. |
| 00:06 |
TBC_x |
I want to move at least the init stuff out |
| 00:06 |
est31 |
to where |
| 00:06 |
TBC_x |
to Server |
| 00:06 |
TBC_x |
atm |
| 00:07 |
est31 |
which handshake do you mean? |
| 00:07 |
TBC_x |
the init handshake, including client state |
| 00:07 |
est31 |
the whole client state? |
| 00:08 |
est31 |
whats left in clientiface if you take that away? |
| 00:08 |
TBC_x |
the client and its blocks |
| 00:09 |
TBC_x |
I don't like accessing the client directly |
| 00:09 |
TBC_x |
so I want to hide as much as possible behind the client interface |
| 00:09 |
est31 |
so why do you remove stuff from it then? |
| 00:10 |
TBC_x |
well... only the stuff that is required for init |
| 00:10 |
est31 |
the states are much more than just init. |
| 00:10 |
TBC_x |
I'm trying to remove all getClient() methods |
| 00:10 |
est31 |
so why are the states obstructing you with that? |
| 00:12 |
est31 |
also, why do you think is a file with 3428 lines a better place in your mind? |
| 00:13 |
TBC_x |
my goal is to hide RemoteClients behind ClientInterface |
| 00:13 |
TBC_x |
and I was not sure whether the srp is needed for the entire session |
| 00:14 |
TBC_x |
if it was not, I could move auth out of RemoteClients |
| 00:15 |
est31 |
we need it not just for init. |
| 00:16 |
est31 |
also, auth data is in the clientiface, no? |
| 00:16 |
est31 |
err sorry |
| 00:16 |
est31 |
its in remoteclients. |
| 00:16 |
est31 |
an abstraction layer which handles all auth would be very good though. |
| 00:16 |
TBC_x |
yes |
| 00:17 |
est31 |
so if you design it, you should keep in mind, that srp is needed at all those three occasions |
| 00:17 |
TBC_x |
current problem is that emergethread may access client when packet handlers have reference to it but not lock |
| 00:17 |
TBC_x |
therefore data race |
| 00:18 |
est31 |
what's it the business of emergethrea |
| 00:18 |
est31 |
d |
| 00:18 |
TBC_x |
setBlocksNotSent |
| 00:18 |
est31 |
why can't it just have a queue, of outstanding mapblocks to be delivered? |
| 00:19 |
TBC_x |
probably someone's optimization? |
| 00:19 |
TBC_x |
this is my clientiface.h right now http://sprunge.us/aTAP |
| 00:20 |
TBC_x |
I removed all getClient() methods |
| 00:20 |
est31 |
perhaps a diff would be better |
| 00:20 |
TBC_x |
ok |
| 00:21 |
TBC_x |
http://sprunge.us/ODRP |
| 00:21 |
est31 |
grr #2885 uses getClient extensively |
| 00:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/2885 -- Utf8 based chat by est31 |
| 00:22 |
TBC_x |
I wrapped some scattered member variables into logical structures |
| 00:22 |
|
blaaaaargh joined #minetest-dev |
| 00:22 |
TBC_x |
but I need to break HandshakeInfo struct |
| 00:24 |
est31 |
eh, why so much Handshake*Info structs |
| 00:24 |
est31 |
new struct for just two variables? |
| 00:25 |
TBC_x |
this is not final |
| 00:26 |
est31 |
also, c++ has constructors |
| 00:26 |
TBC_x |
I know |
| 00:26 |
est31 |
we dont need createEmpty |
| 00:27 |
est31 |
bad descision that rust has no constructors. |
| 00:27 |
TBC_x |
rust has default trait |
| 00:28 |
TBC_x |
that works like default constructor |
| 00:28 |
TBC_x |
i was definitely doing premature optimizations around createEmpty() |
| 00:29 |
est31 |
VersionInfo is even good I think |
| 00:29 |
TBC_x |
yes |
| 00:29 |
est31 |
it should be perhaps used at more places |
| 00:30 |
est31 |
perhaps even defined by version.h |
| 00:30 |
est31 |
finally something version.h can be used for |
| 00:30 |
est31 |
right now it only lives for version.cpp |
| 00:35 |
TBC_x |
now tell me, what in HandshakeInfo should not be moved out of RemoteClient? |
| 00:35 |
TBC_x |
I wanted to move all of that out |
| 00:37 |
TBC_x |
replaced createEmpty with constructors |
| 00:37 |
est31 |
I don't think we need separate handshakeinfo and clientnetinfo |
| 00:37 |
est31 |
or even separate from clientinfo |
| 00:38 |
TBC_x |
I want to minimize packet handlers touching RemoteClient |
| 00:39 |
TBC_x |
when some of the stuff is used only once, It could be allocated somewhere else |
| 00:39 |
est31 |
we can put that all into clientinfo |
| 00:40 |
est31 |
the problem is, right now I know of no criterion why these things live in separate structs |
| 00:40 |
est31 |
you should be abled to give a clear criterion why something should be in one struct, something else in another |
| 00:41 |
est31 |
otherwise you perhaps should merge them. |
| 00:41 |
est31 |
because you cant define a clear line |
| 00:41 |
est31 |
"its needed by packet handlers" thats a clear line |
| 00:41 |
est31 |
vs "its hidden behind some clientiface logic" |
| 00:42 |
TBC_x |
When I was first separating the clientinfo and friends I was thinking that a initialization handler could do its thing and then initialize RemoteClient with those structs |
| 00:42 |
TBC_x |
I mean, initialize RemoteClient when the init phase finishes |
| 00:43 |
hmmmm |
[07:48 PM] <est31> why an assert now? |
| 00:43 |
hmmmm |
i dunn, we have to do something |
| 00:43 |
TBC_x |
so the final step would pass the initialized data to RemoteClient constructor |
| 00:43 |
hmmmm |
didn't realize it was a pointer at first so yeah i agree it needs to be checked, but i don't think it should persist in a release build |
| 00:44 |
est31 |
My comment was more along "compare it with NULL not with 0" |
| 00:44 |
est31 |
not "make an assert" |
| 00:45 |
TBC_x |
I wanted all the members in HandshakeInfo move away from RemoteClient |
| 00:45 |
est31 |
the problem is I think that channel is somehow settable by the client |
| 00:45 |
est31 |
or the other peer |
| 00:45 |
est31 |
to be neutral |
| 00:45 |
est31 |
TBC_x, nothing wrong with that |
| 00:45 |
hmmmm |
the channel is selectable by an 8 bit ID number |
| 00:45 |
hmmmm |
in the highest protocol layer |
| 00:46 |
est31 |
but why did you split it up this far TBC_x? One struct to separate with is enough, no? |
| 00:47 |
est31 |
otherwise you just keep around hundreds of pointers an have to remember each of the Info and NetInfo objects and what they contain |
| 00:47 |
est31 |
and its unmaintainable too, imagine if something new comes around |
| 00:47 |
est31 |
which doesnt fit into the "design" it has been built after |
| 00:47 |
TBC_x |
This is not final design |
| 00:47 |
est31 |
then all has to be destroyed |
| 00:47 |
hmmmm |
yea there's no way the channel pointer can be manipulated by the client into being NULL |
| 00:47 |
est31 |
so better to not overengineer something |
| 00:48 |
TBC_x |
and I value your input |
| 00:48 |
est31 |
hmmmm, there is no way? |
| 00:48 |
hmmmm |
nope |
| 00:48 |
est31 |
there is a comparison connection != 0 just before the method is called |
| 00:48 |
est31 |
so that can be removed, you say? |
| 00:49 |
hmmmm |
it could be |
| 00:49 |
est31 |
ok. |
| 00:49 |
est31 |
then its ok |
| 00:49 |
hmmmm |
see the main problem is that these checks are mostly pedantic |
| 00:49 |
hmmmm |
they're really not necessary and it would only make sense to explicitly check them if they were intended to be part of a public interface for use by multiple things outside of connection.cpp |
| 00:50 |
hmmmm |
and what's more is that they're completely inconsistent |
| 00:50 |
TBC_x |
est31, also http://sprunge.us/XNQB |
| 00:50 |
est31 |
we don't use channels that much, agreed |
| 00:50 |
hmmmm |
there's so much sanity checking on specific functions, even checking the value of a variable right after an if statement returns if it's equal to something |
| 00:50 |
hmmmm |
generally connection.cpp is a mess |
| 00:51 |
TBC_x |
I think this way it is more readable |
| 00:51 |
est31 |
TBC_x, what's the point in adding the ? thing here |
| 00:51 |
hmmmm |
i would not recommend adding a sanity_check() whatever if there's some convoluted logic involved with that code where such a condition could conceivably arise |
| 00:51 |
est31 |
should that be added to every boolean expression |
| 00:51 |
hmmmm |
TBC_x, that is incredibly repetitive |
| 00:51 |
est31 |
for (int i = 0; (i < 10) ? true : false; i++) |
| 00:51 |
hmmmm |
i don't think it's more readable anyway |
| 00:52 |
hmmmm |
yeah really :p |
| 00:52 |
TBC_x |
at least to assignments |
| 00:53 |
est31 |
ok, then my concerns with the connection.cpp change are gone, +1 |
| 00:53 |
est31 |
now about the lua error handler commit |
| 00:53 |
TBC_x |
more informative messages are good |
| 00:54 |
est31 |
have you seen my comment about that you pass the function name pointer through two methods, even if there is no error? |
| 00:54 |
hmmmm |
it's meant to give us a better clue about what's happening with those two crashes with no stacktraces |
| 00:54 |
hmmmm |
est, yeah |
| 00:55 |
hmmmm |
so what? |
| 00:55 |
est31 |
first its a repurpose, so the methods should be at least renamed, second its needless jumps and complexity. |
| 00:56 |
est31 |
if you want to understand the code, you'll have to travel first to the macro then to the first method, then the second, then only you see the if about the return value |
| 00:56 |
hmmmm |
alright, point made |
| 01:01 |
|
kaeza joined #minetest-dev |
| 01:03 |
est31 |
otherwise +1 to the error msg commit as well. |
| 01:03 |
|
twoelk|2 joined #minetest-dev |
| 01:06 |
est31 |
~tell nrzkt can you make test android builds, and perhaps try to find out whether #2973 is because of device, or because of build setup? If its build setup we dont have to patch around. if its device based, we will have to disable iconv usage, this should be cleared now, before the release. |
| 01:06 |
ShadowBot |
est31: O.K. |
| 01:07 |
est31 |
~tell nrzkt best to upload them somewhere, so that wayward1 and H-H-H can test it on their devices (they both report the bug, both from self built apks) |
| 01:07 |
ShadowBot |
est31: O.K. |
| 01:13 |
hmmmm |
est31, did you see the thing about nerzhul's performance optimization |
| 01:14 |
est31 |
yes, its for after the release |
| 01:14 |
est31 |
imo |
| 01:14 |
hmmmm |
good |
| 01:14 |
hmmmm |
agreed |
| 01:14 |
est31 |
this is why we freeze |
| 01:15 |
|
sloantothebone joined #minetest-dev |
| 02:12 |
est31 |
twoelk|2, http://irc.minetest.ru/minetest-dev/2015-08-04#i_4350608 |
| 02:12 |
est31 |
its how srp has been designed |
| 02:12 |
est31 |
it works together with the old password scheme, but new passwords are set as srp verifiers |
| 02:13 |
est31 |
so if you log in to a new server the first time, or you change your password with a new client, you will get a srp key in the db, and no hash that would be compatible with old versions |
| 02:13 |
est31 |
however, you can ask an admin to set your password |
| 02:16 |
est31 |
/setpassword still sets old style hashes, even if all parties are connected with new clients |
| 02:18 |
twoelk|2 |
it seems one tries to connect with an old valid password and the server rejects. wether the server is new I cannot say but the password is usually old |
| 02:20 |
twoelk|2 |
http://irc.minetest.ru/minetest/2015-08-05#i_4352539 |
| 02:20 |
est31 |
The server has to be new (0.4.12-dev) in order to support srp. |
| 02:22 |
est31 |
If you have a reproducible bug, it would be interesting. |
| 02:22 |
est31 |
I mean, it would be an issue |
| 02:22 |
twoelk|2 |
https://forum.minetest.net/viewtopic.php?p=186041#p186041 and simmilar |
| 02:23 |
est31 |
I'm more with ABJ's theory here. |
| 02:23 |
twoelk|2 |
http://irc.minetest.ru/minetest/2015-08-05#i_4352315 and here |
| 02:25 |
twoelk|2 |
so many password problems is just a bit unusuall |
| 02:25 |
est31 |
hrmm, yes |
| 02:25 |
est31 |
AAAAAAAAAAAAAAAAAAAAAA <---- thats too much A's |
| 02:25 |
est31 |
A's are bad, this is supposed to be the sale |
| 02:25 |
est31 |
salt* |
| 02:26 |
twoelk|2 |
I think there was similar talk on inchra but I don't think they have logs |
| 02:26 |
est31 |
the only place srp changed during the last weeks was a leak fix |
| 02:27 |
est31 |
and that other thing, with the default passwords |
| 02:37 |
est31 |
damn, since when do we have this salt bug |
| 02:52 |
est31 |
I see now how the salt bug happens |
| 03:03 |
est31 |
hmmmm, can you review https://github.com/est31/minetest/commit/e91af8036c7c9a957628e5977f04e20fa3fc25fa |
| 03:04 |
est31 |
analogous to https://github.com/est31/csrp-gmp/commit/44c909e6b4059ee644031c6b8bb95717d2a6ef12 |
| 03:04 |
est31 |
its that AAAAA issue |
| 03:05 |
est31 |
twoelk, I have made a bugfix patch for srp now, but it was only an unrelated bug I've found, I haven't found the case for aerth's reported problem yet |
| 03:12 |
VanessaE |
btw is anyone else getting crashes in the client when the server shuts down? |
| 03:13 |
est31 |
lets test it |
| 03:13 |
est31 |
whats your test port again? |
| 03:13 |
VanessaE |
30007 I think |
| 03:38 |
hmmmm |
est31: yes looks good I suppose |
| 03:39 |
est31 |
I tested it, and it works, so I gonna push it |
| 03:39 |
hmmmm |
i assume init_random() initializes using the system random generator or at least uses the system random generator as a seed? |
| 03:39 |
est31 |
yes |
| 03:40 |
est31 |
the system random generator is even used as only source, if available |
| 03:40 |
hmmmm |
erm, doesn't this mean that the SRP implementation up until now was insecure? |
| 03:40 |
est31 |
there is nothing wrong or slow about /dev/urandom |
| 03:40 |
est31 |
only under certain conditions |
| 03:40 |
est31 |
the random generator was already initialized for the actual login |
| 03:41 |
hmmmm |
mmmmmm |
| 03:41 |
est31 |
just if you logged in for a server for the first time, and this was your first contact with a srp server during the execution period of your client, then yes, you have a vulnerable database hash |
| 03:41 |
hmmmm |
as for the irc mod - no idea there |
| 03:41 |
est31 |
well, its unsalted |
| 03:41 |
hmmmm |
i'd have to look into it better to have a well formed opinion |
| 03:43 |
est31 |
and that bad db hash stays with you, as long as you dont change your password |
| 03:43 |
est31 |
the only vulnerability here is that the server can build rainbow tables, if the server is evil |
| 03:46 |
|
blaise joined #minetest-dev |
| 03:54 |
hmmmm |
https://github.com/kwolekr/minetest/commit/2c508f76541065fa017610edfa4edd0739b1ff39 |
| 03:54 |
hmmmm |
PTAL |
| 04:02 |
est31 |
looks good |
| 04:02 |
hmmmm |
did you make sure that everything matches up |
| 04:03 |
hmmmm |
i looked at it too, but with such repetitive code it's easy to make a typo mistake |
| 04:03 |
est31 |
I'll read through it again |
| 04:09 |
est31 |
ok |
| 04:09 |
est31 |
+1 |
| 04:11 |
hmmmm |
done |
| 04:11 |
hmmmm |
that takes care of all the known security exploits for this dev version i think |
| 04:12 |
hmmmm |
now just to take care of the remaining race conditions/crashes |
| 04:14 |
|
blaise joined #minetest-dev |
| 04:17 |
|
cvtsx1 joined #minetest-dev |
| 04:29 |
hmmmm |
est31: https://github.com/minetest/minetest/pull/3013 |
| 04:32 |
est31 |
nice |
| 04:32 |
est31 |
there is no reason to get this in before the release though, we dont even use it yet |
| 04:32 |
hmmmm |
well this doesn't change any functionality |
| 04:32 |
hmmmm |
it's just a good thing to have |
| 04:32 |
hmmmm |
i actually did this a while ago, never made a pull request for it though |
| 05:00 |
|
est31 joined #minetest-dev |
| 05:19 |
VanessaE |
hmmmm, est31: I'm headed off to bed now. bd0b469d is staged for the 6am reboot. safe to use that? |
| 05:19 |
est31 |
VanessaE, I hope so :) |
| 05:19 |
VanessaE |
"hope" heh |
| 05:20 |
VanessaE |
well I guess if it ain't, I'll know in about 8 hours, and know who to yell at ;) |
| 05:21 |
VanessaE |
nightg |
| 05:22 |
hmmmm |
wait |
| 05:22 |
hmmmm |
update to bd0b469 |
| 05:23 |
est31 |
? |
| 05:23 |
est31 |
thats the one she cited, no? |
| 05:23 |
hmmmm |
oh |
| 05:33 |
hmmmm |
est: do you know if the android graphical glitches ever got fixed? |
| 05:41 |
|
leat joined #minetest-dev |
| 06:04 |
|
amadin joined #minetest-dev |
| 06:09 |
|
Hunterz joined #minetest-dev |
| 06:11 |
|
amadin left #minetest-dev |
| 06:27 |
hmmmm |
pushing in 30 minutes: https://github.com/kwolekr/minetest/commit/8560ece02e36b1e0ee7b86db2a38b8becbb639e4 |
| 06:40 |
celeron55 |
lol, why is the warning in german too |
| 06:40 |
celeron55 |
just to make sure sapier will notice it? 8) |
| 06:40 |
hmmmm |
yeah basically |
| 06:41 |
hmmmm |
but erm, for whatever reason, germans love minetest |
| 06:41 |
hmmmm |
i'd have to estimate that half of our developers are/were german. |
| 06:43 |
celeron55 |
nice work though |
| 06:43 |
hmmmm |
tbc found it with Thread Sanitizer |
| 06:43 |
celeron55 |
that could have ended up being not fixed for forever |
| 06:43 |
hmmmm |
Thread Sanitizer is my new favorite thing ever :) |
| 07:07 |
|
Miner_59 joined #minetest-dev |
| 07:08 |
|
sloantothebone joined #minetest-dev |
| 07:10 |
Miner_59 |
Hi, just want to remember to merge #2241 |
| 07:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/2241 -- Fix for disable_jump group doesn't work on nodeboxes by gregorycu |
| 07:11 |
hmmmm |
oh i'm sorry |
| 07:12 |
hmmmm |
that other day when PRs were flying around I thought est31 merged yours |
| 07:12 |
hmmmm |
I'll do that |
| 07:12 |
hmmmm |
oh this is a different PR |
| 07:12 |
Miner_59 |
cool thanks, but gregorycu wrote this PR not I |
| 07:12 |
Miner_59 |
my PR is already merged :-) |
| 07:13 |
hmmmm |
did your own bouncy jump fix get merged |
| 07:13 |
hmmmm |
okay good |
| 07:13 |
Miner_59 |
the bug is that minetest checks the block under the nodebox, so disable_jump dont work |
| 07:14 |
Miner_59 |
nodebox=not a full block high nodebox |
| 07:14 |
Miner_59 |
although damage_per_second seems to be affected |
| 07:17 |
Miner_59 |
oh I saw its merged thanks! |
| 07:27 |
|
rubenwardy joined #minetest-dev |
| 07:30 |
|
cornernote joined #minetest-dev |
| 07:30 |
|
est31 joined #minetest-dev |
| 07:30 |
est31 |
hmmmm, what about #1551 ? |
| 07:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/1551 -- disable_jump group doesn't work on nodeboxes |
| 07:30 |
est31 |
isnt it fixed by #2241 ? |
| 07:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/2241 -- Fix for disable_jump group doesn't work on nodeboxes by gregorycu |
| 07:31 |
|
CraigyDavi joined #minetest-dev |
| 07:31 |
hmmmm |
I think so |
| 07:31 |
hmmmm |
I just didn't close that issue because I wasn't aware of it |
| 07:31 |
|
FR^2 joined #minetest-dev |
| 07:31 |
hmmmm |
closing 1551 |
| 07:31 |
est31 |
ok |
| 07:31 |
est31 |
np |
| 07:33 |
est31 |
didn't know btw that you can't allocate dynamically sized arrays on the stack until c(+?+?)11 |
| 07:34 |
est31 |
I guess that makes writing a compiler harder, because you dont know until execution how much space on the stack a function will take. |
| 07:35 |
est31 |
well, a bit harder |
| 07:36 |
hmmmm |
well i'm not really sure about C++ |
| 07:36 |
hmmmm |
but so-called "VLA"s came into C with C99 |
| 07:36 |
rubenwardy |
aren't arrays just pointers, so you can malloc the size you mean? |
| 07:36 |
est31 |
not stack arrays |
| 07:36 |
rubenwardy |
ok, nvm |
| 07:36 |
est31 |
they are pointers too, but to the stack |
| 07:37 |
hmmmm |
i'm pretty sure VLAs are usually implemented as officially sanctioned, inline-safe versions of _alloca() |
| 07:37 |
est31 |
and on the stack, there is no malloc |
| 07:37 |
est31 |
you declare it, you allocate it |
| 07:37 |
est31 |
out of scope, it gets deleted |
| 07:37 |
hmmmm |
Stack? What is this 'stack' thing you speak of? :) |
| 07:38 |
hmmmm |
that's called a variable with the "auto" storage specifier. |
| 07:39 |
hmmmm |
C/C++ has absolutely no notion of "heap" and "stack" btw |
| 07:39 |
hmmmm |
that's all implementation dependent |
| 07:39 |
est31 |
good to know |
| 07:42 |
hmmmm |
est: 3014 looks good to me. |
| 07:46 |
est31 |
ouch alloca isnt inline safe |
| 07:47 |
est31 |
thats a pretty bad system call |
| 07:47 |
est31 |
"it might work, but only if your compiler is in the mood" |
| 07:49 |
|
FR^2 left #minetest-dev |
| 07:56 |
rubenwardy |
lol, sizeof(u16) |
| 07:56 |
est31 |
hrmm, on one hand 3014 is a feature, which shouldn't be merged during freeze, on the other hand it would actually benefit server owners with the irc commands mod who have srp problems. |
| 07:57 |
rubenwardy |
#3014 |
| 07:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/3014 -- Add LuaSecureRandom by est31 |
| 07:57 |
est31 |
also, nothing much can break, if its merged, you can just not use it. |
| 07:58 |
rubenwardy |
Are floats always 4 bytes on all devices? https://github.com/kwolekr/minetest/commit/2c508f76541065fa017610edfa4edd0739b1ff39#diff-ca07aa642678d1d0c23dd61b842741f7L264 |
| 07:59 |
est31 |
yes |
| 07:59 |
est31 |
I mean no |
| 08:00 |
est31 |
but we serialize them always as 4 bytes |
| 08:00 |
est31 |
thats precisely why its bad to have sizeof(float) for serialisation considerations |
| 08:00 |
|
Gael-de-Sailly joined #minetest-dev |
| 08:01 |
|
Calinou joined #minetest-dev |
| 08:01 |
|
Yepoleb_ joined #minetest-dev |
| 08:04 |
est31 |
perhaps I merge it after lotsa tests |
| 08:04 |
est31 |
finally something I can use mtt for! |
| 08:05 |
est31 |
the main argument here would be that its a completely new feature which is totally isolated, and therefore can't break anything existing. |
| 08:08 |
rubenwardy |
#2094 |
| 08:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/2094 -- Fix offset being ignored by inventory bar HUD by rubenwardy |
| 08:27 |
|
OldCoder joined #minetest-dev |
| 08:29 |
|
andy___ joined #minetest-dev |
| 08:47 |
|
Amaz joined #minetest-dev |
| 09:18 |
|
wischi joined #minetest-dev |
| 09:20 |
|
Darcidride joined #minetest-dev |
| 09:25 |
|
paramat joined #minetest-dev |
| 09:34 |
|
OldCoder joined #minetest-dev |
| 09:41 |
|
kilbith joined #minetest-dev |
| 09:53 |
paramat |
sfan5 any comments on game#607 ? including the extra stuff i propose in comments, i think spores need a clearer name |
| 09:53 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/607 -- Biomes: Improve biome system and v6 mushroom spawning WIP by paramat |
| 09:58 |
|
cvtsx joined #minetest-dev |
| 10:47 |
|
paramat left #minetest-dev |
| 10:51 |
|
Mine joined #minetest-dev |
| 11:05 |
|
Gael-de-Sailly joined #minetest-dev |
| 11:21 |
|
SopaXorzTaker joined #minetest-dev |
| 11:22 |
|
Puma_rc joined #minetest-dev |
| 11:28 |
|
Puma_rc joined #minetest-dev |
| 11:34 |
|
Lunatrius` joined #minetest-dev |
| 11:42 |
|
SopaXorzTaker joined #minetest-dev |
| 11:44 |
|
Puma_rc joined #minetest-dev |
| 11:45 |
|
Ritchie joined #minetest-dev |
| 11:52 |
|
Zeitgeist_ joined #minetest-dev |
| 12:11 |
|
Puma_rc joined #minetest-dev |
| 12:20 |
|
Puma_rc joined #minetest-dev |
| 12:33 |
|
SopaXorzTaker joined #minetest-dev |
| 12:34 |
|
Puma_rc joined #minetest-dev |
| 12:37 |
|
H-H-H joined #minetest-dev |
| 12:43 |
|
alket joined #minetest-dev |
| 13:00 |
|
Amaz joined #minetest-dev |
| 13:01 |
|
Amaz joined #minetest-dev |
| 13:28 |
|
kilbith joined #minetest-dev |
| 13:34 |
|
crazyR joined #minetest-dev |
| 13:48 |
|
Puma_rc joined #minetest-dev |
| 13:57 |
|
Gael-de-Sailly joined #minetest-dev |
| 14:10 |
|
werwerwer joined #minetest-dev |
| 14:16 |
|
nrzkt joined #minetest-dev |
| 14:30 |
RealBadAngel |
https://imgrush.com/BgJ5_VrYDNgh.png |
| 14:30 |
RealBadAngel |
i just made swimming pool on Skyblock server :) |
| 14:32 |
sfan5 |
are those lots of tiny skyblock islands? |
| 14:47 |
|
proller joined #minetest-dev |
| 14:48 |
VanessaE |
sfan5: yep, they are |
| 14:48 |
sfan5 |
sounds interesting |
| 14:48 |
VanessaE |
nice-looking pool, RealBadAngel |
| 14:48 |
RealBadAngel |
come see it |
| 14:49 |
RealBadAngel |
theres teleporter next to your house |
| 14:50 |
VanessaE |
impressive. where the hell did you get so much obsidian? |
| 14:58 |
RealBadAngel |
recipes allow to get that as much as you want |
| 14:58 |
RealBadAngel |
craft one shard + stone to get obsidian |
| 14:58 |
RealBadAngel |
obsidian to 9 shards |
| 14:58 |
RealBadAngel |
and you have shitload of it |
| 15:14 |
|
Hunterz joined #minetest-dev |
| 15:16 |
VanessaE |
ok, official request for minetest-game et al. PLEASE go back to the old, darker junglewood color |
| 15:16 |
VanessaE |
RealBadAngel: oh right, forgot about that recipe in skyblock |
| 15:17 |
Amaz |
Yes, please can we have the old dark color junglewood back? |
| 15:18 |
VanessaE |
this lighter color just plain suicks |
| 15:18 |
VanessaE |
sucks* |
| 15:19 |
|
Gael-de-Sailly joined #minetest-dev |
| 15:20 |
kilbith |
the chocolate-y junglewood even worse |
| 15:21 |
kilbith |
(ie. the old one) |
| 15:21 |
VanessaE |
no, what's really worse is the old OLD wood texture (still used in "minimal" I think :) ) |
| 15:21 |
kilbith |
for you maybe |
| 15:22 |
VanessaE |
similarly, for YOU the "chocolate" junglewood is worse :) |
| 15:23 |
|
alket joined #minetest-dev |
| 15:24 |
kilbith |
no, for the _game maintainers that decided that |
| 15:27 |
VanessaE |
... |
| 15:27 |
VanessaE |
[08-06 11:20] <kilbith> the chocolate-y junglewood even worse <--- pretty sure that's your opinion |
| 15:28 |
kilbith |
ofc, but if it has been replaced it was for the same reason |
| 15:28 |
kilbith |
well, stupid bikeshedding anyways |
| 15:30 |
|
hmmmm joined #minetest-dev |
| 15:31 |
|
luizrpgluiz joined #minetest-dev |
| 15:33 |
VanessaE |
actually the color of the texture affects general usefulness (think contrast relative to regular and pine woods), and directly affects at least one mod also (building_blocks creates "hardwood" from jungle wood + regular, and it's dark like junglewood used to be) |
| 15:34 |
kilbith |
i agree that junglewood color should be more distinctive though |
| 15:34 |
Amaz |
Was there actually a pull for that texture change? Or was it just discussed here? |
| 15:43 |
VanessaE |
I think there was bug damned if I remember which |
| 15:44 |
VanessaE |
er wtf?> |
| 15:44 |
VanessaE |
that came out way wrong |
| 15:44 |
VanessaE |
I think there was pull request, but damned if I remember which |
| 15:44 |
VanessaE |
that's better :P |
| 15:54 |
|
Zeitgeist_ joined #minetest-dev |
| 15:54 |
|
luizrpgluiz left #minetest-dev |
| 16:05 |
|
nrzkt joined #minetest-dev |
| 16:38 |
|
Puma_rc joined #minetest-dev |
| 16:57 |
|
MinetestForFun joined #minetest-dev |
| 16:58 |
|
MinetestForFun joined #minetest-dev |
| 17:00 |
|
RealBadAngel joined #minetest-dev |
| 17:14 |
|
MinetestForFun joined #minetest-dev |
| 17:15 |
|
FR^2 joined #minetest-dev |
| 17:32 |
|
kilbith joined #minetest-dev |
| 17:50 |
|
twoelk joined #minetest-dev |
| 17:53 |
|
Zeitgeist_ joined #minetest-dev |
| 18:20 |
|
Gael-de-Sailly joined #minetest-dev |
| 18:22 |
|
Gael-de-Sailly joined #minetest-dev |
| 18:52 |
VanessaE |
has anyone fixed the problem with jungle tree and pine trunks replacing other nodes when they grow from a sapling? |
| 18:53 |
VanessaE |
(the server I'm playing on has this problem, but I don't remember if that's since been fixed) |
| 19:24 |
|
nore joined #minetest-dev |
| 19:35 |
|
lag01 joined #minetest-dev |
| 19:49 |
|
paramat joined #minetest-dev |
| 19:50 |
paramat |
VanessaE yes, it was mgv6 pine trunk replacing nodes, i have added a check for air or ignore |
| 19:50 |
RealBadAngel |
accacia too |
| 19:51 |
VanessaE |
paramat: jungle trees do it too. |
| 19:51 |
RealBadAngel |
also default trees sometime do not replace saplings |
| 19:52 |
RealBadAngel |
tree grows on top of a sapling |
| 19:52 |
paramat |
v6 jungletree trunk and roots check for air or ignore |
| 19:52 |
VanessaE |
paramat: either the jungle trees check is failing or stormchaser's server is doing something weird then |
| 19:52 |
paramat |
i'm preparing a PR to not force-place the acacia root |
| 19:53 |
RealBadAngel |
i saw accacia failing on singleplayer world |
| 20:03 |
|
AnotherBrick joined #minetest-dev |
| 20:12 |
|
Gael-de-Sailly joined #minetest-dev |
| 20:13 |
|
lag01 joined #minetest-dev |
| 20:29 |
|
alket joined #minetest-dev |
| 20:58 |
|
WSDguy2014 joined #minetest-dev |
| 21:06 |
|
proller joined #minetest-dev |
| 21:12 |
|
H-H-H joined #minetest-dev |
| 21:16 |
|
paramat left #minetest-dev |
| 21:32 |
|
alket_ joined #minetest-dev |
| 21:35 |
|
diemartin joined #minetest-dev |
| 21:49 |
OldCoder |
/opt/minebest/src/core/server/minetest/src/server.cpp:505: |
| 21:49 |
OldCoder |
void Server::step(float): A fatal error occurred: error in error handlin |
| 21:49 |
OldCoder |
Um? |
| 21:49 |
OldCoder |
WTH is error in error handling? |
| 22:03 |
|
GunshipPenguin joined #minetest-dev |
| 22:03 |
|
GunshipPenguin left #minetest-dev |
| 23:39 |
|
crazyR_ joined #minetest-dev |
| 23:39 |
|
crazyR_ joined #minetest-dev |
| 23:53 |
|
wischi2 joined #minetest-dev |
