Minetest logo

IRC log for #minetest-dev, 2014-02-02

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:07 us_0gb joined #minetest-dev
00:13 Miner_48er joined #minetest-dev
00:14 us_0gb joined #minetest-dev
00:29 whirm joined #minetest-dev
00:32 EvergreenTree joined #minetest-dev
00:32 EvergreenTree joined #minetest-dev
00:40 Weedy joined #minetest-dev
00:40 Weedy joined #minetest-dev
01:17 Exio4 joined #minetest-dev
01:21 Weedy joined #minetest-dev
01:21 Weedy joined #minetest-dev
02:07 hmmmm alright
02:07 hmmmm i came up with a much more sane mapgen param setup
02:07 hmmmm MapgenParams is not a polymorphic class
02:08 hmmmm MapgenParams has a pointer to a MapgenSpecificParams, which is the polymorphic class
02:08 hmmmm instead of reallocating the whole MapgenParams structure and updating pointers to everything that stays the same, the only thing that is modified is the specific params
02:09 hmmmm there is *only* one instance of the specific params, which is statically allocated and has the hardcoded parameters set as default
02:10 hmmmm every modification just overwrites this single data structure
02:10 hmmmm there is no more any mapgen noise param related things in defaultsettings.cpp
02:11 hmmmm i added a new set of Settings methods called tryGet*() that returns true/false if it was able to get that setting, and the variable to get the setting is apassed by reference
02:11 hmmmm this way if you really don't give a shit if the setting is present or not you don't have to do a try/catch statement for each
02:25 EvergreenTree joined #minetest-dev
02:46 us_0gb joined #minetest-dev
04:44 bas080 joined #minetest-dev
05:07 Zeitgeist_ joined #minetest-dev
05:12 Yepoleb joined #minetest-dev
06:42 nore joined #minetest-dev
06:50 khonkhortisan joined #minetest-dev
07:14 darkrose joined #minetest-dev
07:14 darkrose joined #minetest-dev
09:06 deltib joined #minetest-dev
09:24 bas080 joined #minetest-dev
09:45 sapier joined #minetest-dev
09:54 darkrose joined #minetest-dev
09:54 darkrose joined #minetest-dev
09:57 sapier https://github.com/minetest/minetest/pull/1131 ShadowNinja I merged your comments is it ok now?
10:32 rsiska joined #minetest-dev
10:34 BrandonReese_ joined #minetest-dev
10:36 Kray_ joined #minetest-dev
10:36 kahrl_ joined #minetest-dev
10:52 ImQ009 joined #minetest-dev
11:07 PilzAdam joined #minetest-dev
11:45 specing joined #minetest-dev
11:55 Jordach joined #minetest-dev
12:20 sapier missing TOSERVER_RECEIVED_MEDIA in 0.4.9 seems to be more of a problem then I initially expected. as 0.4.9 client does spam console with error messages in "half initialized" state
12:20 sapier I can imagine various options to fix it:
12:20 sapier 1) bump protocol and handle "old" clients in a special way
12:21 sapier 2) add a connection timeout ... bad option as it'd kick clients on slow lines too
12:21 sapier 3) a server notification about "possible old client" but don't do anything else ... almost as doing nothin
12:21 sapier 4) do nothing
12:21 sapier does anyone have a better idea?
12:27 bas080 joined #minetest-dev
12:28 sapier http://i.imgur.com/RM7HIa0.png this is what will happen to 0.4.9 clients on connecting without having all textures. It's permanent for this session but wont happen again on next connect (unless server got new media in between)
12:43 whirm joined #minetest-dev
13:14 whirm joined #minetest-dev
14:07 sapier https://github.com/minetest/minetest/issues/1127 comments?
14:49 Yepoleb joined #minetest-dev
15:05 iqualfragile joined #minetest-dev
15:26 rubenwardy joined #minetest-dev
15:26 rubenwardy joined #minetest-dev
15:28 bas080 joined #minetest-dev
15:44 hmmmm joined #minetest-dev
15:51 NakedFury joined #minetest-dev
15:55 zat joined #minetest-dev
15:58 rubenwardy joined #minetest-dev
16:14 ShadowNinja sapier: https://github.com/minetest/minetest/pull/1122/files#diff-2543b17841165757ac531ffedd0b5fddR169 Space after , here and { on the same line.
16:17 whirm joined #minetest-dev
16:17 whirm joined #minetest-dev
16:20 sapier nope { on same line isn't used anywhere?
16:26 Calinou joined #minetest-dev
16:27 sapier "...m_ for members.  The latter is discouraged for newer code (since one can  simply notice there is no variable by that name declared in that  method's scope)..." ???????
16:28 sapier is there anyone out there who memorized full class definitions of minetest?
16:28 sapier that's from coding style
16:30 hmmmm intellisense bro
16:31 sapier I don't consider hinting to a special tool to be a valid reason for a coding style decision ... especially if it's a commercial quite expensive one
16:31 hmmmm besides, you just double click on the variable name and it gets highlighted everywhere throughout the rest of the function so that's a pretty good visual aide
16:31 hmmmm well I mean intellisense in the general class member hinting popup thing
16:31 hmmmm some people call it code completion but it's not quite that
16:32 hmmmm about the code style, it's not like it matters too much because everybody ends up doing their own thing anyway
16:32 sapier tools change but code stays sometimes for decades so relying to a certain feature isn't a good idea
16:32 hmmmm like the no-whitespace-around-control-statements thing
16:32 hmmmm if(foobar)
16:32 hmmmm and then an opening brace on a new line
16:32 hmmmm {
16:33 hmmmm eww
16:33 sapier well maybe because we didn't ever have a real complete coding style ... current one does look like a collection of random thoughts
16:33 hmmmm what I'm asking for something like the Linux kernel style
16:33 hmmmm that's because the Linux kernel style is the first link on the page, that's the completed thing
16:33 sapier maybe but kernel style doesn't match as we do have c++ code not c code
16:33 hmmmm yeah
16:34 hmmmm I try to fill in some things for the C++ specific things
16:34 hmmmm s/things/constructs/
16:35 sapier and m_ notation has another benefit, you don't have to name your parameters size_ in setSize() function
16:35 hmmmm alright, maybe I should attach an importance level to each of the items (rule -> shall, guideline -> should, suggestion -> may)
16:36 hmmmm when I wrote that up also I tried to make it match my own style so I didn't have to go back and rewrite my own stuff
16:36 hmmmm but
16:36 hmmmm i'd rather work on the mapgen param fixing
16:36 sapier well it's not a "must" rool so I guess it's not really necessary to discuss g_ m_ ... it to death :-)
16:36 sapier rool --> rule :-)
16:37 hmmmm i think g_ should stick around because there really aren't too many globals
16:37 ShadowNinja sapier: It is. And it's in the style guidelines. With the exception of functions. (And classes, namespaces, and the like)
16:37 hmmmm and they're indistinguishable from members in the same sense of not being in a local scope
16:37 sapier actually we should try to get rid about globals ... at least if it's possible
16:38 hmmmm well all of the global nparams_<mgname>_def_<noisename>s are going
16:38 sapier well ShadowNinja I'm looking at style guideline for exactly that reason, there's not a single comment about where to place {
16:38 hmmmm like the Linux kernel style
16:38 hmmmm or BSD KNF
16:38 hmmmm K&R
16:39 sapier well code most of time does exactly opposite
16:39 hmmmm void Function(void *param1, char *param2, ...goes over 80 chars...
16:39 hmmmm \tint param5)
16:39 hmmmm {
16:39 hmmmm if (!param1)
16:39 sapier as I saif, code doesn't stick to that rule
16:39 hmmmm \tparam1 = something;
16:39 sapier so do we change 90% of minetests code ?
16:39 hmmmm if (morecomplexifstatement()) {
16:40 hmmmm do stuff here;
16:40 hmmmm } else {
16:40 hmmmm so on and so forth
16:40 sapier look at code!
16:40 hmmmm no we don't change 90% of minetest's code
16:40 hmmmm you just try to do the 'right' thing from now on
16:40 sapier why do we define a style we'd have to change all of our code?
16:40 ShadowNinja We update things as we go along ^.
16:40 hmmmm you don't need to change things
16:41 sapier come one guys do you really not understand my point?
16:41 hmmmm I think the rule of thumb is that you typically stick to the module's existing code style unless you're changing over 1/3rd of it
16:41 hmmmm soooo if it's a brand new source file why not just do it in the new style
16:42 sapier ok if you want to get a new style we need a way to automate style fixes.
16:42 hmmmm non ononnonoon
16:42 hmmmm astyle is out of the question
16:42 hmmmm there have been people who brought this up before and it's definitely not going to be automated
16:42 sapier noone will fix all of those things and I'm really anoyed about discussing when is 1/3 changed or not
16:43 hmmmm right
16:43 hmmmm nobody discusses that though
16:43 hmmmm because it doesn't really matter that much
16:43 sapier see discussion with ShadowNinja, that file uses quite mixed style
16:43 hmmmm lemme see
16:43 PilzAdam sapier, astyle misses some options to configure it to match our style
16:43 hmmmm jesus christ
16:44 hmmmm ShadowNinja, it'd be really great if you stop micromanaging people
16:44 ShadowNinja Hmmm?
16:45 hmmmm for people making lots of changes, unless the style is wayy out of wack, just let it go
16:45 hmmmm focus on the big things like program logic
16:45 hmmmm this is what matters most^
16:45 ShadowNinja Alright.
16:45 hmmmm reviewing a pull request doesn't mean you need to scruitinize the spacing or whatever
16:45 hmmmm that's just mostly frustration
16:46 hmmmm i mean if they get it right that's awesome
16:46 sapier well don't blame ShadowNinja basically he's right but how to handle files like that without really style in there
16:46 hmmmm especially for modules with the old irrlicht style
16:46 hmmmm like if somebody were to add shit like
16:46 hmmmm if( 0 != fooSomething() )
16:46 hmmmm { doBlah();
16:46 ShadowNinja sapier: https://github.com/sapier/minetest/commit/695230db86918929c04aead76931f21b3e6d3b73#diff-18513665750ef5adf42b5ec29e14162eR1036 Um...  You're missing a number of combinations, I think you should just remove the check as resolving works properly with those addresses.
16:46 hmmmm into emerge.cpp
16:47 hmmmm I think i'd have a fit
16:47 sapier maybe we should add a function isNullAddress(std::string) :)
16:48 ShadowNinja sapier: Use resolveString and check if it's null.  But that's what is does if the conditional succeeds.
16:48 sapier ok you're right keep it simple
16:48 hmmmm i know MIRSA says that you should compare explicitly against a value but it's really not unclear in 99% of cases
16:49 ShadowNinja And it looks like you're using the bind address on the client still.
16:49 hmmmm this is why i like to do if (!foo) instead of if (foo == NULL)
16:49 hmmmm but it doesn't matter, that's up to personal taste because it's unregulated
16:50 ShadowNinja sapier: You also do the check here, although this patch shouldn't touch the meinmenu at all.
16:50 ShadowNinja https://github.com/minetest/minetest/pull/1131/files#diff-16525c326f5842e04cbdf0b3ae8254fcR961
16:50 sapier if(!foo) may fail dependent on truth value of architecture ... but I don't know any where it may fail ... gues that's theoretical case only
16:51 hmmmm no it wont
16:51 hmmmm because
16:51 sapier well that's the addition I made now you can control the binding from main menu too once you set it
16:51 hmmmm you're implicitly casting foo to an integer
16:51 ShadowNinja NULL == 0L == false == 0 And 0 is the only value that fails.
16:52 hmmmm straight from the standard, "the integer representation of a null pointer shall compare true to 0"
16:52 sapier you know as good as me compilers not always correctly implement standard, but that's more of a problem in embedded development then in application dev
16:52 ShadowNinja sapier: And this is only available in the server tab, and is shown as the "Bind address" and preferable marked as advanced.
16:53 hmmmm yes and like i said in an embedded environment where that happens to *not* work, that's not standard C anymore
16:53 ShadowNinja s/\./?/
16:53 ShadowNinja I don't think such an advanced option as the bind address should be in the menu.
16:53 hmmmm and most of them aren't standard C anyway, they don't even claim to be, they're a "C-like language"
16:53 sapier everyone capable of enabling this already prooved to have advanced knowledge
16:55 ShadowNinja As for https://github.com/minetest/minetest/issues/1127 I guess the default should just be raised to max_clients * 4 or so.
16:56 hmmmm ShadowNinja, see: http://c-faq.com/null/ptrtest.html
16:57 VanessaE max_clients * 4 would be twice my current setting, which would be overkill probably in my case, but (currently connected) * 3 or 4 would be pretty close to "just right"
16:58 ShadowNinja hmmmm: What about that?  I know that.
16:58 hmmmm [11:51 AM] <ShadowNinja> NULL == 0L == false == 0 And 0 is the only value that fails.
16:58 ShadowNinja Yes, and?
16:58 sapier well if you set it to max_clients * 4 you may increase lag more then required for e.g. 2 player games
16:59 hmmmm int foo = (NULL == 0); printf("%d\n", foo); on ANY ISO 1989:9989 compliant compiler, and you're going to get 1
16:59 ShadowNinja That's a max though, right?  Setting it very high shouldn't cause any lag.
16:59 ShadowNinja hmmmm: Yes, of course.
17:00 hmmmm so then maybe I misunderstood what you were trying to say in that sentence
17:00 ShadowNinja Yes, I think so.  :-)
17:00 sapier it will cause lag as this is the number maximum blocks processed in server thread. a large number may cause quite a lot of blocks initially queued
17:00 ShadowNinja I meant (NULL == 0L == false == 0) == true.
17:01 sapier well it's a design issue ... I really don't know why actually cyclic tasks are called async in minetest engine
17:02 Zeitgeist_ joined #minetest-dev
17:02 sapier what do you think about splitting server thread in a cyclic and async thread? cyclic is doing all that stuff required to be done regularly while async does user interaction
17:03 hmmmm user interaction, like handling packets?
17:03 sapier yes
17:04 sapier basicaly
17:04 hmmmm yes that would be great
17:04 hmmmm back when celeron was suggesting that minetest be rewritten this is what really needs to happen
17:04 sapier we'd get best result if we added thread priorities along with this change
17:04 hmmmm the entire queue-it-up-and-process-it-in-one-huge-loop thing isn't very efficient with resources
17:04 sapier well that's not a rewrite it's a minor change
17:04 hmmmm well
17:05 hmmmm it's the beginning of a huge change
17:05 sapier I already started doing this some time ago ;-)
17:05 hmmmm there are thread priorities
17:05 sapier where?
17:05 hmmmm except they don't work on Linux
17:05 hmmmm porting.cpp
17:06 hmmmm thread priorities only mean anything if it's using SCHED_RR or SCHED_FIFO
17:06 hmmmm and to change the policy you need to have root permissions
17:06 sapier hmm I remember dark I may have even been the one adding that code long long ago
17:07 sapier but I'd move it to jthread as that code is now ours
17:07 hmmmm yeah
17:07 hmmmm i remember you did try adding thread priorities but that was a pull request that never made it
17:07 hmmmm and here i actually did add it along with thread affinities for emergethread but i realized what the problem was
17:07 sapier could be true too
17:09 sapier but if we have separate threads for cyclic as well as acylic things we can only gain full benefit by doing cyclic things low prio. It's useless to generate map at full speed if network thread is starved and can't send it to clients
17:09 sapier just to name one example
17:10 hmmmm i think linux takes this into account actually
17:10 hmmmm if something is cpu bound it lowers its priority slightly
17:10 hmmmm shrug
17:12 sapier I think so too but it's quite limited
17:14 Sokomine joined #minetest-dev
17:16 hmmmm it'd be pretty annoying to have the user enter their root pw every time they run minetest
17:16 hmmmm and weird
17:17 hmmmm it wouldn't really make a difference either unless all cores are pegged at 100% cpu usage, and even then, the thing that it really makes a difference with is latency
17:17 sapier yes ... the nice value is honored for SCHED_OTHER ... is nice usable thread specific?
17:17 hmmmm i'd hope so
17:18 sapier running minetest at root is not an option so we can forget about RR and FIFO
17:19 hmmmm well
17:19 hmmmm if you can figure something out, by all means...
17:20 sapier :-( nice seems to be process specific
17:29 whirm joined #minetest-dev
17:31 sapier https://github.com/minetest/minetest/pull/1131 ShadowNinja fine this way?
17:33 sapier https://github.com/minetest/minetest/pull/1129 is ok now
17:33 sapier at least as of my point of view
17:37 sapier https://github.com/minetest/minetest/issues/1132 comments?
17:41 EvergreenTree joined #minetest-dev
17:41 EvergreenTree joined #minetest-dev
17:59 bas080 joined #minetest-dev
18:16 EvergreenTree joined #minetest-dev
18:16 EvergreenTree joined #minetest-dev
18:35 grrk-bzzt joined #minetest-dev
18:45 RealBadAngel joined #minetest-dev
19:03 werwerwer joined #minetest-dev
19:03 EvergreenTree_ joined #minetest-dev
19:05 EvergreenTree_ joined #minetest-dev
19:07 EvergreenTree_ joined #minetest-dev
19:36 whirm joined #minetest-dev
20:13 emptty joined #minetest-dev
20:14 emptty Hello there
20:15 emptty I have a bug reported against the debian package stating that the game segfaults when browsing the public serverlist
20:15 emptty does it sounds like something known to you guys?
20:15 sapier yes
20:15 sapier well maybe
20:15 sapier is luajit involved?
20:16 emptty luajit is compiled in, yes
20:16 sapier what version?
20:16 VanessaE debian doesn't have a luajit package I thought?
20:16 emptty there is a backtrace and a strace in the bug report, if it helps: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733974#17
20:16 emptty VanessaE: yes we do, but not on all architectures
20:16 sapier 2.0.2 hmm that's not the bug I expected
20:16 emptty some of our rare architectures don't have luajit, but nobody has a luajit on powerpsce or so
20:17 sapier we know about a bul in bet version of luajit
20:18 VanessaE however, sapier.... look at event #7 of the backtrace... :)
20:18 ShadowBot https://github.com/minetest/minetest/issues/7 -- Fix build with Pathscales EKOPath by Merkil
20:18 VanessaE shaddup ShadowBot :P
20:18 sapier looks like the bug xyz mentioned for beta4
20:18 sapier beta7
20:21 sapier well that's great everything is attached except the relevant information
20:22 emptty what would you need?
20:23 sapier well the script error has a error message attached I can't find it in this traces
20:24 VanessaE sapier: it wouldn't have.
20:24 VanessaE it threw a C++ exception
20:24 VanessaE it got bit by the "errors don't get logged" bug
20:25 sapier whoo
20:25 VanessaE emptty: any chance of a console capture of the crash?
20:25 sapier it's not supposed to crash there
20:25 emptty you have a console capture for the same issue above on the same page
20:25 VanessaE oh yeah, so i do
20:25 VanessaE derp
20:25 emptty but the first capture was produced with version 0.4.8
20:26 emptty that's why I pointed you guys directly on the bottom of the page, with recent info
20:26 VanessaE yeah, I'm just blind, don't mind me :P
20:27 sapier well that issue seems to be what xyz mentioned but for some reason he didn't get that error on 2.0.2 but on 2.0.0beta7 only ... at least that's what I understood
20:28 VanessaE well wait a sec here
20:28 VanessaE wtf am I using then
20:28 VanessaE *looks*
20:29 nore joined #minetest-dev
20:29 VanessaE my copy of luajit is at commit 6964a7752ae314dcae693abcb0c1175c95ad22e0 ...
20:30 VanessaE minetest is within one or two commits of HEAD
20:30 sapier it's only relevant on client
20:31 VanessaE oh right,  I tend to forget about the client-side Lua in the menu.
20:32 VanessaE lesse.  client side is within one or two of minetest HEAD also, luajit there is 2.0.0 as included in Xubuntu's repo
20:32 VanessaE (12.04)
20:32 sapier and it does work?
20:32 VanessaE yup
20:33 VanessaE no problems here.
20:33 sapier well not sure if this is a good or bad sign
20:33 VanessaE wait
20:33 VanessaE specifically,
20:33 VanessaE 2.0.0 beta 9
20:35 sapier emptty did I understand correct you are able to reproduce this error?
20:36 emptty let me try
20:36 emptty yes :)
20:36 sapier that's good
20:36 hmmmm watch the error be caused by some guy missing the mainmenu .lua files
20:36 hmmmm :\
20:36 emptty If I tick the "public list" box, it lasts maybe one second and crashes
20:36 VanessaE hmmmm: wouldn't be the first time that's been the case :P
20:36 hmmmm oh
20:37 hmmmm serverlist, hahaha, that thing :p
20:37 sapier no this seems like some lua error occuring in async thread
20:37 emptty yeah, that's not as soon as I click
20:37 emptty that's a delayed death :)
20:37 sapier xyz reported a bug about serialization not working correct on luajit 2.0.0beta7
20:37 hmmmm shouldn't errors in the async thread be handled and not fatal?
20:38 sapier actually yes but ShadowNinja made it a fatal error on catching luajit errors
20:38 hmmmm i'd call that a regression
20:38 sapier still there shouldn't happen an error in this code
20:38 hmmmm sure, but there are two problems at least we know about now
20:39 emptty let's call it *two* bugs, then ;)
20:39 emptty I can run whatever tests you want from me, but I'm clueless to investigate the issue myself
20:40 sapier no problem I know where to start searching async_env.lua
20:41 emptty highlight me when you need me, then.
20:41 emptty many thanks for digging into that issue
20:41 sapier https://gist.github.com/sapier/8774597
20:41 sapier can you add those two lines right at beginning of engine.job_processor function?
20:43 emptty FCT: "6\2{\0\0\0\27LJ\1\0/@/usr/share/games/minetest/builtin/mainmenu.luaD\0\1\3\0\3\0\4\13�\1\0024\1\0\0007\1\1\1%\2\2\0@\1\2\0\11online\18get_favorites\11engine\1\1\1\1param\0\0\5\0\0\0\0\0\0"
20:43 emptty DATA: "0"
20:43 emptty (but it didn't crash this time oO )
20:44 hmmmm what happens when you comment out the first line of those two?
20:44 emptty unticked the box, reticked it, got exactly the same output, and a crash
20:44 sapier try again :-) this looks fine
20:44 emptty the FCT ?
20:44 hmmmm yea
20:44 hmmmm try it a few times
20:45 hmmmm does it consistently crash?
20:45 emptty yeah
20:45 emptty 3 crashes out of 4 tests
20:45 emptty w/o FCT, I get DATA "0" and crash
20:45 hmmmm hmm
20:46 hmmmm try adding the following:
20:46 sapier1 joined #minetest-dev
20:46 hmmmm local t = clock()
20:46 hmmmm err
20:46 hmmmm local t = os.clock()
20:46 emptty I'm by 9 crash out of 10 or something
20:46 hmmmm while os.clock() - t <= 5 do end
20:46 hmmmm and then see if it crashes then
20:47 emptty btw, I put the print before the local lines, right?
20:47 hmmmm it doesn't really matter
20:47 hmmmm local line, i meant the latter of the two
20:47 emptty should I put the waiting loop before the decode lines or after?
20:47 sapier1 put it before so we can be sure we read it if there's a unmarshall error
20:48 emptty crash after 5sec
20:48 hmmmm ah okay
20:48 sapier what did you do now?
20:49 hmmmm lol
20:49 sapier can you gist the code?
20:49 hmmmm I tried to diagnose if it was a race condition
20:49 hmmmm without even looking at the code in question
20:49 emptty (3 times on 3 tests)
20:49 sapier hmmmm race condition ... ok I gues that's an issue we can solve
20:50 hmmmm no it's not
20:50 hmmmm see he just said it crashes even after delaying 5 seconds
20:50 emptty State of my code: https://gist.github.com/mquinson/8774730
20:50 sapier and it doesn't crash if you print the fct?
20:51 hmmmm it does crash, but just not all of the time
20:51 hmmmm you realize you're not going to get anywhere without debugging right?
20:51 sapier ok good but we need to know if the serialized_fct is broken in this "crash case"
20:51 emptty Nah, it crashes with the print FCT uncommented too
20:52 sapier that's the information I need
20:52 emptty Ran 3 tests with the print (but w/o the delay), and all of them crashed
20:52 sapier yes hmmmm but the more information I have the better I can reproduce
20:53 grrk-bzzt_ joined #minetest-dev
20:54 salamanderrake joined #minetest-dev
20:54 sapier emptty? whats printed in a crash situation?
20:55 emptty sapier: http://paste.debian.net/79842/
20:56 sapier ok seems like serialized data isn't messed up
20:56 sapier bug has to be hidden somewhere in (un)marshalling code
21:09 rsiska joined #minetest-dev
21:48 hmmmm what do you guys say about removing the math mapgen?
21:48 VanessaE proller will kick your ass :P
21:48 blaise lmao
21:48 hmmmm he's not around
21:48 blaise people tend to time out on my server... and I can't figure out which mod is doing it..
21:48 hmmmm and he's not even associated with minetest anymore
21:48 blaise I actually have no issues connecting..
21:49 blaise do you guys think it's due to impatience?
21:49 VanessaE frankly, I have no use for it, and in the end, the mapgen is math ANYWAY
21:49 VanessaE (what is perlin noise if it isn't a math formula?)
21:50 VanessaE blaise: the biggest issue with timeouts now is tablet users versus servers with more mods than tablets have memory to handle the media for, or so I woudl have to guess.
21:50 VanessaE would*
21:51 emptty sapier: I go to bed now. If you need to contact me, I'm very very often connected to irc.debian.org (I don't even know which irc network we are on here)
21:53 sapier ok thanks emptty I havent found it by now
21:53 hmmmm oh a debian guy
21:54 blaise hrmm
21:54 hmmmm debian ships with PermitRootLogin yes
21:54 hmmmm lol
21:55 VanessaE blaise: and a lot of THAT can be blamed on those clients being, as far as I can tell, unable to disable the "preload item visuals" feature.  So they try to preload hundreds, if not thousands of textures and boom, crash + timeout.
21:55 sapier well for servers root login is at least comfortable ... but not very safe :-)
21:57 blaise anyone care to log in to my server and take a guess at why people time out?
21:59 blaise I tried to shut off all the mob mod's to see if it was better...
22:02 blaise oh wow, I'm in -dev
22:02 blaise sorry..
22:26 iqualfragile joined #minetest-dev
23:23 hmmmm so like
23:23 hmmmm who ever said that assert() from assert.h is always a macro
23:24 hmmmm nevermind
23:24 hmmmm was going to say something about debug.h
23:33 hmmmm ugh
23:34 hmmmm i hate how Map needs a pointer to emergemanager but it needs to stay in there until Map only does Map stuff and absolutely nothing else
23:35 hmmmm come to think of it, ServerMap has a gamedef too... this is not really good design
23:37 Miner_48er joined #minetest-dev
23:38 sapier well hmmmm there are a lot of bad design decisions as of data separation. If there's a chance to hide data from other subsystems I suggest doing it
23:39 hmmmm sapier, what i'm doing now is an improvement, but only an improvement...
23:39 sapier yes but a lot of small improvements will still still help to reach our goal
23:39 hmmmm but at least I'll be able to die knowing that MapgenParams isn't a trainwreck
23:40 sapier e.g. my connection fixes hide "peer" from everyone except connection classes I'd like to hide the RemoteClients too but by now I didn't get that far
23:41 hmmmm who made environment take an emergemanager
23:41 sapier :-) why does server need environment to know a player ;-)
23:42 hmmmm well my question is a real question because I didn't make it like that
23:42 hmmmm i know i didn't because the member is named m_emerger, i would've made it m_emerge
23:42 sapier there's a lot of cleanup missing :-) ... or why does connection need emerge mangager to cleanup peer ;-)
23:43 hmmmm in any case it's being used in exactly one spot
23:43 sapier well if it's only one location you could try to get rid of it ... or add a sane interface if something really needs to be done
23:45 hmmmm oh nice, and that bit of code is a bug anyway
23:45 hmmmm it passes a NULL MapBlock * to activateBlock
23:45 sapier a reason more to clean it
23:46 hmmmm i think people ought to reexamine their assumptions and take a look at functions they're calling because it might not handle NULL appropriately
23:47 sapier well I usually check any parameter I get from some other class and only consider class internal pointers which are initialized by constructor and never changed as not null :)
23:48 sapier everything else is at least worth and assert(param != null)
23:48 sapier well ... that's how I try to do it :-) sometimes I miss it
23:48 hmmmm that's a good scheme
23:49 Miner_48er joined #minetest-dev
23:49 sapier I have to get rid of that damn "well" again recently I use it permanently
23:51 hmmmm heh.  for a while i had this verbal tick where i'd end my sentences with "...and what not" whenever i'd get nervous
23:51 hmmmm i didn't realize how stupid i sounded until afterward
23:57 sapier I can't reproduce that damn error emptty found
23:58 sapier I forgot to ask him what machine he did use ... seems my good old phenon II is getting a little bit slow recently

| Channels | #minetest-dev index | Today | | Google Search | Plaintext