| Time |
Nick |
Message |
| 00:04 |
gentoobro |
ok, thanks :) |
| 00:38 |
|
CraigyDavi`` joined #minetest-dev |
| 00:41 |
|
CraigyDavi joined #minetest-dev |
| 00:43 |
|
zat joined #minetest-dev |
| 00:54 |
|
Anchakor_ joined #minetest-dev |
| 00:59 |
|
Robby joined #minetest-dev |
| 01:14 |
|
CraigyDavi` joined #minetest-dev |
| 01:24 |
|
Exio joined #minetest-dev |
| 01:36 |
|
swaaws joined #minetest-dev |
| 01:37 |
|
sebastia joined #minetest-dev |
| 01:38 |
|
sebastia joined #minetest-dev |
| 01:39 |
|
sebastia joined #minetest-dev |
| 01:45 |
|
Robby_ joined #minetest-dev |
| 01:56 |
|
CraigyDavi`` joined #minetest-dev |
| 02:13 |
|
CraigyDavi joined #minetest-dev |
| 02:40 |
|
swaaws joined #minetest-dev |
| 02:50 |
|
luizrpgluiz joined #minetest-dev |
| 02:50 |
|
luizrpgluiz left #minetest-dev |
| 02:57 |
|
CraigyDavi` joined #minetest-dev |
| 02:59 |
|
CraigyDavi`` joined #minetest-dev |
| 03:26 |
|
CraigyDavi` joined #minetest-dev |
| 03:29 |
|
CraigyDavi joined #minetest-dev |
| 03:32 |
|
Robby joined #minetest-dev |
| 03:33 |
|
CraigyDavi` joined #minetest-dev |
| 03:43 |
|
Hunterz joined #minetest-dev |
| 04:27 |
|
Robby joined #minetest-dev |
| 04:40 |
|
Kalista joined #minetest-dev |
| 04:57 |
|
CraigyDavi joined #minetest-dev |
| 05:00 |
|
CraigyDavi` joined #minetest-dev |
| 05:44 |
|
grrk-bzzt joined #minetest-dev |
| 05:50 |
|
CraigyDavi`` joined #minetest-dev |
| 05:54 |
|
CraigyDavi joined #minetest-dev |
| 05:54 |
|
Hunterz joined #minetest-dev |
| 06:15 |
|
CraigyDavi` joined #minetest-dev |
| 06:45 |
|
werwerwer joined #minetest-dev |
| 06:52 |
|
Garmine joined #minetest-dev |
| 07:51 |
|
CraigyDavi joined #minetest-dev |
| 08:03 |
|
CraigyDavi` joined #minetest-dev |
| 08:12 |
|
CraigyDavi`` joined #minetest-dev |
| 08:24 |
|
CraigyDavi joined #minetest-dev |
| 08:26 |
|
CraigyDavi` joined #minetest-dev |
| 09:02 |
|
CraigyDavi joined #minetest-dev |
| 09:31 |
|
Krock joined #minetest-dev |
| 09:32 |
|
BlockMen joined #minetest-dev |
| 09:55 |
|
deltib joined #minetest-dev |
| 09:56 |
|
Amaz_ joined #minetest-dev |
| 10:05 |
|
VargaD joined #minetest-dev |
| 10:06 |
sfan5 |
https://github.com/minetest/minetest/pull/1510 |
| 10:06 |
sfan5 |
^ comments please |
| 10:13 |
Krock |
+1 |
| 10:14 |
|
vifino joined #minetest-dev |
| 10:24 |
|
Zefram_Fysh joined #minetest-dev |
| 10:26 |
|
CraigyDavi` joined #minetest-dev |
| 10:38 |
|
LemonLake joined #minetest-dev |
| 10:42 |
|
sfan5_ joined #minetest-dev |
| 10:48 |
|
Jordach joined #minetest-dev |
| 10:53 |
sfan5 |
BlockMen: any comments on #282 - #287 ? (at _game) |
| 10:57 |
BlockMen |
sfan5, 282 seems fine. 287 could cause crash when node is nil |
| 10:58 |
sfan5 |
how about #282 - #286 ? |
| 10:58 |
sfan5 |
I'll merge 282 now |
| 10:59 |
sfan5 |
how about #282 - #286 ? -> how about the others? |
| 10:59 |
|
proller joined #minetest-dev |
| 10:59 |
|
ImQ009 joined #minetest-dev |
| 11:00 |
|
CraigyDavi joined #minetest-dev |
| 11:00 |
Zefram_Fysh |
the door code already relies on node definitions not being nil |
| 11:00 |
Zefram_Fysh |
that should probably be fixed; it's just not a new issue introduced by that patch |
| 11:01 |
BlockMen |
283, no; 284 yes; 285 yes; 286 yes |
| 11:01 |
Zefram_Fysh |
why no for 283? |
| 11:02 |
Amaz |
imo 283 doesn't make sense. |
| 11:03 |
sfan5 |
merging the ones BlockMen said yes to. |
| 11:03 |
Zefram_Fysh |
the filled buckets are distinct inventory items, and are useful in creative mode. why would they not be in the creative inventory? |
| 11:03 |
BlockMen |
creative inventory is already overstuffed |
| 11:04 |
BlockMen |
we need categories first (or something else to sort it) and then we can add more items |
| 11:04 |
Zefram_Fysh |
categorisation would be nice, sure |
| 11:05 |
BlockMen |
Zefram_Fysh, you can still convince nore and sfan5, then it goes in |
| 11:05 |
sfan5 |
nore is not here ATM |
| 11:05 |
sfan5 |
he told me we should not wait for his approval of things |
| 11:05 |
Zefram_Fysh |
ah, sporting |
| 11:05 |
Zefram_Fysh |
yeah, nore is on holiday |
| 11:05 |
BlockMen |
well, then for now no 283 |
| 11:05 |
Zefram_Fysh |
sfan5: what is your opinion on 283? |
| 11:06 |
sfan5 |
filled buckets in creative menu would make sense |
| 11:07 |
Zefram_Fysh |
nore has occasionally come online from holiday. I'll try to catch him for at least a quick opinion |
| 11:07 |
sfan5 |
and the {water,lava}_source nodes should probably get removed from the creative inv |
| 11:07 |
Zefram_Fysh |
thanks for your attention to these issues |
| 11:09 |
Zefram_Fysh |
I vacillate about the source nodes. it is useful in creative mode, for some operations, to be able to take a stack of source nodes and place them directly. but they're clearly in a different class from the rest of the inventory, as they're not items that should ever appear in inventory in the regular game |
| 11:10 |
Zefram_Fysh |
the status of "in creative inventory" is a bit overloaded. unified_inventory uses it to decide which items should be visible for the survival-mode craft guide, which is kinda inevitable because there isn't any more specific flag for that |
| 11:11 |
Zefram_Fysh |
and I worry somewhat about creative inventory bloat, for things that would add tens of items to the creative inventory. but I wouldn't worry about it for one-per-liquid-type filled bucket items |
| 11:12 |
BlockMen |
this time its 2 buckets, next time something else. the sum is the point ;) |
| 11:12 |
Zefram_Fysh |
in the technic game, I have an idea for uranium enrichment that would add about 50 grades of uranium metal, potentially each in dust, ingot, and block form. *that's* a bloat worry |
| 11:13 |
BlockMen |
because somewhere else its even worse we dont make it bad |
| 11:13 |
BlockMen |
*need to make |
| 11:13 |
sfan5 |
idea: creative inventory categories |
| 11:14 |
Zefram_Fysh |
true, but I don't think adding the filled buckets is making it bad at all. the filled buckets are distinctly different items; the essence of bloat is to have explicit listing of items that are essentially repeating information |
| 11:14 |
BlockMen |
sfan5, feel free to add it |
| 11:14 |
Zefram_Fysh |
slab and stair and microblock items for each solid block type: that's bloat |
| 11:18 |
Zefram_Fysh |
what do you want to do on 287? I can work up an additional patch that makes the door code generally robust against unregistered nodes. or, the weaker option, I could do a new version of the pairing patch that just avoids repeating that vulnerability in the new code |
| 11:21 |
BlockMen |
https://github.com/minetest/minetest/blob/aebbcbf398a9dde6b2cbc8ab05c103f44f6f703d/builtin/game/misc.lua#L83 |
| 11:21 |
|
asl joined #minetest-dev |
| 11:22 |
Zefram_Fysh |
oh, that's convenient. didn't know about that |
| 11:22 |
Zefram_Fysh |
will revise the patch |
| 11:28 |
|
proller joined #minetest-dev |
| 11:28 |
Zefram_Fysh |
http://paste.scsys.co.uk/409107 is revised patch for #287 |
| 11:34 |
BlockMen |
it should be ~= 0 since the function should return 1 if its a door |
| 11:34 |
Zefram_Fysh |
it was always a negated test |
| 11:38 |
|
BlockMen joined #minetest-dev |
| 11:38 |
Zefram_Fysh |
BlockMen: it was always a negated test. the line being replaced has a "not"; the meaning of the line is "if pt3 isn't a (matching) door" |
| 11:38 |
BlockMen |
oh, right |
| 11:38 |
BlockMen |
sfan5, could you merge ^ |
| 11:39 |
sfan5 |
sure |
| 11:40 |
Zefram_Fysh |
thanks |
| 11:44 |
Kalista |
hey Blockmen i heard you got leveldb to compile from source in windows? |
| 11:45 |
Kalista |
I tried and ran into a few problems, was wondering if you had any specific tips/versions used to get the .lib compiled |
| 11:45 |
BlockMen |
Kalista, just search for leveldbwin |
| 11:45 |
BlockMen |
the download includes a msvc project file |
| 11:46 |
Kalista |
the vs2010 project file? might of got that version already |
| 11:46 |
BlockMen |
yes |
| 11:46 |
sfan5 |
Kalista: I used the leveldb from here https://github.com/bitcoin/bitcoin/tree/master/src/leveldb (just btw) |
| 11:46 |
Kalista |
i ran into a linker error with its .lib after linking it |
| 11:47 |
|
CraigyDavi` joined #minetest-dev |
| 11:49 |
Kalista |
i upgraded the 2010 project to 2013 to match my IDE, then during compilation get 'error LNK2001: unresolved external symbol __imp__PathFileExistsW 4C:\x\leveldb.lib(env_win.obj)minetest' |
| 11:49 |
BlockMen |
what os are you using? |
| 11:49 |
Kalista |
win7 64bit |
| 11:50 |
Kalista |
trying to build 32bit bin |
| 11:50 |
BlockMen |
hmm...have you been using multithreaded (/MT) codegeneration for the lib? |
| 11:50 |
Kalista |
ill double check |
| 11:51 |
Kalista |
set to Multi-threaded Debug DLL (/MDd) |
| 11:51 |
Kalista |
should i recompile with MT? |
| 11:52 |
BlockMen |
yes |
| 11:52 |
Kalista |
kk trying now :) |
| 11:54 |
Kalista |
same error, file was the same size too so maybe it was already /MT |
| 11:55 |
Kalista |
oh wait i made a debug .lib |
| 11:55 |
Kalista |
retrying with release |
| 11:57 |
Kalista |
nope still LNK2001 error :/ |
| 12:04 |
BlockMen |
do you get the link error when trying to compile minetest with leveldb or when compiling leveldb |
| 12:04 |
Kalista |
compiling minetest with leveldb, leveldb compiles file |
| 12:06 |
BlockMen |
could you show me all your additional dependencies for linker input? |
| 12:28 |
|
BlockMen left #minetest-dev |
| 12:32 |
|
CraigyDavi joined #minetest-dev |
| 12:34 |
|
sfan5 joined #minetest-dev |
| 13:23 |
|
AnotherBrick joined #minetest-dev |
| 13:36 |
|
CraigyDavi joined #minetest-dev |
| 14:13 |
|
rubenwardy joined #minetest-dev |
| 14:37 |
|
rubenwardy joined #minetest-dev |
| 14:42 |
|
PilzAdam joined #minetest-dev |
| 14:55 |
|
PenguinDad joined #minetest-dev |
| 14:56 |
|
Taoki[mobile] joined #minetest-dev |
| 15:04 |
|
Calinou joined #minetest-dev |
| 15:27 |
|
Exio joined #minetest-dev |
| 15:32 |
|
Garmine joined #minetest-dev |
| 15:35 |
ShadowNinja |
''tell BlockMen I removed the collision detection a while ago, or at least removed the property, so unless it defaults to true it should be disabled. *checks* |
| 15:35 |
HLuaBot |
I'll tell that to "BlockMen" next time I see them around. |
| 15:36 |
ShadowNinja |
celeron55: http://pastebin.ubuntu.com/7831616/ |
| 15:36 |
celeron55 |
maybe you can fix it |
| 15:42 |
ShadowNinja |
celeron55: Maybe, but I don't know much about how launchpad works, so I might just break all the builds. |
| 15:42 |
ShadowNinja |
Comments? (better non-freetype font) https://github.com/minetest/minetest/pull/1427 |
| 15:42 |
Krock |
^ don't know about license |
| 15:43 |
celeron55 |
ShadowNinja: me neither |
| 15:43 |
celeron55 |
launchpad is basically working on pure luck by now |
| 15:44 |
celeron55 |
there was some reason why the stable build was locked to a version |
| 15:45 |
celeron55 |
i don't remember what it was; someone maintaining it at that time made it so |
| 15:46 |
celeron55 |
i guess the same person who committed the stuff in packaging? |
| 15:46 |
celeron55 |
https://code.launchpad.net/~minetestdevs/minetest-c55/packaging |
| 15:48 |
celeron55 |
http://irc.minetest.ru/minetest-dev/2014-03-25 |
| 15:48 |
celeron55 |
looks like he is called spillz on IRC |
| 15:49 |
celeron55 |
(found this by searching "minetest launchpad gettext site:irc.minetest.ru #minetest-dev" on duckduckgo.com) |
| 16:02 |
|
Hunterz joined #minetest-dev |
| 16:06 |
|
rubenwardy joined #minetest-dev |
| 16:09 |
|
zat joined #minetest-dev |
| 16:12 |
Calinou |
Krock, isn't it the same? |
| 16:13 |
Krock |
Calinou, I think, it's LGPL but it's a font... |
| 16:13 |
Calinou |
it's the same if you didn't changed stuff substantially |
| 16:14 |
Krock |
ok |
| 16:14 |
ShadowNinja |
Krock: Where did you get that font? Did you make it yourself? |
| 16:14 |
Krock |
ShadowNinja, it's an edited .png file |
| 16:14 |
Krock |
already contain in the minetest project |
| 16:16 |
|
alexxs joined #minetest-dev |
| 16:17 |
ShadowNinja |
Krock: Same license then. |
| 16:17 |
Krock |
fine. I just was a little confused about the source of that font |
| 16:19 |
Calinou |
likely from Irrlicht |
| 16:39 |
|
rubenwardy joined #minetest-dev |
| 16:41 |
|
vifino joined #minetest-dev |
| 16:47 |
|
smoke_fumus joined #minetest-dev |
| 16:51 |
ShadowNinja |
Hmmm, there are two ways to implement case-insensitive player names, but one might not work. The player name has to keep it's proper case, because mods do case-sensitive checks and otherwise chests, areas and the like will only work when you connect with the correct case. However, does the client depend on it's player name? If a player connects as sHaDoWnInJa can I forcibly change the name to |
| 16:51 |
ShadowNinja |
ShadowNinja on the server without there being any issues? |
| 16:51 |
sfan5 |
https://github.com/minetest/minetest/pull/1510 |
| 16:52 |
sfan5 |
^ comments please |
| 16:52 |
ShadowNinja |
If not, we'll have a pseudo-case-insensitivity where you can only connect with the right case. |
| 16:52 |
ShadowNinja |
sfan5: Done. |
| 16:58 |
|
CheapSeth joined #minetest-dev |
| 17:04 |
ShadowNinja |
celeron55: Do you know if changing the playername on the server will affect anything? |
| 17:13 |
ShadowNinja |
Well, if it doesn't I might have a working case-insensitive-playername patch soon... |
| 17:16 |
Zefram_Fysh |
the sensible way to be case-insensitive is to fold all strings to canonical case (usually lowercase), so that you're not preserving distinctions that you've decided don't make a difference |
| 17:18 |
Zefram_Fysh |
I wouldn't object terribly to names being fully case insensitive, but please don't give us a bastardised sometimes-case-insensitive-sometimes-case-sensitive (aka "case-insensitive-but-case-preserving") system |
| 17:25 |
|
rubenwardy left #minetest-dev |
| 17:29 |
ShadowNinja |
-_- Using the player name as the salt is being wonderfully helpfull. |
| 17:30 |
ShadowNinja |
Zefram_Fysh: That's exactly what I intend to do. Like IRC does, but with persistence and some semplance of compatability. |
| 17:31 |
Zefram_Fysh |
you will not succeed in maintaining compatibility unless you fully separate the concepts of internal name and display name |
| 17:32 |
Zefram_Fysh |
that's the only way to prevent the "preserved" case screwing up normal string operations on the true name |
| 17:33 |
celeron55 |
hmm, this is pretty hard actually |
| 17:34 |
celeron55 |
doing it adequately could be practically impossible |
| 17:35 |
celeron55 |
even with completely discarding compatibility it would be stupidly hard to get mods work like players would expect |
| 17:37 |
ShadowNinja |
celeron55: Minetest's braindead hashing makes it impossible to do anything much better than https://github.com/ShadowNinja/name_restrictions/blob/master/init.lua#L40-L73 |
| 17:37 |
ShadowNinja |
(Must connect with proper casing) |
| 17:37 |
celeron55 |
braindead hashing? |
| 17:37 |
sfan5 |
<ShadowNinja> -_- Using the player name as the salt is being wonderfully helpfull. |
| 17:38 |
ShadowNinja |
celeron55: hash = sha1(password + name); |
| 17:38 |
sfan5 |
better than no salt |
| 17:38 |
celeron55 |
that's not braindead |
| 17:38 |
celeron55 |
it's just incompatible with this thing |
| 17:40 |
ShadowNinja |
celeron55: The proper way to do it is with a long random string and a seperately transmitted salt. |
| 17:40 |
celeron55 |
so? |
| 17:41 |
Zefram_Fysh |
name as salt isn't a great choice generally, it's just a lot better than having no salt at all |
| 17:41 |
celeron55 |
i'm not going to continue arguing about this; it is what it is and you can't change history |
| 17:41 |
ShadowNinja |
But the sent hash and the hash in our Auth table may differ and still be for the same password. |
| 17:42 |
sfan5 |
the auth system wasn't designed with case-insensetivity in mind |
| 17:43 |
ShadowNinja |
So, for case-insensitive player names we've got that mod, that's about as smart as it gets. |
| 17:45 |
Zefram_Fysh |
the issue you run into here is generally of the form that you can't have different parts of the system disagree about which distinctions (case distinctions here) are significant. IRC gets away with case preservation because it was always so, so everything that talks IRC (at least in theory) knows to treat names that way. you can't retrofit case insensitivity |
| 17:47 |
ShadowNinja |
Zefram_Fysh: You can by forcibly changing the name of the player when they connect to the proper case, if you don't salt the password with the playername. |
| 17:47 |
celeron55 |
we could make this work so that for all new hashes, a special character is prepended to the hash in auth.txt to mean that it is made using a lowercase name; also we will add the hash generated using lowercased name in TOCLIENT_INIT as a new field |
| 17:47 |
celeron55 |
i mean |
| 17:47 |
celeron55 |
TOSERVER_INIT |
| 17:47 |
celeron55 |
then this allows us to move forward with this during the next versions |
| 17:48 |
Zefram_Fysh |
you've got here a disagreement between the auth system and your new code about case sensitivity. that's firmly in the class of problem that I mentioned. if you overcome that, you'll run into an unlimited number of similar disagreements with existing mod code |
| 17:48 |
ShadowNinja |
celeron55: Better yet, don't hash with the player name at all. |
| 17:49 |
Krock |
I got an idea about case insensitive names: create file "renamed.mt", rename all players/* files to lowercase, after then, only use lowercase of each name to open that file |
| 17:49 |
celeron55 |
ShadowNinja: in that case please write a full proposal of how to rework the password hashing scheme |
| 17:49 |
celeron55 |
ShadowNinja: and when agreed, then implement it |
| 17:49 |
celeron55 |
of course we could just push this to 0.5 and do it in an incompatible way; but 0.5 can be even years awayy |
| 17:49 |
celeron55 |
-y |
| 17:50 |
ShadowNinja |
celeron55: salt = random_bytes(); hash = sha1(password + salt) + "$" + salt; |
| 17:50 |
celeron55 |
yes, then the network protocol please |
| 17:51 |
celeron55 |
you need to send the salt to the client at some point, and at the moment that point does not exist |
| 17:51 |
celeron55 |
there is no packet moving before TOSERVER_INIT |
| 17:51 |
ShadowNinja |
That needs work, because the strings are sent with a fixed size. You'll have to add another saly field to TOSERVER_INIT. |
| 17:51 |
celeron55 |
the client can't generate the salt because the salt has to be grabbed from the server's storage |
| 17:51 |
ShadowNinja |
I'd rather just redo this incompatibly in 0.5 though. |
| 17:52 |
sfan5 |
^ |
| 17:52 |
celeron55 |
do you feel like starting to implement it now? |
| 17:53 |
celeron55 |
i've been fine with the idea of somebody starting an official 0.5 branch for a long time already |
| 17:53 |
sfan5 |
BTW: minetest.net could use some new screenshots |
| 17:53 |
ShadowNinja |
Hmmm, yes, the client needs the salt, which means that it would have to send the password in TOSERVER_INIT@ or similar. |
| 17:54 |
ShadowNinja |
INIT2* |
| 17:57 |
|
domtron joined #minetest-dev |
| 18:02 |
* VanessaE |
shudders at the thought of starting the 0.5 branch |
| 18:02 |
Exio |
there have been |
| 18:02 |
Exio |
like, a lot of "start 0.5 branch, why not" |
| 18:04 |
ShadowNinja |
https://github.com/minetest/minetest/pull/1511 |
| 18:04 |
ShadowNinja |
^ Fully compatible, but not ideal. |
| 18:04 |
Zefram_Fysh |
actually, looking at the way you use hashing, the salt isn't winning you anything at all |
| 18:05 |
Zefram_Fysh |
the only benefit you get from the hashing is to force the password's entropy into a fixed size |
| 18:05 |
sfan5 |
are you saying we shouldn't hash passwords? |
| 18:05 |
Zefram_Fysh |
you might as well hash with no salt at all |
| 18:05 |
sfan5 |
nope |
| 18:05 |
sfan5 |
that makes brute-force even easier |
| 18:05 |
sfan5 |
-> rainbow tables |
| 18:06 |
Zefram_Fysh |
I'm not saying you shouldn't hash passwords. the issue is that you're not using hashing in the way that's normally reckoned to be helpful |
| 18:06 |
Zefram_Fysh |
as things stand, there's no need for an attacker to brute-force or otherwise reverse the hash |
| 18:06 |
sfan5 |
we shouldn't use sha1 for passwords anyway |
| 18:06 |
sfan5 |
uh, why? |
| 18:06 |
VanessaE |
sfan5: AES or blowfish then? |
| 18:07 |
Zefram_Fysh |
if an attacker swipes the hash from a server's password database, all he needs to send to login is the captured hash |
| 18:07 |
ShadowNinja |
VanessaE: SHA256 or 512. |
| 18:07 |
sfan5 |
VanessaE: thats not a hashing function |
| 18:07 |
sfan5 |
VanessaE: bcrypt |
| 18:07 |
sfan5 |
ShadowNinja: no |
| 18:07 |
sfan5 |
Zefram_Fysh: no |
| 18:07 |
ShadowNinja |
SHA1 was deprecated for password hashing a while ago. |
| 18:07 |
VanessaE |
I know, but I thought I'd read somewhere that those two could be used for the purpose. |
| 18:07 |
VanessaE |
sha256? bad idea I think. |
| 18:07 |
Krock |
md5? |
| 18:07 |
VanessaE |
md5? O_o |
| 18:07 |
VanessaE |
you're kidding, right? |
| 18:08 |
Krock |
don't know. but it hashes |
| 18:08 |
sfan5 |
Zefram_Fysh: IIRC passwords are sha1(name + sha1(password)) with the sha1(password) coming from the client |
| 18:08 |
sfan5 |
Krock: gtfo |
| 18:08 |
|
Krock left #minetest-dev |
| 18:08 |
VanessaE |
md5 is, as I understand, somewhat trivial to reverse now. |
| 18:08 |
sfan5 |
http://codahale.com/how-to-safely-store-a-password/ |
| 18:08 |
Zefram_Fysh |
the way password hashing is normally done, the way that's really useful for security, is that the client needs to send the actual password, and the server hashes it and compares that to the stored hash. that requires that an attacker who swiped the hash reverse the hash. what you've done is that the client sends the hash, so the server has no proof that the client knows the password, only that he knows the hash |
| 18:09 |
sfan5 |
Zefram_Fysh: no, see what I said |
| 18:09 |
VanessaE |
"You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt." <-- plol |
| 18:10 |
celeron55 |
Zefram_Fysh: yeah, that is true; it doesn't make much sense to do anything more special than the current thing when we have no encryption |
| 18:10 |
celeron55 |
and encryption doesn't make sense unless we have certificates |
| 18:10 |
celeron55 |
and it gets kind of totally over the top |
| 18:10 |
VanessaE |
celeron55: but if you go that route, what good are passwords at all then? |
| 18:10 |
Zefram_Fysh |
sfan5: src/server.cpp around line 1570 appears to just compare the supplied value against stored value, without performing a hashing operation |
| 18:10 |
celeron55 |
VanessaE: just as good for any https web service? |
| 18:10 |
celeron55 |
+as |
| 18:10 |
VanessaE |
celeron55: nononono |
| 18:11 |
ShadowNinja |
Zefram_Fysh: Correct. The client sends the hash the first time and it's compared on every subsequest connection. |
| 18:11 |
VanessaE |
celeron55: I mean as in how some other games do it, where you supply a name, and the game/server generate and exchange a cert and THAT is serves as the user's credentials in the future |
| 18:11 |
VanessaE |
I forget exactly which games - maybe some Quake/OA derivatives. |
| 18:11 |
sfan5 |
VanessaE: how mumble does it? |
| 18:11 |
VanessaE |
sfan5: maybe the same |
| 18:12 |
ShadowNinja |
sfan5: You don't need the password, you just need the hash and an appropriatly modified client. |
| 18:12 |
sfan5 |
ShadowNinja: last time I checked it wasn't like that |
| 18:12 |
ShadowNinja |
VanessaE: The problem with that is that users have to keep track of their cert. |
| 18:12 |
VanessaE |
jeez, my english sucks. |
| 18:13 |
ShadowNinja |
sfan5: Check again. |
| 18:13 |
VanessaE |
ShadowNinja: apparently, the games in question do that automagically. |
| 18:13 |
sfan5 |
ShadowNinja: currently doing |
| 18:13 |
|
Krock joined #minetest-dev |
| 18:13 |
ShadowNinja |
VanessaE: How? |
| 18:13 |
VanessaE |
ShadowNinja: beats me how. I've never looked into it in great detail |
| 18:14 |
Zefram_Fysh |
celeron55: proper password hashing is still useful in the absence of encryption, as it tackles a major threat model (hash spied from static storage), even though it doesn't tackle another major threat model (password sniffed in transit) |
| 18:14 |
Zefram_Fysh |
also, encryption is still useful without certs, as it tackles passive sniffing, even though it doesn't tackle MitM |
| 18:14 |
VanessaE |
I'm surprised sapier isn't here right now ;() |
| 18:14 |
ShadowNinja |
I don't see how that's possible. But SSL/TLS doesn't require you to explictly provide a custom cert, it can make one for you for the duration of the connection. |
| 18:14 |
VanessaE |
;) he loves these security discussions |
| 18:16 |
VanessaE |
ShadowNinja: well it's not like the user needs to know where their key files are stored |
| 18:16 |
ShadowNinja |
Zefram_Fysh: The server could optionally have a custom cert, and on connect you could see something like "this server's certificate fingerprint is 11:22:33:44 do you trust it?". |
| 18:16 |
VanessaE |
I mean, honestly, they don't. |
| 18:16 |
ShadowNinja |
VanessaE: But what if I switch computers? |
| 18:17 |
VanessaE |
ShadowNinja: THEN you can copy your keys over. Surely it would be documented? |
| 18:17 |
Zefram_Fysh |
SN: yes, there are many options along those lines. having certs would be sensible, and the ssh behaviour of picking up public key on first contact to check all later contacts is sensible |
| 18:17 |
VanessaE |
just as when you copy your worlds, mods, etc etc etc over to the new machine |
| 18:17 |
|
Garmine joined #minetest-dev |
| 18:17 |
ShadowNinja |
VanessaE: Too much work for users, too easy to lose your accounts. |
| 18:17 |
VanessaE |
ShadowNinja: tell that to the users who play the games I mentioned |
| 18:18 |
VanessaE |
apparently it's not that big a deal in practice |
| 18:18 |
|
LemonLake left #minetest-dev |
| 18:18 |
PenguinDad |
VanessaE: but what would happen if you accidentally delete your cert? |
| 18:18 |
celeron55 |
VanessaE: that's a client-side certificate then |
| 18:18 |
VanessaE |
or maybe there's a graceful way to recover one's keys? |
| 18:18 |
celeron55 |
VanessaE: it's an additional thing to what i described |
| 18:18 |
celeron55 |
VanessaE: i was talking about a server certificate so that the client can trust the server |
| 18:18 |
ShadowNinja |
VanessaE: I connect from multiple devices, including my tablet(s), and I don't want to have to copy an SSL cert to all of them. |
| 18:18 |
VanessaE |
celeron55: ah, ok. different issue then |
| 18:18 |
celeron55 |
or, maybe just a key pair |
| 18:18 |
celeron55 |
but something like that anyway |
| 18:19 |
VanessaE |
PenguinDad: I don't know. I'm no security expert but come on, there are people who figured this stuff out long ago. doesn't matter, c55 was talking about something else anyways |
| 18:19 |
sfan5 |
ShadowNinja: you were right. last time I tried this with a modified client it didn't work |
| 18:19 |
VanessaE |
(or rather a different part of the same problem) |
| 18:20 |
* VanessaE |
shrugs |
| 18:20 |
VanessaE |
I'll shut up now |
| 18:22 |
Calinou |
<VanessaE> I forget exactly which games - maybe some Quake/OA derivatives. |
| 18:22 |
Calinou |
it uses GUID (globally unique ID) |
| 18:22 |
Calinou |
it's quite evadable and fakable |
| 18:22 |
Calinou |
<sfan5> VanessaE: how mumble does it? |
| 18:23 |
Calinou |
certificates, self-signed, automatic generation |
| 18:23 |
Calinou |
worth as much as a dirt block |
| 18:23 |
sfan5 |
hm? |
| 18:23 |
sfan5 |
care to explain why? |
| 18:23 |
Calinou |
self-signed and automatically generated |
| 18:23 |
Calinou |
it's exactly how certificates are not meant to be used |
| 18:23 |
sfan5 |
who cares about that |
| 18:24 |
sfan5 |
[citation needed] |
| 18:24 |
sfan5 |
as long as the server checks the certificate against a know cert |
| 18:24 |
sfan5 |
it doesn't matter whether self-signed or not |
| 18:27 |
|
grrk-bzzt joined #minetest-dev |
| 18:27 |
|
grrk-bzzt joined #minetest-dev |
| 18:28 |
ShadowNinja |
TLS would be good, but that depends on TCP. This is all best done in 0.5 to avoid compatability headaces or even impossibilities. |
| 18:28 |
|
Garmine42 joined #minetest-dev |
| 18:29 |
sfan5 |
ShadowNinja: dts |
| 18:29 |
sfan5 |
dtls* |
| 18:29 |
VanessaE |
now how about something new... this just came up: http://pastebin.ubuntu.com/7837622/ |
| 18:30 |
sfan5 |
this is not useful without a backtrace |
| 18:30 |
VanessaE |
that's all I got, sorry. |
| 18:33 |
VanessaE |
(you know I'd have produced a backtrace had that been running in gdb or so) |
| 18:40 |
|
Garmine joined #minetest-dev |
| 18:44 |
VanessaE |
I've got it loaded in gdb for the next time though. |
| 18:45 |
VanessaE |
one thing I have noticed is rather high CPU usage lately. can't pin down why |
| 19:24 |
|
fireglow joined #minetest-dev |
| 19:24 |
fireglow |
http://bpaste.net/show/T5cQ4vnJuYGDms2vlI4C/ |
| 19:25 |
VanessaE |
https://github.com/minetest/minetest/issues/1270 |
| 19:27 |
VanessaE |
fireglow: ^^^ |
| 19:27 |
VanessaE |
bbl |
| 19:40 |
|
zat joined #minetest-dev |
| 19:53 |
|
luizrpgluiz joined #minetest-dev |
| 20:15 |
luizrpgluiz |
hi devs |
| 20:19 |
|
proller joined #minetest-dev |
| 20:45 |
|
luizrpgluiz left #minetest-dev |
| 21:02 |
|
luizrpgluiz joined #minetest-dev |
| 21:14 |
RealBadAngel |
https://github.com/minetest/minetest_game/pull/290 |
| 21:17 |
VanessaE |
RealBadAngel: line 327, make it math.random(90) |
| 21:17 |
|
domtron joined #minetest-dev |
| 21:17 |
RealBadAngel |
i picked 180 to be able to flip the plant |
| 21:17 |
Zefram_Fysh |
math.random has inclusive bounds, so math.random(0, 180) has 181 possible outputs, including both 0 and 180. that's not what you want |
| 21:18 |
VanessaE |
RealBadAngel: turning it 180 will flip the textures? |
| 21:18 |
Zefram_Fysh |
you want math.random(0, 179) or math.random(0, 89) |
| 21:18 |
RealBadAngel |
Zefram_Fysh, doesnt really matter |
| 21:19 |
Zefram_Fysh |
it's easy to get it right |
| 21:19 |
VanessaE |
RealBadAngel: then use math.random(180) |
| 21:19 |
VanessaE |
you don't need the 1, |
| 21:19 |
VanessaE |
er 0, |
| 21:19 |
Zefram_Fysh |
math.random(180) is equivalent to math.random(1, 180). that's also a correct approach, if you're not fussy about where you wrap |
| 21:20 |
VanessaE |
since you already offset them by 1 degree anyway to avoid the z-fighting glitch, m.r(180) would be just as good |
| 21:25 |
|
fireglow left #minetest-dev |
| 21:25 |
RealBadAngel |
i made it 0,179 |
| 21:26 |
RealBadAngel |
it afftects dry shrubs, grass, flowers, wheat, papyrus |
| 21:26 |
RealBadAngel |
and ofc not the jungle grass |
| 21:26 |
VanessaE |
cotton too |
| 21:27 |
VanessaE |
if you change wheat, don't forget to change cotton to follow. |
| 21:28 |
VanessaE |
though in this case I guess you already did |
| 21:28 |
RealBadAngel |
yeah |
| 21:28 |
Zefram_Fysh |
is the change of an ABM from interval=90 chance=2 to interval=2 chance=90 intentional? it seems unrelated to the rotation |
| 21:28 |
RealBadAngel |
ouch |
| 21:28 |
RealBadAngel |
thats a mistake |
| 21:29 |
VanessaE |
haha |
| 21:29 |
VanessaE |
good catch, Zefram_Fysh |
| 21:30 |
RealBadAngel |
i was testing that and messed values when restoring defaults ;) |
| 21:33 |
RealBadAngel |
VanessaE, with 180 deg whole the plant will be flipped just |
| 21:34 |
RealBadAngel |
it applies to vertices and texture will follow |
| 21:34 |
VanessaE |
ahh |
| 21:34 |
VanessaE |
ok then 180 ist is. |
| 21:34 |
VanessaE |
it is* |
| 21:34 |
Zefram_Fysh |
with an asymmetric texture, wouldn't a rotation of 181 deg be different from a rotation of 1 deg? |
| 21:35 |
Zefram_Fysh |
I think you need a 360 deg range to cover all visually distinct possibilities |
| 21:35 |
RealBadAngel |
i cant |
| 21:35 |
RealBadAngel |
param2 is u8 |
| 21:35 |
VanessaE |
Zefram_Fysh: 8 bits. |
| 21:35 |
Zefram_Fysh |
oh, of course |
| 21:35 |
VanessaE |
besides, plantlike drawtype has some mirroring anyway |
| 21:36 |
Zefram_Fysh |
you could scale so that the unit is 2 deg, so that param2 in [0, 180) covers a 360 deg range |
| 21:36 |
Zefram_Fysh |
or make the unit 360/256 deg, so that param2 in [0, 256) covers 360 deg |
| 21:36 |
RealBadAngel |
is that really needed? |
| 21:37 |
Zefram_Fysh |
if you rely on mirror symmetry, then surely the relevant rotational symmetry is four-way, because of the crossed polygons of plantlike drawtype, in which case you only want a 90 deg range, not 180 deg |
| 21:37 |
RealBadAngel |
we dont wanna make plants smoothly animate, we want them to be some random |
| 21:37 |
Zefram_Fysh |
absent mirror symmetry, covering the full 360 deg range is not necessary, it just produces a better result |
| 21:38 |
RealBadAngel |
and 180 for sure, textures are asymetric |
| 21:38 |
RealBadAngel |
90 would be correct for symetric texture |
| 21:39 |
Zefram_Fysh |
using as small a rotation unit as possible is also not necessary, just produces a fractionally better result, making better use of the available resources (the u8) |
| 21:39 |
Zefram_Fysh |
there's nothing magical about the degree as a unit |
| 21:40 |
RealBadAngel |
and theres no need to add some magical code to scale it in draw loop |
| 21:40 |
Zefram_Fysh |
oh, but there is |
| 21:41 |
Zefram_Fysh |
if param2 is denominated in degrees, then it *does* have to be scaled |
| 21:41 |
RealBadAngel |
no |
| 21:41 |
RealBadAngel |
its just adding the value |
| 21:41 |
luizrpgluiz |
devs, what programs do I need to do my first mod for minetest? |
| 21:41 |
RealBadAngel |
https://github.com/minetest/minetest/commit/9dc8901e32fcf875c2b3bc52c2dec6b03a29bf37 |
| 21:41 |
Zefram_Fysh |
adding to a value that then gets scaled? |
| 21:42 |
RealBadAngel |
it doesnt get scaled or whatever |
| 21:42 |
VanessaE |
luizrpgluiz: a text editor, an image editor, and minetest. |
| 21:42 |
luizrpgluiz |
But which one? have a good program that can recommend me to use? |
| 21:42 |
VanessaE |
luizrpgluiz: I use gedit and sometimes nano |
| 21:43 |
VanessaE |
RealBadAngel uses geany |
| 21:43 |
VanessaE |
some folks are happy with notepad++ or whatever it's called |
| 21:43 |
Zefram_Fysh |
rotateXZBy is obviously doing some scaling internally |
| 21:43 |
RealBadAngel |
but thats not our concern, its irrlicht |
| 21:44 |
luizrpgluiz |
and to draw the blocks? |
| 21:44 |
VanessaE |
luizrpgluiz: you specify the blocks in your code by telling the engine what draw type you want to use. |
| 21:44 |
Zefram_Fysh |
anyway, if you insist on using a degree-denominated API, you can have the unit be 2 deg, with "+ n.param2 * 2", and on x86 that's exactly the same cost as "+ n.param2". that's cheap scaling |
| 21:45 |
VanessaE |
luizrpgluiz: i.e. you tell the engine that a given node is a cube, or a plantlike, or flat, or one of a number of others |
| 21:45 |
VanessaE |
and you tell it what the properties are of that node, such as how much light it projects (if any), what groups its in, its name, and a whole host of other things |
| 21:45 |
VanessaE |
supply textures to it |
| 21:46 |
VanessaE |
and the engine does the rest |
| 21:46 |
VanessaE |
later on you can tell the engine to execute pieces of code in response to your node being punched, right clicked, etc. |
| 21:48 |
VanessaE |
RealBadAngel: he does have a point - if the processor won't run any slower with a multiplier/shift operation added, you may as well designate it in 2-degree increments. |
| 21:50 |
Zefram_Fysh |
it's the LEA (load effective address) instruction. you get an addition of up to two registers, one of them optionally shifted left by up to 3 bits, and a constant, all in one instruction that executes in one tick |
| 21:50 |
Zefram_Fysh |
CISC, eh |
| 21:53 |
RealBadAngel |
please explain me what for? |
| 21:54 |
Zefram_Fysh |
so that the range of possible plant rotations covers the full circle |
| 21:54 |
RealBadAngel |
180 degs cover whole circle |
| 21:54 |
Zefram_Fysh |
no, 180 deg covers half a circle |
| 21:54 |
RealBadAngel |
remember that texture is 2 sided |
| 21:55 |
VanessaE |
RealBadAngel: yeah, but the other side is mirrored. |
| 21:55 |
RealBadAngel |
back of it will come in front |
| 21:55 |
RealBadAngel |
exactly |
| 21:55 |
VanessaE |
I mean left-to-right mirrored. |
| 21:55 |
Zefram_Fysh |
if you ignore asymmetry of the texture, then the fact that the texture is shown in two places 90 deg apart means that 90 deg range would effectively cover the whole circle |
| 21:56 |
RealBadAngel |
but most of the textures are asymmetric |
| 21:56 |
Zefram_Fysh |
if asymmetry applies, then you need 360 deg. neither way is 180 deg both necessary and sufficient |
| 21:56 |
RealBadAngel |
its good enough |
| 21:57 |
Zefram_Fysh |
try it out with a temporary very-asymmetric texture. try to get a screenshot showing plants covering the whole 360 deg at intervals of 30 deg |
| 21:57 |
RealBadAngel |
as i said its used to randomize stuff, not for smooth animations of plants |
| 21:58 |
RealBadAngel |
nobody will walk around and check if flowers in the world does rotate in full circle |
| 21:58 |
Zefram_Fysh |
the randomisation would be appreciably better if it covered the whole range. not attempting smooth animation is exactly why a 2 deg step will be fine |
| 21:59 |
Zefram_Fysh |
as for "good enough", the game is good enough without this param2 rotation at all |
| 21:59 |
RealBadAngel |
no its not |
| 21:59 |
luizrpgluiz |
I want to create a biome using the blocks game |
| 21:59 |
RealBadAngel |
all the plants in the row look the same |
| 22:00 |
RealBadAngel |
and thats not any good |
| 22:00 |
Zefram_Fysh |
it doesn't affect gameplay. it's only cosmetic |
| 22:00 |
VanessaE |
luizrpgluiz: can you be more specific? |
| 22:00 |
RealBadAngel |
like almost everything i code in the engine lately |
| 22:01 |
luizrpgluiz |
I looked a mod minecraft with giant trees using the blocks game |
| 22:01 |
VanessaE |
luizrpgluiz: https://forum.minetest.net/viewtopic.php?id=4394 |
| 22:02 |
RealBadAngel |
if you doesnt care bout it make flowers full nodes ;) |
| 22:02 |
RealBadAngel |
no rotations or whatever needed, funcionality will remain the same |
| 22:03 |
Zefram_Fysh |
I do like the game to look better than what is merely good enough. as do you |
| 22:03 |
luizrpgluiz |
yes, bad blocks using the game itself without using other dependencies |
| 22:04 |
VanessaE |
RealBadAngel, Zefram_Fysh all of this aside, what about the placement of the orthogonal textures? Would a rotation of +90 look the same as 180? |
| 22:05 |
Zefram_Fysh |
no |
| 22:05 |
VanessaE |
luizrpgluiz: you could always code your own game or mod to do the same thing but why re-invent the wheel? |
| 22:06 |
Zefram_Fysh |
looking at the node, you can pick out, for example, the right-hand sides of each instance of the texture. the combination of the two uniquely identifies a quadrant of the node |
| 22:06 |
VanessaE |
Zefram_Fysh: good point |
| 22:06 |
Zefram_Fysh |
if you rotate that by 90 deg, you have textures in the same planes, but one of them the opposite way round |
| 22:09 |
luizrpgluiz |
is not it, what I want is to create new biomes using blocks minetest own, such as a biome where trees have one on top of another |
| 22:12 |
VanessaE |
luizrpgluiz: well that should be easy enough to code. |
| 22:14 |
luizrpgluiz |
yes |
| 22:28 |
|
Ritchie joined #minetest-dev |
| 23:11 |
Jordach |
apparently minetestserver is not detecting existing games with --gameid <gameid> |
| 23:17 |
|
grrk-bzzt joined #minetest-dev |
| 23:17 |
|
grrk-bzzt joined #minetest-dev |
| 23:52 |
|
Gethiox joined #minetest-dev |
