| Time |
Nick |
Message |
| 00:00 |
paramat |
off by default to not break old worlds |
| 00:01 |
paramat |
to avoid straight-edged biome borders if snowbiomes are added to an old world |
| 00:03 |
|
troller joined #minetest-dev |
| 00:10 |
Taoki |
Ah. So it needs to be off forever just for this reason? |
| 00:11 |
Taoki |
Or just temporarily |
| 00:11 |
|
VanessaE joined #minetest-dev |
| 00:11 |
paramat |
yes forever |
| 00:12 |
paramat |
mgv6 must never break old worlds |
| 00:22 |
|
troller joined #minetest-dev |
| 00:25 |
|
proller joined #minetest-dev |
| 00:33 |
paramat |
biomes are now slightly too small in the 8 biome system of mgv5/v7, i will try out spreads of 750 |
| 00:36 |
paramat |
custom biome systems like ethereal and BFD tend to have (much) more than 8 biomes so the biomes end up very small |
| 01:00 |
paramat |
750 is good, i'll prepare a PR |
| 01:01 |
|
Darcidride joined #minetest-dev |
| 01:14 |
paramat |
2 for review and possible push in a few hours #2703 #2706 back later |
| 01:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/2703 -- Mapgen v5/v7: Detect sandstone, enable sandstone brick dungeons by paramat |
| 01:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/2706 -- Biome API: Increase heat and humidity spreads to 750 by paramat |
| 01:14 |
|
paramat left #minetest-dev |
| 01:37 |
|
Wayward_Tab joined #minetest-dev |
| 01:56 |
|
Miner_48er joined #minetest-dev |
| 02:21 |
|
Adimgar joined #minetest-dev |
| 02:39 |
|
luizrpgluiz joined #minetest-dev |
| 02:40 |
luizrpgluiz |
some doubts, as I generate a tree from treedef without relying on other mods? eg only using the default |
| 02:40 |
luizrpgluiz |
changed tree generation system? |
| 02:42 |
|
paramat joined #minetest-dev |
| 02:49 |
luizrpgluiz |
paramat: changed treedef generation system? |
| 02:50 |
paramat |
best to ask on minetest channel |
| 02:52 |
RealBadAngel |
luizrpgluiz, what do you want exactly? |
| 03:14 |
|
luizrpgluiz left #minetest-dev |
| 03:24 |
|
OldCoder joined #minetest-dev |
| 03:24 |
|
chchjesus joined #minetest-dev |
| 03:39 |
|
paramat left #minetest-dev |
| 03:39 |
|
FR^3 joined #minetest-dev |
| 03:42 |
|
FR^3 joined #minetest-dev |
| 03:49 |
RealBadAngel |
anybody awake? |
| 03:52 |
|
FR^3 joined #minetest-dev |
| 04:03 |
|
FR^3 joined #minetest-dev |
| 04:52 |
|
Zeno` joined #minetest-dev |
| 05:08 |
* VanessaE |
peeks in |
| 05:09 |
RealBadAngel |
hi |
| 05:09 |
VanessaE |
RealBadAngel: what luiz wanted, I think, was some kind of simple way to determine where on the terrain to actually create a tree, and I don't think he wants to use l-system at all |
| 05:09 |
VanessaE |
rather, I get the impression that he wants to do it with schematics. |
| 05:10 |
RealBadAngel |
idk |
| 05:10 |
RealBadAngel |
he mentioned lsystems |
| 05:10 |
VanessaE |
I don't think such a feature exists within the engine's decoration system, which is what he needs if he doesn't want to rely on a third-party mod |
| 05:10 |
VanessaE |
but idk |
| 05:10 |
RealBadAngel |
anyway, a question for ya |
| 05:10 |
VanessaE |
hm? |
| 05:10 |
RealBadAngel |
<RealBadAngel> hmmm, im wondering now if minimap should work always in full bright or show terrain with current light |
| 05:11 |
VanessaE |
combination of both. |
| 05:11 |
VanessaE |
pilcrow's suggestion has merit |
| 05:11 |
RealBadAngel |
you mean to show things not that dark as they really are? |
| 05:11 |
VanessaE |
if you can match the actual in-game lighting, that's really good - but yeah there should be a lower limit |
| 05:11 |
VanessaE |
yes |
| 05:11 |
|
Hunterz joined #minetest-dev |
| 05:12 |
RealBadAngel |
i can fine tune light levels for that |
| 05:12 |
VanessaE |
because when you think about it, a fully-dark map at night won't actually have much visible if you're in newly-explored terrain |
| 05:12 |
VanessaE |
i.e. you won't have placed enough torches to mark your position/path/etc |
| 05:12 |
RealBadAngel |
you can use nightvision then :) |
| 05:12 |
VanessaE |
heh |
| 05:13 |
RealBadAngel |
radar mode works pretty much that way |
| 05:13 |
VanessaE |
a simple multiplier over the in-game lighting table would probably be sufficient |
| 05:13 |
RealBadAngel |
http://i.imgur.com/eDhCBdV.png |
| 05:13 |
VanessaE |
wrong link :) |
| 05:13 |
VanessaE |
I saw the radar mode previously |
| 05:14 |
RealBadAngel |
we will see if that idea could be used (playable) |
| 05:16 |
VanessaE |
actually not a multiplier. dark stuff would still be dark. more like log() or something would be better. |
| 05:19 |
Zeno` |
well, display lighting is already logarithmic curve so, yes... |
| 05:19 |
Zeno` |
a* |
| 05:21 |
VanessaE |
Zeno`: I thought the lighting table in minetest was linear? |
| 05:21 |
VanessaE |
(with some fudge) |
| 05:21 |
Zeno` |
But brightness is kind of different... you'd need to brighten and then apply gamma |
| 05:21 |
Zeno` |
is it? |
| 05:21 |
VanessaE |
when I last saw, yeah |
| 05:21 |
VanessaE |
mostly linear with a bit of fudging in the middle or some such |
| 05:22 |
Zeno` |
there is still fudging :( |
| 05:22 |
Zeno` |
to keep people happy |
| 05:22 |
Zeno` |
https://github.com/minetest/minetest/commit/3d29be24e089b1c267409f05b897ce3f03e99a07 |
| 05:23 |
Zeno` |
The fudging is now so that a gamma of 1.8 produces the same light table as before gamma was introduced |
| 05:23 |
Zeno` |
https://github.com/minetest/minetest/commit/3d29be24e089b1c267409f05b897ce3f03e99a07#diff-1bf86c5e08b07bc255ad8698c565bab6R73 <--- The fudge factors |
| 05:25 |
Zeno` |
But internally (the light values that RBA is using) does not use these values... they are *display* values only |
| 05:25 |
Zeno` |
err, well.. maybe not |
| 05:25 |
Zeno` |
RealBadAngel which light values are you using? |
| 05:25 |
Zeno` |
:) |
| 05:25 |
VanessaE |
They're for display ONLY. if you handle them too much, they're not gonna last. |
| 05:25 |
VanessaE |
wait what? :) |
| 05:26 |
RealBadAngel |
im using? where? |
| 05:27 |
RealBadAngel |
night minimaps are an idea by now, not implemented yet |
| 05:28 |
Zeno` |
I mean where are you getting luminosity from, when you do |
| 05:28 |
Zeno` |
if you handle them too much? lol |
| 05:29 |
* Zeno` |
grumbles something about references to movies he's never seen |
| 05:30 |
RealBadAngel |
i can get light for minimap node from there: https://github.com/minetest/minetest/blob/master/src/mapblock_mesh.cpp#L192 |
| 05:30 |
RealBadAngel |
same way as engine does for rendering |
| 05:31 |
Zeno` |
so decoded/display lighting with gamma applied |
| 05:31 |
RealBadAngel |
propably yes |
| 05:31 |
Zeno` |
'tis good |
| 05:33 |
RealBadAngel |
that wont be that much laggy because im gonna call that only for 256 faces per mapblock |
| 05:33 |
Zeno` |
well it's only a LUT anyway |
| 05:33 |
Zeno` |
so I doubt it'd be slow in any meaningful measure |
| 05:34 |
RealBadAngel |
mapblock mesh updates are threaded anyway |
| 05:34 |
Zeno` |
true |
| 05:36 |
RealBadAngel |
http://pastebin.com/fKqkDPTg |
| 05:36 |
RealBadAngel |
this is code from mapblock_mesh for scanning the whole mapblock |
| 05:36 |
RealBadAngel |
as you can see i can easily insert there light data |
| 05:38 |
Zeno` |
oh |
| 05:38 |
Zeno` |
I thought it'd be more complicated than that :) |
| 05:38 |
Zeno` |
I suppose everything seems simple once it's done/seen hehe |
| 05:40 |
RealBadAngel |
just when i find top non air node from in the column i call the function linked before with it and node above |
| 05:40 |
RealBadAngel |
thats all |
| 05:40 |
Zeno` |
yeah... straightforward |
| 05:45 |
VanessaE |
RealBadAngel: can't use the engine's heightmap code for finding non-air-top-nodes ? |
| 05:45 |
Zeno` |
I was waiting for someone to ask that |
| 06:00 |
|
jin_xi joined #minetest-dev |
| 06:08 |
RealBadAngel |
VanessaE, im not sure it can provide me enough data |
| 06:09 |
RealBadAngel |
i need also air nodes count in the column |
| 06:09 |
RealBadAngel |
thats for radar mode |
| 06:11 |
VanessaE |
oh. |
| 06:12 |
RealBadAngel |
wheres that heighmat code you are talkin about btw? |
| 06:13 |
VanessaE |
I don't remember |
| 06:13 |
VanessaE |
*pokes hmmmm* |
| 06:13 |
jin_xi |
hey RealBadAngel good to see you again |
| 06:14 |
RealBadAngel |
hi |
| 06:41 |
jin_xi |
hm so cpp is weird at times, or whatever it is that causes this: |
| 06:41 |
jin_xi |
im trying to call this function and get the same values everytiem https://github.com/minetest/minetest/blob/master/src/particles.cpp#L39 |
| 06:42 |
jin_xi |
but when it spell out exactly what the function does it works as expected |
| 06:43 |
|
nore joined #minetest-dev |
| 06:49 |
kahrl |
jin_xi how do you call it |
| 06:52 |
jin_xi |
tried this in a particle emitter: Particle.pos = random_v3f(minpos, maxpos); |
| 06:54 |
kahrl |
how did you check that is always returns the same value? |
| 06:54 |
kahrl |
it* |
| 06:56 |
jin_xi |
hm, let me try again, maybe i messed up with lua input |
| 06:56 |
kahrl |
I recommend printing it directly to dstream in the line after that, I wouldn't rely on the visuals as they might be affected by bugs in the physics / collision detection |
| 06:57 |
jin_xi |
ok will keep that in mind |
| 06:57 |
kahrl |
see comments on #2690 |
| 06:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/2690 -- positions of particle_spawner output not entirely accurate |
| 06:57 |
jin_xi |
yes i saw that and surely enough it also happens with all of particle code replaced |
| 06:58 |
jin_xi |
so its probably in collision somewhere as thats the only common thing |
| 07:27 |
|
cib0 joined #minetest-dev |
| 07:30 |
|
Calinou joined #minetest-dev |
| 07:32 |
|
leat joined #minetest-dev |
| 07:35 |
jin_xi |
welp, parens... |
| 07:56 |
|
Krock joined #minetest-dev |
| 08:05 |
|
Yepoleb joined #minetest-dev |
| 08:11 |
|
kilbith joined #minetest-dev |
| 09:24 |
|
VargaD_ joined #minetest-dev |
| 09:32 |
|
cib0 joined #minetest-dev |
| 09:33 |
|
Aaron101- joined #minetest-dev |
| 09:36 |
|
friti joined #minetest-dev |
| 09:37 |
|
Aaron1011 joined #minetest-dev |
| 09:47 |
|
ElectronLibre joined #minetest-dev |
| 09:47 |
|
pozzoni joined #minetest-dev |
| 10:07 |
|
OldCoder joined #minetest-dev |
| 10:08 |
|
technomancy joined #minetest-dev |
| 10:11 |
|
selat joined #minetest-dev |
| 12:08 |
|
cib0 joined #minetest-dev |
| 12:25 |
|
EvergreenTree joined #minetest-dev |
| 13:09 |
|
jin_xi joined #minetest-dev |
| 13:24 |
|
Wayward_Tab joined #minetest-dev |
| 13:45 |
|
TheWild joined #minetest-dev |
| 14:28 |
|
hmmmm joined #minetest-dev |
| 14:30 |
|
prozacgod joined #minetest-dev |
| 14:30 |
|
cib0 joined #minetest-dev |
| 14:40 |
|
Calinou joined #minetest-dev |
| 14:47 |
|
RealBadAngel joined #minetest-dev |
| 15:03 |
|
daswort joined #minetest-dev |
| 15:03 |
|
technomancy joined #minetest-dev |
| 15:26 |
|
celeron55 joined #minetest-dev |
| 15:36 |
|
Wayward_Tab joined #minetest-dev |
| 15:59 |
|
Adimgar joined #minetest-dev |
| 16:04 |
Calinou |
#2707 review please? |
| 16:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/2707 -- Modified input and output format for /time command by LeMagnesium |
| 16:08 |
RealBadAngel |
looks ok for me, but what us folks will say? |
| 16:09 |
RealBadAngel |
still we didnt have 9000 AM or 11000 PM before ;) |
| 16:24 |
|
cib0 joined #minetest-dev |
| 16:28 |
hmmmm |
https://github.com/kwolekr/minetest/commit/a6da66299659a832d11c81711dc0fd73ca1602e3 |
| 16:28 |
hmmmm |
PTAL |
| 16:30 |
Krock |
Calinou, because you ponted to this, I'll tell you to edit the "params" or /time, make it backwards compatible there aswell |
| 16:30 |
Krock |
*pointed |
| 16:30 |
|
est31 joined #minetest-dev |
| 16:32 |
hmmmm |
2707 LGTM, but a minor improvement would be to fix the spacing between operators |
| 16:33 |
hmmmm |
wait I take that back, 2707 does not look good to me. copy paste error on line 706, "elseif minutes < 0 or minutes > 23 then" |
| 16:34 |
est31 |
hmmmm, to the srp discussion from yesterday: the srp packets were +1ed by two people Zeno and nrz, and you said sb else should review it. |
| 16:34 |
hmmmm |
yeah I didn't get around to that |
| 16:34 |
hmmmm |
so let's continue where i left off |
| 16:36 |
ElectronLibre |
hmmm: What do you mean by copy paste error? |
| 16:36 |
est31 |
because its the same as for hours |
| 16:36 |
hmmmm |
means whoever wrote it copied and pasted that line of code from somewhere else, in this case two lines above, and forgot to change everything |
| 16:36 |
ElectronLibre |
I wrote those lines. |
| 16:36 |
est31 |
if hour < 0 or hour > 23 then |
| 16:36 |
hmmmm |
oh |
| 16:36 |
ElectronLibre |
Without copying them. |
| 16:37 |
hmmmm |
you realize there are 60 minutes in an hour then... correct..? |
| 16:37 |
|
est31 joined #minetest-dev |
| 16:37 |
ElectronLibre |
That's what I'm doing right now with all the other things said. |
| 16:38 |
hmmmm |
sorry, I don't know everyone's username on github |
| 16:38 |
hmmmm |
didn't know you were here |
| 16:38 |
est31 |
ElectronLibre, can you also add a space here: local hour,minutes = param:match("^(%d+):(%d+)$") |
| 16:38 |
ElectronLibre |
est31: Yes I will. hmmm: No problem, very often people don't recognize me. |
| 16:39 |
est31 |
here too, right after hmmmm's comment core.log("action",name .. " set time " .. newtime) |
| 16:39 |
hmmmm |
http://dev.minetest.net/Lua_code_style_guidelines |
| 16:39 |
est31 |
and "sets time" not "set time" |
| 16:40 |
hmmmm |
probably would be better to say "sets time to" |
| 16:40 |
hmmmm |
so that's three changes |
| 16:40 |
est31 |
yea |
| 16:41 |
ElectronLibre |
I kept the original sentence I guess, so yes, I will do it. |
| 16:41 |
est31 |
the old message was "sets time" but "to" sounds better |
| 16:42 |
hmmmm |
est31, in your documentation you have std::string to denote a serialized string |
| 16:42 |
hmmmm |
does this mean strings serialized in the pascal format? |
| 16:42 |
hmmmm |
i.e. using serializeString() |
| 16:42 |
est31 |
is the pascal format with \0 or with length? |
| 16:43 |
hmmmm |
pascal format strings have a length prefix |
| 16:43 |
est31 |
yes then I use that |
| 16:43 |
est31 |
thats what networkpacket does |
| 16:43 |
hmmmm |
well my point is why name it std::string |
| 16:43 |
est31 |
because std::string does it the same way? |
| 16:43 |
hmmmm |
this network protocol has nothing to do with C++ |
| 16:43 |
est31 |
? |
| 16:43 |
hmmmm |
and no, std::string has absolutely no definitive memory layout |
| 16:43 |
hmmmm |
it's implementation dependent |
| 16:44 |
est31 |
std::string doesn't care for \0s |
| 16:44 |
est31 |
does it |
| 16:44 |
hmmmm |
it doesn't, but so what? |
| 16:44 |
est31 |
so its precisely what we're sending here |
| 16:44 |
hmmmm |
we are not sending std::strings |
| 16:44 |
est31 |
but yes we're first serializing them |
| 16:44 |
hmmmm |
this is a network protocol standard |
| 16:45 |
est31 |
of course we dont take the binary network layout |
| 16:45 |
hmmmm |
we're sending sequences of octets with a length prefix |
| 16:45 |
est31 |
so you want me to write instead "serialized std::string" then? |
| 16:45 |
hmmmm |
ehh |
| 16:45 |
est31 |
thats loooong |
| 16:45 |
hmmmm |
I don't want you to do anything per se |
| 16:45 |
hmmmm |
dude |
| 16:46 |
hmmmm |
you have such a crazy aversion to "long" |
| 16:46 |
hmmmm |
being shorter isn't necessarily better |
| 16:46 |
hmmmm |
if you want short then why not use an "expressive" language like perl |
| 16:46 |
hmmmm |
#{@#}${@#$ |
| 16:46 |
est31 |
lol |
| 16:46 |
hmmmm |
but no |
| 16:46 |
est31 |
ok what is your idea :) |
| 16:46 |
hmmmm |
I'll change the nomenclature all at once |
| 16:47 |
hmmmm |
this should probably be done separately |
| 16:47 |
hmmmm |
in any case, there are a couple cases where you send a fixed length of data as a string |
| 16:47 |
hmmmm |
est, you need to be VERY careful about what you do here before enabling this |
| 16:48 |
hmmmm |
once you enable this new network version, there's no going back, and whatever mistake you might have made is now cemented into minetest history |
| 16:48 |
est31 |
when I send fixed lengths its either for flexibility, or I do explicit checks |
| 16:48 |
ElectronLibre |
I fixed everything and pushed it. #2707 should be ready now. |
| 16:48 |
hmmmm |
I'm really sorry if things seem to be going slowly but it's needed |
| 16:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/2707 -- Modified input and output format for /time command by LeMagnesium |
| 16:48 |
hmmmm |
this is a huge change, and literally every time a large change was rushed, we paid for it |
| 16:49 |
est31 |
so then, make suggestions :) |
| 16:49 |
hmmmm |
i'm looking at it |
| 16:49 |
hmmmm |
ElectronLibre, not to nitpick, but shouldn't "invalid minutes" be "Invalid minute" |
| 16:49 |
hmmmm |
hour minutes, minutes is plural but hours is not |
| 16:50 |
hmmmm |
does it sound better to have it as "hours and minutes"? |
| 16:50 |
hmmmm |
or "hour and minute" |
| 16:50 |
hmmmm |
you're specifying an exact hour and an exact minute |
| 16:50 |
hmmmm |
or, an exact hour and some minutes after that hour |
| 16:50 |
ElectronLibre |
I would say, "hour" and "minute". |
| 16:50 |
hmmmm |
hmm, I think it's okay like it is now |
| 16:50 |
hmmmm |
I don't have any preference |
| 16:51 |
ElectronLibre |
"minutes" is a typo as far as I remember, I wanted it to be singular. |
| 16:51 |
hmmmm |
okay |
| 16:52 |
est31 |
std::string was nrz's idea, I only took what was there. len,char[len] has the problem that then people start inventing funny things |
| 16:52 |
hmmmm |
nrz is not exactly a beacon of good ideas |
| 16:52 |
est31 |
like "names are never longer than 20 chars, lets send char[20] over the line" |
| 16:53 |
hmmmm |
oh ElectronLibre, sorry about this again but the word "included" should be "inclusive" |
| 16:53 |
hmmmm |
i just saw that now |
| 16:53 |
ElectronLibre |
Ok. I'm not native english speaker so I might have done mistakes in the text. |
| 16:53 |
est31 |
what I want is some kind of abstraction, I dont care wheter its called std::string or serstring or omgABSTRACT. |
| 16:53 |
ElectronLibre |
Thanks for pointing all of these. |
| 16:53 |
hmmmm |
no problem |
| 16:54 |
hmmmm |
est31: we'll worry about naming later |
| 16:54 |
hmmmm |
i just want to make sure all the packet formats make sense |
| 16:54 |
est31 |
ok |
| 16:54 |
hmmmm |
I still don't 100% understand the sudo mode thing |
| 16:55 |
hmmmm |
why the hell is the password transmitted over the wire in base64 |
| 16:55 |
hmmmm |
i realize you didn't make it this way, but I just think it was a decision that never made any sense |
| 16:56 |
est31 |
it is |
| 16:56 |
est31 |
should be changed then |
| 16:56 |
est31 |
you mean FIRST_SRP? |
| 16:56 |
hmmmm |
anywhere where PASSWORD_SIZE is used |
| 16:57 |
est31 |
ummm PASSWORD_SIZE is for legacy clients |
| 16:57 |
hmmmm |
ahh |
| 16:57 |
est31 |
I don't touch that anymore |
| 16:57 |
hmmmm |
yeah, so then in FIRST_SRP |
| 16:57 |
est31 |
I'll review whether its base64 encoded there, and if it is, then I'll binary code it |
| 16:58 |
est31 |
(we have no plaintext protocol like SMTP where you base64 attachments and bloat emails size) |
| 17:00 |
hmmmm |
so wait a minute is the network traffic being compressed now? |
| 17:00 |
hmmmm |
was it ever not? |
| 17:00 |
est31 |
is it? |
| 17:01 |
est31 |
I haven't seen any compression as I looked at it with wireshark |
| 17:01 |
hmmmm |
look at enum NetProtoCompressionMode |
| 17:01 |
hmmmm |
is that simply not implemented? |
| 17:01 |
est31 |
I think thats for node compression |
| 17:02 |
est31 |
mapblock* |
| 17:02 |
hmmmm |
it's never used anywhere |
| 17:02 |
est31 |
yes, not implemented yet |
| 17:03 |
hmmmm |
note to self: change enum value 0 to "no compression" |
| 17:03 |
est31 |
nope |
| 17:03 |
est31 |
right now we compress with zlib, not? |
| 17:04 |
hmmmm |
it's not used anywhere |
| 17:04 |
est31 |
it should be |
| 17:04 |
est31 |
I'll use that |
| 17:04 |
hmmmm |
go search for NETPROTO_COMPRESSION_ZLIB in the project |
| 17:04 |
hmmmm |
don't do it right now.. |
| 17:04 |
est31 |
thanks for pointing |
| 17:04 |
hmmmm |
this is a separate commit entirely |
| 17:04 |
est31 |
https://github.com/est31/minetest/commit/e68e2280c884f6e136e3516fe21cfa313b68dd0d |
| 17:04 |
est31 |
you see the u16 compression_modes = 0; ? |
| 17:04 |
hmmmm |
oh |
| 17:05 |
est31 |
I'll change it to = NETPROTO_COMPRESSION_ZLIB |
| 17:05 |
hmmmm |
wow |
| 17:05 |
hmmmm |
it's a magic value |
| 17:05 |
hmmmm |
learn to use define macros, enums, or something, anything to make it less cryptic |
| 17:05 |
hmmmm |
I don't know WTF "0" means here unless I'm you |
| 17:05 |
est31 |
I didnt introduce it sorry |
| 17:05 |
est31 |
and its not bound to any functional code |
| 17:05 |
est31 |
yet |
| 17:05 |
hmmmm |
in any case, compression modes are a completely new thing that were just introduced |
| 17:05 |
hmmmm |
so then change 0 to mean "no compression" |
| 17:06 |
hmmmm |
and then make zlib compression 1 |
| 17:06 |
est31 |
sounds reasonable |
| 17:06 |
hmmmm |
if you tell clients you're using zlib compression but you aren't because it hasn't been implemented yet... you're lying to the clients |
| 17:07 |
hmmmm |
besides, i don't understand why compression would be mandatory |
| 17:07 |
est31 |
its mapblock compression I think |
| 17:07 |
est31 |
yes the enum is bad |
| 17:08 |
hmmmm |
mapblock compression can use either RLE or Zlib by the way |
| 17:08 |
hmmmm |
this is dependent upon MAPBLOCK serialization version |
| 17:08 |
est31 |
ok |
| 17:08 |
hmmmm |
NOT the net protocol serialization version |
| 17:08 |
hmmmm |
they are two different things |
| 17:08 |
est31 |
hm... |
| 17:08 |
hmmmm |
this clearly says, "NETPROTO_COMPRESSION" |
| 17:08 |
est31 |
then I have no idea why its there. |
| 17:09 |
hmmmm |
because nerzhul had big ideas no doubt |
| 17:09 |
hmmmm |
i support compression for network data. really i do. it's just that i'd prefer one of us does it so we can be reasonably sure there won't be 500 bugs |
| 17:09 |
est31 |
lol |
| 17:10 |
hmmmm |
sorry but it's the truth |
| 17:10 |
hmmmm |
what file is the network diagram in?? |
| 17:10 |
hmmmm |
connection sequence i mean |
| 17:10 |
est31 |
clientiface.h I think |
| 17:10 |
est31 |
yup |
| 17:10 |
hmmmm |
that is completely random |
| 17:11 |
est31 |
? |
| 17:11 |
hmmmm |
i mean the location |
| 17:12 |
hmmmm |
why clientiface.h |
| 17:12 |
est31 |
what I think the reason was that it ended up in this file is that the states are managed there |
| 17:12 |
hmmmm |
yeah, maybe. |
| 17:12 |
hmmmm |
it should really be in a different file. |
| 17:12 |
est31 |
but, I dont defend it, move it where you want |
| 17:12 |
hmmmm |
not right now |
| 17:12 |
hmmmm |
all these things are TODOs |
| 17:13 |
hmmmm |
now you have there "Authentication, depending on packet sent by client" |
| 17:13 |
est31 |
I didn't want to make the diagram too large |
| 17:13 |
hmmmm |
this means it could be any of TOSERVER_FIRST_SRP, TOSERVER_SRP, TOSERVER_LEGACY_SRP |
| 17:13 |
hmmmm |
well |
| 17:13 |
hmmmm |
here is where you should be as large as you need |
| 17:13 |
hmmmm |
you're describing how it works |
| 17:13 |
hmmmm |
trying to be compact in documentation is the very last place |
| 17:14 |
hmmmm |
that it would be appropriate |
| 17:14 |
est31 |
one line has 96 chars already our hard limit is 90 chars |
| 17:14 |
hmmmm |
ya... like I said, it's time to move it out into a different file |
| 17:14 |
hmmmm |
sudo mode isn't enabled for account creation, correct? |
| 17:15 |
hmmmm |
only password changing? |
| 17:15 |
est31 |
still people who have tight screens should be abled to see it, not a fucked up version of it |
| 17:15 |
est31 |
sorry to use "fucked" |
| 17:15 |
hmmmm |
eh it's okay |
| 17:15 |
hmmmm |
nobody's screen should be fucked to the point where it's less than 120 columns though |
| 17:15 |
est31 |
nope, sudo mode only for existing ones |
| 17:16 |
hmmmm |
for descriptive diagrams, i think the max column length should be increased. |
| 17:16 |
hmmmm |
it's very important and shouldn't be compressed horziontally because of some legacy screen size limitation |
| 17:16 |
hmmmm |
it shouldn't be in the code to begin with though |
| 17:16 |
hmmmm |
right, anyway, we'll do that later. |
| 17:17 |
hmmmm |
so am i correct in saying that sudo mode is only used for changing passwords??? |
| 17:17 |
est31 |
yes |
| 17:17 |
hmmmm |
why don't you just call the packets "change SRP password" |
| 17:18 |
hmmmm |
oh right, because that's too long |
| 17:18 |
est31 |
thats naming mostly |
| 17:18 |
hmmmm |
we had this same conversation like 3 times but i keep forgetting |
| 17:18 |
hmmmm |
I still think you should change "sudo" to "change password" |
| 17:18 |
hmmmm |
just to make completely certain, this is how it works: |
| 17:19 |
hmmmm |
we're already logged in |
| 17:19 |
hmmmm |
we want to change our password |
| 17:19 |
hmmmm |
so we enable sudo mode |
| 17:19 |
est31 |
yes |
| 17:19 |
hmmmm |
send a TOCLIENT_FIRST_SRP |
| 17:19 |
hmmmm |
do all the SRP stuff |
| 17:19 |
hmmmm |
and then sudo mode disengages after a successful password change?? |
| 17:19 |
est31 |
TOSERVER_SRP_BYTES_A to be precise |
| 17:19 |
hmmmm |
another thing I'd like to talk about |
| 17:19 |
est31 |
yes it disengages |
| 17:20 |
hmmmm |
though this isn't extremely important because it's just naming, not the actual protocol format |
| 17:20 |
hmmmm |
why expose such low-level details about SRP in the packet names? |
| 17:20 |
hmmmm |
shouldn't it be like AUTH_BEGIN or something? |
| 17:20 |
hmmmm |
shrug |
| 17:20 |
est31 |
I had such things in mind |
| 17:20 |
hmmmm |
we'll figure it out later |
| 17:20 |
est31 |
where I have a packet, and then have the auth related messages in there |
| 17:20 |
hmmmm |
in any case |
| 17:21 |
est31 |
so only two opcodes TOSERVER_AUTH_MSG |
| 17:21 |
est31 |
and TOCLIENT_AUTH_MSG |
| 17:21 |
hmmmm |
a lot of games i used to play worked like this |
| 17:21 |
hmmmm |
you connect to the server |
| 17:21 |
est31 |
then inside i had another opcode indicating the actual data |
| 17:21 |
hmmmm |
you pass around basic init messages |
| 17:21 |
hmmmm |
then you get to the login screen |
| 17:21 |
est31 |
but then I thought it would be too much abstraction |
| 17:21 |
hmmmm |
at the login screen, you give your username/password if you want to login |
| 17:21 |
hmmmm |
and get a repsonse back |
| 17:22 |
hmmmm |
if you fail, the session does not end, the user is simply not authenticated |
| 17:22 |
hmmmm |
at the login screen you also have other choices like: |
| 17:22 |
hmmmm |
change password |
| 17:22 |
hmmmm |
recover password via email |
| 17:22 |
hmmmm |
etc. |
| 17:22 |
hmmmm |
create new account |
| 17:22 |
hmmmm |
so I'm wondering if that model doesn't make more sense. what is your take on it? |
| 17:23 |
est31 |
that model is good, especially the "create account" part. supporting it in the future would however add two additional packets to the init |
| 17:24 |
est31 |
where only one value gets exchanged |
| 17:24 |
est31 |
so I thought it can be also achieved in future with a trick |
| 17:24 |
est31 |
being that we make this a new auth mechanism |
| 17:25 |
hmmmm |
alright back |
| 17:25 |
hmmmm |
i thought about it a bit more |
| 17:26 |
hmmmm |
if we activate this protocol as-is, i don't think it would add any more ill effects if we switch to a different model |
| 17:26 |
est31 |
gtg now, bbi one hour, have to buy as long as shops are still open |
| 17:26 |
hmmmm |
aside from having more legacy packets to deal with |
| 17:26 |
hmmmm |
but i think this is okay since our opcode field is 16 bit |
| 17:26 |
hmmmm |
we can afford having a crapload of packets |
| 17:26 |
hmmmm |
I approve of this change |
| 17:26 |
hmmmm |
looks good to me, activate it |
| 17:27 |
hmmmm |
push the button |
| 17:27 |
hmmmm |
all of the changes I want to make really should be separate from this |
| 17:27 |
est31 |
I'll have an additional look at the compression handling |
| 17:27 |
VanessaE |
I sure hope y'all have backware compat in mind :) |
| 17:27 |
est31 |
yes |
| 17:27 |
VanessaE |
I mean going all the way back to, say 0.4.9 :) |
| 17:28 |
est31 |
the only way srp breaks backward compat is when you log in with a new client and its first time or you change your password, it gets changed to a password you can't use to log in with a legacy client |
| 17:29 |
est31 |
people who regularly switch back should keep that in mind |
| 17:29 |
est31 |
and forth* |
| 17:29 |
est31 |
ok hmmmm I'll look at this compression mode thing, then activate srp |
| 17:29 |
est31 |
but not now, in an hour |
| 17:29 |
* est31 |
is away |
| 18:25 |
|
cib0 joined #minetest-dev |
| 18:54 |
|
MinetestForFun joined #minetest-dev |
| 19:07 |
hmmmm |
by the way |
| 19:07 |
hmmmm |
nobody said anything about https://github.com/kwolekr/minetest/commit/a6da66299659a832d11c81711dc0fd73ca1602e3 |
| 19:09 |
est31 |
pushing in 5 minutes https://github.com/est31/minetest/commit/c1268e32fbf30bf6bce62358f467b8157f4d42b8 |
| 19:10 |
est31 |
hmmmm, that commit is for the lua api, am I right? |
| 19:10 |
hmmmm |
yes |
| 19:10 |
hmmmm |
ahh |
| 19:10 |
est31 |
ah thats what SAPI stands for |
| 19:10 |
hmmmm |
Script API |
| 19:10 |
est31 |
should be documented |
| 19:10 |
hmmmm |
one thing |
| 19:11 |
hmmmm |
u16 compression_modes |
| 19:11 |
est31 |
yes? |
| 19:11 |
hmmmm |
why is that plural? you imply like there are more than one possible |
| 19:11 |
hmmmm |
it's not a bitmap like authentication_methods |
| 19:11 |
est31 |
is it not? |
| 19:11 |
hmmmm |
the compression mode you're choosing is NETPROTO_COMPRESSION_NONE |
| 19:12 |
hmmmm |
compression_modes makes it seem like it could be... |
| 19:12 |
est31 |
umm |
| 19:12 |
hmmmm |
NETPROTO_COMPRESSION_ZLIB | NETPROTO_COMPRESSION_SOMETHING_ELSE |
| 19:12 |
est31 |
yes |
| 19:12 |
hmmmm |
so is compression_modes supposed to be a bitfield?? |
| 19:12 |
est31 |
what I think should happen is that the client sends the compression modes it supports to the server, the server answers with the deployed mode |
| 19:13 |
est31 |
because how can a client chose a compression mode without knowing what the server supports |
| 19:13 |
hmmmm |
but that's in TOSERVER_INIT |
| 19:13 |
est31 |
yes it is supposed |
| 19:13 |
hmmmm |
supported_compression_modes |
| 19:13 |
est31 |
ok |
| 19:14 |
hmmmm |
and make it a static const u16 |
| 19:14 |
hmmmm |
we should document that it's a bitfield somewhere in the documentation |
| 19:14 |
est31 |
why static const? |
| 19:15 |
hmmmm |
it optimizes better |
| 19:15 |
est31 |
it could be a setting for example |
| 19:16 |
hmmmm |
okay nevermind it is there |
| 19:16 |
hmmmm |
(the documentation) |
| 19:17 |
hmmmm |
see, I think it was originally meant to be a single value, not a bitfield |
| 19:17 |
hmmmm |
when nerzhul wrote that enum, he made zlib == 0, not 1 |
| 19:17 |
hmmmm |
i.e. not a flag |
| 19:17 |
hmmmm |
your design to make it a bitfield is ultimately much more sensible |
| 19:18 |
est31 |
:) |
| 19:18 |
hmmmm |
s/design/decision/ |
| 19:18 |
est31 |
and about this "change password, recover password through email" thing |
| 19:18 |
hmmmm |
we'll do that later |
| 19:18 |
est31 |
it is indeed possible right now |
| 19:18 |
hmmmm |
I'd rather not |
| 19:19 |
hmmmm |
let's do all this "login screen" stuff at once |
| 19:19 |
est31 |
because the client sends the desired username |
| 19:19 |
est31 |
the server then sends a list of supported auth methods |
| 19:19 |
est31 |
one of them could be "reset through email" |
| 19:19 |
hmmmm |
not just change password and recover password, but what about create account? |
| 19:19 |
est31 |
so we only have to move the GUI one connection step back |
| 19:20 |
est31 |
yes thats already even there |
| 19:20 |
hmmmm |
so 4 functions |
| 19:20 |
est31 |
its FIRST_SRP :) |
| 19:20 |
hmmmm |
login to existing, create new, change password, recover password |
| 19:20 |
hmmmm |
anything else?? |
| 19:20 |
hmmmm |
if you have a better design please do tell me |
| 19:20 |
hmmmm |
i'm just saying what's intuitive to me personally |
| 19:20 |
hmmmm |
i'm sure there could be better options |
| 19:21 |
est31 |
my idea was |
| 19:21 |
est31 |
that the person enters their username |
| 19:21 |
est31 |
then the init comes |
| 19:21 |
est31 |
then the client either displays "please enter password" |
| 19:21 |
est31 |
or, "create account" |
| 19:21 |
est31 |
this can be done like with modern websites inside the GUI |
| 19:22 |
est31 |
or perhaps not |
| 19:22 |
hmmmm |
so you'd rather have the username and password screens separate |
| 19:22 |
hmmmm |
is what you're saying |
| 19:22 |
|
ElectronLibre joined #minetest-dev |
| 19:23 |
|
ElectronLibre joined #minetest-dev |
| 19:23 |
|
TeTpaAka joined #minetest-dev |
| 19:24 |
est31 |
we can either make a "dynamic" screen where the user only enters username, that gets sent to the server, and the client then either changes the gui to "create new account" or to "log in" |
| 19:25 |
est31 |
or we can make it "static" where the user has to press create account and log in buttons separately |
| 19:25 |
hmmmm |
what if the user fails authentication because he entered a wrong username |
| 19:25 |
hmmmm |
i think i like the static model better |
| 19:25 |
hmmmm |
no reason to fragment |
| 19:27 |
est31 |
either way |
| 19:27 |
est31 |
can I merge the patch? |
| 19:27 |
hmmmm |
yeah |
| 19:27 |
est31 |
good |
| 19:27 |
hmmmm |
i think that in the future, we should couple the username with the auth packets |
| 19:27 |
hmmmm |
keep it separate from initialization |
| 19:28 |
est31 |
hrmm this is what nrz favoured too |
| 19:28 |
est31 |
I decided against because it would have required even more packet sent back and forth |
| 19:28 |
est31 |
=> longer log in process |
| 19:28 |
hmmmm |
why??? |
| 19:28 |
hmmmm |
send it along with A |
| 19:28 |
est31 |
not possible |
| 19:29 |
est31 |
what if user a has only legacy password, and user b has new srp password in the database? |
| 19:29 |
est31 |
the server has to look up inside the database to determine which auth methods it supports for the user |
| 19:30 |
hmmmm |
hmm |
| 19:30 |
est31 |
http://lists.minetest.net/archives/minetest-dev/2015-April/000005.html |
| 19:30 |
hmmmm |
true |
| 19:30 |
est31 |
read from "we have two options now:" |
| 19:31 |
est31 |
or from "About the TOSERVER_AUTH package.", better |
| 19:40 |
hmmmm |
pushing https://github.com/kwolekr/minetest/commit/a6da66299659a832d11c81711dc0fd73ca1602e3 in 5 minutes if nobody has an objection... |
| 19:41 |
est31 |
where exactly is it exposed in the API? |
| 19:41 |
hmmmm |
any time you'd normally enter an {a=255, r=255, g=10, b=10} sort of ARGB8 quad table |
| 19:41 |
hmmmm |
now you have the option of specifying "red" or "purple" instead |
| 19:43 |
est31 |
really? |
| 19:43 |
est31 |
will it also work for the nametag color? |
| 19:43 |
hmmmm |
yep. |
| 19:44 |
est31 |
nice |
| 19:44 |
est31 |
doc/lua_api.txt should point this out though |
| 19:46 |
est31 |
we even accept numbers now, dont we? |
| 19:49 |
est31 |
see my comment hmmmm |
| 19:54 |
|
hmmmmm joined #minetest-dev |
| 20:00 |
|
hmmmmmm joined #minetest-dev |
| 20:05 |
|
hmmmmm joined #minetest-dev |
| 20:08 |
|
hmmmm joined #minetest-dev |
| 20:08 |
|
neoascetic joined #minetest-dev |
| 20:09 |
neoascetic |
Hey. Latest master is broken! https://travis-ci.org/minetest/minetest/builds/62845257 |
| 20:09 |
est31 |
ouch |
| 20:10 |
est31 |
dammit my fault |
| 20:10 |
est31 |
I did compile it |
| 20:10 |
est31 |
I did |
| 20:10 |
est31 |
and then I didnt look at the output |
| 20:10 |
est31 |
argh |
| 20:10 |
neoascetic |
Does travis send some angry error, doesn't it? |
| 20:11 |
|
hmmmmmm joined #minetest-dev |
| 20:11 |
neoascetic |
I noticed this from my osx builds report |
| 20:11 |
est31 |
its my fault |
| 20:12 |
neoascetic |
Travis has IRC integration, I think it would be cool to have it write here on errors on master |
| 20:12 |
est31 |
sfan5, ^ |
| 20:15 |
est31 |
neoascetic, check now |
| 20:31 |
|
est31 joined #minetest-dev |
| 20:50 |
sfan5 |
est31: if you want to have something changed in the travis settings you need to talk to c55 |
| 20:50 |
est31 |
o |
| 20:50 |
est31 |
ok |
| 21:41 |
|
ElectronLibre left #minetest-dev |
| 21:55 |
|
RealBadAngel joined #minetest-dev |
| 22:02 |
ShadowNinja |
.../src/noise.cpp:617:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] |
| 22:02 |
ShadowNinja |
hmmmmmm: Do you have -Wno-sign-compare or something? |
| 22:14 |
ShadowNinja |
I'll push security now. I'll leave it disabled by default at first, and then enable it in a week or so after all mods that I know of that will break from it have been patched. |
| 22:18 |
est31 |
which mods? |
| 22:19 |
ShadowNinja |
est31: WorldEdit, IRC, player_textures, and datastorage will need minor patches to work. |
| 22:20 |
ShadowNinja |
(I've already written patches for all of those mods) |
| 22:36 |
est31 |
ok |
| 23:29 |
|
Wayward_One joined #minetest-dev |
| 23:31 |
hmmmmm |
anyway if you guys don't have any qualms about a6da662 i'll push now |
| 23:33 |
est31 |
hmmmmm, have you seen my comment? |
| 23:33 |
hmmmmm |
oh i'll go look now |
| 23:34 |
est31 |
also it should be documented hmmmmm. |
| 23:34 |
est31 |
otherwise its ok# |
| 23:35 |
hmmmmm |
maybe i'm not understanding your comment |
| 23:36 |
hmmmmm |
i don't think setNametagColor can fail |
| 23:36 |
est31 |
read_color can |
| 23:36 |
hmmmmm |
ahh good catch |
| 23:36 |
hmmmmm |
i forgot about that |
| 23:53 |
|
Wayward_Tab joined #minetest-dev |
| 23:57 |
hmmmmm |
https://github.com/kwolekr/minetest/commit/2daf65fd71555fe31b5140a77acc64261db9260f |
| 23:57 |
jin_xi |
https://github.com/obneq/minetest/tree/scenenodeparticles here is moar wip for irrlicht particles |
| 23:59 |
jin_xi |
so, what do to get some feedback by people who actually know something? make another PR seems kinda weird and all feedback i got there was kinda useless |
| 23:59 |
jin_xi |
anyway if anyone has tips regarding how things _work_ im happy to hear |
