| Time |
Nick |
Message |
| 01:44 |
|
kaeza joined #minetest-dev |
| 02:18 |
|
NakedFury joined #minetest-dev |
| 02:42 |
|
Splizard joined #minetest-dev |
| 02:43 |
Splizard |
Hello I have a question regarding minetest networking. Is there any plan to implement player movement calculated by the server? |
| 02:48 |
Splizard |
The reason I ask is that the current way if things, player lag can badly affect the game. I don't have too much experience with c++ but I have some experience in game networking and I am able to write up some psudo-code to fix this if the devs are interested. |
| 02:59 |
|
sokomine joined #minetest-dev |
| 04:16 |
|
kaeza joined #minetest-dev |
| 04:36 |
IceCraft |
mornin` |
| 04:44 |
|
neko259 joined #minetest-dev |
| 05:43 |
|
RealBadAngel joined #minetest-dev |
| 07:59 |
|
jin_xi joined #minetest-dev |
| 08:24 |
|
nalkri joined #minetest-dev |
| 09:23 |
|
ironzorg joined #minetest-dev |
| 09:23 |
ironzorg |
hoi |
| 09:23 |
ironzorg |
10:57:17: ERROR[main]: generate_shader(): failed to generate "bumpmaps_solids", addHighLevelShaderMaterial failed. |
| 09:23 |
ironzorg |
do I have to look into the code to fix this ? |
| 09:23 |
ironzorg |
I tried enable_shaders = {1,2} |
| 09:34 |
sfan5 |
ironzorg: thats pretty normal |
| 09:34 |
sfan5 |
the bumpmap shaders seem to be some sort of non portable |
| 09:34 |
* sfan5 |
is now afk |
| 09:35 |
sfan5 |
^ not an automatic script |
| 09:35 |
celeron55 |
>since he told proller to push it although 3 other core devs are against it |
| 09:35 |
celeron55 |
eh |
| 09:36 |
celeron55 |
if you're against something, tell it clearly; and nobody noticed anything bad in the code the way it was now revealed |
| 09:37 |
celeron55 |
anyway that should be fixed |
| 09:39 |
|
iqualfragile joined #minetest-dev |
| 09:40 |
celeron55 |
there are reasons why i'm trying to be extra careful with everything that involves the map and versions, but apparently that wasn't enough 8) |
| 09:40 |
|
Calinou joined #minetest-dev |
| 09:40 |
celeron55 |
oh also |
| 09:40 |
celeron55 |
it's not my responsibility to make sure that contributors listen to core devs |
| 09:41 |
celeron55 |
if everyone disagrees with me and i'm too dumb to see it (if somebody thinks that is what happened), then the contributor is supposed to see it |
| 09:43 |
Exio4 |
celeron55: proller saw 'everybody' was against it and was looking for someone to say yes |
| 09:44 |
celeron55 |
i see that the reason why this went bad is because before we haven't ever added anything to mapblocks in such a way that they aren't saved to disk but are transferred over network |
| 09:45 |
celeron55 |
and the versioning doesn't take that into account |
| 09:46 |
celeron55 |
hmm |
| 09:47 |
celeron55 |
so as far as i can see, this will not break network compatibility |
| 09:48 |
celeron55 |
because the server keeps track of which clients support which map serialization format and serializes accordingly |
| 09:48 |
celeron55 |
so this breaks disk compatibility because of a backwards-compatible network addition was made 8) |
| 09:48 |
celeron55 |
5/5 |
| 09:50 |
celeron55 |
this can be fixed though |
| 09:51 |
celeron55 |
via two things |
| 09:51 |
celeron55 |
first, map version 26 will be declared the same as 25 and saved versions will be 25 until version 27 is made |
| 09:52 |
celeron55 |
second, an additional separately versioned mapblock over-network data will be transferred with mapblocks to newer clients |
| 09:52 |
celeron55 |
in where the weather stuff goes |
| 09:53 |
celeron55 |
and all future things that are similar to it |
| 09:54 |
celeron55 |
do people think that is needed? it's needed if it is desired to either solve this incompatibility now, or solve future incompatibilities similar to this |
| 09:57 |
celeron55 |
(i can code it, but won't if people think we should rather keep it simpler like now) |
| 10:01 |
celeron55 |
(also if people think that proller's stuff is really not wanted, then the whole thing can be reverted (and v26 declared same as 25); however, for that to happen, people will actually need to say it rather than mumble something close to it) |
| 10:02 |
|
Jordach joined #minetest-dev |
| 10:11 |
|
RealBadAngel joined #minetest-dev |
| 10:17 |
|
proller joined #minetest-dev |
| 10:23 |
celeron55 |
(this is the commit for reference: https://github.com/minetest/minetest/commit/3aedfac9685c2d9ae8bac5a5b7e72e527f22c08d) |
| 10:26 |
ironzorg |
(somebody likes LSIP) |
| 10:26 |
ironzorg |
LISP |
| 10:26 |
ironzorg |
I ruined my joke |
| 10:43 |
Exio4 |
the next step is rewriting minetest in haskell |
| 10:46 |
Exio4 |
ironzorg: what is the error itself? |
| 10:47 |
ironzorg |
what ? |
| 10:47 |
|
Calinou joined #minetest-dev |
| 10:50 |
Exio4 |
the shader(s) problem |
| 10:51 |
Exio4 |
RealBadAngel: https://github.com/EXio4/minetest/commit/c1d4467a132c1ee5673dcbc774421aca571d168e |
| 10:51 |
Exio4 |
i hope he looks at it later |
| 10:55 |
ironzorg |
Exio4: that's the error |
| 10:55 |
Exio4 |
ironzorg: er, it should said something before |
| 10:56 |
ironzorg |
yea wait |
| 10:56 |
ironzorg |
http://codepad.org/epw7vPeL |
| 10:56 |
ironzorg |
linux amd64 |
| 10:58 |
Exio4 |
what gpu? what driver? |
| 10:58 |
Exio4 |
well, move this to #minetest, this is getting converted into support |
| 11:05 |
RealBadAngel |
ironzorg, your video drivers doesnt support opengl, propably youre using open ones. please install propertiary drivers for your GPU |
| 11:06 |
ironzorg |
yea that' what I thought |
| 11:06 |
ironzorg |
I have an integrated chipset… |
| 11:06 |
Calinou |
RealBadAngel: WTF? |
| 11:06 |
Calinou |
the open source drivers do support OpenGL |
| 11:06 |
Calinou |
also, intel doesn't even have a proprietary driver for their recent (non-crappy) IGPs |
| 11:07 |
ironzorg |
obviously it supports opengl yes |
| 11:08 |
|
nalkri joined #minetest-dev |
| 11:09 |
RealBadAngel |
Calinou, open drivers support for opengl one can stick deep in the ... ;) |
| 11:09 |
Calinou |
not at all |
| 11:09 |
Calinou |
they follow standards, but aren't permissive, unlike nvidia's impelemntation |
| 11:09 |
Calinou |
if you follow the standards it'll work |
| 11:09 |
Calinou |
but sadly, people believe creating headaches for code correctness is better than saving time |
| 11:10 |
RealBadAngel |
on my box they do work, yes |
| 11:10 |
RealBadAngel |
generating 5-6fps |
| 11:10 |
Calinou |
nvidia doesn't want an open source driver |
| 11:10 |
Calinou |
so nouveau sucks |
| 11:10 |
RealBadAngel |
while with propertiary i do get 40+ fps |
| 11:11 |
Calinou |
AMD actually supports their OSS driver |
| 11:11 |
ironzorg |
just for the records, minetest runs flawlessly with the oss drivers I have |
| 11:11 |
ironzorg |
just can't get glsl to work |
| 11:12 |
Calinou |
old intel IGP then |
| 11:12 |
ironzorg |
yes |
| 11:12 |
Calinou |
back when they were crappy :P |
| 11:13 |
Jordach |
when did intel make something good |
| 11:13 |
Calinou |
their CPUs, and recent IGPs |
| 11:33 |
|
BlockMen joined #minetest-dev |
| 12:03 |
|
PilzAdam joined #minetest-dev |
| 12:45 |
|
serengeor joined #minetest-dev |
| 12:53 |
|
proller joined #minetest-dev |
| 14:04 |
celeron55 |
intel never makes anything but good |
| 14:05 |
celeron55 |
speed is only one measurement and often irrelevant |
| 14:21 |
|
Calinou joined #minetest-dev |
| 14:28 |
|
nalkri joined #minetest-dev |
| 14:34 |
proller |
im trying to make clouds upper than 120, to 1000 - and they shart cutting on ~2000 range from me |
| 14:34 |
Calinou |
far clip |
| 14:35 |
proller |
maybe increase clipping to 3000-4000? or maybe it possible to adjust only for clouds ? |
| 14:35 |
Calinou |
try 500 instead of 1000 |
| 14:35 |
proller |
no, only 300 works good |
| 14:36 |
proller |
with 500 clipping works too |
| 14:36 |
proller |
with 300 its hidden in fog |
| 14:36 |
proller |
visible with 500 |
| 14:57 |
|
diemartin joined #minetest-dev |
| 15:04 |
|
sapier joined #minetest-dev |
| 15:11 |
sapier |
https://github.com/minetest/minetest/pull/640 I know I asked this yesterdays but except of pilzadam noone responded |
| 15:12 |
|
serengeor joined #minetest-dev |
| 15:12 |
sapier |
and of course this one too: https://github.com/minetest/minetest/pull/418 |
| 15:15 |
* proller |
+1 for 640 |
| 15:16 |
|
hmmmm joined #minetest-dev |
| 15:16 |
proller |
+#include <math.h> |
| 15:16 |
proller |
dont |
| 15:16 |
sapier |
no? |
| 15:16 |
sapier |
why? |
| 15:17 |
proller |
or yes with #include "util/mathconstants.h" |
| 15:17 |
proller |
or only #include "util/mathconstants.h" |
| 15:17 |
proller |
because MSVshit doesnt know about M_PI |
| 15:18 |
sapier |
ok I'll fix it |
| 15:19 |
ShadowNinja |
sapier: I think it would be better to search down. That would make hitting caves less likely. But doesn't the mapgen have a height map? |
| 15:19 |
* proller |
+1 for 418 |
| 15:19 |
proller |
height map doesnt work on float islands |
| 15:20 |
ShadowNinja |
Ok, is there already a height map function? |
| 15:20 |
proller |
and on your buildings |
| 15:21 |
sapier |
spawning mobs requires to know surface this is done in lua atm and causes lots of load thus I made this fct quite some time ago ... long before any heightmap was added ... I'm not sure if heighmap would be an exact replacement |
| 15:21 |
ShadowNinja |
+1 for 418 |
| 15:22 |
|
Calinou joined #minetest-dev |
| 15:22 |
proller |
no sense to use heightmap after mapgen, height may be changed by player, trees, liquid |
| 15:27 |
sapier |
ok I removed math.h the other one was already there |
| 15:33 |
sfan5 |
what about lowering the default player count to 32? |
| 15:36 |
sapier |
for what reason? |
| 15:37 |
sfan5 |
Do you think a default limit of 100 makes much sense? |
| 15:37 |
sapier |
does 32 make more sense? ;-) |
| 15:37 |
sfan5 |
yes, its lower |
| 15:37 |
sapier |
and you think lower is better? |
| 15:37 |
sfan5 |
and it won't limit anyone |
| 15:37 |
sfan5 |
you can change it anyway |
| 15:38 |
sapier |
yes but you still haven't told any reason except you feel 32 is better |
| 15:39 |
sfan5 |
because possible (d)dos script for servers (which can work using a spoofed IP) -> see scrollback of #minetest |
| 15:39 |
sapier |
and minetest should be capable of handling way more than 100 players as mobs have about same performace impact (not exactly same of course)... so 100 or 500 doesn't make much difference |
| 15:40 |
sapier |
ok I'll have a look at #minetest but I don't think this really fixes any problem ... imho it's more like hiding a problem |
| 15:41 |
sapier |
btw "to stop (d)dos attacks" would've been the reason I was asking for at first ;-) |
| 15:44 |
sfan5 |
you don't even need the second D of ddos to get a minetest server unuseable |
| 15:50 |
|
sapier1 joined #minetest-dev |
| 15:57 |
Jordach |
most servers DoS themselves with < 13 users |
| 15:58 |
proller |
/usr: write failed, filesystem is full |
| 15:58 |
proller |
cause to crash 8) |
| 16:00 |
|
RealBadAngel joined #minetest-dev |
| 16:04 |
celeron55 |
oh god, it's that encryption discussion yet again on #minetest |
| 16:04 |
sfan5 |
yet again? |
| 16:04 |
celeron55 |
all of that has been talked through in here at least twice |
| 16:04 |
sfan5 |
and the conclusion was ? |
| 16:05 |
|
NakedFury joined #minetest-dev |
| 16:05 |
celeron55 |
it always results in that doing it non-properly is worthless, and doing it properly is so much work that it's not going to happen in near future; it will possibly be included in a far-future protocol rewrite |
| 16:06 |
|
iqualfragile joined #minetest-dev |
| 16:06 |
celeron55 |
anyway, DoS resistance should be improved if the server is so vulnerable to it |
| 16:06 |
celeron55 |
(there are many ways for doing that) |
| 16:06 |
sfan5 |
define non-properly and properly or link a discussion please |
| 16:08 |
sfan5 |
max conns from an IP is worthless against the attack we already had because DoS-ing can be done with a spoofed IP |
| 16:10 |
RealBadAngel |
celeron55, kahrl: were there any particular reason to pick SMhesh instead of IMesh? |
| 16:10 |
|
tango_ joined #minetest-dev |
| 16:12 |
celeron55 |
RealBadAngel: probably some additional method in SMesh |
| 16:12 |
celeron55 |
sfan5: i can't really find a proper one |
| 16:12 |
RealBadAngel |
im askin because i need methods that use IMesh |
| 16:13 |
RealBadAngel |
SMesh is simplified from what i have read in docs |
| 16:14 |
celeron55 |
sfan5: but anyway, for example encryption isn't that useful unless you can verify the peer you're connected to is what it says it is |
| 16:14 |
celeron55 |
i'm all in for more security, but i think it's worthless to do it for the current protocol |
| 16:15 |
celeron55 |
(also there are library issues) |
| 16:15 |
RealBadAngel |
celeron55, i need to convert all the meshes ingame with this: http://irrlicht.sourceforge.net/docu/classirr_1_1scene_1_1_i_mesh_manipulator.html#ab849bd2c83b206de1e5da19ce3481e35 |
| 16:15 |
celeron55 |
SMesh implements the IMesh interface |
| 16:15 |
celeron55 |
afaik |
| 16:15 |
RealBadAngel |
so it shall work? |
| 16:16 |
celeron55 |
oh, that outputs IMesh though |
| 16:16 |
celeron55 |
so it won't |
| 16:16 |
RealBadAngel |
i need it because it provides tangent space |
| 16:16 |
celeron55 |
oh well, i guess you'll need to find out whether the SMesh pointers can be degraded to IMesh |
| 16:16 |
RealBadAngel |
both tangent and binormal |
| 16:17 |
RealBadAngel |
and those are vital to any advanced effects |
| 16:17 |
celeron55 |
by the way, nobody commented anything to what i said at the morning about the map backwards compatibility that proller committed |
| 16:17 |
RealBadAngel |
can you quote urself? |
| 16:18 |
celeron55 |
this day's and yesterday evening's log |
| 16:18 |
celeron55 |
it's long |
| 16:18 |
RealBadAngel |
im workin on night shifts so i was afk for sure, please point me to logs |
| 16:18 |
celeron55 |
http://irc.minetest.ru/minetest-dev/2013-07-30#i_3226568 http://irc.minetest.ru/minetest-dev/2013-07-31 |
| 16:19 |
RealBadAngel |
ty |
| 16:19 |
|
PilzAdam joined #minetest-dev |
| 16:27 |
sfan5 |
celeron55: so public key auth would need to be added too, that would increase the number of libs Minetest depends on |
| 16:29 |
celeron55 |
well any encryption will increase |
| 16:29 |
celeron55 |
the first step would be to find a suitable library that does something that is wanted |
| 16:29 |
sfan5 |
openssl, polarssl, libtomcrypt |
| 16:30 |
celeron55 |
as for what i've looked, libtomcrypt seems best out of those |
| 16:30 |
sfan5 |
I've used libtomcrypt too(for small things); works pretty well |
| 16:31 |
celeron55 |
sapier is most familiar with openssl i guess; i'm most familiar with crypto++ (due to work), but crypto++ is probably not really what we want here |
| 16:33 |
sfan5 |
I guess RSA is the only choice for Public key auth, what about the block cipher for data encryption? |
| 16:34 |
celeron55 |
dunno; something that happens to work easily |
| 16:35 |
|
proller_ joined #minetest-dev |
| 16:35 |
sfan5 |
AES and XTEA are the ones that work simple (RC4 too, but isn't too secure) |
| 16:35 |
sfan5 |
s/simple/good/ |
| 16:35 |
PilzAdam |
celeron55, the problem with proller's code is not that nobody wants this features, but rather that its currently too unfinished to judge it |
| 16:36 |
PilzAdam |
celeron55, the last thing that was pushed "too early" were finite liquids, and now nobody cares to fix them since they are already upstream |
| 16:36 |
celeron55 |
sfan5: try making a branch that does some tiny thing with some crypto library that is also bundled in the source for easy building on windows; that way somebody can start working from there if we can approve it as a base |
| 16:36 |
proller_ |
https://github.com/proller/minetest/commit/5038bc00564913b2db5f1839ad52083c7e08414c |
| 16:37 |
proller_ |
celeron55, liquids per map, upper clouds ^^ |
| 16:37 |
celeron55 |
PilzAdam: i agree |
| 16:37 |
celeron55 |
PilzAdam: it's problematic because we also really can't just do nothing |
| 16:37 |
proller_ |
PilzAdam, i'm ix luquids |
| 16:37 |
PilzAdam |
proller_ tends to pop up with little features/tweaks, and nobody can see what he tries to accomplish at the end |
| 16:38 |
celeron55 |
we need to have something larger going on because, well, people like that and in the end we're just trying to do something people will like |
| 16:38 |
sfan5 |
celeron55: I'll do that.. ..after I have understood libtomcrypts build system |
| 16:38 |
PilzAdam |
I already suggested this a few times: I think it would be best if proller_ just works in his own fork for a while, until we can actually see the end result |
| 16:38 |
celeron55 |
i agree with that too; i really think proller should write down what he wants to accomplish in the long term |
| 16:38 |
celeron55 |
that way other people can judge his solutions |
| 16:39 |
celeron55 |
(and improve them) |
| 16:39 |
proller_ |
and "nobody wants"- its false. many peoles want it and use it |
| 16:39 |
celeron55 |
you should document that too; who uses it and for what reasons |
| 16:40 |
proller_ |
i think about write to wiki.. |
| 16:40 |
celeron55 |
PilzAdam: i agree that that would solve some problems |
| 16:40 |
celeron55 |
also, i think most larger features were developed like that |
| 16:41 |
proller_ |
PilzAdam, long forks is too hard to keep updated |
| 16:41 |
|
iqualfragile joined #minetest-dev |
| 16:42 |
proller_ |
and nobody will agree to merge huge fork |
| 16:42 |
celeron55 |
yes they will, if you've worked with them and they have know from the start (the documentation) what it's for |
| 16:43 |
celeron55 |
of course depending that they agree to it from the start |
| 16:43 |
proller_ |
in next steps i want to fix liquid visuals and make it 63 levels for smoooth flowing |
| 16:44 |
celeron55 |
the only thing i know about what you're trying to do is that you want some kind of dwarf fortressy water physics with somewhat improved visuals, but all the details are completely unknown |
| 16:44 |
proller_ |
and maybe make one liquid block "water" and "lava" with levels and infinity flag |
| 16:44 |
PilzAdam |
celeron55, your solution to mapblock version seems good to me |
| 16:45 |
proller_ |
celeron55, maybe like this (it ideas, not all is true for implement) https://forum.minetest.net/viewtopic.php?id=4618 |
| 16:45 |
celeron55 |
PilzAdam: so you think separating the only-over-network data would be best? |
| 16:46 |
PilzAdam |
yep |
| 16:47 |
celeron55 |
do you or proller want to do that or do i have to (i would rather work on something else i'm working on... as usual 8)) |
| 16:48 |
PilzAdam |
proller_ said yesterday that he wants to fix it |
| 16:49 |
proller_ |
i can maybe in weekend |
| 16:51 |
Exio4 |
revert the weather commit now then |
| 16:51 |
celeron55 |
Exio4: you can't do that, you'll break stuff because of... "laws of versions" |
| 16:51 |
celeron55 |
(as opposed to laws of physics) |
| 16:52 |
Exio4 |
hm |
| 16:52 |
proller_ |
sipler to make try-catch |
| 16:52 |
celeron55 |
basically it should work when made with these two principles: 1) the disk data should be saved with format number 25, and 26 should be loaded like 25; serialization.h should read "26: Same as 25. This should be never written on disk."; 2) the network data should be versioned according to the protocol version |
| 16:52 |
celeron55 |
s/the network data/the additional network data/ |
| 16:53 |
celeron55 |
of course 26 could be simply reverted, but then some maps will be broken quite unrepairably |
| 16:54 |
celeron55 |
as people use git head while they shouldn't |
| 16:54 |
|
Miner_48er joined #minetest-dev |
| 16:55 |
Exio4 |
good job proller! |
| 16:56 |
proller_ |
its by design |
| 16:56 |
|
neko259 joined #minetest-dev |
| 16:57 |
proller_ |
celeron55, maybe make supported version = current+1 ? |
| 16:57 |
Exio4 |
ehm |
| 16:57 |
celeron55 |
lol no |
| 16:57 |
proller_ |
and increase by 2 when really incompatible changes ? |
| 16:57 |
|
Calinou joined #minetest-dev |
| 16:57 |
Exio4 |
nice way to workaround the things proller_ |
| 16:57 |
celeron55 |
you can't do it like that; if one wants to do it like that, then something like each 10 being incompatible would work, kind of, but not really |
| 16:58 |
celeron55 |
and that still leves you with only 10 versions between breakage |
| 16:58 |
RealBadAngel |
https://github.com/minetest/minetest/pull/688 this seems to be ready to merge |
| 16:58 |
celeron55 |
the whole thing could support major, minor and patch versions, but that gets awfully complicated |
| 16:59 |
proller_ |
.. 100 ! 8) |
| 16:59 |
celeron55 |
we're best off with what we have, but simply by not inducing on-disk format version changes from network changes, like i suggested and what pilzadam agreed to |
| 17:00 |
proller_ |
will try to fix faster... |
| 17:01 |
RealBadAngel |
celeron55, according to talks you have mentioned earlier. imho from time to time major chages will break compability no matter what. taking care of backwards compability (extra code) sometimes can bring more harm than good |
| 17:02 |
RealBadAngel |
introducing such big change as weather imho shall bump minetest version |
| 17:02 |
Exio4 |
http://irc.minetest.ru/minetest-dev/2013-07-27#i_3220738 |
| 17:03 |
RealBadAngel |
theres still 031 alive |
| 17:03 |
celeron55 |
RealBadAngel: we don't do backwards compatibility in on-disk changes |
| 17:03 |
celeron55 |
because of exactly that |
| 17:03 |
celeron55 |
as for network we can afford it... but the framework we currently have kind of struggles with it and various people tend to not be familiar enough with it... |
| 17:03 |
RealBadAngel |
so lets make new border line, new version |
| 17:04 |
celeron55 |
there doesn't need to be any "border lines" |
| 17:04 |
celeron55 |
it's nonsense |
| 17:04 |
RealBadAngel |
at least with naming at informing the players |
| 17:05 |
RealBadAngel |
"like from now on.." |
| 17:05 |
celeron55 |
we can do that in any case as we have regular releases |
| 17:05 |
RealBadAngel |
but we still are stuck to rollin model |
| 17:06 |
proller_ |
now network backward compat is broken by nodeboxes |
| 17:06 |
RealBadAngel |
lets make at least monthly realease plan |
| 17:07 |
Exio4 |
that would suck |
| 17:07 |
RealBadAngel |
why do you think so? |
| 17:08 |
Exio4 |
1 month is nothing in terms of time |
| 17:08 |
celeron55 |
any kind of versioning or release plans only sound to me like "endless hurry and endless hastily broken compatibilities" |
| 17:08 |
RealBadAngel |
but short enough for any developer to plan when to push the changes |
| 17:08 |
celeron55 |
you can propose something though |
| 17:09 |
RealBadAngel |
now many code seems to be "on hold" |
| 17:09 |
RealBadAngel |
waiting for xmas |
| 17:10 |
PilzAdam |
RealBadAngel, a fixed release plan would get even more pull request rejected |
| 17:10 |
RealBadAngel |
ofc |
| 17:10 |
PilzAdam |
since we have at least 1 week feature freeze before a release |
| 17:10 |
RealBadAngel |
that should effect with more better quality pulls |
| 17:10 |
celeron55 |
if you're so interested and concerned, start arranging the merging of those then :P |
| 17:11 |
celeron55 |
it's awful work and that's why it doesn't happen, not because of missing schedules or something |
| 17:11 |
Exio4 |
1 month, 3 weeks bugfix the features of the first week |
| 17:11 |
RealBadAngel |
celeron55, i got some patches on my mind, i will rebase them and fix |
| 17:12 |
RealBadAngel |
wielded light, remove craft recipe to name just two of them |
| 17:12 |
celeron55 |
btw, i think minetest should move to a specification-driven map format |
| 17:12 |
RealBadAngel |
sometimes good idea is worth more than the code |
| 17:12 |
celeron55 |
that would get rid of mishaps like this proller's one |
| 17:13 |
proller_ |
first try but not tested https://github.com/proller/minetest/compare/ver |
| 17:13 |
celeron55 |
it's really important to not fuck up stuff saved on disks so it's worth the effort |
| 17:13 |
RealBadAngel |
setting standards is always a good solution |
| 17:13 |
celeron55 |
otoh, we don't need it work network, because network incompatibilities are just momentary and don't "fuck up" things |
| 17:13 |
celeron55 |
for network* |
| 17:14 |
RealBadAngel |
btw i do have (solved) a big problem |
| 17:14 |
RealBadAngel |
i dont know if you gonna like the solution |
| 17:14 |
Exio4 |
what problem? |
| 17:15 |
RealBadAngel |
Irrlicht is not capable to pass attribute variable to shader (material) instance |
| 17:15 |
celeron55 |
proller_: that didn't even come to my mind; quickly thinking it looks like a fine first fix |
| 17:15 |
RealBadAngel |
theres no fuckin legal way to do it |
| 17:15 |
celeron55 |
PilzAdam: check proller's code ^ |
| 17:15 |
RealBadAngel |
i solved it with creating short image (texture) files |
| 17:16 |
RealBadAngel |
and passing them to shaders |
| 17:16 |
PilzAdam |
proller_, can you still read maps that have version 26? |
| 17:16 |
RealBadAngel |
2-3 pixels wide images, that hold boolean values for shaders, or the tangent space vectors |
| 17:17 |
sfan5 |
RealBadAngel: that solution should get the hackiest solution award ;) |
| 17:17 |
RealBadAngel |
haha i know |
| 17:17 |
RealBadAngel |
but theres no other way |
| 17:18 |
|
sapier joined #minetest-dev |
| 17:18 |
RealBadAngel |
theres no problem to send to shaders global variables |
| 17:18 |
sfan5 |
git cloning minetest/minetest takes f***king long with a connection of 6 KiB/s |
| 17:18 |
RealBadAngel |
but i do need to send variables for every tile shaded |
| 17:19 |
proller_ |
PilzAdam, yes, max check by highest |
| 17:19 |
RealBadAngel |
especially its tangent space vector |
| 17:19 |
proller_ |
25%] Building CXX object my cpu too busy now 8( |
| 17:19 |
PilzAdam |
proller_, can old clients connect to new servers? |
| 17:19 |
celeron55 |
(i really like it that PilzAdam "gets" things like these immediately and asks the exact right questions) |
| 17:19 |
RealBadAngel |
by now im using solution to calculate tangent in vertex shader |
| 17:20 |
proller_ |
PilzAdam, no, its broken by nodebox (not me) |
| 17:20 |
PilzAdam |
celeron55, umm.. thx |
| 17:20 |
PilzAdam |
:-) |
| 17:20 |
celeron55 |
the mapblock serialization format is agreed by the server and client |
| 17:20 |
RealBadAngel |
but its not perfect, on some angles it produces weird artifacts |
| 17:20 |
celeron55 |
the server will use whatever the highest is that they support |
| 17:20 |
PilzAdam |
ah |
| 17:20 |
RealBadAngel |
2nd, it takes GPU time |
| 17:20 |
PilzAdam |
proller_, its good then |
| 17:20 |
celeron55 |
however i don't know of this nodebox thing, what's it all about? |
| 17:21 |
RealBadAngel |
new drawtype |
| 17:21 |
celeron55 |
i've been hearing it but i don't know of anything like that |
| 17:21 |
proller_ |
celeron55, old 0.4.7 cannot connect to new git servers now 8( |
| 17:21 |
celeron55 |
why? |
| 17:21 |
proller_ |
ym server is empty because of it |
| 17:21 |
celeron55 |
it will be fixed as long as i know why the hell |
| 17:22 |
RealBadAngel |
ah ah, theres a patch to fix bumpmapping for irrlicht 1.8 |
| 17:22 |
PilzAdam |
I dont know about such a change... ? |
| 17:22 |
RealBadAngel |
i recommend merging it |
| 17:22 |
PilzAdam |
RealBadAngel, I recommend you include that in your branch |
| 17:22 |
RealBadAngel |
no |
| 17:22 |
* VanessaE |
peeks in |
| 17:23 |
RealBadAngel |
its not related to my code |
| 17:23 |
PilzAdam |
proller_, can you point to the commit? |
| 17:23 |
RealBadAngel |
its engine fix |
| 17:23 |
PilzAdam |
(the one that broke the compatibility) |
| 17:23 |
RealBadAngel |
hi VanessaE |
| 17:23 |
VanessaE |
celeron55: protocol change to support the vector-ized node count |
| 17:23 |
VanessaE |
plus something else, I forget what |
| 17:24 |
celeron55 |
oh it's the "Leveled nodebox" one? |
| 17:24 |
RealBadAngel |
https://github.com/EXio4/minetest/commit/c1d4467a132c1ee5673dcbc774421aca571d168e |
| 17:24 |
celeron55 |
9733dd |
| 17:24 |
RealBadAngel |
this is Exio4's one |
| 17:24 |
proller_ |
PilzAdam, no, its players complaints |
| 17:24 |
celeron55 |
proller_: ? |
| 17:25 |
celeron55 |
stop being so cryptic |
| 17:25 |
VanessaE |
(112dbba7c and 46d1d70e4 to be more specific) |
| 17:25 |
proller_ |
9733dd dont bump any versions |
| 17:27 |
PilzAdam |
9733dd is included in the bump to protocol version 21, and it shouldnt be a problem if this drawtype is not used |
| 17:27 |
proller_ |
celeron55, something earlies |
| 17:27 |
celeron55 |
oh... ehm... well i'm assuming then that after proller merges the small fix that he showed, there are no important problems |
| 17:28 |
RealBadAngel |
PilzAdam, its not only bumpmapping related, its about the shaders at all |
| 17:28 |
PilzAdam |
RealBadAngel, merge it then |
| 17:29 |
RealBadAngel |
so i will tommorow |
| 17:29 |
RealBadAngel |
now im goin to take a short nap before night shift |
| 17:29 |
RealBadAngel |
cya folks |
| 17:30 |
proller_ |
http://s018.radikal.ru/i503/1307/0b/52af4f0ace2f.png |
| 17:30 |
celeron55 |
proller_: keep in mind that this version 26 that you use for the additional network data is a special privilege and it should be gotten rid of in the long-term, probably roughly like i've suggested |
| 17:31 |
celeron55 |
the map version shouldn't be used for the same purpose in the future and it would be best if you get rid of it's usage there (it requires some actual design though) |
| 17:32 |
celeron55 |
proller_: ...whaaat |
| 17:32 |
proller_ |
celeron55, small chsnges via try-catch |
| 17:32 |
proller_ |
? |
| 17:32 |
proller_ |
celeron55, its error from 0.4.7 |
| 17:33 |
PilzAdam |
RealBadAngel, tested Exio4's patch and it works |
| 17:34 |
celeron55 |
proller_: how is this possible |
| 17:34 |
celeron55 |
proller_: the version has not changed since a year ago |
| 17:34 |
celeron55 |
something probably offsets the data and it reads the wrong byte |
| 17:35 |
celeron55 |
hmm, yes |
| 17:35 |
proller_ |
strange |
| 17:35 |
celeron55 |
it's not strange at all |
| 17:35 |
celeron55 |
this happens only if the new nodeboxes are used, right? |
| 17:36 |
proller_ |
snow now using it |
| 17:36 |
proller_ |
on my server, yes |
| 17:36 |
celeron55 |
so does a server run by default so that they aren't used? |
| 17:36 |
proller_ |
snow now generating only from mod |
| 17:37 |
proller_ |
but possible to place in creative |
| 17:38 |
|
nalkri joined #minetest-dev |
| 17:39 |
celeron55 |
the problem here is that the nodebox serialization format does not contain a length field |
| 17:40 |
celeron55 |
so the offset gets fucked up if the type is unknown |
| 17:40 |
celeron55 |
however, this lacks a thing that will make it work, which is included in ContentFeatures::serialize |
| 17:41 |
celeron55 |
notice it? 8) it's the u16 protocol_version in the parameter |
| 17:41 |
celeron55 |
simly do not send the client the NODEBOX_LEVELED type if the protocol version is older than which supports it |
| 17:41 |
celeron55 |
simply* |
| 17:42 |
PilzAdam |
i.e. < 21 |
| 17:42 |
celeron55 |
has 21 been used in some released version of minetest? |
| 17:42 |
PilzAdam |
no, 20 is the one that was released as 0.4.7 |
| 17:43 |
celeron55 |
if so, then it should be incremented to 22 and 22 be declared to support NODEBOX_LEVELED |
| 17:43 |
celeron55 |
then that's good |
| 17:43 |
PilzAdam |
21 is already meant to support the leveled nodebox (see clientserver.h) |
| 17:43 |
celeron55 |
it should be said there more clearly |
| 17:45 |
celeron55 |
also notice the "(0.4.0, 0.4.1)" in the file? that convention seemed to have been dropped at the same time as it was invented, but that'd be a good way to keep track of if a protocol version is still under work or if it's "locked" |
| 17:45 |
celeron55 |
and yes, i know all of this sounds excessively complicated |
| 17:45 |
celeron55 |
...it's kind of simple once one gets used to it; it's just hard to explain all the practical laws behind versioning 8) |
| 17:46 |
PilzAdam |
oh, never saw the release versions in there |
| 17:46 |
celeron55 |
basically limiting accepted version is not the key; the key is rising versions at the correct times and doing stuff that matters based on the rises |
| 17:47 |
celeron55 |
also if the versions were marked in there, we could easily determine which versions we can drop support for |
| 17:47 |
proller_ |
celeron55, its need to switch NodeBox version to 2 ? |
| 17:48 |
PilzAdam |
proller_, yes, you check the protocol version of the client and send the old or new version according to it |
| 17:48 |
celeron55 |
proller_: that version in there is kind of redundant... but yes, it's a good idea because it is there |
| 17:50 |
celeron55 |
we should change all of our serialization formats to some kind of binary key-value storage which easily supports missing fields with default values |
| 17:50 |
proller_ |
json ! 8) |
| 17:50 |
celeron55 |
it would make all this that we're talking about irrelevant |
| 17:51 |
celeron55 |
but i'm too lazy and focused on other things to do that |
| 17:52 |
celeron55 |
or, well |
| 17:52 |
celeron55 |
i actually have such a one implemented, but i'm not too positive about people liking it as-is |
| 17:55 |
celeron55 |
please somebody get interested 8)? |
| 17:55 |
celeron55 |
it's here: https://github.com/celeron55/minetest/blob/meta_set_nodedef_2/src/util/template_serialize.h https://github.com/celeron55/minetest/blob/meta_set_nodedef_2/src/util/template_serialize.cpp |
| 17:56 |
celeron55 |
with a usage example here: https://github.com/celeron55/minetest/blob/meta_set_nodedef_2/src/nodedef.cpp#L327 |
| 17:57 |
celeron55 |
it includes storing the lengths of stuff so for example this unknwon nodebox length stuff would be a complete non-issue with it |
| 18:01 |
celeron55 |
because of the key-value storage, it has inherent cross-version compatibility and simply will not stop working as long as default values are fine... and due to that template "traits" pattern, it's also fairly compact to use |
| 18:01 |
PilzAdam |
that seems actually pretty good |
| 18:02 |
celeron55 |
the downside is that the keys and value lengths and value types take some space... but it tries to squeeze them reasonably tight |
| 18:02 |
PilzAdam |
I wonder how insane it would be to release 0.5.0 with this without backwards compatibility |
| 18:03 |
celeron55 |
completely fine |
| 18:03 |
proller_ |
+1 |
| 18:03 |
celeron55 |
the only problem in version incompatibility is if it happens all the time |
| 18:03 |
Exio4 |
there should be a small 'list' of things that could be done that can break backward compatibility |
| 18:03 |
Exio4 |
so it is, that serializing protocol + other changes that "would need it" |
| 18:03 |
celeron55 |
this could be basically a once-in-project-lifetime thing |
| 18:04 |
sapier |
no even if we use tlv we are not 100% safe to version incompatibilities |
| 18:05 |
sapier |
data transmission is safe yes but client can still be incompatible e,g, due to new required values |
| 18:05 |
celeron55 |
yes, if something is *actually* required, of course it won't then work |
| 18:05 |
sapier |
but its a big improvement |
| 18:05 |
celeron55 |
but 99% of the time minetest doesn't actually need almost anything |
| 18:06 |
sapier |
we could even do as dirty things as sending data in different formats dependent on client version ;-) |
| 18:07 |
celeron55 |
we do that all the time currently |
| 18:07 |
kahrl |
what's dirty about it? |
| 18:10 |
sapier |
really ? I though we just send some parameters or not |
| 18:11 |
VanessaE |
aw shit |
| 18:11 |
sapier |
I meant really different e.g. send cmd x for client version y and a for version b |
| 18:11 |
VanessaE |
something in latest git is busted - can't connect to any server (nothing happens when clicking "connect" or pressing enter) |
| 18:11 |
VanessaE |
(the list works, though) |
| 18:12 |
VanessaE |
</offtopic> |
| 18:12 |
sapier |
I didn't do anything you didn't already tes |
| 18:12 |
sapier |
t |
| 18:12 |
proller_ |
second try but not tested! https://github.com/proller/minetest/compare/ver |
| 18:12 |
VanessaE |
odd. |
| 18:13 |
Exio4 |
you can always blame proller_ for that! :> |
| 18:13 |
sapier |
and what I did didn't solve your problem :-) not sure if anyone already did discover the problem it solved :-) |
| 18:13 |
sapier |
yes it's "blame proller" week |
| 18:13 |
sapier |
;-) just kiddinh |
| 18:14 |
proller_ |
8(.. but building n server... |
| 18:16 |
proller_ |
bad try |
| 18:16 |
VanessaE |
sapier: took out that last commit of yours and that fixed it. |
| 18:17 |
proller_ |
or not.. can somebody to connect with 0.4.7 to "Sky" server ? |
| 18:17 |
sapier |
didn't that happen yesterday too?? |
| 18:17 |
VanessaE |
I never thought to try it with the IP address already present (I was typing it in for each try) |
| 18:18 |
sapier |
ok so most likely it was broken yesterday too |
| 18:18 |
VanessaE |
I'm now at clean git HEAD, with the vbo, hard-coded-value-of-e, and max registered nodes = 0x7fff patches added. |
| 18:18 |
VanessaE |
and it works fine there. |
| 18:19 |
sapier |
ok I understand what happens you don't have anything in serverlist selected am I right? |
| 18:19 |
VanessaE |
correct. |
| 18:20 |
sapier |
in this case nothing is started :-) |
| 18:20 |
celeron55 |
< sapier> I meant really different e.g. send cmd x for client version y and a for version b |
| 18:20 |
VanessaE |
that explains it :) |
| 18:20 |
sapier |
I guess I missed that usecase |
| 18:20 |
celeron55 |
oh that, i'm not sure if we do that at all |
| 18:20 |
sapier |
celeron I don't thing we do that atm and thats what I meant with dirty |
| 18:38 |
proller_ |
https://github.com/proller/minetest/compare/ver - old client now connects to me ! |
| 18:38 |
proller_ |
but something wrong with snow |
| 18:39 |
kahrl |
Exio4: started the list you talked about http://dev.minetest.net/TODO#Big_protocol_changes |
| 18:40 |
sapier |
https://github.com/minetest/minetest/pull/846 VanessaE could you try? it at least fixes the problem singleplayer overwriting the address field ... if you didn't connect to server it still will be reset |
| 18:41 |
VanessaE |
checking.. |
| 18:46 |
celeron55 |
proller_: well, you could send a regular nodebox that is similar to a leveled nodebox of some height to the client |
| 18:47 |
celeron55 |
but whatever, not that important |
| 18:48 |
VanessaE |
sapier: that seems to be good now |
| 18:48 |
proller_ |
celeron55, if (version == 1)type = NODEBOX_FIXED ? |
| 18:49 |
celeron55 |
also, making new #defines like that isn't really useful |
| 18:49 |
sapier |
but I don't understand why it didn't work at all for you with previous version looking at code a second time it should've worked |
| 18:49 |
sapier |
it == connecting |
| 18:49 |
Exio4 |
i don't understand one thing, couldn't the leveled nodebox be "server-side"? |
| 18:49 |
celeron55 |
they can only break things accidentally as it's important to keep the same code identical over versions |
| 18:51 |
celeron55 |
hmm........ |
| 18:51 |
Exio4 |
what was the problem with request_blocks, or why it didn't get merged? |
| 18:51 |
celeron55 |
what does this leveled nodebox even actually do? |
| 18:51 |
celeron55 |
now that i think of it, why isn't it a new node drawtype? |
| 18:51 |
proller_ |
its like regular nodebox, but height gets from param2 |
| 18:52 |
Exio4 |
i don't see why it needs to be a 'new' nodebox now that proller_ documented it... |
| 18:53 |
sapier |
so you could create a nodebox being 20 blocks high? |
| 18:53 |
celeron55 |
proller_: but why is it a "nodebox"? |
| 18:53 |
celeron55 |
why isn't it a regular node |
| 18:53 |
celeron55 |
i mean, a new drawtype |
| 18:53 |
celeron55 |
nodebox is just a drawtype like many other drawtypes |
| 18:54 |
celeron55 |
who even approved this thing |
| 18:54 |
PilzAdam |
probably proller just saying "will commit!" and nobody shouting "NO!"? |
| 18:55 |
proller_ |
you can define custom nodebox and grow it with param=1 |
| 18:55 |
proller_ |
param2++ |
| 18:55 |
celeron55 |
why would you do that? |
| 18:55 |
proller_ |
hmmmm, approve |
| 18:55 |
proller_ |
for making growing snow |
| 18:55 |
celeron55 |
but snow is just a block with height |
| 18:55 |
celeron55 |
no need to have anything fancy in it |
| 18:55 |
proller_ |
and later maybe liquids |
| 18:56 |
celeron55 |
same for them |
| 18:56 |
proller_ |
now snow can grow |
| 18:56 |
celeron55 |
...holy hell |
| 18:56 |
proller_ |
how to increase height without it ? |
| 18:56 |
celeron55 |
by making a drawtype that uses height and shows up a node with that height, but all other sides normal |
| 18:56 |
Exio4 |
did he? i don't see him "aproving it" |
| 18:57 |
kahrl |
celeron55: although that wouldn't affect collision handling |
| 18:57 |
kahrl |
which I presume is the intention |
| 18:58 |
celeron55 |
is that not doable otherwise? |
| 18:58 |
celeron55 |
i mean, the system is quite borked if you have to do odd things in the network protocol in order to have the client do something in collision detection |
| 18:58 |
kahrl |
the collision code could check the drawtype, but there's no precedent for that |
| 18:59 |
sapier |
I don't think that'd be a big change |
| 18:59 |
celeron55 |
you just need to modify MapNode::getNodeBoxes |
| 18:59 |
celeron55 |
it's like two lines of code |
| 19:00 |
kahrl |
there he goes :P |
| 19:00 |
celeron55 |
holy shit this was a crap implementation, unless people want to make growing chairs or something |
| 19:00 |
|
proller_ joined #minetest-dev |
| 19:01 |
sapier |
alice in wonderland mod ;-) |
| 19:01 |
celeron55 |
so is there any reason why we wouldn't change this to a sane implementation that uses a drawtype? |
| 19:02 |
sapier |
+1 for separate drawtype it's much more simple and reduces complexity while keeping all intended features (as far as I understand) |
| 19:03 |
celeron55 |
it does that by a whole lot |
| 19:03 |
celeron55 |
(at least i haven't heard any feature that it wouldn't keep) |
| 19:04 |
sfan5 |
yay! libtomcrypt built correctly |
| 19:05 |
celeron55 |
maybe proller_ should do that for exercise 8) |
| 19:05 |
proller_ |
growing chair is good too 8) |
| 19:05 |
proller_ |
maybe plants |
| 19:05 |
PilzAdam |
yea, leveled should become an own drawtype |
| 19:05 |
sfan5 |
I guess the server should have RSA keys, right? |
| 19:06 |
sapier |
a security lib not beeing updated for almost a year? |
| 19:07 |
kahrl |
sapier: could mean that it is secure and has always been :) |
| 19:07 |
celeron55 |
hmm |
| 19:07 |
sapier |
could but most likely it means "it's broken and unsafe" |
| 19:07 |
* celeron55 |
is still looking into this leveled thing |
| 19:07 |
sapier |
last official version is from 2007 ... |
| 19:08 |
celeron55 |
proller_: how does this leveled nodebox achieve the collision thing? |
| 19:08 |
sapier |
official sipport for gcc2.95 and vc6 ... sfan are you sure it's worth working at it? |
| 19:08 |
celeron55 |
oh now i see it |
| 19:08 |
celeron55 |
okay so |
| 19:09 |
celeron55 |
i think we'll keep this; it's actually quite lightweight and not worth all this trouble to remove and is kind of sane for... maybe something |
| 19:10 |
celeron55 |
proller_: just finish the compatibility thing to be good and we're set |
| 19:10 |
proller_ |
90% done |
| 19:11 |
proller_ |
why i recieve version==6 ? |
| 19:11 |
proller_ |
where it defined& |
| 19:12 |
celeron55 |
sfan5, sapier: wait, what; the last official version is from 2007 and even in the git repo they have commits after that like "prevent double-free" and "prevent access to NULL pointer" |
| 19:12 |
celeron55 |
8D |
| 19:13 |
* sfan5 |
has downloaded 1.17 |
| 19:13 |
kaeza |
why? |
| 19:13 |
kaeza |
dereferencing null pointers is fun |
| 19:13 |
celeron55 |
but! the latest commits in git are only 10 months old |
| 19:14 |
celeron55 |
the git version might be good; what does sapier think? 8) |
| 19:14 |
celeron55 |
https://github.com/libtom/libtomcrypt |
| 19:15 |
sapier |
I know did you have a look what has been fixed? Does anyone know if this library is actively used or just sitting around beeing dead? |
| 19:16 |
PilzAdam |
I dont get why people are always talking about security, this is a game and not a web browser |
| 19:17 |
sapier |
that's what home automation and heating control system creators said too :-) ... imho if we add a crypto lib we should add a good one |
| 19:17 |
VanessaE |
PilzAdam: a hacker doesn't care if it's a game server or webserver behind a particular port, all they care about is "can I exploit that and get root on this box?". |
| 19:17 |
sapier |
we shouldn't claim to add security while we don't actually do it |
| 19:17 |
PilzAdam |
VanessaE, we dont need encrypton to prevent that |
| 19:17 |
sapier |
last significant fixes of tomcrypt are 2 years old |
| 19:18 |
sapier |
imho this is a dead project not very usefull if you really want to add security |
| 19:18 |
PilzAdam |
the encryption is for people who are so paranoid that they think the user data on a Minetest server is worth to protect |
| 19:19 |
sapier |
I don't like to do it but I'm with pilzadam as noone really wants to add full security it's better to not add anything |
| 19:19 |
sfan5 |
celeron55: where does the JTHREAD_INCLUDE_DIR var come from in src/CMakeLists.txt ? |
| 19:20 |
celeron55 |
from find_package(Jthread REQUIRED), which calls stuff in cmake/Modules/FindJthread.cmake |
| 19:20 |
sfan5 |
hm, ok |
| 19:21 |
celeron55 |
sfan5: anyway, as you can see from this discussion, there's much consideration to be done |
| 19:21 |
sfan5 |
I need some ideas on how to encrypt the connection |
| 19:22 |
sapier |
there's only one safe way ;-) server certificates and tls ;-) |
| 19:22 |
kahrl |
sapier: one time pad |
| 19:22 |
kahrl |
;P |
| 19:22 |
sapier |
ok ok next level of paranoia ;-) |
| 19:23 |
celeron55 |
in any case we should define where the users might expect security and then address that |
| 19:23 |
PilzAdam |
if peopel are really that paranoid then there is always localhost.... or is that insecure too?! |
| 19:23 |
celeron55 |
not encrypt random things and then not care what help that is even of |
| 19:24 |
sapier |
pilzadam we had a case in company where spys used elecromagnetic waves transmitted by devices to gain information ... |
| 19:24 |
celeron55 |
wireless keyboards, anyone? 8) |
| 19:24 |
sapier |
that's why our windows are metall shielded now and cellulars don't work anymore |
| 19:25 |
celeron55 |
does sapier work in some kind of military it department |
| 19:25 |
sapier |
no just industrial security ;-) |
| 19:25 |
sapier |
and I'm by far not most paranoid one ;-) |
| 19:26 |
PilzAdam |
anyone wanna host a Minetest server in a nuclear blat-proof faraday bunker? |
| 19:26 |
PilzAdam |
*blast |
| 19:26 |
celeron55 |
with no internet connection, of course |
| 19:27 |
PilzAdam |
of course |
| 19:27 |
PilzAdam |
RSA encrypted localhost connection only |
| 19:27 |
celeron55 |
the players are let in naked, to play on terminals in the chamber |
| 19:27 |
sapier |
:-) and of course no doors as internal attackers are more common than external ones |
| 19:27 |
celeron55 |
or actually outside the chamber, with an another chamber over that |
| 19:28 |
sapier |
naked? guys could we plz increase waf before setting up this ? |
| 19:29 |
celeron55 |
no |
| 19:29 |
nalkri |
waf? |
| 19:29 |
celeron55 |
8D |
| 19:29 |
sapier |
lets get serious again .. if we want to add security we need to look at full picture first ... not worth adding steel front doors while backdoor is paper |
| 19:30 |
celeron55 |
kahrl: btw, that's a good addition to the wiki |
| 19:30 |
sapier |
and I guess the only thing worth defending is users password |
| 19:31 |
celeron55 |
probably; all the other things can be defended by aiming for easy wiki-like reverts |
| 19:31 |
PilzAdam |
celeron55, funny that you say it in the exact same moment I started to read it :-) |
| 19:31 |
sapier |
but we could print a big fat warning instead of defending the password too ;) |
| 19:31 |
celeron55 |
well yes, maybe |
| 19:32 |
celeron55 |
it really depends on how much trouble it is |
| 19:32 |
celeron55 |
an another thing that maybe could be wished to be defended is the chat on servers |
| 19:32 |
sapier |
defending password could be as easy as using a strong hash algorithm with a lot of salt on client side |
| 19:32 |
PilzAdam |
"Make the client request mapblocks" cant this be done based on the protocol version of the client? |
| 19:33 |
celeron55 |
one guy once asked here or somewhere that it would be good to have encrypted chat because... he lived in a country where the government doesn't like almost anything that people talk about |
| 19:33 |
sapier |
defending chat is more difficult |
| 19:33 |
sfan5 |
could we get back on the topic how security and encryption should be done |
| 19:33 |
kahrl |
PilzAdam: most of the points can. but it would involve lots of checks in different places |
| 19:33 |
kaeza |
celeron55, arsdragonfly, from... China |
| 19:34 |
proller_ |
celeron55, http://msgpack.org/ |
| 19:35 |
sapier |
imho following prioritys should be used for deciding for a security lib: license compatibiliry; active development + security fixes; at least some projects using it; ease of use |
| 19:36 |
celeron55 |
proller_: that's quite an over-marketed and half-designed thing IMO |
| 19:36 |
celeron55 |
proller_: but could be good; not sure |
| 19:36 |
celeron55 |
proller_: there are certain things that make it suboptimal in certain uses, while minetest probably isn't one of those uses |
| 19:37 |
PilzAdam |
kahrl, I think that exactly this list should be the goal for 0.5.0, and nothing else |
| 19:37 |
celeron55 |
proller_: the single biggest benefit would be easier compatibility with external programs |
| 19:38 |
proller_ |
but its probably better than reimplementing wheel |
| 19:38 |
proller_ |
and better than json and others for internal protocol |
| 19:39 |
celeron55 |
json shouldn't come even to mind when thinking about this; it's not suitable at all |
| 19:39 |
proller_ |
yes, it for example |
| 19:39 |
celeron55 |
does msgpack support maps with integers as keys? |
| 19:40 |
celeron55 |
we can't afford string keys because they are too wasteful |
| 19:40 |
proller_ |
http://wiki.msgpack.org/display/MSGPACK/Format+specification#Formatspecification-Maps |
| 19:41 |
celeron55 |
our data is basically generally like four bytes, so if there's something like "post_effect_color" along with it, that defeats the purpose altogether |
| 19:41 |
celeron55 |
so we want to just enum all those keys and use the ids |
| 19:41 |
sfan5 |
what I got now: https://github.com/sfan5/minetest/tree/security |
| 19:41 |
kahrl |
proller_: though that stores type information for each key |
| 19:41 |
kahrl |
wasteful when we know all keys are integers from the beginning |
| 19:43 |
celeron55 |
well it's not too bad, really |
| 19:43 |
sapier |
so we really need to fight for any single byte? we're using ethernet or wlan not zigbee |
| 19:44 |
proller_ |
if we want to support 1000+ players pr server - yes |
| 19:44 |
celeron55 |
it's going to be on on-disk data too and pretty much everything |
| 19:44 |
celeron55 |
it's a matter of whether to, well, double or triple the data size compared to current |
| 19:44 |
sapier |
ok ok didn't think about on disk data ... but for those access methods are even more important |
| 19:44 |
celeron55 |
8) |
| 19:45 |
celeron55 |
well it's not going to double; more like 150% of current; but all that adds to it |
| 19:45 |
kahrl |
there's the fact that loading a mapblock from disk is already slower than running the mapgen, unless that changed recently |
| 19:45 |
celeron55 |
the bottleneck to that isn't speed |
| 19:45 |
celeron55 |
i mean, bulk sped |
| 19:45 |
celeron55 |
+e |
| 19:46 |
sapier |
if this is true we need to find more smart caching/preloading methods |
| 19:46 |
celeron55 |
also, i still think that the loading is slow most likely because of *writing* is slow, and that *might* be slow because we run sqlite in synchronous mode... i and nobody else has still tested that i think |
| 19:46 |
celeron55 |
MT writes a mapblock always after loading it to update the timestamp, IIRC |
| 19:47 |
|
iqualfragile joined #minetest-dev |
| 19:47 |
kahrl |
the timestamp could be changed into a separate column |
| 19:47 |
sapier |
hmm don't modern os support multiple (non overlapping) file accesses? |
| 19:48 |
celeron55 |
someone try PRAGMA synchronous=OFF |
| 19:49 |
celeron55 |
kahrl: but otoh we can't stick to sqlite either |
| 19:49 |
proller_ |
pray=on 8) |
| 19:50 |
celeron55 |
it breaks with huge worlds (for some reason) and large servers currently, or at least back in some time ago use leveldb |
| 19:50 |
celeron55 |
i don't know if the leveldb patches are still up to date though; does anyone have up-to-date info on this? |
| 19:51 |
celeron55 |
gah, there's so much stuff going on |
| 19:51 |
celeron55 |
or, more like not going on |
| 19:52 |
celeron55 |
i feel minetest should be split to smaller parts with well-defined interfaces so development could be more distributed |
| 19:52 |
celeron55 |
but that's a lot of work too *toolazy* |
| 19:52 |
celeron55 |
or not lazy but wanting to do other things, as always |
| 19:52 |
celeron55 |
hell, i just talk here by myself, i'm out -> |
| 19:53 |
PilzAdam |
celeron55, everyone wants that the leveldb pull request gets merged but its really out of date, like 0.4.4 or so |
| 19:53 |
celeron55 |
i have only one comment to everything asked from me today from now on: yeah just handle it somehow |
| 19:53 |
kahrl |
I thought about the splitting thing, but like everything uses g_settings, while it's managed by the most top level piece of code |
| 19:53 |
kahrl |
and issues like that |
| 19:55 |
proller_ |
compat 95% done.. |
| 19:55 |
celeron55 |
if someone feels like all this is too clogged up and you can't do anything because of that, we could have a "minetest reworked" branch that addresses all the technical issues on a framework level and rearranges the existing code to that |
| 19:56 |
celeron55 |
but only one, please |
| 19:56 |
kahrl |
suddenly: all the pull requests marked "rebase needed" :D |
| 19:57 |
celeron55 |
well, once again, you can do incompatible stuff as long as it's good in the long term |
| 19:58 |
celeron55 |
i hate days like these when i just write n+9001 lines and nothing actually happens, not to minetest and not to anything else |
| 19:59 |
celeron55 |
i guess i at least learn to write english a bit better... but it probably sums up negative because of all the headache other people get |
| 19:59 |
celeron55 |
8D |
| 20:00 |
celeron55 |
i mean, what's the problem with all this; the more i try to address things, the more things pop up |
| 20:00 |
celeron55 |
it never ends |
| 20:00 |
celeron55 |
it's insane |
| 20:01 |
kahrl |
indeed and I guess that's why nobody has the courage to start such a "minetest reworked" branch |
| 20:02 |
celeron55 |
the work behind, and the work yet to be done is pretty intense |
| 20:03 |
sapier |
I'm used to rebase all of my pull requests at least 5 times until someone finaly decides to add them ;-P |
| 20:03 |
celeron55 |
people tend to start minecraft clones, and even kind of minetest clones, but they all are in C# or Java 8D |
| 20:03 |
celeron55 |
what's up with that too |
| 20:04 |
kahrl |
except the one that is written in x86 assembly and bootable |
| 20:07 |
|
Akien joined #minetest-dev |
| 20:08 |
celeron55 |
i would really like to start a remake of minetest with all the knowledge i've learned, but i don't want to code most of it by myself |
| 20:08 |
celeron55 |
that's what's stopping me from even starting |
| 20:09 |
celeron55 |
and really, the gains would come after so long time... for like a year it would be greatly inferior from everyone's standpoint |
| 20:09 |
celeron55 |
assuming everyone worked on it |
| 20:10 |
celeron55 |
so, really that's why we should be happy that we have this acceptably working blob of code called "minetest"; because nobody in hell is going to do that all again |
| 20:10 |
celeron55 |
:-D |
| 20:12 |
sapier |
I don't think so ... we shouldn't be happy but only thankfull and keep improving it to get it to something we can be happy with in some distant future ;-) |
| 20:13 |
celeron55 |
after the year, it would be 100% awesome though |
| 20:13 |
sapier |
and after one and a half year you'd know what you could have done even better ;-) |
| 20:14 |
celeron55 |
remaking something too early is a common begninner's mistake |
| 20:14 |
celeron55 |
and yes, we can learn even more from working on current minetest |
| 20:14 |
celeron55 |
it's really hard to tell when you've learned enough for a remake to be reasonable |
| 20:14 |
sapier |
minetest is still far from feature stable so I guess it's not time for a remake |
| 20:15 |
celeron55 |
that's one reasonable way to see it |
| 20:15 |
sapier |
e.g. the client side lua ... threaded lua mods |
| 20:16 |
sapier |
we don't have any experience how to do this right |
| 20:16 |
sapier |
we just think that could solve some issues ... most likely it will fix them but who knows what sideeffects will occur |
| 20:18 |
celeron55 |
there are some things like versioning and formats that could be gotten much more right from the start |
| 20:18 |
celeron55 |
but we don't really know whether something would work much better than eg. irrlicht |
| 20:19 |
celeron55 |
and what you said about client-side lua and whatever |
| 20:20 |
celeron55 |
in many senses it would be just "an another attempt", more like a sibling than a child 8) |
| 20:20 |
celeron55 |
there's more material to learn from in the internet about these though |
| 20:21 |
sapier |
and imho versioning things could be done without rewriting ... yes it's gonna break compatibility ... but why not use that first and second number in versioning scheme ? ;-) |
| 20:21 |
celeron55 |
but there's also a lot more technologies... for example there is a voxel module to unity3d, in which many games are made these days |
| 20:21 |
sapier |
unity3d as in ubuntu unity? |
| 20:22 |
celeron55 |
no |
| 20:22 |
sapier |
puuuh :-) |
| 20:22 |
celeron55 |
they were started at the same time so they happen to have same names because they didn't know of each other 8) |
| 20:24 |
celeron55 |
that's more from the "indie game world" than the "free and open source world" that people working on minetest are more involved in |
| 20:24 |
sapier |
I don't understand why irrlicht is considered that bad? yes the gui isn't as perfect as e.g. gtk or qt but it's a 3d engine not a gui toolkit |
| 20:24 |
celeron55 |
as a 3d engine it's kind of lagging behind in technology |
| 20:25 |
celeron55 |
but whatever, it works |
| 20:25 |
celeron55 |
much of minetest's cross-platform usefullness is due to it |
| 20:25 |
sapier |
ok ... but we're not even using full irrlicht feature set as far as I know ;-) |
| 20:26 |
sapier |
but I'm not a 3d developer maybe rba would be more skilled to tell about it |
| 20:32 |
celeron55 |
minetest is by a large margin the most used program that uses irrlicht |
| 20:33 |
celeron55 |
nothing can beat it in that, like probably ever |
| 20:35 |
Akien |
Hi minetest devs :) I don't mean to interrupt but I'd like to have some advice about a compilation issue with minetest 0.4.7 on Mageia 3 (I'm looking at updating Mageia's minetest package, we're currently shipping 0.4.3). |
| 20:35 |
Akien |
I run in this kind of issue: BUILD/minetest-0.4.7/src/util/serialize.h:32:32: error: 'u64' has not been declared. Looking at your issue tracker, it seems this kind of issue was already reported and fixed, so I was thinking it might be a well-known problem with an easy fix on my side? |
| 20:36 |
PilzAdam |
Akien, it happens if you use a pre-release 1.8 of Irrlicht |
| 20:36 |
|
proller joined #minetest-dev |
| 20:37 |
celeron55 |
you'll need to patch it yourself |
| 20:38 |
celeron55 |
see irrlichttypes.h |
| 20:38 |
celeron55 |
that's where irrlicht 1.8 is checked for (the issue is that you have an early version of 1.8 that does not define u64, while minetest only defines it if you aren't using irrlicht 1.8) |
| 20:40 |
celeron55 |
for example just comment out the outer #if/#endif where it checks for it |
| 20:40 |
|
nalkri joined #minetest-dev |
| 20:41 |
celeron55 |
...or alternatively package the actual release version of irrlicht 1.8, which work |
| 20:41 |
celeron55 |
+s |
| 20:42 |
Akien |
Thanks for the advice. I'll see with our irrlicht maintainer that we package the release version of irrlicht, we currently have the 4094 revision. |
| 20:43 |
celeron55 |
hmm, i wonder what it should be |
| 20:44 |
Akien |
I'll try to check on irrlicht SVN if 4094 was prior to the release. |
| 20:45 |
Akien |
But I guess so, if not I don't think we would have bothered to package a development snapshop when an official release is available. |
| 20:46 |
celeron55 |
http://irrlicht.svn.sourceforge.net/viewvc/irrlicht/tags/release-1.8/ |
| 20:46 |
celeron55 |
this says 4374 |
| 20:47 |
celeron55 |
but i'm not sure if it's a correct number |
| 20:50 |
|
nalkri` joined #minetest-dev |
| 20:50 |
Akien |
Well it probably means the trunk rev was around 4370 to 4373 |
| 20:50 |
Akien |
So Mageia's package is outdated, I'll update it with the upstream tarball then. |
| 20:51 |
celeron55 |
i recall there was something similar in fedora sometime |
| 20:51 |
celeron55 |
that's an RPM-based distribution too so it could be related |
| 20:52 |
|
nalkri` joined #minetest-dev |
| 21:03 |
|
Taoki[laptop] joined #minetest-dev |
| 21:11 |
proller |
seems ready - https://github.com/proller/minetest/compare/ver |
| 21:13 |
proller |
"sky" server up with this code |
| 21:22 |
proller |
but need 1 more % |
| 21:32 |
|
iqualfragile_ joined #minetest-dev |
| 21:42 |
Akien |
celeron55, PilzAdam: Packaging the 1.8 release of irrlicht fixed the u64 issue, thanks :) |
| 21:42 |
Akien |
Now I'm running into: https://github.com/minetest/minetest_game/issues/132 but sadly the fix is not described on the ticket |
| 21:45 |
PilzAdam |
Akien, the jthread libary in the Minetest source is modified, you have to use it |
| 21:45 |
Akien |
Ah indeed in our latest package we patched minetest to use the system jthread |
| 21:45 |
Akien |
I'll remove the patch then. |
| 21:46 |
celeron55 |
oh hell, that hasn't been renamed yet or fixed in the cmake scripts? |
| 21:46 |
celeron55 |
the jthread in minetest is currently our own fork of it... without a modified name |
| 21:47 |
celeron55 |
what the hell guys, why does this FindJthread.cmake still try to use the system jthread? |
| 21:47 |
celeron55 |
hmmmm? |
| 22:12 |
|
Miner_48er joined #minetest-dev |
| 22:13 |
|
Miner_48er left #minetest-dev |
| 22:13 |
proller |
ready ! - https://github.com/proller/minetest/compare/ver |
| 22:19 |
Akien |
Seems I'm having an issue with the use of the shared jthread library over the static one: |
| 22:19 |
Akien |
Linking CXX shared library libjthread.so |
| 22:19 |
Akien |
CMakeFiles/jthread.dir/pthread/jthread.cpp.o: In function `JThread::Start()': |
| 22:19 |
Akien |
/home/akien/Contribution/Checkout/minetest/SOURCES/minetest-0.4.7/src/jthread/pthread/jthread.cpp:82: undefined reference to `pthread_create' |
| 22:19 |
Akien |
CMakeFiles/jthread.dir/pthread/jthread.cpp.o: In function `JThread::Kill()': |
| 22:19 |
Akien |
/home/akien/Contribution/Checkout/minetest/SOURCES/minetest-0.4.7/src/jthread/pthread/jthread.cpp:122: undefined reference to `pthread_cancel |
| 22:30 |
Akien |
Time to call it a day - I'll look at it tomorrow. Thanks for your help :) |
| 22:47 |
proller |
tested! ! - https://github.com/proller/minetest/compare/ver |
| 22:48 |
proller |
save to disk and old clients works! |
| 22:53 |
proller |
commit? |
| 23:04 |
|
hmmmmm joined #minetest-dev |
| 23:13 |
|
BlockMen joined #minetest-dev |
| 23:14 |
Exio4 |
wait for other devs |
| 23:16 |
proller |
Exio4, can you test ? |
| 23:16 |
proller |
but already saved in 26 format will only works in current version |
| 23:27 |
Exio4 |
proller: not really |
| 23:55 |
|
khonkhortisan joined #minetest-dev |
