| Time |
Nick |
Message |
| 00:00 |
kahrl |
well CONTENT_UNKNOWN is kind of needed in this (rare) case |
| 00:01 |
kahrl |
there is an alternative, adding a separate fallback ContentFeatures in NodeDefManager |
| 00:01 |
kahrl |
but that does not really mesh with how updateTextures etc. work |
| 00:03 |
kahrl |
well anyway, how about this plan: |
| 00:03 |
kahrl |
1. slightly increase MAX_CONTENT now to get VanessaE's server working again |
| 00:03 |
kahrl |
2. later, when a big protocol change is needed anyway, merge my patch |
| 00:04 |
kahrl |
to get 2. to happen sooner work on the TCP branch |
| 00:04 |
Exio4 |
the second thing is what i was thinking |
| 00:05 |
Exio4 |
if something big needs to get changed, pack all the stuff :P |
| 00:08 |
PilzAdam |
kahrl, are there any existing methods to compare a char[] and a string case insensitive? |
| 00:09 |
kahrl |
i'd have said str_equal but that takes std::wstring |
| 00:09 |
kahrl |
strcasecmp? |
| 00:10 |
kahrl |
yeah, porting.h has some magic to make strcasecmp work portably |
| 00:14 |
PilzAdam |
yea, that works |
| 01:47 |
|
ssieb joined #minetest-dev |
| 02:04 |
|
kaeza joined #minetest-dev |
| 03:09 |
hmmmmm |
anyway |
| 03:10 |
hmmmmm |
it looks like that DavidMikeSimon's work was basically the exact same thing as what I wanted to do |
| 03:10 |
hmmmmm |
(well, except, i wouldn't request an entire cube, i'd limit the range in the Y direction) |
| 03:12 |
hmmmmm |
celeron always used to post the URLs to the branch here so somebody could continue working, but i honestly think it would be more beneficial if he just articulated with words the general idea of what's going on, what problems they faced, and why it never made it in |
| 03:13 |
VanessaE_ |
imho, don't request/send the whole block or even a limited part - send only that which the user should be able to see (the server does know the player's yaw and look pitch), starting with the closest block first |
| 03:14 |
VanessaE_ |
otherwise you're wasting bandwidth |
| 03:14 |
hmmmmm |
yes, that's cute, but it's what we've been doing since forever and it hasn't been working |
| 03:14 |
VanessaE_ |
not really. |
| 03:14 |
VanessaE_ |
I often see blocks farther away from me appear before blocks immediately next to me. |
| 03:15 |
hmmmmm |
it's not sent in that order |
| 03:15 |
hmmmmm |
that must be due to some client-side thing |
| 03:15 |
VanessaE_ |
interesting |
| 03:15 |
VanessaE_ |
well, you know what you're doing. |
| 03:15 |
VanessaE_ |
I'll shut up now. |
| 03:15 |
hmmmmm |
i'm just saying |
| 03:15 |
hmmmmm |
as of right now, blocks are sent the exact way you described |
| 03:15 |
VanessaE_ |
oh ok |
| 03:16 |
hmmmmm |
but it doesn't work out well because, well, you already see the problems we have with it |
| 03:16 |
VanessaE_ |
*nod* |
| 03:16 |
hmmmmm |
I honestly think effort is better put into making mesh generation algorithmically faster |
| 03:16 |
hmmmmm |
and if that's not possible, then, multithreading it and optimizing it for performance |
| 03:17 |
VanessaE_ |
yes, indeed so. How slow do you figure it is now? (as a percentage of the maximum theoretical speed you should be able to get)? |
| 03:17 |
VanessaE_ |
-? |
| 03:17 |
hmmmmm |
lol how should i know |
| 03:17 |
VanessaE_ |
heh |
| 03:17 |
hmmmmm |
research is needed |
| 03:18 |
VanessaE_ |
well it's simple - my husband and I have this agreement. He knows everything, and I'm always right, so maybe the former part applies to you also :D |
| 03:19 |
VanessaE_ |
question: is it possible to tell irrlicht/video driver/etc. that a mesh has simply changed a little bit, rather than always giving it whole meshes for those updates? |
| 03:19 |
VanessaE_ |
(i.e. "delete these two polys and replace them with these two others") |
| 03:19 |
hmmmmm |
i think it tries something like that |
| 03:20 |
hmmmmm |
honestly i remember looking at the mesh generation thread once. i remember it iterates through all of the nodes in the mapblock 6 times |
| 03:20 |
hmmmmm |
that's a lot |
| 03:21 |
VanessaE_ |
ok. I got the impression that it generates whole mapblock-sized meshes each time some little change is made |
| 03:21 |
VanessaE_ |
6 times? surely there's a reason for that? |
| 03:21 |
hmmmmm |
that's just the way the algorithm turned out i guess? |
| 03:21 |
VanessaE_ |
*shrug* |
| 03:21 |
VanessaE_ |
wish I understood the engine more. |
| 03:22 |
hmmmmm |
just read the code a lot |
| 03:23 |
VanessaE_ |
eventually I'll come to understand it. |
| 03:24 |
hmmmmm |
well, you can start by looking at mapblock_mesh.cpp:994 i guess |
| 03:25 |
hmmmmm |
eww. i seriously wonder why realbadangel thought this was an acceptable code style |
| 03:25 |
hmmmmm |
i actually feel so strongly against it i want to fix it right now |
| 03:33 |
kahrl |
hmmmmm: go right ahead. I hate it with a passion |
| 03:38 |
hmmmmm |
erm, actually, can anybody tell me what lines 1175 to 1179 actually do |
| 03:41 |
kahrl |
look wrong |
| 03:43 |
hmmmmm |
so what's the point of checking isKnownSourceImage and then doing some wacky string manipulation to use getTexture a moment later |
| 03:44 |
kahrl |
wtf |
| 03:47 |
kahrl |
might the intention be to handle stuff like ^[inventorycube{a.png{b.png{c.png --> ^[inventorycube{a_normal.png{b_normal.png{c_normal.png? |
| 03:47 |
VanessaE_ |
wait a sec, didn't you guys just optimize a bunch of such things out just recently? |
| 03:47 |
kahrl |
but I don't get the isKnownSourceImage check in that case |
| 03:48 |
kahrl |
also quite the hack |
| 03:48 |
kahrl |
VanessaE_: what things? |
| 03:49 |
VanessaE_ |
kahrl: string manipulations in hot areas |
| 03:49 |
kahrl |
that's not really "hot" |
| 03:49 |
VanessaE_ |
well no, but the particular patch I'm thinking of was. |
| 03:50 |
kahrl |
patch? |
| 03:50 |
hmmmmm |
also what's up with missing parameters? |
| 03:50 |
hmmmmm |
there is no TextureSource::getTexture(std::string &), yet that getTexture is called as if there is |
| 03:50 |
VanessaE_ |
kahrl: nevermind, I can't find the reference now anyways. |
| 03:51 |
hmmmmm |
if the omitted parameter isn't NULL, that'd be a pretty big bug |
| 03:52 |
hmmmmm |
or rather it doesn't even check if id is a valid pointer |
| 03:52 |
kahrl |
huh? it does |
| 03:52 |
hmmmmm |
am i missing something here? how is this valid? is this a bug? |
| 03:52 |
kahrl |
tile.cpp:768 |
| 03:53 |
hmmmmm |
yeah, that takes a u32 * as well though |
| 03:53 |
kahrl |
which can be NULL and is optional |
| 03:53 |
hmmmmm |
ahhh i missed the = NULL |
| 03:54 |
kahrl |
basically wherever code previously (before the atlas removal patch) called getTextureRaw(str) it can now call getTexture(str) |
| 03:55 |
hmmmmm |
anyway i'm going to remove that weird loop |
| 03:55 |
kahrl |
I'd ask RBA |
| 03:55 |
hmmmmm |
if it really is supposed to handle those sorts of cases, it's broken anyway since it doesn't check all of them for existence |
| 03:55 |
kahrl |
I'm not touching that stuff because bump maps don't ever work for me |
| 03:55 |
kahrl |
s/ever/even |
| 03:56 |
hmmmmm |
heh. graphics driver problem? |
| 03:56 |
kahrl |
ATI, yeah :P |
| 03:56 |
hmmmmm |
that sucks. |
| 03:56 |
hmmmmm |
well i guess i'll leave the logic intact but at least fix the code style |
| 03:56 |
VanessaE_ |
kahrl: irrlicht 1.8? |
| 03:57 |
kahrl |
VanessaE_: yup |
| 03:57 |
VanessaE_ |
that's why. |
| 03:57 |
VanessaE_ |
MT + irrlcht 1.8 = no bumpmaps. |
| 03:57 |
VanessaE_ |
no one's sure yet why that's the case. |
| 03:57 |
kahrl |
I use 16px textures anyway so it doesn't bother me |
| 04:03 |
kahrl |
did something about shader parameter passing change in 1.8? |
| 04:03 |
kahrl |
can't really think of much else that would cause problems |
| 04:03 |
VanessaE_ |
dunno |
| 04:04 |
VanessaE_ |
but come to think of it, I seem to recall that some folks were complaining about shaders generally not working at all in 1.8. |
| 04:04 |
kahrl |
the other minetest shaders work though |
| 04:04 |
kahrl |
so it must be something specific to the bumpmap shader |
| 04:05 |
VanessaE_ |
hm. |
| 04:06 |
hmmmmm |
look good? https://github.com/kwolekr/minetest/commit/d1a50adfd7083b7df31b91abf54bfd7c407fbf20 |
| 04:07 |
kahrl |
hmmmmm: initialize i = 0 |
| 04:07 |
hmmmmm |
whoops |
| 04:07 |
hmmmmm |
good catch |
| 04:07 |
hmmmmm |
anything else? |
| 04:08 |
hmmmmm |
should probably change "replace" to something else that isn't the same name as the function |
| 04:08 |
kahrl |
can you reassign shadermat1/2 like that? |
| 04:08 |
hmmmmm |
yes |
| 04:08 |
hmmmmm |
they aren't used anywhere after that |
| 04:09 |
kahrl |
next loop iteration? |
| 04:09 |
hmmmmm |
the whole thing is in a loop |
| 04:09 |
hmmmmm |
agh |
| 04:09 |
hmmmmm |
i am really screwing up today |
| 04:11 |
kahrl |
renaming "replace" sounds sensible |
| 04:12 |
kahrl |
the rest of the patch looks good |
| 04:12 |
hmmmmm |
(i can't really test it either since that requires the whole shader setup) |
| 04:12 |
hmmmmm |
here's the finalized version: https://github.com/kwolekr/minetest/commit/fc6725f14ed371fc626c023faf89e370ea8c2105 |
| 04:13 |
kahrl |
much better than what is in master :) |
| 04:13 |
|
kaeza joined #minetest-dev |
| 04:13 |
kahrl |
if you are confident feel free to push it |
| 04:14 |
hmmmmm |
who could possibly feel confident after making two goofups in the same commit :P |
| 04:16 |
hmmmmm |
and upon reexamination, it doesn't go through the entire mapblock 6 times like i originally said, it does 16 * 16 * 3 iterations of updateFastFaceRow (16 iterations in itself), so half as much |
| 04:17 |
hmmmmm |
could probably be optimized for cache locality |
| 04:17 |
hmmmmm |
at the least |
| 04:19 |
VanessaE_ |
hrm...something ain't right |
| 04:19 |
VanessaE_ |
texture packs ain't working. |
| 04:19 |
hmmmmm |
after the latest commit? |
| 04:19 |
VanessaE_ |
not sure if it's that commit or not, lemme revert and check it |
| 04:20 |
hmmmmm |
i don't *see* what the problem could possibly be with that |
| 04:20 |
VanessaE_ |
nope, wasn't that one |
| 04:21 |
VanessaE_ |
lemme step backwards a bit and see where it went wrong |
| 04:22 |
VanessaE_ |
oh wait |
| 04:22 |
VanessaE_ |
I know why. |
| 04:22 |
VanessaE_ |
forgot I renamed the dir my texture packs are stored in. forgot to update my config accordingly. |
| 04:23 |
VanessaE_ |
there, that's better. |
| 04:23 |
VanessaE_ |
bumpmaps seem to work normally. |
| 04:27 |
hmmmmm |
yeah, and next time you see RBA be sure to ask him WTF is up with that replacement loop in mapblock_mesh.cpp |
| 04:28 |
VanessaE_ |
heh, I'll try to remember :) |
| 04:28 |
hmmmmm |
thx |
| 04:30 |
|
neko259 joined #minetest-dev |
| 04:31 |
VanessaE_ |
oh I think I see what he's trying to do here. |
| 04:31 |
VanessaE_ |
brute-force search for the .xxx extension, insert _normal.png in its place when found |
| 04:32 |
VanessaE_ |
surely there's a better way? |
| 04:32 |
hmmmmm |
no, see karhl's explanation above |
| 04:33 |
VanessaE_ |
dunno then. As if I needed to say anything anyways :) |
| 04:36 |
VanessaE_ |
in the meantime, I think I'll get some sleep. I'm making far more mistakes myself tonight than usual. |
| 04:38 |
VanessaE_ |
night. |
| 05:27 |
|
Miner_48er joined #minetest-dev |
| 05:41 |
|
darkrose joined #minetest-dev |
| 06:18 |
|
darkrose joined #minetest-dev |
| 06:18 |
|
darkrose joined #minetest-dev |
| 07:00 |
|
NakedFury joined #minetest-dev |
| 07:39 |
|
Calinou joined #minetest-dev |
| 07:42 |
|
darkrose joined #minetest-dev |
| 07:42 |
|
darkrose joined #minetest-dev |
| 08:38 |
celeron55 |
umm |
| 08:38 |
celeron55 |
https://github.com/minetest/minetest/commit/320a00e7c65c43c2aa64d1da6e855428101c4aa6 |
| 08:39 |
celeron55 |
i think this doesn't make sense; why couldn't password checking just be disabled when the server knows it's in singleplayer? |
| 08:41 |
celeron55 |
hmm, i guess it's better if online players can't mess with the singleplayer player if it's played with otherwise |
| 08:41 |
celeron55 |
whatever |
| 09:14 |
|
Calinou joined #minetest-dev |
| 09:18 |
|
nyuszika7h joined #minetest-dev |
| 09:18 |
kaeza |
"its hacky" |
| 09:55 |
|
around joined #minetest-dev |
| 10:00 |
|
darkrose joined #minetest-dev |
| 10:00 |
|
darkrose joined #minetest-dev |
| 10:48 |
|
PilzAdam joined #minetest-dev |
| 10:54 |
|
proller joined #minetest-dev |
| 11:16 |
PilzAdam |
celeron55, online players could easily "steal" items from the singleplayer inventory or even abuse its privs; and most server admins dont set a password manually for singleplayer |
| 11:50 |
|
Calinou joined #minetest-dev |
| 12:18 |
|
iqualfragile joined #minetest-dev |
| 13:02 |
|
diemartin joined #minetest-dev |
| 13:06 |
|
proller joined #minetest-dev |
| 13:06 |
PilzAdam |
how would I drop an node as item in Map::transformLiquids()? |
| 13:11 |
celeron55 |
i guess there isn't a straightforward way as Map is supposed to only handle nodes |
| 13:12 |
celeron55 |
umm... also it's called by Server |
| 13:12 |
celeron55 |
well that doesn't make sense |
| 13:14 |
celeron55 |
one way would be to add some kind of a callback parameter to it that allows doing some non-node stuff, or make it return some kind of a list of events |
| 13:15 |
celeron55 |
also i guess ServerEnvironment should call it rather than Server |
| 13:17 |
celeron55 |
alternatively the whole transformLiquids could be moved to ServerEnvironment... |
| 13:17 |
celeron55 |
i have a feeling that hmmmm might have an opinion here 8) |
| 13:20 |
|
RealBadAngel joined #minetest-dev |
| 13:21 |
RealBadAngel |
hi all |
| 13:21 |
PilzAdam |
RealBadAngel, http://irc.minetest.ru/minetest-dev/2013-07-12#i_3192882 |
| 13:22 |
RealBadAngel |
answer is simple |
| 13:23 |
RealBadAngel |
i wanted to check if normal is aviable |
| 13:23 |
RealBadAngel |
if so, i use it |
| 13:24 |
RealBadAngel |
either way with direct call for it i will cause tile manager to create dummy files |
| 13:24 |
RealBadAngel |
think. it doesnt hurt |
| 13:26 |
RealBadAngel |
this way texture pack can have textures with normals and height maps and textures that wont use them at the same time |
| 13:26 |
RealBadAngel |
all depends on it if the files are present |
| 13:27 |
RealBadAngel |
for example items, plant like, doesnt need normals |
| 13:30 |
RealBadAngel |
and regarding the style: i already trashed almost all of the code |
| 13:30 |
RealBadAngel |
since i rebuilded WEIRD shaders system |
| 13:31 |
RealBadAngel |
now shaders can be turned on/off, as many of them one would like |
| 13:32 |
RealBadAngel |
and the result of all the shaders work is gathered in one final shader |
| 13:32 |
RealBadAngel |
and theres no weird tree solids/liquids/alpha |
| 13:34 |
RealBadAngel |
type of a surface is a parameter passed to shader |
| 13:39 |
RealBadAngel |
and for the log: answer to hmmm's question: Vanessa'E got it right "brute-force search for the .xxx extension, insert _normal.png in its place when found" |
| 13:40 |
RealBadAngel |
because in the string there can be many texture file names used |
| 13:40 |
RealBadAngel |
this loop finds them all |
| 13:41 |
RealBadAngel |
all this hacky things thx to ^ system |
| 13:42 |
RealBadAngel |
and dont tell me using find and replace functions will wokr |
| 13:42 |
RealBadAngel |
*work |
| 13:43 |
RealBadAngel |
because i should call it with all the aviable extensions |
| 13:44 |
* VanessaE_ |
peeks in |
| 13:44 |
RealBadAngel |
and one can have png^jpg and i would end in the middle of nowhere |
| 13:44 |
RealBadAngel |
hi |
| 13:44 |
RealBadAngel |
please read the explanation above |
| 13:45 |
RealBadAngel |
its about the discusion about my shaders code |
| 13:45 |
* VanessaE_ |
reads.. |
| 13:45 |
proller |
use astyle for new files |
| 13:46 |
proller |
astyle --style=attach --indent=tab --keep-one-line-blocks --keep-one-line-statements --indent-classes --pad-oper *.cpp *.h |
| 13:47 |
VanessaE_ |
done. |
| 13:52 |
VanessaE_ |
oh sure. |
| 13:52 |
VanessaE_ |
I show up and he signs off ;) |
| 13:56 |
|
RealBadAngel joined #minetest-dev |
| 14:06 |
|
proller_ joined #minetest-dev |
| 14:10 |
|
proller joined #minetest-dev |
| 14:13 |
|
ShadowNinja joined #minetest-dev |
| 14:34 |
PilzAdam |
https://github.com/PilzAdam/minetest/commits/stuff any comments on "Randomly choose singleplayer port" and "Fix lighting bug caused by disappearing lava"? |
| 14:35 |
PilzAdam |
also on this: https://github.com/minetest/minetest/pull/820 |
| 14:37 |
VanessaE_ |
PilzAdam: no comments on those, but does flushing those buildable_to nodes away drop them as entities? |
| 14:37 |
VanessaE_ |
(doesn't look like it to me) |
| 14:37 |
PilzAdam |
VanessaE_, that one is not ready yet |
| 14:37 |
VanessaE_ |
maybe you should wait on that one then |
| 14:37 |
PilzAdam |
re-read what I said; I dont want to merge that yet |
| 14:39 |
VanessaE_ |
oh ok |
| 14:39 |
VanessaE_ |
I took that to mean "I have another commit to add after that one goes in" |
| 14:50 |
|
NakedFury joined #minetest-dev |
| 14:51 |
|
Calinou joined #minetest-dev |
| 15:02 |
VanessaE |
noting Taoki's post, http://forum.minetest.net/viewtopic.php?pid=99322#p99322 , what's the status of this patch? |
| 15:13 |
|
Jordach joined #minetest-dev |
| 15:33 |
celeron55 |
the status is "irrlicht is broken and it's too much work for us to make a reasonable workaround" |
| 15:33 |
celeron55 |
oh well, that's what the thread says too anyway |
| 15:56 |
|
diemartin joined #minetest-dev |
| 16:03 |
Anchakor1 |
in hindsight would you rather go ogre3d + sdl route today? |
| 16:05 |
Jordach |
probably not |
| 16:13 |
celeron55 |
plain opengl |
| 16:13 |
celeron55 |
once you know what you're doing, these 3d libraries just get in your way |
| 16:13 |
Anchakor1 |
too much work |
| 16:20 |
celeron55 |
i would also leave out visual studio support |
| 16:21 |
diemartin |
most Windows users use precompiled versions, and those who compile themselves can easily install MinGW anyway (or crosscompile) |
| 16:23 |
sfan5 |
^ |
| 16:26 |
RealBadAngel |
celeron55, did you knew that most of the fancy shaders effects im workin on irrlicht have built-in without shaders? |
| 16:27 |
RealBadAngel |
water reflections, normal mapping, parallax occlusion and more? |
| 16:27 |
RealBadAngel |
by simply specyfying material type |
| 16:27 |
celeron55 |
so? |
| 16:27 |
RealBadAngel |
we cannot use them |
| 16:28 |
RealBadAngel |
thx to 1 node idea |
| 16:28 |
celeron55 |
i don't understand |
| 16:28 |
Jordach |
RealBadAngel, use groups to specify material |
| 16:28 |
celeron55 |
built-in? 1 node? |
| 16:28 |
celeron55 |
not that i even care, i'm working on something else |
| 16:28 |
VanessaE |
celeron55: scene node. |
| 16:29 |
RealBadAngel |
i was suprised lately with what irrlicht can offer |
| 16:30 |
celeron55 |
what do you expect from me? |
| 16:30 |
RealBadAngel |
had hard time with meshes tangent space |
| 16:30 |
celeron55 |
like, can i just continue what i'm doing or should i answer something clever |
| 16:30 |
RealBadAngel |
and learned that irrlicht can just offers a method to create mesh with tangents |
| 16:31 |
|
blaaaaargh joined #minetest-dev |
| 16:31 |
RealBadAngel |
please do continue |
| 16:31 |
RealBadAngel |
i am listening |
| 16:31 |
celeron55 |
if it makes a difference, each mapblock could be an irrlicht scene node |
| 16:32 |
RealBadAngel |
what about fast_faces? |
| 16:32 |
celeron55 |
but it's kind of an another arbitrary way of chunking stuff and will just make the same problems in a different way |
| 16:32 |
RealBadAngel |
they can cross those borders |
| 16:33 |
celeron55 |
wut? |
| 16:33 |
RealBadAngel |
drawing time |
| 16:33 |
celeron55 |
oh well, i'll just stop; you talk way too cryptically for discussion to be enjoyable |
| 16:33 |
celeron55 |
always |
| 16:33 |
|
smoke_fumus joined #minetest-dev |
| 16:33 |
RealBadAngel |
hehe |
| 16:33 |
RealBadAngel |
i thinkin too much of code |
| 16:34 |
RealBadAngel |
ok, i will stop |
| 16:34 |
RealBadAngel |
please do continue, i wont break |
| 16:36 |
proller |
maybe... https://github.com/minetest/minetest/pull/816 |
| 16:36 |
RealBadAngel |
i mean with border problems |
| 16:42 |
|
sapier joined #minetest-dev |
| 16:44 |
|
vals_ joined #minetest-dev |
| 16:45 |
proller |
maybe https://github.com/minetest/minetest_game/pull/185 |
| 16:49 |
|
serengeor joined #minetest-dev |
| 16:57 |
|
darkrose joined #minetest-dev |
| 16:57 |
|
darkrose joined #minetest-dev |
| 16:57 |
|
ssieb joined #minetest-dev |
| 16:59 |
|
hmmmm joined #minetest-dev |
| 16:59 |
|
Jordach_ joined #minetest-dev |
| 17:00 |
|
sapier1 joined #minetest-dev |
| 17:34 |
sapier1 |
did anyone ever try to start minetest in chroot? |
| 17:36 |
|
iqualfragile joined #minetest-dev |
| 17:45 |
|
Calinou joined #minetest-dev |
| 18:11 |
|
proller joined #minetest-dev |
| 18:13 |
|
Zeg9 joined #minetest-dev |
| 18:15 |
|
neko259 joined #minetest-dev |
| 18:17 |
Taoki |
<celeron55> the status is "irrlicht is broken and it's too much work for us to make a reasonable workaround" |
| 18:17 |
Taoki |
We can make a correct and easy workaround. Just that no one who cares to do it was found. It also appears it's primarily the Minetest code's fault for the leaks (not really a fault, it's just due to how it caches mapblocks and automatically loads in the mesh when it does so) |
| 18:18 |
Taoki |
Like PilzAdam said, it should work to keep mapblocks client-side for 10 minutes like currently, but not keep their mesh for as long too. I figure meshes should be deleted after 30 seconds of not looking at them, until they are to be rendered again |
| 18:21 |
Taoki |
I don't think MT's current approach of sending / keeping the mesh of every single mapblock available in the client is normal even without VBO, from my own understanding. Only the meshes of what's being rendered (or likely to be rendered in the next few seconds) should probably be kept available. Even if mapblocks should be kept for 10 minutes under the form of information (not the mesh as well) |
| 18:22 |
Taoki |
I'm not sure, but I think Irrlicht's behavoir might be normal. If you ask Irrlicht to maintain 1000 meshes, it will do so and fill the RAM. So don't ask it to :P |
| 18:24 |
Taoki |
RealBadAngel: Also, hi! And WB... was worried you went missing during the last days :) |
| 18:27 |
RealBadAngel |
im workin all the time |
| 18:28 |
hmmmm |
this was probably said already but i didn't read it explicitly like this, shouldn't you just have a separate (much shorter) timeout for dropping meshes in the client as opposed to deleting the entire mapblock.... |
| 18:31 |
Taoki |
hmmmm: True |
| 18:39 |
|
kaeza joined #minetest-dev |
| 18:56 |
sapier1 |
https://github.com/minetest/minetest/pull/824 |
| 18:57 |
sapier1 |
fixes local favorites name and description getting lost (don't know why this wasn't already merged) as well as (most) issues with RUN_IN_PLACE=0 |
| 19:00 |
proller |
sapier1, fix public servers desc! |
| 19:00 |
sapier1 |
if you did say the magic word I'd have done that at once ;-P |
| 19:03 |
proller |
please! |
| 19:03 |
|
SpeedProg joined #minetest-dev |
| 19:03 |
hmmmm |
okay there dennis |
| 19:06 |
|
PilzAdam joined #minetest-dev |
| 19:07 |
sapier1 |
great we don't have a fixed size font |
| 19:14 |
sapier1 |
proller ... fixed |
| 19:14 |
proller |
thank you! |
| 19:15 |
sapier1 |
someone still needs to merge it |
| 19:16 |
sapier1 |
btw VanessaE Celeron55 PilzAdam did you manage to find a common understanding of bg/overlay/header/footer logics? |
| 19:16 |
VanessaE |
dunno |
| 19:18 |
sapier1 |
if there's no way to get a single solution until sunday afternoon I'm gonna decide on my own what I think is best ... if anyone wants to change that later it's gonna be her/his issue |
| 19:19 |
sapier1 |
bt whoever suggested trying RUN_IN_PLACE=0 within chroot did never try to run minetest in chroot .. am I right? |
| 19:20 |
PilzAdam |
sapier1, looking at f150f638fec04ff9064cbb69154173a51718ff3c; you dont change anything when RUN_IN_PLACE is 0 |
| 19:23 |
sapier1 |
actualy you're only partly right .. I change it everytime instead only if I want to |
| 19:32 |
sapier1 |
did anyone try software rendering recently? |
| 19:34 |
sapier1 |
PilzAdam now it really switches as expected |
| 19:35 |
PilzAdam |
you know, path_share and path_user are equal when RUN_IN_PLACE = 0, your if is completly redundant |
| 19:35 |
PilzAdam |
*1 |
| 19:35 |
PilzAdam |
just always use path_user |
| 19:36 |
sapier1 |
then you're wrong they are not equal |
| 19:36 |
PilzAdam |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L34 |
| 19:36 |
PilzAdam |
seems very equal to me |
| 19:36 |
sapier1 |
then doc is wrong |
| 19:37 |
sapier1 |
within core they are not same |
| 19:37 |
PilzAdam |
porting.cpp_259 |
| 19:37 |
PilzAdam |
s/_/: |
| 19:37 |
sapier1 |
path_share is <prefix>/share while user is <user>/.minetest/ ... I can only tell what i got |
| 19:38 |
PilzAdam |
that is with RUN_IN_PLACE=0 |
| 19:38 |
PilzAdam |
with run in place they are both binary/../ |
| 19:38 |
sapier1 |
try it |
| 19:39 |
PilzAdam |
look at the code |
| 19:39 |
PilzAdam |
porting.cpp line 332 and 333 set them exactly the same in #if RUN_IN_PLACE |
| 19:45 |
sapier1 |
pilzadam plz read code again they are only equal if RUN_IN_PLACE=1 |
| 19:45 |
PilzAdam |
yes, thats what Im saying |
| 19:46 |
PilzAdam |
so you can always use what RUN_IN_PLACE=0 needs, since it doesnt matter for 1 |
| 19:48 |
sapier1 |
ok original intention was to use path_share ... obviously that decision was wrong |
| 19:52 |
sapier1 |
better? |
| 19:52 |
sapier1 |
stop |
| 19:53 |
sapier1 |
forgot second occurance |
| 20:06 |
proller |
any objections? https://github.com/proller/minetest/commit/8348405a982ad33638aa986f3f932ccdd9f3961e |
| 20:06 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 20:06 |
proller |
no? okay, will commit. |
| 20:06 |
proller |
8-) |
| 20:07 |
sapier1 |
wait |
| 20:07 |
sapier1 |
why do you announce mods? |
| 20:09 |
sapier1 |
ok they can be viewed by browser so at least some use |
| 20:10 |
proller |
yes |
| 20:10 |
PilzAdam |
sapier1, can we get a horizontal scrollbar in the public server list? |
| 20:11 |
sapier1 |
lemme have a look if irrlicht supports that |
| 20:11 |
proller |
no objections? |
| 20:13 |
sapier1 |
PilzAdam no we can't |
| 20:13 |
proller |
maybe make more width in window? |
| 20:14 |
proller |
90% from screen |
| 20:14 |
sapier1 |
won't change the basic problem ... if we increase size descriptions will increase at same rate |
| 20:14 |
proller |
smaller font? |
| 20:14 |
PilzAdam |
that would be unreadable |
| 20:16 |
sapier1 |
server owners just need to accept some limits ... we may increase the size but there still will be limits |
| 20:16 |
proller |
we can cut names before show |
| 20:17 |
sapier1 |
grr irrlicht doesn't even support tooltips :-( |
| 20:17 |
sapier1 |
at least not for listboxes |
| 20:19 |
sapier1 |
ShadowNinja's server (A creative server by ShadowNinja?) ok I guess there may be some ppl out there not realizing that ShadowNinja's server may be run by ShadowNinja :-) |
| 20:20 |
Jordach |
by *a* ShadowNinja |
| 20:21 |
sapier1 |
we could show description of selected entry in a textfield between Name/Password and Connected |
| 20:27 |
ShadowNinja |
sapier1: Yep, I intended to change that to something a little more interesting. |
| 20:28 |
sapier1 |
:-) you're not the only one doing it that way |
| 20:34 |
|
Naked joined #minetest-dev |
| 20:42 |
sapier1 |
ok I removed description from server list and show it above connect button now |
| 20:43 |
PilzAdam |
why not a "Details" button, which opens a new window? |
| 20:43 |
sapier1 |
do you really want to click an additional button to see description? |
| 20:43 |
PilzAdam |
yes, and all the flags and stuff too |
| 20:44 |
PilzAdam |
also the modlist |
| 20:44 |
sapier1 |
I assume this is a feature request |
| 20:44 |
|
diemartin joined #minetest-dev |
| 20:44 |
|
Taoki joined #minetest-dev |
| 20:45 |
PilzAdam |
why do you have commented out code in ffcaa243bc415c9383ade7d87298aec9f6c73c47 ? |
| 20:45 |
sapier1 |
because I didn't want to remove it (yet) |
| 20:47 |
PilzAdam |
meh, the flags dont look good how you display them currently |
| 20:48 |
sapier1 |
I know but it's best that can be done |
| 20:48 |
sapier1 |
at least atm |
| 20:48 |
PilzAdam |
and why do you add "____" to the favorite list? |
| 20:49 |
sapier1 |
because we do have a non fixed size character font using " " results in completly messed up indentions |
| 20:49 |
PilzAdam |
I mean, why do you want to show flags at all in the favorites list? |
| 20:50 |
sapier1 |
because proller requested it |
| 20:50 |
PilzAdam |
there are no flags in favoriteservers.txt |
| 20:50 |
sapier1 |
ohhh you're talking about the local list |
| 20:53 |
sapier1 |
fixed |
| 20:57 |
PilzAdam |
merged |
| 20:57 |
proller |
is any... https://github.com/proller/minetest/commit/e166bad625cd2785f2bb67cf0127bdd1499a9e36 ? |
| 20:58 |
PilzAdam |
proller, why? |
| 20:58 |
sapier1 |
does anyone know what the second "depends on" was in original configure world dialog? |
| 20:58 |
PilzAdam |
it was a list of mods that depend on the selected one |
| 20:59 |
proller |
PilzAdam, thexyz have list of VerySecret Mods |
| 20:59 |
sapier1 |
so it's required by |
| 20:59 |
PilzAdam |
"is required by:" |
| 20:59 |
proller |
and maybe someone want hide mods |
| 21:00 |
PilzAdam |
sapier1, but caps it, so "Depends:" and "Required by:" |
| 21:00 |
PilzAdam |
proller, there is still the /mods chatcommand |
| 21:00 |
thexyz |
proller: moreover, I name my mods after my SSH passwords |
| 21:01 |
sapier1 |
Required by is difficult to rebuild |
| 21:01 |
PilzAdam |
sapier1, then just remove it |
| 21:02 |
PilzAdam |
you would get enough space for the "Enable all" and "Disable all" buttons |
| 21:02 |
PilzAdam |
and you can move the "Hide game" box to a proper place |
| 21:02 |
sapier1 |
I still think this is a topic that needs clarification |
| 21:03 |
sapier1 |
If you use local mods as some sort of local modstore what I assume it is meant to be those buttons are of no use at all |
| 21:04 |
sapier1 |
hmm I schould use some "," sorry |
| 21:04 |
PilzAdam |
why not add them and let users decide how they use them? |
| 21:05 |
PilzAdam |
I know some people who just enable all mods for all of their worls |
| 21:05 |
PilzAdam |
*worlds |
| 21:05 |
sapier1 |
because our gui is just not big enough to add everything anyone might be able to use by some time ;-) |
| 21:06 |
sapier1 |
I know others that do use games only |
| 21:06 |
sapier1 |
both ways are perfectly legit but just don't fit |
| 21:06 |
proller |
PilzAdam, thexyz can disable /mods |
| 21:06 |
PilzAdam |
then give both ways all abilities |
| 21:07 |
PilzAdam |
proller, then he can also disable the announce in the core |
| 21:07 |
PilzAdam |
updated 814 |
| 21:07 |
sapier1 |
imho this cowardish to run away by a decision by doing everything bad instead of one thing correct |
| 21:08 |
sapier1 |
and of course I would have to rename "enable all" to "enable all mods of modpack" |
| 21:09 |
sapier1 |
I guess that won't fit the button |
| 21:09 |
PilzAdam |
then name the new button "Enable all mods" |
| 21:09 |
PilzAdam |
and the old one stays "Enable all", thats not the problem |
| 21:09 |
PilzAdam |
I dont understand why you are against adding a button |
| 21:09 |
sapier1 |
because I think it's too much of buttons |
| 21:09 |
PilzAdam |
the people who need it, need it; and the people who dont need it just ignore it |
| 21:10 |
sapier1 |
I haven't heared about anyone that needs it ... you don't need it I know for sure. |
| 21:11 |
sapier1 |
you only want it because you've been forced to add it some time ago ;-) |
| 21:11 |
PilzAdam |
IIRC NekoGloop and kaeza enable all mods for all their worlds |
| 21:11 |
sapier1 |
we've got a game manager they can simply create a game and use that |
| 21:12 |
PilzAdam |
go tell them that their way of using mods is not supported by the engine |
| 21:12 |
sapier1 |
it's not exactly same I know but it may even be better |
| 21:12 |
kaeza |
PilzAdam, no, I don't use mods/ ; I always use separate games |
| 21:12 |
sapier1 |
it is ... if they use a custom menu |
| 21:13 |
PilzAdam |
it worse, when you think of keeping it in sync with minetest_game |
| 21:13 |
PilzAdam |
kaeza, then it was someone else, dont want to search the logs yet |
| 21:13 |
thexyz |
PilzAdam: do you have anything personal against that patch? |
| 21:13 |
PilzAdam |
thexyz, what patch? |
| 21:14 |
sapier1 |
imho the new menu is a chance to cleanup some gui mess that has been added ... it'll get messed up soon enough |
| 21:14 |
PilzAdam |
if you want to clean up mess then dont always show all mods of modpacks |
| 21:15 |
thexyz |
PilzAdam: proller's |
| 21:15 |
sapier1 |
that's not a inconsistency in gui but only a little bit more detail than might be required |
| 21:15 |
PilzAdam |
thexyz, I have something against the direction it may lead: having settings for each bit that is announced |
| 21:16 |
kaeza |
oh right |
| 21:17 |
sapier1 |
I'm with pilzadam too what's use for it? I don't see any good reason why someone wants to hide what mods are run on server if she/he already announces the server |
| 21:18 |
thexyz |
PilzAdam: having control of what information you're sharing with third party is an important thing, isn't it? |
| 21:18 |
PilzAdam |
maybe create a single setting similiar to mg_flags |
| 21:19 |
sapier1 |
it is but you're already sharing most information I don't see anything about modlist that is more worth to protect than other already announced ones |
| 21:30 |
thexyz |
sapier1: I want to control what information I share, I can change name or description (most information) but I can't protect my mods from being visible |
| 21:30 |
sapier1 |
ok from that point of view you're right |
| 21:31 |
VanessaE |
thexyz: that said, any user can just type /mods after signing in with a gibberish userid/pass |
| 21:31 |
VanessaE |
(your main point still stands, of course) |
| 21:33 |
thexyz |
VanessaE: I can change /mods output or disable it completely |
| 21:33 |
VanessaE |
true |
| 21:35 |
|
iqualfragile joined #minetest-dev |
| 21:35 |
proller |
now without disabling mods: https://github.com/proller/minetest/commit/67da4037e1197393253b3fe32cb5db004151389f |
| 21:37 |
PilzAdam |
why dont you try that announce_flags thing? |
| 21:37 |
proller |
more code, not now |
| 21:38 |
PilzAdam |
remove the lines, dont just comment them out |
| 21:41 |
|
iqualfragile joined #minetest-dev |
| 21:42 |
proller |
okay |
| 21:42 |
hmmmm |
erm guys |
| 21:42 |
hmmmm |
0.4.8 is really overdue |
| 21:42 |
hmmmm |
basically we stopped it from happening because of the formspec main menu |
| 21:43 |
sapier1 |
not exactly ... formspec was added because 0.4.8 wasn't to happen as soon as wanted |
| 21:43 |
hmmmm |
would you all say that the main menu is stable enough for a release? |
| 21:43 |
PilzAdam |
https://github.com/minetest/minetest/issues/814 |
| 21:43 |
sapier1 |
no the background issue is still open |
| 21:43 |
hmmmm |
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm |
| 21:43 |
VanessaE |
hmmmm: not really. |
| 21:44 |
PilzAdam |
feature freeze until all fixable points of 814 are fixed and then release it? |
| 21:44 |
hmmmm |
sounds fair to me |
| 21:44 |
VanessaE |
wait! |
| 21:44 |
sapier1 |
pilzadam you schould split this up to different issues as you're collecting feature requests and can't fixes there |
| 21:44 |
VanessaE |
what about the nodeid limit thing (#822)? |
| 21:44 |
hmmmm |
the nodeid limit should be temporarily increased so your server works |
| 21:45 |
VanessaE |
I need to be able to point my users to a stable release that includes the fix, if they end up needing a new client that is |
| 21:45 |
PilzAdam |
VanessaE, would it make much difference if it happens directly after 0.4.8? |
| 21:45 |
hmmmm |
the vector contentfeatures table is an 0.4.8 thing |
| 21:45 |
hmmmm |
definitely |
| 21:45 |
hmmmm |
there are way too many big changes as it is right now and 0.4.8 should've happened a long time ago |
| 21:46 |
hmmmm |
erm, hey guys, i've been thinking |
| 21:46 |
thexyz |
isn't that what always happens? |
| 21:46 |
PilzAdam |
we can go through the pull request list one more time and merge things |
| 21:46 |
hmmmm |
whenever there's a version number bump everybody gets into this big hoopla |
| 21:46 |
hmmmm |
this isn't what celeron ever wanted |
| 21:46 |
hmmmm |
this is why it almost went to a rolling release model |
| 21:47 |
|
NakedFury joined #minetest-dev |
| 21:47 |
hmmmm |
what if we were to more regularily change the patch version (when there's enough for a *PATCH* and then only make a big deal when the minor version number increases |
| 21:47 |
PilzAdam |
hmmmm, thats due to the long time between the releases, most users use stable releases and everyone wants that they have the latest and coolest stuff in it |
| 21:48 |
sapier1 |
that won't change ever |
| 21:48 |
VanessaE |
hmmmm: for me, it's more a matter of "wtf? this doesn't work, I have latest git!", yet "latest" ends up being 2-3 weeks old. |
| 21:48 |
thexyz |
we need in-game version check then |
| 21:48 |
VanessaE |
so to be able to refer to a specific version number (if it's needed at all) makes it easier on the users |
| 21:48 |
hmmmm |
right |
| 21:48 |
hmmmm |
what i'm saying makes way more sense |
| 21:49 |
sapier |
and we need that version number for online modstore too |
| 21:49 |
hmmmm |
so really this all comes down to how *you* act about a release |
| 21:49 |
hmmmm |
so i say, stop making big deals about patch versions |
| 21:49 |
PilzAdam |
we could change our release model, everything that was a patch increase becomes a a bump of version minor, and patches are done for every huge thing that gets in |
| 21:49 |
hmmmm |
and i'll be glad to bump it more often |
| 21:49 |
VanessaE |
how long we go between versions isn't of too much concern to me beyond of that particular corner case though |
| 21:49 |
VanessaE |
PilzAdam: trying to compete with chrome and ff? :) |
| 21:49 |
proller |
sapier, please add number of players in public serverlist |
| 21:50 |
hmmmm |
pilzadam, that's stupid though because then all you're doing is replacing the first dword of the hash with an incremental number |
| 21:50 |
hmmmm |
a patch level needs to mean something more |
| 21:50 |
PilzAdam |
hmmmm, isnt that the same that you suggested? |
| 21:50 |
proller |
sapier, and if showing address - add port if port != 30000 |
| 21:50 |
thexyz |
hmmmm: it'll be easier for users to understand |
| 21:50 |
hmmmm |
no.... i want to increase the frequency of patch version bumps |
| 21:50 |
hmmmm |
not make them every single commit or whatever |
| 21:50 |
sapier |
it's already crowded proller and the indention disortion won't get better by adding more information |
| 21:51 |
PilzAdam |
I havent said "every commit" |
| 21:51 |
thexyz |
true, he hasn't |
| 21:51 |
hmmmm |
the patch version number could be increased, say, when there's a bigger feature added or significant, long time nagging bug fixed |
| 21:51 |
VanessaE |
sapier, proller: about showing the description of the server, imho it belongs *above* the username/pass fields (that is, move those fields down to make room). As if to say to the user, "This is what I am, if you like it, enter your info below..." |
| 21:51 |
PilzAdam |
"and patches are done for every huge thing that gets in" |
| 21:51 |
sapier |
I suggest to follow pilzadams suggestion and add a details button ... after next version |
| 21:51 |
VanessaE |
hmmmm: that makes sense |
| 21:51 |
hmmmm |
right |
| 21:52 |
hmmmm |
like every time you feel the need to compile a new version for windows |
| 21:52 |
hmmmm |
you know how you have tags like -oregen or -voxelmanip or -performance |
| 21:52 |
hmmmm |
those ought to be patch version bumps |
| 21:52 |
proller |
sapier, i have 2 servers on one ip, seeml like duplicate in list |
| 21:52 |
PilzAdam |
seems reasonable |
| 21:52 |
sapier |
use different names! |
| 21:52 |
proller |
sapier, and players number MUST BE |
| 21:53 |
proller |
names in favorites? |
| 21:53 |
VanessaE |
proller: number of players might lead a bit to selection bias. |
| 21:53 |
PilzAdam |
hmmmm, so, we dont do feature freezes for patch version increases anymore? |
| 21:53 |
sapier |
no it's not a must it just messes up the indentions ... |
| 21:53 |
hmmmm |
no |
| 21:54 |
hmmmm |
only minor versions |
| 21:54 |
PilzAdam |
so, we can actually release 0.4.8 now |
| 21:54 |
hmmmm |
i'd rather not |
| 21:54 |
hmmmm |
we'll only start this after erm.... 0.5.0 |
| 21:55 |
PilzAdam |
so we do our old release cycle and release 0.5.0 and then we use the new model, seems good |
| 21:55 |
hmmmm |
0.5.0 was originally supposed to be when the lua api could be declared stable |
| 21:55 |
hmmmm |
it's already well past that stage |
| 21:55 |
VanessaE |
I'd say the API is more than stable |
| 21:55 |
VanessaE |
ninja'd. |
| 21:55 |
hmmmm |
i think we should repurpose 0.5.0 to mean something like, mobs are in by default, well supported, and plenty fast |
| 21:55 |
hmmmm |
and using mapgen v7 by default, you think? |
| 21:56 |
hmmmm |
along with all the biomes and everything polished off and added |
| 21:56 |
PilzAdam |
so you dont want to release it soon? |
| 21:56 |
VanessaE |
mmmm |
| 21:56 |
hmmmm |
there's obviously a bit of a way to go, but i am under the impression that's where we want to be headed |
| 21:56 |
VanessaE |
hmmmm: do you really think it's *that* close? |
| 21:56 |
hmmmm |
the whole biome thing? |
| 21:57 |
VanessaE |
the whole "package" you just decribed as a reason for 0.5.0 |
| 21:57 |
hmmmm |
yes, i think so |
| 21:57 |
PilzAdam |
I dont know about the mobs |
| 21:58 |
hmmmm |
the whole biome/mapgen v7 thing at the very least is basically done |
| 21:58 |
VanessaE |
the only thing really holding back mobs is that entity duplication glitch I think. |
| 21:58 |
hmmmm |
all i realistically need to do is add l-system support for decorations (which is easy actually) |
| 21:58 |
PilzAdam |
I recently played with simplemobs on server; it was unplayable, really high latency |
| 21:59 |
PilzAdam |
I punchede a mob 100 times until it died, without looking in my direction |
| 21:59 |
sapier |
what server did you play pilzadam? |
| 21:59 |
PilzAdam |
Jordach's |
| 22:00 |
sapier |
hmmm I never realized anything like that with mobf but there may be a regression or it's just jordachs server |
| 22:00 |
PilzAdam |
well, the whole connection to that server was bad |
| 22:01 |
PilzAdam |
(as usual when its in the US) |
| 22:01 |
NakedFury |
me too. they dont have hitting animations, the selection box when you aim at them looks bad, they ignore you while you hit them, no sounds when they attack or are attacked. |
| 22:01 |
sapier |
ok in laggy environments mobs never will behave well |
| 22:01 |
PilzAdam |
even in singleplayer some of this things happen |
| 22:01 |
VanessaE |
there needs to be some client-side prediction for those too, then. No other way to really fix that problem |
| 22:02 |
VanessaE |
(and that would be... hard.) |
| 22:02 |
sapier |
I haven't realized anything like that before last mobf release but I don't have many mobs installed when preparing and testing an new version |
| 22:03 |
NakedFury |
I like having mobs but if they are to be part of a package players, new players or returning players, will expect them to be and act like in other games. |
| 22:03 |
PilzAdam |
there should be something like PlayerObject support in the API, you just call walk(pos) and the client automatically applies the correct animation |
| 22:03 |
sapier |
https://github.com/minetest/minetest/pull/825 VanessaE's description swap as well as a revertion of a double added check |
| 22:04 |
sapier |
pilzadam that is already possible |
| 22:04 |
PilzAdam |
with automated turning arround, client side prediction and automated animation? |
| 22:04 |
sapier |
there's a pull request with automatic animation speed adjustment |
| 22:04 |
VanessaE |
PilzAdam: so essentially, just move the bulk of the mobs' logic to the client. |
| 22:04 |
PilzAdam |
yea |
| 22:05 |
VanessaE |
is that wise? |
| 22:05 |
hmmmm |
pilzadam, i think i'd want mobf to be in minetest_game |
| 22:05 |
sapier |
yes combining those 3 pull requests will give way better client experience |
| 22:05 |
PilzAdam |
when looking at MC it seems like thats what they do |
| 22:05 |
hmmmm |
no offense |
| 22:05 |
VanessaE |
I mean, can it be made generic enough to cover all the current types of mobs we have now? |
| 22:05 |
sapier |
no you can't move mob logics to client |
| 22:05 |
sapier |
only graphics |
| 22:06 |
PilzAdam |
sapier, what about movement and animation? |
| 22:06 |
sapier |
not even movement |
| 22:06 |
VanessaE |
sapier: well movement, animations, killing prediction, etc. could be client-side, as long as the model, textures, and extra actions are server-side |
| 22:06 |
PilzAdam |
like the server sends the path, not only the current velocity |
| 22:06 |
VanessaE |
as long as the server executes the same instructions at the same assumed time, it won't be any worse than say anti-cheat and placed blocks disappearing |
| 22:07 |
sapier |
it's not that critical in mobf as I use accelerations which are predicted by client |
| 22:07 |
sapier |
but of course have other restrictions |
| 22:08 |
sapier |
paths aren't that usefull they seem to be at first |
| 22:09 |
sapier |
most movement is random ... yes you could predict some random movement but if player modifys something you need to recalculate path everytime ... which is quite costly |
| 22:09 |
sapier |
killing is already predicted vanessae |
| 22:10 |
VanessaE |
sapier: I guess it doesn't work as well as it should - I've seen mobs show as "killed" (a puff of smoke) and still remain standing |
| 22:10 |
PilzAdam |
if client and server have the same pathfinding code, and the server just sends the target, then it could work quite nice |
| 22:10 |
sapier |
no it won't |
| 22:11 |
sapier |
lag is still an issue |
| 22:11 |
sapier |
anytime a server sends a target he needs to make sure client and server maps are exactly in sync at that time |
| 22:11 |
sapier |
no node dig prediction on client for example |
| 22:12 |
VanessaE |
then the cause of the lag itself needs fixed, we're only talking 300-400 ms for the worst servers on the list, this shouldn't snowball into several seconds' worth of lag. |
| 22:12 |
sapier |
if there's only one player ... no problem of course but once there are multiple players ... tricky |
| 22:12 |
PilzAdam |
if the client places some node locally to block the mobs way, then the client would predict a movement change in the mob and the server will do the same if the client tells it about the placed nodes |
| 22:13 |
sapier |
only if the node prediction isn't aborted |
| 22:13 |
PilzAdam |
that shouldnt happen with an average ping to the server |
| 22:13 |
sapier |
and of course you do path prediction multiple times |
| 22:14 |
VanessaE |
sapier: at some point, you have to trust the client at least a little bit. |
| 22:14 |
PilzAdam |
pathfinding can be optimized, I guess |
| 22:15 |
sapier |
I don't trust client ... but that's not my main point main point is most movement is random |
| 22:15 |
PilzAdam |
then dont make the movement random but just the targets |
| 22:15 |
PilzAdam |
e.g. the server sets a random target ~5 nodes away from the mob, it walks there and then it gets another random target |
| 22:16 |
PilzAdam |
and the targets are send to the client, so he can predict the movement |
| 22:16 |
sapier |
what exactly does this change? |
| 22:16 |
sapier |
it's already done this way |
| 22:16 |
PilzAdam |
no, currently only the current velocity is send to the client |
| 22:16 |
sapier |
for simplemobs |
| 22:16 |
PilzAdam |
wich make walking arround a corner look really weird |
| 22:17 |
sapier |
mobf predicts position in future based upon velocity and acceleration |
| 22:17 |
PilzAdam |
setting acceleration doesnt help walking arround a corner |
| 22:17 |
sapier |
and then sends a new acceleration to reroute a mob |
| 22:17 |
sapier |
of course it helps |
| 22:18 |
sapier |
movement is even way more smooth than with fixed point traversal |
| 22:18 |
sapier |
paths very quickly result in stop and go movement |
| 22:18 |
PilzAdam |
if there is a lag of the time the mob walks 2 nodes, then of course just sending the current velocity and acceleration is stupid |
| 22:19 |
VanessaE |
which, of course, is what causes carts to fly off their rails |
| 22:19 |
sapier |
yes but if there's lag of 5 seconds paths won't work either as mob always needs to "Jump" to it's new position |
| 22:20 |
kaeza |
better than with accel |
| 22:20 |
sapier |
both aren't usefull |
| 22:20 |
PilzAdam |
if you add the ETA to the target, then the client could adjust the velocity |
| 22:21 |
VanessaE |
I suggested a short while back that both velocity and time-to-move be sent, so that the client can predict where the entity should stop at |
| 22:21 |
PilzAdam |
and when the mob attacks, then the server just sends the player as target |
| 22:21 |
sapier |
that all fixes single symptoms but not the root cause ... by some time the workarounds will add more issues than they fix |
| 22:22 |
PilzAdam |
examples? |
| 22:22 |
PilzAdam |
and what is the "root cause"? |
| 22:22 |
sapier |
e.g. eta: result ->stop and go |
| 22:22 |
sapier |
player target --> attacks from mobs beeing far away |
| 22:23 |
kaeza |
still better than the current scheme |
| 22:23 |
sapier |
root cause is lag that just isn't really explainable |
| 22:23 |
PilzAdam |
can you please form whole English sentences? |
| 22:24 |
sapier |
ping from germany to new zealand is 200 ms ... |
| 22:24 |
PilzAdam |
I mean for "<sapier> e.g. eta: result ->stop and go" and "<sapier> player target --> attacks from mobs beeing far away" |
| 22:24 |
sapier |
those are the side effects of the suggested workaround |
| 22:25 |
kaeza |
what is "stop and go"? |
| 22:25 |
PilzAdam |
how does "eta" lead to "stop and go"? |
| 22:25 |
sapier |
if you specify a eta and have lag server may already have sent a new direction and eta while client simply stops a mob |
| 22:25 |
VanessaE |
kaeza: move 5 seconds at 1m/sec -> 5m down the line, the server lags for a moment before sending the next move sequence |
| 22:26 |
VanessaE |
but then, many of the naturally wandering mobs do that *anyway* |
| 22:26 |
sapier |
plz don't only think about velocity ... there's acceleration too |
| 22:26 |
PilzAdam |
sapier, this system would be used when the mob idles arround, I dont see how standing in this state hurts |
| 22:26 |
kaeza |
and how is acceleration better? |
| 22:27 |
kaeza |
if you have 1 sec lag before the server sends the accel change, the mob will probably be far off the intended point |
| 22:27 |
sapier |
it's predicted by client ... on the other hand it'll result in runaway mobs ... a workaround for acceleration based movement would be max speed ... but it's as silly as eta |
| 22:27 |
VanessaE |
sapier: accel isn't that hard to figure in, if you already have a max movement time field also |
| 22:27 |
kaeza |
(in the client) |
| 22:28 |
sapier |
most movement in mobf just doesn't even rely on positions |
| 22:28 |
sapier |
so there's neither a target nor an eta |
| 22:29 |
PilzAdam |
so there is no possiblity of prediction |
| 22:29 |
sapier |
the eta is not bad don't get me wrong it's just a completely different aproach |
| 22:29 |
PilzAdam |
of course we need a completly different approach |
| 22:29 |
PilzAdam |
everything we currently have obiously doesnt work |
| 22:30 |
sapier |
using eta won't help mobfs movement style while it may improve simplemobs style at cost of lots of calculations |
| 22:31 |
PilzAdam |
it doesnt improve simplemobs at all |
| 22:31 |
PilzAdam |
forget about the current mods |
| 22:31 |
sapier |
if you use pathfinding it'd help |
| 22:31 |
PilzAdam |
we need a new way of supporting mobs in the engine that is predicatble by clients |
| 22:32 |
sapier |
that's not possible by definition |
| 22:32 |
sapier |
a mob is same as a human player |
| 22:32 |
PilzAdam |
and the "target system" I described is the best thing I can think of currently |
| 22:33 |
sapier |
I already thrown that idea away because of the movement generated by it |
| 22:33 |
PilzAdam |
I dont really want mobs that pass the turing test, something that _works_ would be enough |
| 22:34 |
sapier |
you're just replacing one glitch by another ... which one is more bad is personal opinion ... I guess most will be fine with it as they don't complain about simple mobs walking in water too :-) |
| 22:35 |
sapier |
my next step will be use core collision handling to reduce server load for movement prediction in mobf |
| 22:37 |
sapier |
but that won't help if it just results in server admins adding other slow mods ... as it'll always be the mobs that will be called laggy ... the rest just doesn't show up |
| 22:37 |
PilzAdam |
your current system can always just send the current state, this means you can walk arround edges in the client smoothly; my system would let the client caclculate a smooth transition, its like you would send mutltiple states at once |
| 22:38 |
PilzAdam |
*cant walk arround edges smoothly |
| 22:38 |
sapier |
only if you add smoothing code aditionally |
| 22:39 |
sapier |
if not it won't walk smooth but in worst cas to instand 360° rotations |
| 22:39 |
PilzAdam |
cant you see that sending the goal instead of each single step is more effective? |
| 22:40 |
sapier |
can't you realize 99% of movement just doesn't have a goal? |
| 22:40 |
Taoki |
celeron55, PilzAdam: I had a discussion with RBA some time ago. He pointed out another issue which in my opinino, might be worth considering; |
| 22:40 |
sapier |
the chicken running around doesn't require a goal |
| 22:40 |
Taoki |
Is it really that good of an idea that the entire world (all mapblocks) are one mesh? Specifically, that no z-buffering can be used on the world for this reason? |
| 22:41 |
PilzAdam |
thats just a matter of what the mod does; currently e.g. simpglemobs just sets randomly new directions and velocoties; but it can also just set random goals every 5 seconds or so |
| 22:41 |
Taoki |
What if each mapblock was made into a different Irrlicht node, and z-buffering could be allowed? |
| 22:41 |
PilzAdam |
doesnt make much difference |
| 22:41 |
sapier |
yes but that goal is artificial |
| 22:41 |
PilzAdam |
sure |
| 22:41 |
NakedFury |
taoki what does that mean? |
| 22:41 |
PilzAdam |
it would in the end would be as random as your current system, but it looks better in the client |
| 22:42 |
sapier |
I didn't use targets on purpose because I wanted smooth direction changes |
| 22:42 |
Taoki |
NakedFury: All mapblocks are a single Irrlicht node. This doesn't allow z-buffering to be possible. Than if for example every mapblock was its own node |
| 22:42 |
PilzAdam |
smooth direction change can only be done in the client if the client can predict them |
| 22:42 |
Taoki |
So the entire world is a whole mesh |
| 22:42 |
PilzAdam |
wich requires a goal |
| 22:42 |
sapier |
no it never would be as random as current there always will be a sharp direction cut at goal |
| 22:43 |
sapier |
but there is no goal pilzadam ;-) |
| 22:43 |
NakedFury |
so we divide irrlicht nodes for mapblocks? |
| 22:43 |
PilzAdam |
I dont see how randomly choosing a goal is different from randomly chaning direction |
| 22:43 |
NakedFury |
would that allow z buffering? and what would z buffering bring to the game? |
| 22:44 |
sapier |
if you choose a goal you have two options |
| 22:44 |
sapier |
one goal at a time |
| 22:44 |
sapier |
multiple points resulting in a path |
| 22:44 |
sapier |
first one will in any case result in sharp direction changes |
| 22:45 |
sapier |
second one will suffer about updating path on change |
| 22:45 |
sapier |
how big those effects are need to be researched |
| 22:45 |
sapier |
but still I don't see the real issue ... even if we get this better for mobs other player's movement still will be strange while lag is that big |
| 22:47 |
PilzAdam |
why do we even have that much lag? other games dont seem to have this issue |
| 22:48 |
sapier |
that's exactly what I'm pointing at. my assumption is if we did fix that issue we wouldn't need any of those suggestions we discussed |
| 22:48 |
Taoki |
For mobs? |
| 22:48 |
Taoki |
I noticed the simple mobs lag a bit. Players too. |
| 22:48 |
sapier |
no the mobs just show up the lag |
| 22:48 |
kaeza |
sapier, paths can be smooth or coarse depending on the object |
| 22:48 |
sapier |
they're not the issue causing it (most of time) |
| 22:48 |
Taoki |
PilzAdam: Other games (Minecraft does IIRC) might be using a direct stream instead of TCP packats every X seconds |
| 22:48 |
Taoki |
I heard about that occasionally |
| 22:49 |
Taoki |
So player omvement is sort of streamed like media is streamed for online TV... continuous and with little gaps |
| 22:49 |
Taoki |
I think, never tested that myself |
| 22:49 |
sapier |
yes kaeza but calculating paths is costly |
| 22:49 |
PilzAdam |
sapier, a path for a goal that is lets say 10 nodes away at max? |
| 22:50 |
Taoki |
MT might also not have all the best systems to predict movement and prevent lag |
| 22:50 |
sapier |
depends on your map |
| 22:50 |
sapier |
I guess in worst case a 2 digit number of miliseconds |
| 22:50 |
PilzAdam |
and there is no need for complex paths |
| 22:51 |
kaeza |
sapier, I don't have that much experience with motion planning, but paths are not always needed for "good enough" results |
| 22:51 |
sapier |
you just don't know how complex a path will be untell you look for it pilzadam |
| 22:52 |
sapier |
if you don't have paths forget about the smoothing ... you'll have to life with either one of those options |
| 22:52 |
sapier |
vombie in mobf uses a hybrid solution |
| 22:53 |
sapier |
they have targets but use acceleration to reach it (while attacking) |
| 22:54 |
sapier |
but ... if there's no path between target and vombie that's consuming way more cpu power than I'd want it to |
| 22:54 |
kaeza |
hmm... this is very terse, but should give some idea http://wiki.yoyogames.com/index.php/Mp_potential_step |
| 22:55 |
sapier |
that's the unsmothed version ;-) |
| 22:55 |
kaeza |
err nope |
| 22:56 |
sapier |
mobf did this while pathfinding wasn't implemented |
| 22:56 |
sapier |
it is |
| 22:56 |
sapier |
they're just using pixels instead of blocks ;-) |
| 22:57 |
kaeza |
GM can look ahead a tiny bit (say, 10 pixels). if there's a solid object, it gradually changes direction until it no longer "sees" a solid object |
| 22:57 |
sapier |
kaeza this is already done by mobf |
| 22:57 |
sapier |
was first thing I added when creating the movement gen |
| 22:58 |
PilzAdam |
sapier, why? https://github.com/sapier/minetest/commit/26426b4b81a982578aff9bd6dd97786476dfaad8 |
| 22:58 |
sapier |
and there the problem starts ... what to do if you detect a solid object? currently mobf tries a random acceleration change and checks again |
| 22:59 |
sapier |
because it got added twice due to rebase error |
| 23:00 |
|
diemartin joined #minetest-dev |
| 23:01 |
iqualfragile |
ipv6 works for me |
| 23:02 |
sapier |
iqualfragile could you add a mod with screenshot to moddb? |
| 23:03 |
iqualfragile |
test has a screenshot |
| 23:03 |
iqualfragile |
http://forum.minetest.net/mmdb/mod/test/ |
| 23:04 |
iqualfragile |
"titlepic": {"id": 2, "file": "modpictures/2/haus.png", "desc": "haus vom nikolaus", "mod": 2} |
| 23:06 |
sapier |
ok I guess I need to add that to core |
| 23:21 |
|
kaeza joined #minetest-dev |
| 23:25 |
|
Weedy_lappy joined #minetest-dev |
| 23:37 |
|
kaeza joined #minetest-dev |
| 23:40 |
sapier |
https://github.com/minetest/minetest/pull/825 mod download store including screenshots |
| 23:44 |
kaeza |
awesome |
| 23:48 |
Taoki |
I'm noticing something interesting. Even in singleplayer, it takes a LOT to load some games up. Mainly the "loading textures" part |
| 23:48 |
Taoki |
technic_game for instance takes QUITE a lot to... boot up. In comparison to minetest_game |
| 23:49 |
Taoki |
Even after it's already started once and textures should have been cached |
