Time |
Nick |
Message |
00:07 |
|
troller joined #minetest-dev |
00:08 |
celeron55 |
hmm |
00:08 |
celeron55 |
maybe i'll add it anyway |
00:14 |
NakedFury |
make the chat look like in mmos with background textures? |
00:18 |
|
sapier1 joined #minetest-dev |
00:24 |
sapier1 |
#844 and #546 in general I'd suggest not adding new non formspec driven gui elements, but we don't have formspec sliders by now. The settings formspec can be easyly extracted from mainmenu, in best case it's done in a non copying way |
00:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/844 -- Added mouse sensitivity setting to pause menu. by joshuaj |
00:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/546 -- (WIP) In-game settings by khonkhortisan |
00:33 |
sapier1 |
celeron55 the hang you found is not a result of protocol fixes but of inconsistent shutdown handling causing problems with semaphore driven mutex queues |
00:34 |
celeron55 |
sapier1: can i push this? http://paste.ubuntu.com/6700390/ |
00:34 |
celeron55 |
it fixes error messages being cut at half of second line |
00:36 |
celeron55 |
well i will anyway |
00:42 |
|
proller joined #minetest-dev |
00:43 |
NakedFury |
I dont see a reason not to push it |
00:47 |
sapier1 |
http://paste.ubuntu.com/6700390/ yes using textarea should be better |
00:53 |
sapier1 |
argh with current structure I have 3 options for this hang, ... 1) don't care about it 2) make it crash by throwing an exception, 3) don't throw exception but corrupt memory (in some in game cases too) ... none of them are acceptable |
00:55 |
sapier1 |
I'd prefere option 4 move texture and shader processing from main loop to separate thread which can be shutdown in a coordinated way |
00:55 |
celeron55 |
ehm |
00:55 |
celeron55 |
they are in the main loop for the exact reason that irrlicht expects them to be done in the main thread |
00:56 |
sapier1 |
then I guess it's more to rework |
00:56 |
celeron55 |
why is 2 bad |
00:56 |
sapier1 |
because it will crash on shutdown? |
00:57 |
celeron55 |
oh well yeah, maybe it's not good 8) |
00:57 |
sapier1 |
option 2 is adding a hard timeout for texture/shader processing if this is hit the only way is to abort any other processing as the one waiting for it can't proceed without the result |
00:58 |
sapier1 |
in this hang case the shader/texture processing is already halted but a thread is still waiting for it's result |
00:58 |
celeron55 |
why can't it return by exception to the one who waits |
00:59 |
celeron55 |
and then just handle that exception in all threads that wait |
00:59 |
sapier1 |
as I said lots of rework it's about 4 levels of code that don't handle not getting a result :-) |
00:59 |
celeron55 |
when the texture/shader processing shuts down, it can set a flag that it has shut down, throw() on all requests |
01:00 |
VanessaE |
celeron55: regarding http://paste.ubuntu.com/6699855/ , have you taken a look at minetest-classic recently? darkrose fixed the player model lighting bug there. |
01:00 |
VanessaE |
maybe her fix may be of interest. |
01:00 |
celeron55 |
it's an exception; levels don't matter as you just add handling to the base level |
01:02 |
sapier1 |
no won't work this way, the thread requesting it may already have queued it prior shutdown was initiated and may already wait in semaphore ... maybe we can just answer the requests with some empty result |
01:03 |
sapier1 |
the processing isn't explicitly halted but just not done any longer due to exit of main loop |
01:03 |
sapier1 |
let me have a look where to force answer the request queues |
01:04 |
celeron55 |
can't you trigger the semaphore to continue? |
01:04 |
sapier1 |
that's what I meant with force answer, the semaphore is hidden within the mutexqueue |
01:05 |
sapier1 |
it'd be ugly to make it public |
01:05 |
celeron55 |
an alternative is to return some useless static stuff |
01:06 |
sapier1 |
that's what I meant with empty result |
01:06 |
celeron55 |
i guess it's worth trying |
01:07 |
sapier1 |
yes ... first of a ll I need to know where to do it game.cpp 1306 is some optimization result there's nothing in code there :-) |
01:07 |
|
proller joined #minetest-dev |
01:09 |
sapier1 |
argh :-) that damn file should be split to 10 files ... btw that's now true for connection.cpp too ;-) |
01:11 |
celeron55 |
VanessaE: it doesn't seem to do anything special so i wonder if it actually works |
01:13 |
VanessaE |
celeron55: is this client-side? |
01:13 |
VanessaE |
(it looks like it but you know the code better than me) |
01:16 |
celeron55 |
of course it is |
01:19 |
VanessaE |
no good against current HEAD |
01:20 |
VanessaE |
fatal: patch fragment without header at line 97: @@ -960,13 +1026,13 @@ class GenericCAO : public ClientActiveObject |
01:22 |
sapier1 |
celeron as I can't reproduce the hang could you try if this patch is enough to fix it https://gist.github.com/sapier/8276589 |
01:29 |
celeron55 |
doesn't help |
01:30 |
sapier |
hmm I have to have misread something in this case |
01:30 |
celeron55 |
here's a useless release build backtrace http://paste.ubuntu.com/6700619/ |
01:31 |
celeron55 |
probably the same as the -O0 one |
01:33 |
sapier |
actually I can't use -O0 right now too due to gdb pretty printing beeing broken on -O0 ... ironic isn't it? |
01:33 |
sapier |
but I guess I know what's happening |
01:35 |
sapier |
you have shaders disabled am I right about this? |
01:35 |
sapier |
no no forget about it you have them enabled otherwise you couln't even reach that code |
01:37 |
celeron55 |
the way i reproduce the hang is that i simply quit to menu or os right after getting into a singleplayer game and starting to see mapblocks |
01:37 |
celeron55 |
enabled |
01:37 |
celeron55 |
it can hang by quitting at any point though |
01:37 |
celeron55 |
sometimes doesn't |
01:38 |
sapier |
anytime a mapblock mash is generated |
01:41 |
celeron55 |
it's funny how development changes when i finally got a new computer; this builds minetest in 38 seconds so it's not really an issue to rebuild all the time 8) |
01:42 |
sapier |
38 seconds? I'm jelouse :-) |
01:42 |
sapier |
and I can't reproduce it, your pc is to fast ;-) |
01:42 |
VanessaE |
jeez even my badass box ain't THAT fast :) |
01:51 |
sapier |
https://gist.github.com/sapier/8276589 ok one last try if this isn't working I guess I need to do a more deep check what happens on shutdown |
01:57 |
celeron55 |
this is even a laptop |
02:00 |
celeron55 |
this seems to fix it |
02:01 |
celeron55 |
oh how delightful it is to press the quit button knowing it will actually quit! |
02:02 |
sapier |
ok so continuing texture and shadere processing until mesh update thread is shutdown solves it. Proofs the explanation was correct ... it's not as clean as I'd prefere it to be but I'd not consider it a ugly hack either |
02:03 |
celeron55 |
it's fine |
02:04 |
sapier |
I'm gonna clean those things up tomorrow it's late now |
02:04 |
celeron55 |
yeah it's a tad late here too.... 4AM 8) |
02:04 |
sapier |
good time to go to bed right after fixing a bug :-) prior next one to appear ;-) |
02:06 |
|
sapier left #minetest-dev |
02:19 |
|
Miner_48er joined #minetest-dev |
03:12 |
VanessaE |
guys, we may have a problem in the map generator? |
03:13 |
VanessaE |
I need a mapgen expert to join my server please |
03:13 |
VanessaE |
hmmmmm: if you are available, this needs your attention |
03:15 |
VanessaE |
I have a rather large area that looks like it got generated normally except that it appears to have replaced air with IGNORE of all things. I can't be sure how this happened, if it's a bug in mapgen or map corruption ot what |
03:15 |
VanessaE |
the nodes are there, they're pointable, walkable, and buildable-on. //inspect (worldedit) identfies them normally |
03:15 |
VanessaE |
but they're invisible, as if the air nodes have been replaced with CONTENT_IGNORE |
03:17 |
VanessaE |
placing things like torches reveals a dirt surface, using worldedit works normally, etc. |
03:18 |
Miner_48er |
who's an expert in that? |
03:23 |
Miner_48er |
ShadowNinja any experts? |
03:24 |
ShadowNinja |
hmmmmm, kahrl, and celeron55 might be able to help. |
03:30 |
|
ImQ009 joined #minetest-dev |
03:44 |
ShadowNinja |
This isn't helpfull. Fine if I remove it? https://github.com/minetest/minetest/pull/1078#issuecomment-31601463 |
03:45 |
VanessaE |
oh jeez |
04:07 |
|
OldCoder joined #minetest-dev |
04:28 |
|
hmmmm joined #minetest-dev |
04:30 |
|
hmmmm joined #minetest-dev |
04:31 |
* VanessaE |
pokes hmmmm |
04:33 |
hmmmm |
yes? |
04:34 |
VanessaE |
hmmmm: http://irc.minetest.ru/minetest-dev/2014-01-06#i_3535543 |
04:34 |
VanessaE |
"Houston, we've had a problem." |
04:34 |
hmmmm |
screenshot? |
04:34 |
VanessaE |
coming up |
04:34 |
VanessaE |
gimme a minute |
04:34 |
hmmmm |
if it is what you say it is, I would assume that's caused by a mod |
04:34 |
hmmmm |
there is literally no way for content_ignore to get placed by the mapgen |
04:35 |
hmmmm |
except if you were to alias literally everything to ignore |
04:35 |
hmmmm |
and even then that wouldn't work for the air part |
04:35 |
VanessaE |
lemme get the surrounding area loaded up again (I'd since signed out) |
04:35 |
hmmmm |
because the air constant is used |
04:39 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2001052014%20-%2011%3a35%3a06%20PM.png |
04:39 |
VanessaE |
the whole affected area |
04:39 |
VanessaE |
now, here's the strange part: |
04:39 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2001052014%20-%2011%3a35%3a35%20PM.png |
04:39 |
VanessaE |
see those torches? |
04:39 |
VanessaE |
they were placed on invisible ground. the ground became visible when they were placed. it was dirt, which changed to grass via the usual abm |
04:39 |
VanessaE |
that tells me there was CONTENT_IGNORE there before. |
04:40 |
hmmmm |
yes, that is content_ignore on the ground |
04:40 |
hmmmm |
anyway like i said, it's gotta be a mod that doesthat |
04:40 |
VanessaE |
but you just said that's impossible :) |
04:40 |
hmmmm |
no..... |
04:40 |
VanessaE |
[01-05 23:32] <hmmmm> and even then that wouldn't work for the air part |
04:40 |
VanessaE |
because the *dirt* is still there |
04:40 |
VanessaE |
it's not aliased out |
04:41 |
VanessaE |
you can `//inspect on`, punch a node, and it'll identify as dirt |
04:41 |
hmmmm |
yes yes |
04:41 |
hmmmm |
but how do you know that the air has been replaced by ignore |
04:41 |
hmmmm |
it's literally impossible to tell that if you have noclip on |
04:41 |
hmmmm |
well aside from using mods |
04:42 |
VanessaE |
because I can also walk on the invisible nodes. |
04:42 |
VanessaE |
and dig and build normally. |
04:42 |
hmmmm |
yeah so like i said |
04:42 |
hmmmm |
this absolutely must be the result of a mod |
04:42 |
hmmmm |
there is just no way for the mapgen to place content ignore in place of air |
04:42 |
VanessaE |
but there;s no way for a mod to do so either |
04:42 |
hmmmm |
welp |
04:42 |
VanessaE |
the engine will throw an error |
04:43 |
hmmmm |
we have quite a connundrum |
04:43 |
VanessaE |
it'll expressly reject the placement of content_ignore |
04:43 |
hmmmm |
not if it's placed by voxelmanip |
04:44 |
VanessaE |
hm |
04:44 |
VanessaE |
well that at least leaves out anything I coded :) |
04:45 |
kaeza |
well, I have the same problem on my server |
04:45 |
kaeza |
https://dl.dropboxusercontent.com/u/100008207/screenshot_4191227949.jpg |
04:46 |
kaeza |
and I'm certain the only mod that uses VoxelManip is worldedit, and I haven't used it anywhere remotely near there |
04:47 |
kaeza |
the only mod I have * |
04:47 |
VanessaE |
in fact, worldedit can be used to replace the bad nodes with eg. mese blocks and then back to air |
04:48 |
VanessaE |
kaeza: btw when I was last up there, that node had taken on a solid block appearance |
04:48 |
VanessaE |
a \grey cube, as I recall |
04:48 |
kaeza |
O.o |
04:49 |
VanessaE |
hmmmm: so maybe calling it content_ignore is wrong, but I think air is, itself, being defined badly in those mapblocks.... but is it not impossible to redefine air?? |
04:49 |
hmmmm |
it's not |
04:49 |
hmmmm |
any way you look at this, it cannot be a problem concerning me |
04:50 |
VanessaE |
could you at least humor me and take a look around the affected area before I repair it? |
04:50 |
hmmmm |
not really going to help, I see what it is, but we need to know how it got there |
04:52 |
VanessaE |
what's the pattern to search my tree for, for vmanip? |
04:52 |
hmmmm |
write_to_map? |
04:52 |
VanessaE |
get_voxel_manip I guess |
04:52 |
VanessaE |
ok |
04:54 |
VanessaE |
only used by default, the technic force field generator (which can't have been used here, it needs an infrastructure that clearly is not here), and worldedit, which only cheapie and I have privs for. |
04:54 |
VanessaE |
http://pastebin.ubuntu.com/6701294/ |
04:54 |
VanessaE |
(don't mind the copy&paste error on line 1) |
04:55 |
VanessaE |
hmmmm: ok to clean up the "bad air" now? |
04:56 |
hmmmm |
yeah |
04:56 |
VanessaE |
ok |
05:04 |
* VanessaE |
waits for worldedit to finish |
05:05 |
VanessaE |
//pos1 //pos2 //replace air xxxxxx //replace xxxxxx air <--- where xxxxxx = something unique, in this case mese blocks. |
05:14 |
|
ImQ009 joined #minetest-dev |
05:18 |
|
darkrose joined #minetest-dev |
05:22 |
VanessaE |
^^^^^ was not enough. |
05:22 |
VanessaE |
the bad nodes are NOT air |
05:25 |
VanessaE |
what do I do now? |
05:27 |
VanessaE |
ok, I confirmed it |
05:27 |
VanessaE |
worldedit can match on "ignore" and that works. |
05:27 |
VanessaE |
//replace ignore air --> gives me back the visible landscape in the affected area |
05:29 |
VanessaE |
what I am seeing in the restored area is that the top surface is MISSING THE DIRT |
05:29 |
VanessaE |
except where it goes below the nominal top of the area, e.g. into a valley |
05:29 |
VanessaE |
there's dirt down there |
05:30 |
VanessaE |
in a minute or two I will post a screenshot of the area after restoring it |
05:33 |
VanessaE |
ok, there's nothing in this area at all that could have done it |
05:33 |
VanessaE |
it's totally barren except for some trees and a couple of white wool blocks |
05:33 |
VanessaE |
cheapie reports than he can /giveme ignore and ...it works? |
05:33 |
VanessaE |
this can't possibly be right |
05:33 |
VanessaE |
I can do the same, and I get an unknown item, "Ignore (you hacker, you!)" in the ivnentory |
05:33 |
hmmmm |
content_ignore is bliss. |
05:34 |
VanessaE |
lol |
05:34 |
VanessaE |
cheapie just tried to place one, the engine denies the action, as expected. |
05:55 |
|
darkrose joined #minetest-dev |
06:00 |
VanessaE |
ok |
06:00 |
VanessaE |
the affected area has been cleaned up. |
06:00 |
VanessaE |
there is literally nothing of interest here. |
06:01 |
VanessaE |
just stone, and now dirt (after repairing the landscape), no plantlife of any kind except a few ferns and default trees |
06:01 |
VanessaE |
so no mods could have done this |
06:02 |
VanessaE |
at least no third-party mods |
06:11 |
VanessaE |
meanwhile... WILL SOMEONE FIX THIS G*D DAMNED problem with wide/multi-byte chars? people writing in cyrliic et al. comes up as just plain blank in the chat, and "Character conversion failed!" in things like the IRC mod |
06:11 |
VanessaE |
whatever the problem is, for G*d sakes SHIT OR GET OFF THE POT with that |
06:16 |
hmmmm |
lol you're worried about multi-byte chars |
06:16 |
hmmmm |
I'm gonna have to be out in -12F degree weather |
06:16 |
hmmmm |
-35F with the windchill factor |
06:20 |
VanessaE |
... |
06:20 |
VanessaE |
you DO realize you just made my point for me, yes? |
06:21 |
VanessaE |
"lol, you're worried about easy thing X, I'm gonna have to do painful/hard thing Y"... |
06:22 |
VanessaE |
almost everyone has to deal with cold weather :P |
06:22 |
VanessaE |
inb4 xyz pops in and says that -35 is shorts-and-tshirt weather |
06:29 |
VanessaE |
well I guess it ain't blank in-game anymore, but still char conversion failed when it makes it to IRC. |
06:39 |
|
damiel joined #minetest-dev |
06:39 |
|
damiel joined #minetest-dev |
06:39 |
|
damiel joined #minetest-dev |
06:39 |
|
damiel joined #minetest-dev |
07:48 |
|
salamanderrake joined #minetest-dev |
07:48 |
|
nyuszika7h joined #minetest-dev |
07:53 |
|
mrtux joined #minetest-dev |
08:19 |
|
mrtux joined #minetest-dev |
09:39 |
|
NakedFury joined #minetest-dev |
09:47 |
|
Calinou joined #minetest-dev |
09:58 |
celeron55 |
i don't understand why all those unicode problems are just getting worse and never any better |
09:58 |
celeron55 |
there are so many non-english-speaking people here that i would think fixing them would happen at an instant |
09:59 |
celeron55 |
even while trying to figure out what the fuck is happening isn't the easiest thing in the world |
10:04 |
darkrose |
celeron55: my model lighting fix in classic works around Irrlicht's clone() not working: it puts a wrapper on the meshloader so a new mesh is loaded into memory, instead of cloned in memory |
10:05 |
celeron55 |
darkrose: can you point out some line numbers? |
10:06 |
darkrose |
https://gitorious.org/minetest-classic/minetest-classic/commit/81b22028e0b500c00150daf0d6ae7b8336b4946f is the commit for irrlicht 1.8 |
10:06 |
darkrose |
https://gitorious.org/minetest-classic/minetest-classic/commit/746fe606d4408b6e341f19445a38379642031d92 adds 1.7 support |
10:09 |
darkrose |
http://daffodil.ltmnet.com/player_light.png <- end result, 2 models with different lighting values |
10:27 |
celeron55 |
hmm, that 1.7 way relies on irrlicht reloading the data from disk by the file name |
10:27 |
celeron55 |
that can't be done in minetest 0.4 because it's manually inserted into the mesh cache when resources are loaded from the server |
10:28 |
celeron55 |
maybe i'll add storage of the mesh data and re-pull it from there |
10:28 |
celeron55 |
that would universally and forever work |
10:29 |
celeron55 |
oh, and what you do on 1.8 also relies on the file being available so that's the only way |
10:30 |
celeron55 |
well really, what i did in the patch is the alternative; it's ugly though |
10:45 |
|
jin_xi joined #minetest-dev |
11:12 |
celeron55 |
http://paste.ubuntu.com/6702580/ |
11:12 |
celeron55 |
this implements what minetest-classic does |
11:12 |
celeron55 |
i think this is pretty good |
11:14 |
|
ImQ009 joined #minetest-dev |
11:15 |
celeron55 |
i was thinking about caching some instances of the mesh, but it would need some kind of id allocation to know which ones are still used |
11:15 |
celeron55 |
hmm, or maybe that would be possible by playing with irrlicht refcounts |
11:16 |
celeron55 |
i'll note that in a comment but i think it's not needed for now |
11:16 |
darkrose |
looks good to me |
11:17 |
sfan5 |
if it works and is not too hacky why not commit and push right now |
11:18 |
celeron55 |
i will; i'm just looking for somebody having even better ideas |
11:26 |
celeron55 |
pushed |
11:27 |
VanessaE |
celeron55: sorry to get so upset earlier about the utf/multibyte stuff, it's just that even if I can't read it, it's better to see "foo bar did blah and such and such <some Cyrillic gibberish here>" than "Character conversion failed!" (thus losing the whole sentence) |
11:28 |
VanessaE |
and when you see it 10-15-20 times in a row when two people are talking you just wanna pull your hair out and shut the fucking server off :) |
11:28 |
xyz |
a friendly notice: we can't take any code from minetest-classic because it's licensed under gplv3 |
11:29 |
pitriss |
VanessaE: BTW: about that ignore blocks.. we have them on our private server mostly in dungeons (indev mapgen) |
11:29 |
darkrose |
xyz: you can't take it, but I can give it |
11:29 |
celeron55 |
xyz: didn't notice that, but also didn't take any |
11:29 |
VanessaE |
pitriss: regular mapblocks full of normal content except air had been replaced with ignore? |
11:30 |
xyz |
darkrose: well, yeah, just that it's not really convenient |
11:31 |
pitriss |
VanessaE: Nope it looks like stairs in dungeons are marked as ignore blocks.. (checked with improved tricorder mod) |
11:31 |
pitriss |
we didnt research it so much.. |
11:31 |
VanessaE |
pitriss: interesting. well, about the same effect - something that shouldn't be ignore became it. |
11:34 |
xyz |
VanessaE: cyrillic works fine for me |
11:34 |
pitriss |
VanessaE: yep.. |
11:34 |
VanessaE |
xyz: only an example language, and you don't use the IRC mod so you don't see the "other end" of that glitch |
11:34 |
xyz |
VanessaE: yes, I don't |
11:35 |
xyz |
VanessaE: has it ever worked in the IRC mod for you? |
11:35 |
VanessaE |
nope, because it has never worked right in the engine I guess. I am not too familiar with the details, ShadowNinja could explain it better. |
11:36 |
xyz |
I see |
11:36 |
VanessaE |
it happens a layer or two below Lua I guess |
11:36 |
xyz |
the thing is, my simple mod which connected xmpp with game chat has always worked flawlessly |
11:36 |
VanessaE |
(for lack of a better way to put it) |
11:38 |
* VanessaE |
shrugs |
11:38 |
VanessaE |
if he says it ain't anything he can fix as part of the mod, then I'm willing to accept that. |
11:39 |
pitriss |
xyz: can you point me to your xmpp connection mod? |
11:40 |
VanessaE |
xyz: of course, you're russian, and it stands to reason that you'd be using that as your locale, yes? so wouldn't you NOT need a char conversion then? |
11:42 |
VanessaE |
my point being, it could just as easily have been hebrew or japanese. hell even a spanish "ñ" is enough to trip it up |
11:42 |
VanessaE |
anything non-latin |
11:43 |
celeron55 |
it trips up with finnish ä and ö for me |
11:44 |
celeron55 |
i'm using en_DK.UTF-8 on this computer because it's the most convenient one (english language but nordic numbers, calendar and so) |
11:44 |
celeron55 |
(is nordic a word? well whatever) |
11:45 |
VanessaE |
yes |
11:46 |
celeron55 |
wait... actually, i think it doesn't really fail, maybe; it could be just a font issue altough i really don't know |
11:47 |
celeron55 |
oh no, it isn't a font issue; in the server list there is an <invalid multibyte string> server |
11:47 |
VanessaE |
ah yes |
11:48 |
VanessaE |
probably related |
11:48 |
VanessaE |
same happens in signs' infotext |
11:48 |
VanessaE |
something about a wide-to-narrow() call in the engine? |
11:48 |
VanessaE |
wish shadow were awake, he'd be able to explain it better. |
11:49 |
celeron55 |
the server list comes from the master server as utf-8 and then at some point is converted from it to irrlicht's wide string (which is some probably-partially-broken version of utf-16) |
11:49 |
celeron55 |
(like all utf-16 implementations are) |
11:56 |
|
rsiska joined #minetest-dev |
11:58 |
celeron55 |
https://github.com/minetest/minetest/pull/528 |
11:58 |
celeron55 |
so, this one merges fine currently; do we want it? |
11:58 |
xyz |
VanessaE: no, my locale has always been en_US.UTF-8 |
11:58 |
VanessaE |
celeron55: does a big bear shit in the woods? :) |
11:58 |
VanessaE |
<PilzAdam> no, not voxely enough. |
11:59 |
celeron55 |
it isn't compatible with current games that provide rail and looks like this with them: http://i.imgur.com/utfe2Gw.png |
11:59 |
celeron55 |
if it was, then it would be pretty good |
11:59 |
VanessaE |
interesting |
12:00 |
VanessaE |
hm |
12:02 |
xyz |
VanessaE: I just checked with this simple mod: http://pastebin.com/raw.php?i=1tSYTGSf and it works fine in current master |
12:06 |
VanessaE |
well I dunno |
12:06 |
Taoki |
celeron55: Oh... what is your take on this? https://github.com/minetest/minetest_game/pull/232 Probably not, but still asking :P |
12:21 |
celeron55 |
the same as PilzAdam's |
12:22 |
|
iqualfragile joined #minetest-dev |
12:23 |
celeron55 |
especially as that will interfere with many mods that do something with formspecs |
12:24 |
celeron55 |
minetest_game's only purpose now is to serve as a base for people who like to mod the hell out of something |
12:24 |
VanessaE |
celeron55: 4x4/5x5 should be included by default *as separate workbenches* that one could place and use, but don't touch the default inventory formspec at all. |
12:25 |
VanessaE |
without including them, no modder eill ever bother supporting larger recipes. |
12:25 |
VanessaE |
will* |
12:25 |
celeron55 |
that might be okay |
12:25 |
celeron55 |
it serves that purpose at least |
12:29 |
Taoki |
celeron55: Yeah, until I spoke with PilzAdam I didn't know the purpose of minetest_game is mostly to serve as a base, rather than becoming an own game with a lot of stuff like I thought. On one side it's better for it to be a framework... but unless there's also a large and full game by default, Minetest might not get even further as it could |
12:31 |
Taoki |
celeron55: Oh, and I had another idea I wanted to bring up regarding that. What do you think about making each mod included with a game possible to disable? The same way mods can be turned on or off, but also for the default mods in minetest_game. This would allow it to include certein default components, but they could be disabled if a server wants to use a custom mod for that |
12:32 |
Taoki |
So for example, it could have a default workbench system, but if a server installs its own the one in minetest_game can be disabled. Same for mobs as another example... we could include PilzAdam's simple mobs (which are safe and work fine) and if someone else wants to use another mob mod, they can disable the mobs in minetest_game and use that |
12:33 |
Taoki |
This could allow minetest_game to be both a framework as well as a full game with a lot of defaults. And the ability to turn components inside a game on or off just like mods would be great anyway IMO |
12:34 |
proller |
mobs - fine?? |
12:35 |
celeron55 |
Taoki: minetest_game will be replaced by other games when we get our lazy asses to actually doing it |
12:35 |
celeron55 |
or just left there with them, whatever |
12:35 |
Taoki |
nice |
12:35 |
Taoki |
celeron55: Anyway, please consider coding a menu where not only mods can be disabled, but also "mods" included inside the game. Like minetest_game has default, buckets, fire, etc. This could allow for a lot more customization |
12:36 |
celeron55 |
why do you expect me to code that |
12:36 |
Taoki |
Even better, mods that are part of a game could have a setting which indicates whether they can be disabled or not |
12:36 |
Taoki |
Since eg: You can't disable "default" :) |
12:36 |
celeron55 |
(i won't) |
12:36 |
Taoki |
Not expect... just suggesting it, since I think it would be a great ability |
12:36 |
Taoki |
ok |
12:36 |
Taoki |
Maybe someone else can, I should probably post about it |
12:37 |
Taoki |
It's prolly a small change, but someone more familiar with that area of code should look at it. Hopefully some dev will |
12:37 |
|
iqualfragile joined #minetest-dev |
12:50 |
|
sapier joined #minetest-dev |
12:52 |
sapier |
https://github.com/minetest/minetest/pull/1090 is backported from current multiprotocol branch removing alll except legacy protocol, it doesn't contain any known (protocol) errors so please test and find them prior we merge it |
12:52 |
sapier |
celeron55 fix for the hang is in here: https://github.com/minetest/minetest/pull/1054 |
12:59 |
celeron55 |
you should rename removeAVG and removeADD to removeAvg and removeAdd |
12:59 |
celeron55 |
that's how our naming convention goes (when remove is prepended to add() and avg()) |
13:00 |
proller |
and better to make one universal avg/add/max/min counter |
13:00 |
|
iqualfragile joined #minetest-dev |
13:00 |
celeron55 |
ehm, this commit isn't about improving the profiler |
13:01 |
celeron55 |
stop suggesting random unrelated things |
13:01 |
proller |
unrelated to minetest? |
13:02 |
celeron55 |
unrelated to fixing the protocol and some hangs |
13:12 |
|
iqualfragile joined #minetest-dev |
13:25 |
|
hmmmm joined #minetest-dev |
13:25 |
kahrl |
sapier: is there any reason you do iter = find(key) and then erase(iter), instead of simply erase(key)? |
13:26 |
kahrl |
sapier: and shouldn't removeAVG/removeAvg erase from m_data too? |
13:27 |
kahrl |
actually why not one remove() that erases from m_avgcounts and m_data? |
13:30 |
celeron55 |
what would people think of: http://paste.ubuntu.com/6703182/ |
13:31 |
celeron55 |
as a generic and simple answer to this https://github.com/minetest/minetest/pull/237 |
13:31 |
celeron55 |
the defaults are very arguable |
13:32 |
sapier |
kahrl where exactly are you right now? |
13:33 |
sapier |
oh the profiler changes |
13:35 |
sapier |
if remove(key) works I guess it's better, to be honest I didn't think that much about those changes, we don't even need to add it for protocol fixing |
13:36 |
sapier |
I thought m_data and m_avgcounts are independent? aren't they? |
13:38 |
sapier |
pause menu and mainmenu are different things celeron |
13:38 |
celeron55 |
sapier: and? mainmenu doesn't have CPU hogging issues |
13:39 |
sapier |
forget about it misread menu_fps_max as "mainmenu_fps_max" |
13:43 |
celeron55 |
i don't like this patch either though; people could just quit the game and open it again |
13:43 |
celeron55 |
or that's what i do |
13:44 |
sapier |
I don't really understand that issue, in pause menu shouldn't be any more cpu used then in game? am I wrong about that? |
13:45 |
celeron55 |
that's the issue |
13:45 |
celeron55 |
same usage as in game |
13:45 |
celeron55 |
somebody apparently expects it to have something else |
13:46 |
sapier |
strange it's exactly what I'd expect it to be as it's not really a "pause" maybe we should rename it ;-) |
13:46 |
Exio4 |
people excepts to pause the whole game (in singleplayer) when they open the pause menu |
13:47 |
celeron55 |
bah, well i'll do that |
13:49 |
sapier |
renaming will fix the next issue "Game is not paused when in pause menu" ;-) |
13:50 |
celeron55 |
i'll make it pause singleplayer and i'll also make it the only menu affected by extra fps limit |
13:53 |
|
jin_xi joined #minetest-dev |
13:53 |
sapier |
hmm for some reason enet claims to have no jitter at all ... not sure if it's wise to trust it's rtt calculations |
13:54 |
|
EvergreenTree joined #minetest-dev |
13:54 |
|
EvergreenTree joined #minetest-dev |
13:54 |
kahrl |
sapier: avg() stores the sum in m_data and the count in m_avgcounts |
13:59 |
sapier |
hmm obviously both do so a single "remove" function should be enough |
14:06 |
celeron55 |
well crap, if i don't stop irrlicht's timer, animations continue running, and if i do, all the timing-related code stops working (which isn't a problem in itself but that makes all profiler and other debug stuff show useless data) |
14:07 |
celeron55 |
i think i'll let animations run 8) |
14:08 |
celeron55 |
it's nice to get proper timing diagnostics at the paused state |
14:11 |
sapier |
https://github.com/sapier/minetest/commit/53491d06d3bfc9915c75c79682b77d811acecfe6 kahrl better this way? |
14:12 |
kahrl |
sapier: yeah |
14:12 |
sapier |
ok now the more complicated task ... replacing a commit in middle of a branch :-) |
14:13 |
kahrl |
that's always fun |
14:13 |
kahrl |
well you can push that commit to master imho |
14:14 |
celeron55 |
it's fun because git is good at doing it |
14:14 |
kahrl |
do we care about std::string parameters as opposed to const std::string&? |
14:14 |
kahrl |
looks like the other Profiler functions use const std::string& |
14:17 |
sapier |
fixed |
14:17 |
celeron55 |
http://paste.ubuntu.com/6703386/ |
14:18 |
celeron55 |
(the comments on the setting are wrong) |
14:18 |
celeron55 |
i sure hope there aren't people who want single-player game to run while being in the pause menu |
14:19 |
sapier |
I'm sure there are but I don't care about them ;-) |
14:20 |
kahrl |
(insert link to "workflow" xkcd here) |
14:20 |
sapier |
as cutting a commit is way more easy then replacing it I push the profiler fix if you agree to it kahrl? |
14:20 |
kahrl |
sure |
14:26 |
sapier |
pushing now |
14:31 |
kahrl |
what should we do with those XDG things? (#864, #395) |
14:31 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/395 -- HTTP Error 404: Not Found |
14:32 |
kahrl |
neither of those explains *why*, so simply wontfix? |
14:32 |
Exio4 |
#864 |
14:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/864 -- XDG Base Directory Specs |
14:34 |
sapier |
I guess the "why" is because its a standard ... ok there are plenty of standards out there ... don't we have a "low prio improvemen" flag? ;-) |
14:35 |
kahrl |
yeah but I'd like to get the open issues in my section close to 0 ;) |
14:35 |
sapier |
imho we already have enough trouble with where to find what |
14:35 |
sapier |
but if you have 0 you don't have any work left and have to find new work ;-) |
14:36 |
kahrl |
maybe I could rewrite the core in UPPERCASE as was requested in #minetest |
14:38 |
sapier |
you're kidding? is there really anyone suggesting this? |
14:38 |
jin_xi |
SURE |
14:38 |
sapier |
guess we don't have any real problems left ;-) |
14:39 |
sapier |
ok I pushed that branch half an hour ago and already have to rebase it .... guess I should talk to sapier not to always break my branches ;-) |
14:43 |
sapier |
https://github.com/minetest/minetest/pull/1067 kahrl is right about the fact that using a lock will use additional cpu power, but I don't se any chance to safely use shared buffers from different threads without it |
14:48 |
celeron55 |
kahrl: does XDG specify how to migrate from a non-XDG directory to an XDG one? |
14:48 |
celeron55 |
if not, then we can just drop it 8) |
14:49 |
celeron55 |
well okay, that doesn't matter; but that's probably one of the most arguable things ever |
14:50 |
celeron55 |
i'd prefer not changing our directories |
14:50 |
celeron55 |
there's no real problem in them at the moment |
14:50 |
celeron55 |
and changing them just means we have to support one structure more |
14:52 |
kahrl |
I've left a comment in each issue, if there's no response in the next weeks I'll close them |
14:52 |
celeron55 |
there's a difference between crappy configuration directories, and for me that limit is the difference between ~/.minetest/whatever and ~/minetest/whatever |
14:52 |
|
smoke_fumus joined #minetest-dev |
14:53 |
celeron55 |
(being that the second one would be crappy) |
14:53 |
celeron55 |
>50% of the software out there uses a scheme like this in any case and it works |
14:54 |
kahrl |
indeed, and this whole XDG thing just means I suddenly am lost why program foo doesn't store its configuration in ~/.foo |
14:54 |
kahrl |
then I remember "oh, maybe it's one of those few that use .config" |
14:55 |
kahrl |
standards are great, especially when there's lots of them |
14:56 |
celeron55 |
the issue was about considering it, so it's now considered and done 8) |
15:09 |
Taoki |
Someone please merge this: https://github.com/minetest/minetest_game/pull/234 VanessaE found a bug with the character animations and I just fixed it |
15:10 |
Taoki |
I tested and it works fine, but if anyone's unsafe feel free to test it as well. It simply fixes the feet sliding over the ground during standing due to bad keyframe blending |
15:11 |
|
Yepoleb joined #minetest-dev |
15:22 |
Ritchie |
xyz: did you release your xmpp mod for minetest? |
15:50 |
|
Zeitgeist_ joined #minetest-dev |
15:50 |
|
Zeitgeist_ joined #minetest-dev |
15:57 |
|
Calinou joined #minetest-dev |
16:00 |
|
john_minetest joined #minetest-dev |
16:07 |
|
Jordach joined #minetest-dev |
16:12 |
|
kaeza joined #minetest-dev |
16:14 |
sapier |
actually storing mods and texture packs in >>.config<</minetest seems a little bit weird to me too. a mod isn't a config |
16:17 |
celeron55 |
it wouldn't all go to .config |
16:18 |
sapier |
not? ... one more reason not to do it :-) |
16:18 |
celeron55 |
there's for example ~/.local/share for mod-like stuff and ~/.cache for caches |
16:18 |
VanessaE |
Oh G*d no |
16:18 |
celeron55 |
i would all spread around |
16:19 |
VanessaE |
the person who came up with that scheme should be shot, raked over hot coals, dragged behind a truck, keel-hauled, drawn and quartered, and then really REALLY hurt. |
16:19 |
sapier |
I change my oppinion from "some later time" to "NEVER EVER" ;-) |
16:19 |
celeron55 |
minetest is really an environment in itself; those are more suitable for some commodity desktop applications that want to store some settings like some calculator or other useless thing |
16:20 |
celeron55 |
that nobody even expects to store anything |
16:20 |
celeron55 |
altough, that xdg stuff is very friendly to backing up stuff |
16:21 |
celeron55 |
just take the .config and maybe .local/share if you want more, and leave .cache behind; same goes for networked storage and whatever |
16:21 |
celeron55 |
and other things that have use for knowing what the data is |
16:22 |
celeron55 |
if you now backup .minetest, you get infinite amount of stuff you don't want |
16:22 |
sapier |
the other way round it's quite unfriendly to remove all things :-) "rm -r .minetest" is way more simple then looking everywhere |
16:22 |
celeron55 |
yeah, for that it's hard |
16:22 |
sapier |
and another question why would someone backup application data but not his own personal data? |
16:23 |
celeron55 |
altough you really don't care; if you want to clear config, then .config/minetest; if you want to save space, take the cache of every program; if you want to copy minetest's data, take .local/share/minetest |
16:23 |
celeron55 |
you rarely actually want to do all three except as a developer |
16:23 |
celeron55 |
sapier: why would someone backup a cache? |
16:24 |
sapier |
to not have to download it next time? ;-) .... yes I know quite constructed usecase |
16:24 |
celeron55 |
anyway really any backup script should ignore any directory called "cache" anyway |
16:25 |
celeron55 |
none of them are probably useful 8) |
16:25 |
sapier |
hmm maybe but you can argue about beeing wise to rely on others to use correct naming |
16:25 |
celeron55 |
of course some people would say nevere ignore anything; i guess they have infinite disk spaace and bandwidth |
16:25 |
celeron55 |
-e |
16:27 |
celeron55 |
i would actually think we could put a globally installed minetest's cache in ~/.cache/minetest |
16:27 |
celeron55 |
all the others are best kept in ~/.minetest |
16:28 |
|
Jordach joined #minetest-dev |
16:29 |
sapier |
hmm what about using /tmp/.minetest for caching? of course we might risk hash collisions for media if two players at same pc start at least two games same time |
16:29 |
sapier |
ok tmp is cleared on reboot at lots of distibutions |
16:30 |
VanessaE |
sapier: initial impression with your latest code: map doesn't seem to be too keep to load sometimes, yet chat will be instantaneous at the same time. |
16:30 |
VanessaE |
s/keep/keen/ |
16:31 |
sapier |
ok I'm gonna compare it to the last version you tried I'd expected it to be functional identical |
16:35 |
celeron55 |
tmp isn't good because of exactly that |
16:36 |
Exio4 |
lets use user's ~/tmp! |
16:39 |
celeron55 |
and cache isn't temporary data anyway; it's a separate thing |
16:41 |
sapier |
yes you're right there's a small but important difference |
16:43 |
|
iqualfragile joined #minetest-dev |
16:43 |
xyz |
Ritchie: nope |
16:45 |
Ritchie |
xyz: will you release it someday? |
16:46 |
xyz |
hasg collisions my ass, are you even trying? |
16:46 |
xyz |
Ritchie: probably not |
17:10 |
|
PilzAdam joined #minetest-dev |
17:12 |
iqualfragile |
that character conversion error still exists, can somebody tell me how to fix it (when a message contains äüö and similar the server just prints character conversion failed instead of displaying the string) |
17:19 |
VanessaE |
where do you see that come up at? I only ever see it via the IRC mod |
17:23 |
iqualfragile |
in the server log |
17:26 |
VanessaE |
ah |
17:26 |
|
Akien joined #minetest-dev |
17:28 |
|
rubenwardy joined #minetest-dev |
17:30 |
|
iqualfragile joined #minetest-dev |
17:34 |
|
EvergreenTree joined #minetest-dev |
17:34 |
|
EvergreenTree joined #minetest-dev |
17:36 |
PilzAdam |
celeron55, your commit that fixes the model brighness doesnt fix the bone positions (#1091) |
17:37 |
xyz |
iqualfragile: enable gettext |
17:37 |
iqualfragile |
xyz: how |
17:37 |
xyz |
cmake -DENABLE_GETTEXT=1 |
17:37 |
iqualfragile |
k |
17:38 |
Ritchie |
iqualfragile: or you can use ccmake |
17:38 |
Ritchie |
run in console: ccmake . |
17:39 |
celeron55 |
wait what |
17:39 |
celeron55 |
enabling gettext fixes it for me too |
17:39 |
celeron55 |
why is it broken without gettext? |
17:39 |
celeron55 |
it definitely shouldn't be |
17:40 |
celeron55 |
and also gettext should be enabled by default if it's found |
17:40 |
xyz |
it works like that after latest windows-related locale fixes |
17:41 |
celeron55 |
well this sucks, i'm fixing it now, prepare to test |
17:42 |
VanessaE |
why is gettext even disabled at all? |
17:43 |
iqualfragile |
i am running debian |
17:44 |
xyz |
doesn't matter |
17:46 |
iqualfragile |
seems not to work with gettext either… |
17:46 |
iqualfragile |
cmake . -DENABLE_GETTEXT=1 -DRUN_IN_PLACE=1 -DENABLE_SOUND=0 -DBUILD_CLIENT=0 -DCMAKE_BUILD_TYPE=Release |
17:49 |
xyz |
then something other is wrong, I've tested with gettext enabled and disabled and it solves the issue |
17:50 |
iqualfragile |
nope, not working |
17:50 |
celeron55 |
http://paste.ubuntu.com/6704413/ |
17:50 |
celeron55 |
this appears to fix it on linux when gettext isn't used |
17:51 |
celeron55 |
and it doesn't do anything too problem-prone so with a little testing we can be confident that it works |
17:52 |
PilzAdam |
celeron55, http://mg.viewskew.com/mgoblin_media/media_entries/512/ErrorDialogBug.png |
17:53 |
PilzAdam |
has 86c616a545efcc8ed8487440d686a17358170756 broken this? |
17:53 |
celeron55 |
did it work in the first place? |
17:54 |
celeron55 |
if that traceback ends up in the formspec unescaped, it has a [C] which could mess it up |
17:54 |
PilzAdam |
it was also empty before 86c616a545efcc8ed8487440d686a17358170756 |
17:55 |
celeron55 |
try adding escaping to it |
17:56 |
PilzAdam |
escaping fixes it |
17:57 |
celeron55 |
take a screenshot so we can enjoy the fixed error dialog! |
17:57 |
PilzAdam |
can I push this? https://gist.github.com/PilzAdam/8286684 |
17:57 |
|
iqualfragile joined #minetest-dev |
17:57 |
celeron55 |
yes |
17:58 |
PilzAdam |
http://mg.viewskew.com/mgoblin_media/media_entries/513/WorkingErrorDialog.png |
17:59 |
celeron55 |
well... it clearly could work better, probably by increasing the defined textarea size in the formspec |
18:03 |
|
iqualfragile joined #minetest-dev |
18:15 |
celeron55 |
iqualfragile: did you try my patch? |
18:16 |
iqualfragile |
celeron55: not yet |
18:32 |
celeron55 |
sapier: i think instead of adding a mutex to SharedBuffer a UniqueBuffer should be implemented and used instead |
18:32 |
celeron55 |
which could be owned by one thing at a time and always would invalidate the previous reference |
18:33 |
celeron55 |
also SharedBuffer works fine there as-is assuming it's used like a UniqueBuffer |
18:33 |
celeron55 |
the mutex in there is unacceptable |
18:34 |
celeron55 |
we don't add mutexes to any data structures that aren't specifically designed to be thread-safe and from which you can't tell the overhead from the name |
18:36 |
sapier |
the buffer can't be "owned" by a single thread without passing it from one to another everytime. the situation where this might cause errors is when a packet is acknowledged parallel to it's resend beeing done |
18:37 |
celeron55 |
hmm, actually that's true because of the refcount |
18:37 |
celeron55 |
so UniqueBuffer is needed which always has only a single reference |
18:37 |
celeron55 |
...i think |
18:38 |
sapier |
is shared buffer used somewhere else? |
18:39 |
celeron55 |
by the way, isn't copying the data usually cheaper than managing a mutex? |
18:39 |
celeron55 |
for UDP packets like that |
18:39 |
sapier |
because I'd like to try not to copy packet data if not absolutely required ... it's already to much copying |
18:39 |
sapier |
depends on packet size |
18:39 |
celeron55 |
well a benchmark would be very useful |
18:39 |
sapier |
ok we have 512 max right now |
18:40 |
sapier |
true I can't tell for sure what will be more heavy |
18:42 |
celeron55 |
but... wait |
18:42 |
celeron55 |
how is the data transferred between threads |
18:42 |
celeron55 |
the data structure there for sure is thread-safe |
18:43 |
celeron55 |
which means the SharedBuffer copy contstructors and assignments and destructors are always atomically executed |
18:43 |
sapier |
yes |
18:43 |
celeron55 |
so there is no problem at all even now? |
18:43 |
celeron55 |
so you shouldn't add a mutex in SharedBuffer and nowhere else either |
18:43 |
sapier |
the problem is once the data is take from it |
18:44 |
sapier |
e.g. if we're about to send it and in parallel the incoming ack is removing it |
18:45 |
celeron55 |
are you sure this threading is going to help at all in performance |
18:45 |
celeron55 |
instead of consuming X% of one core it will consume X% of each N cores |
18:45 |
celeron55 |
with same throughput |
18:45 |
sapier |
wait you're right getTimedOuts does this with list locked |
18:46 |
sapier |
so reference counting should already have been done |
18:47 |
sapier |
threading is just uncoupling things that shouldn't be coupled |
18:47 |
sapier |
usually the receive thread is blocked using no cpu at all |
18:47 |
sapier |
in a single thread I have to check for incoming packets in each loop no matter if there is anything |
18:48 |
sapier |
without need for stopping a thread I could even block send thread until something needs to be sent |
18:48 |
sapier |
thinking about it ... I guess I don't even need to loop the send threa |
18:48 |
sapier |
d |
18:48 |
celeron55 |
today's way of doing things is light event-based systems! |
18:49 |
sapier |
waiting at a semaphore is basicaly waiting for an event |
18:49 |
celeron55 |
anyway whatever, as long as it works and you maintain it, there is no problem 8) |
18:50 |
|
iqualfragile joined #minetest-dev |
18:51 |
sapier |
that's why I need two threads, or does anyone have an Idea how to wait for two semaphores without implementing some kind of mailbox system? ;-) |
18:51 |
celeron55 |
well if by mailbox you mean an event system, that's the way |
18:51 |
celeron55 |
but let's not do that now |
18:52 |
sapier |
yes I gues it's just different wording same thing |
18:52 |
sapier |
but we're drifting away from original topic the sharedbuffer |
18:52 |
celeron55 |
(meaning you just put everything that can possibly happen behind one semaphore) |
18:52 |
celeron55 |
(or something like that maybe) |
18:52 |
celeron55 |
so is there an issue with current SharedBuffer? |
18:53 |
sapier |
yes that's what I meant passing some form of message containing information what happened |
18:53 |
sapier |
I guess right now we don't need the mutex |
18:53 |
celeron55 |
good, let's maintain that situation because mutexes in generic data structures are a performance issue |
18:53 |
sapier |
but it's dangerous, if someone isn't carefull this will cause strange, hard to find errors |
18:54 |
celeron55 |
we can't redefine every data type to have a mutex |
18:54 |
celeron55 |
it just will jag down the whole system |
18:54 |
celeron55 |
instead it needs to be designed to not have to rely on everything having a mutex |
18:55 |
sapier |
you're right about this but at least I'd interpret "sharedbuffer" as safe datatype ... which it obviously isn't |
18:55 |
celeron55 |
ThreadSharedBuffer 8) |
18:55 |
sapier |
*smile* //ThreadSharedBuffer //TODO implement :-) |
18:56 |
sapier |
ok I'm gonna remove this commit from the udp fixes, guess we will see if I was wrong about "it should work without" |
18:56 |
celeron55 |
this network_fixes_udp_1 hangs at shutdown |
18:56 |
celeron55 |
i guess the fix wasn't in here |
18:57 |
sapier |
it should've been there (unless I merged wrong commit) |
18:57 |
sapier |
no yesterdays fix is in there |
18:58 |
sapier |
another lockup? |
18:58 |
celeron55 |
hmm, now it doesn't seem to |
18:58 |
celeron55 |
maybe it's a way rarer one or something; whatever let's not care now |
18:58 |
sapier |
sounds like another situation we haven't seen by now |
19:00 |
sapier |
talking about locks and performance, I added a lock around log in this branch too ... that one fixes the crashes people compained about when doing chat too |
19:00 |
sapier |
had them quite often when sending connection log to in game chat :-) |
19:02 |
celeron55 |
locked again |
19:02 |
celeron55 |
release backtrace: http://paste.ubuntu.com/6704810/ |
19:03 |
|
iqualfragile joined #minetest-dev |
19:03 |
celeron55 |
so Connection joins it's threads in ~Client and stops there |
19:03 |
sapier |
ok that is connection related now |
19:04 |
celeron55 |
btw, why does this take a constant few seconds to connect now? |
19:04 |
celeron55 |
doesn't seem right |
19:05 |
celeron55 |
delays like that always smell bad |
19:05 |
sapier |
this happens to you too? I thought this was a effect of vanessae's huge game I'm looking for it |
19:06 |
celeron55 |
this is nodetopia, which has like 50 items total |
19:07 |
sapier |
ok this is suspicious, but one by one |
19:07 |
celeron55 |
maybe the send window is too shy |
19:07 |
celeron55 |
it seems to start transferring data immediately but ramps up like a grandma |
19:08 |
sapier |
slow start with fast speedup ... maybe to slow |
19:08 |
celeron55 |
then it suddenly spikes |
19:08 |
celeron55 |
after some seconds |
19:08 |
sapier |
3 seconds are max packet timeout |
19:09 |
celeron55 |
it takes 3 seconds |
19:09 |
sapier |
ok so we wait for a packet to timeout |
19:09 |
sapier |
does client connect prior server is ready to receive? |
19:09 |
celeron55 |
it's a singleplayer game, so maybe |
19:09 |
|
Miner_48er joined #minetest-dev |
19:10 |
sapier |
I don't se a way how destructor can hang in wait |
19:10 |
sapier |
connection destructor |
19:13 |
sapier |
wait there it is |
19:14 |
sapier |
but there have to be two issues as neither send nor receive threads seem to close in your case |
19:14 |
|
iqualfragile joined #minetest-dev |
19:14 |
celeron55 |
http://paste.ubuntu.com/6704867/ |
19:14 |
celeron55 |
with this it connects immediately |
19:14 |
celeron55 |
it doesn't if the server step is removed, and doesn't if the sleep is removed |
19:15 |
sapier |
so it's a combination of both, server not having done initial steps and not enough time to get ready for reception |
19:21 |
celeron55 |
well how about not making server->start() return before it's actually ready? |
19:21 |
celeron55 |
that's kind of what the function is supposed to do |
19:21 |
sapier |
requires adding synchornization |
19:21 |
sapier |
guess it'd not be that much work |
19:22 |
celeron55 |
add the sleep inside it 8) |
19:22 |
sapier |
lol that's dirty ;-) |
19:23 |
celeron55 |
why is the step() needed? that at least shouldn't be |
19:24 |
sapier |
server.cpp L1003 really this step? |
19:25 |
celeron55 |
yes |
19:25 |
sapier |
you could try 0.0011 :-) |
19:25 |
celeron55 |
it makes Server::AsyncRunStep do stuff |
19:25 |
sapier |
AsyncRunStep() doesn't do anything without a dtime > 0.001 |
19:26 |
celeron55 |
well that's why it isn't 0 |
19:26 |
sapier |
seems like something in there is responsible for the "not hang" |
19:27 |
celeron55 |
the question is, should i add that hack to game.cpp or do you fix this in the server |
19:27 |
sapier |
I'd prefere to fix it in server |
19:28 |
sapier |
imho it's not as critical as requireing a immediate hack solution |
19:28 |
celeron55 |
i don't like waiting unnecessary seconds |
19:28 |
celeron55 |
when i don't have to |
19:28 |
celeron55 |
getting into game during development is like the most common thing to do |
19:28 |
sapier |
me to but some seconds don't justify a ugly hack beeing in there for forever ;-) |
19:29 |
celeron55 |
doesn't matter; having headache because of not seeing results immediately justifies it |
19:31 |
sapier |
ok ;-) I'm gonna fix server |
19:31 |
sapier |
I found a possible reason for the hang, but as of your backtrace there might be a second one |
19:32 |
sapier |
but I'm not sure about it |
19:34 |
|
rubenwardy joined #minetest-dev |
19:34 |
celeron55 |
do you really not get a hang ever if you continuously start and stop a singleplayer game? |
19:35 |
sapier |
I didn't try 100 times but doing it 10-20 times I haven't seen it a single time |
19:35 |
celeron55 |
use a lightweight game in it like minimal so it doesn't do much loading |
19:35 |
sapier |
I even tried minimal |
19:36 |
sapier |
I'm talking about the close hang |
19:36 |
sapier |
I can reproduce the startup hang |
19:36 |
sapier |
those 3s |
19:36 |
sapier |
I've got only a phenom 2 X4 ;-) quite old machine |
19:37 |
celeron55 |
http://paste.ubuntu.com/6705020/ |
19:37 |
celeron55 |
putting this in your minetest.conf will probably help |
19:38 |
celeron55 |
it's the default settings i have proposed and will add upstream once this udp improvement is in |
19:38 |
sapier |
ok I try |
19:38 |
sapier |
I pushed the one fix I already did to my pull request |
19:39 |
celeron55 |
oh, 20 isn't a default setting |
19:39 |
celeron55 |
that'll be handled differently, but anyway |
19:41 |
sapier |
either thos changes are crucial or I just had luck this time, first try and it's hanging |
19:41 |
celeron55 |
good 8) |
19:42 |
celeron55 |
it puts stuff much more aggressively through the network so the connection doesn't just idle 99% of the time |
19:42 |
sapier |
using something usually causes bugs to show up :) |
19:43 |
sapier |
seems to be a bug in jthread those threads aren't even requested to stop |
19:44 |
celeron55 |
lol, how can it be still broken |
19:44 |
sapier |
no idea :-) all I see is client is waiting for some thread to be stopped, that one is requested to stop but the connection threads aren't requested to stop |
19:45 |
sapier |
that's crazy ... something is completely wrong here |
19:48 |
sapier |
I'd not recommend to use the old variant right now I'm fixing bugs in udp right now which are necessary there too |
19:54 |
sapier |
ok I was wrong it's not hanging forever just until peer times out |
19:56 |
sapier |
it's opposit of startup hang, client tries to send it's disconnect reliable to server but server doesn't answer anymore |
19:57 |
celeron55 |
the disconnect shouldn't be reliable |
19:57 |
celeron55 |
or maybe it should be some kind of two-tries-reliable |
19:57 |
celeron55 |
or something; nobody wants to wait it anyway |
19:58 |
celeron55 |
and nobody should need to wait it |
19:58 |
proller |
https://github.com/minetest/minetest/pull/1087/files |
19:58 |
sapier |
problem is a disconnect is passed through upper layers, so I don't know a message to be a disconnect or not |
19:58 |
|
khonkhortisan joined #minetest-dev |
19:58 |
celeron55 |
hmm |
19:59 |
sapier |
of course I could bypass regular mechanisms but that's quite ugly and hard to maintain |
20:00 |
celeron55 |
i guess the singleplayer server could be waited to have all clients disconnected before it's destructed |
20:00 |
sapier |
i'll have a look where this is done |
20:00 |
celeron55 |
but that would still unnecessarily effectively hang in buggy situations |
20:01 |
sapier |
that's a basic issue with sever/client concept you have to use timeouts ... this works here to just causes waiting |
20:01 |
celeron55 |
why not just make the client send like three unreliable packets at 100ms intervals and hope that some of them get through? 8) |
20:01 |
sapier |
I don't know if there are other unreliables queued in front of the disconnects |
20:02 |
sapier |
I did a immediate shutdown in a earlier version ... logout was fast ... but you had to wait for server timeout to join again ;-) |
20:03 |
sapier |
maybe I can wait for unreliables to be sent on disconnect only |
20:04 |
sapier |
quite strange to ensure unreliables to be sent but ignore reliables ;-) |
20:13 |
|
NakedFury joined #minetest-dev |
20:18 |
sapier |
ok I need to fix the startup 3s hang first but right after that I'm going to push new tcp version |
20:21 |
sapier |
lol start isn't even called while hanging |
20:28 |
|
werwerwer_ joined #minetest-dev |
20:34 |
sapier |
celeron55 could you check how much textures are within your textures/server folder? |
20:34 |
celeron55 |
what folder? |
20:34 |
sapier |
minetest/textures/server |
20:35 |
celeron55 |
there's no such directory |
20:35 |
sapier |
ok it's an optional folder ... so I can't reproduce the startup hang too |
20:35 |
sapier |
I had 170 mb textures in there causing server creation to be quite slow |
20:38 |
sapier |
I made server to do a initial async step prior confirming server thread to be ready could you try if this is working for you too? |
20:40 |
celeron55 |
diff? |
20:40 |
sapier |
pushed to the pull |
20:41 |
sapier |
oops |
20:41 |
sapier |
now |
20:43 |
celeron55 |
sapier/network_fixes_udp_1 |
20:45 |
celeron55 |
it seems to quite reliably hang at singleplayer shutdown |
20:45 |
celeron55 |
for the disconnect timeout |
20:46 |
celeron55 |
the initial delay is gone though |
20:47 |
daswort |
hi i had to reinstall and recompile the dev version on my new 64bit computer. but know it looks like it cant find the minetest_game |
20:49 |
daswort |
here my dir structure: https://dpaste.de/NqmM |
20:49 |
celeron55 |
the game isn't in games/ |
20:50 |
daswort |
thanks. is that new? |
20:51 |
daswort |
oh i see it is not :( |
20:51 |
celeron55 |
not the hardest of today's development questions 8) |
20:56 |
|
rubenwardy joined #minetest-dev |
21:02 |
|
sapier joined #minetest-dev |
21:03 |
sapier |
oops :-) have been disconnected without knowing ... ok so server startup fixes work (without sleep) but sending unreliables only doesn't work |
21:06 |
|
rubenwardy1 joined #minetest-dev |
21:18 |
celeron55 |
some backtrace: http://paste.ubuntu.com/6705558/ |
21:19 |
celeron55 |
it doesn't happen all the time |
21:22 |
sapier |
hmm actually that one was supposed to be fixed :-( |
21:22 |
|
rubenwardy joined #minetest-dev |
21:22 |
sapier |
ok |
21:32 |
sapier |
ok I pushed a fix sending all non reliable packets immediatly if thread stop is requested but I still don't se a actual reason for this to hang at all |
21:34 |
|
xrogaan joined #minetest-dev |
21:49 |
|
rubenwardy1 joined #minetest-dev |
21:55 |
ShadowNinja |
kahrl: This is the tcpdump log of a server starting up and anouncing on master: http://paste.ubuntu.com/6705725/ (Nothing) |
21:57 |
proller |
ShadowNinja, solved here - https://github.com/minetest/minetest/pull/1087/files |
21:57 |
proller |
your get query longer than X |
21:58 |
|
rubenwardy joined #minetest-dev |
21:58 |
ShadowNinja |
proller: Why would you ever send that as GET? |
21:58 |
ShadowNinja |
And that commit obviously can't be used as it has other things mixed in, as usual. |
21:58 |
proller |
get faster and simpler |
21:59 |
proller |
also in first time query was ~100 bytes length |
21:59 |
proller |
not it contain mod list |
21:59 |
proller |
now |
21:59 |
proller |
as usual i fix many things while it was approwed |
22:00 |
proller |
and as usually i cant solit it to 5 pulls because it change one place |
22:00 |
ShadowNinja |
If it contains more that 20 bytes it should be in POST. |
22:02 |
proller |
before async requests this query have small timeout, i think post was cancelled before sending with it |
22:02 |
sapier |
while some information about lag is usefull for clients I'm not sure if server step is really enough |
22:03 |
ShadowNinja |
Dump of a identically configured connection before that commit: http://paste.ubuntu.com/6705772/ |
22:03 |
proller |
sapier, enough. |
22:03 |
sapier |
and proller don't even try to tell that lag feature is absolutely required for the fix, it isn't but it's usefull |
22:04 |
ShadowNinja |
It contains the same data, so the length shouldn't be the issue. |
22:05 |
proller |
maybe packet is fragmented? |
22:06 |
sapier |
about how much data are we talking? |
22:06 |
ShadowNinja |
The request is fragmented, as you see from that working dump, but it works. |
22:06 |
celeron55 |
hell, minetest really needs to handle three nodes high full-node staircases properly |
22:06 |
celeron55 |
currently it's nearly impossible to walk them upwards |
22:07 |
celeron55 |
and Taoki's movement stuff made it much worse than before |
22:07 |
ShadowNinja |
sapier: ~1000 characters. (Could be considerably shortened by usinf Json:FastWriter instead of Json::StyledWriter) |
22:07 |
celeron55 |
it simply must work; no excuses |
22:07 |
proller |
firs packet with query cutted in 1496 bytes |
22:07 |
proller |
second have +600 bytes |
22:07 |
xyz |
ShadowNinja: what did the server reply? |
22:08 |
sapier |
for serverlist? what's in there? |
22:08 |
ShadowNinja |
xyz: It doesn't matter, it worked. |
22:08 |
Taoki |
Hey. Someone please merge https://github.com/minetest/minetest_game/pull/234 It fixes a bug with player models that causes some pretty ugly foot sliding |
22:08 |
ShadowNinja |
The request isn't being sent at all. |
22:09 |
ShadowNinja |
Taoki: ... and conflicts with SamII+capes. |
22:09 |
ShadowNinja |
Have Jordach fix it in his pull if it still exists there. |
22:09 |
Taoki |
What request, and Samll and capes? |
22:09 |
xyz |
ShadowNinja: not sure what your dump shows; does proller's patch fix it? |
22:09 |
ShadowNinja |
Yes, as I just said. |
22:10 |
xyz |
well, that's fine then; just merge it |
22:10 |
xyz |
and I guess since proller maintains this subsystem he doesn't even need an agreement |
22:10 |
ShadowNinja |
xyz: I haven't bothered to try it. Vanessa has a still longer string and it works. |
22:11 |
ShadowNinja |
Except that it should always use POST. |
22:12 |
ShadowNinja |
The useragent should contain both "Minetest-<version string>" and the OS. |
22:12 |
ShadowNinja |
Hmmm, it does that. |
22:13 |
ShadowNinja |
I agree to the useragent part of the first commit in that pull. |
22:14 |
ShadowNinja |
If the master script uses the Perl equivalent of $_REQUEST using POST should be easy. |
22:15 |
ShadowNinja |
StyledWriter should be FastWriter. |
22:16 |
proller |
masterserver support this post from begining ;) |
22:19 |
proller |
* e3abd71 - (HEAD, origin/post, post) StyledWriter -> FastWriter in announce (32 seconds ago) <proller> |
22:23 |
proller |
what about other parts? |
22:24 |
ShadowNinja |
proller: Remove the merge commit, split the first commit, and always use POST. |
22:25 |
proller |
post is slower and ave no sense for less than 1500-headers size |
22:26 |
celeron55 |
why does this matter |
22:27 |
proller |
and i cant split commits, it take 30% time of writing this patch |
22:27 |
celeron55 |
post just has the data in another part of the http request, it isn't slower or faster and generally just doesn't matter at all with any modern http server libraries |
22:27 |
ShadowNinja |
How much slower? It can't be more than a few miliseconds slower, if it is indeed slower. |
22:27 |
ShadowNinja |
^ |
22:27 |
proller |
post hidden in logs |
22:27 |
proller |
you can alalyze log by get requests |
22:28 |
proller |
i can squash this pull and commit in on |
22:28 |
proller |
one |
22:28 |
ShadowNinja |
Why would I need the whole serialized and quoted anouncement in my logs? |
22:28 |
ShadowNinja |
No, use seperate commits as it involves seperate ideas. |
22:29 |
celeron55 |
ShadowNinja: just let proller have it his way, it's can't actually matter to you when he is the only one who even understands the perl masterserver code |
22:29 |
celeron55 |
as long as the commits are clean it's fine |
22:29 |
|
rubenwardy1 joined #minetest-dev |
22:29 |
ShadowNinja |
celeron55: That's why I rewrote it in PHP(WIP). :-) |
22:30 |
celeron55 |
nobody wants php |
22:30 |
proller |
idea is "yet another masterserver improvement" |
22:30 |
ShadowNinja |
... |
22:30 |
proller |
php is worst language of last 100 years |
22:31 |
pitriss |
ShadowNinja: I will preffer PHP if you finish it..:) |
22:31 |
ShadowNinja |
Why so? It's much more readable and widely supported. |
22:31 |
proller |
wat? |
22:32 |
proller |
i can explode master.cgi to 1500 lines, and every line will be more readable, but for what? |
22:33 |
xyz |
php in my minetest -( |
22:33 |
xyz |
are you really going to do that to us? |
22:33 |
proller |
php, tcp, json->xml, .... |
22:33 |
PilzAdam |
TIL: choose the language _before_ others join your project |
22:34 |
xyz |
as I said the previous time you mentioned it, if you want to improve masterserver, improve client-side js/css |
22:34 |
xyz |
server side doesn't matter, it almost doesn't do anything interesting |
22:34 |
sapier |
celeron55 do the additional fixes fix your shutdown hang? |
22:34 |
proller |
also current servers.jst in not more readable than was in pure js with lot of {{??}} |
22:36 |
proller |
maybe, if anybody wants - master can be rewritten to python with DB (sqlite or ..) support and keeping all current functions |
22:36 |
|
rubenwardy joined #minetest-dev |
22:36 |
celeron55 |
sapier: looks like nope |
22:37 |
proller |
and... can i commit squashed 1087 ? |
22:38 |
sapier |
hmmm maybe it's not the client hanging but server not getting the disconnect ... |
22:38 |
celeron55 |
proller: yes but keep the GET->POST and the other things in separate commits because they are separate things |
22:38 |
sapier |
proller isn't there already some lag counter? |
22:39 |
celeron55 |
proller: oh you've already mixed them up |
22:39 |
celeron55 |
proller: seriously, learn to avoid that, everyone else can do it but you don't |
22:39 |
celeron55 |
this is the last time you can push it as wholly squashed |
22:40 |
proller |
okay, next time i will make new feature only after previous was merged |
22:40 |
celeron55 |
why do you keep adding multiple things in one commit? |
22:40 |
sapier |
proller ... you are aware of git supporting branches? |
22:41 |
celeron55 |
it's not like you couldn't have made a commit after changing to POST, and then made a commit after ading OS to useragent |
22:41 |
celeron55 |
+d |
22:42 |
celeron55 |
altough this is quite small so it might make sense to squash them anyway |
22:43 |
ShadowNinja |
The useragent thing is seperate from the masterserver tweaks though. |
22:44 |
|
Defenestrator joined #minetest-dev |
22:44 |
celeron55 |
proller: in the future just do it in a reasonable way without asking and use that to make people trust that you can do so |
22:45 |
celeron55 |
then people trust you to make good commits and nobody even thinks about asking anymore |
22:45 |
|
Defenestrator left #minetest-dev |
22:46 |
|
Defenestrator joined #minetest-dev |
22:48 |
celeron55 |
proller: also in my opinion ShadowNinja made a larger hassle from this than was needed |
22:49 |
proller |
55 minutes for speaking about nothing |
22:50 |
proller |
okay, StyledWriter -> FastWriter - useful, but it for 3-5 min |
23:17 |
|
salamanderrake joined #minetest-dev |