Time  Nick           Message
05:04 Jonah          hi
07:30 Hijiri         is it possible yet to access player attributes if the player is offline?
08:15 MTBuilder      i tried to use the traders mod but it has an error in lin 33 "attempt to concatenate a nil value
08:15 MTBuilder      Sokomine: could you help, i think it is your mod? :)
08:15 IcyDiamond     then report the issue at the appropriate issue tracker
08:21 MTBuilder      can i have 2 logfiles on my server ... one with the chat only and the other with more
08:27 IcyDiamond     submit a feature request
08:27 sfan5          a mod can do that for you
08:30 MTBuilder      i will have to get back later on that :) thanks so far see ya
08:59 IcyDiamond     would be nice if textlist had a version where each line could have an icon
09:30 cimbakahn      Good Morning Everyone!
09:31 cimbakahn      Is there a video on the net that shows a hydro electric LV setup?
09:32 cimbakahn      I mean.  I know how, but i forgot where the cables go into the hydro electric generators, and i need to know for planning.
11:00 deltasquared   cimbakahn: no video, but here's my setup: https://ptpb.pw/cE2X.png so essentially a column of hydro generators with a single water source on top, and a column of cable running down one side
11:00 deltasquared   all those generators reach 100%
11:04 JDCodeIt       Hello all... I was looking at memory usage on the new 0.5.0 client on Linux and found at start 38M, enter a world 1.2G, playing for 2 mins 1.4G, return to main menu 991M
11:05 deltasquared   JDCodeIt: actually in my experience that's not a new thing
11:05 JDCodeIt       Do we know which resources are not being freed up?
11:05 deltasquared   not that I would know, but if I had to take a guess, probably mapblock cache. I keep tweaking that limit down and yet still MT exceeds it and causes OOM crashes.
11:06 deltasquared   but MT not releasing memory after closing a world, I've had that on 0.4.16
11:07 JDCodeIt       So, possibly entering several worlds, then back to main menu, the client system would run low on memory?
11:09 deltasquared   JDCodeIt: that is my symptom that I have seen
11:09 deltasquared   though in my case it was not "several", it was merely start new minetest, go into one world, come back out, go to another, wander around for a bit- *BANG*
11:09 JDCodeIt       Maybe we should consider some background process to check the age of items in the cache, and release memory over time.
11:10 deltasquared   JDCodeIt: well I thought that would be what the cache would do *anyway*
11:10 JDCodeIt       I'll take a read of the code
11:10 deltasquared   "need to download new mapblock... not enough space in cache, kick out old ones"
11:10 deltasquared   I would be very suprised if there wasn't an LRU cache
11:11 deltasquared   (with possible exceptions for things that are actually visible at that moment)
11:11 deltasquared   that said, I dunno, maybe you'd have to destroy the mapcache instance when the world closes, and that'd free any data? I haven't looked at that code to see what's going on
11:11 JDCodeIt       Still sitting at the main menu for several minutes now - 991M used by the client, so if it is releasing, the expiry time is long
11:13 JDCodeIt       .msg deltasquared afk for a few
11:13 deltasquared   JDCodeIt: you forgot this -->  /
11:13 deltasquared   :P
11:20 cimbakahn      deltasquared, Sorry!  I didn't know someone got back to me.  I'll read what you typed now.
11:22 cimbakahn      deltasquared, Can you place those white cables directly into the bottom of the hydro generators?
11:25 deltasquared   cimbakahn: you could if you desired, but then you'd have to make the array flat. and possible two deep IIRC, the "flow strength" of the water on the sides of the hydro gen matters
11:25 deltasquared   in fact... *goes away to test*
11:30 JDCodeIt       Yeah. But once you hit Enter... there's no going back
11:32 deltasquared   cimbakahn: https://ptpb.pw/hU_R.png and https://ptpb.pw/kEEa.png note that they're identical basins but the one raised off the ground gets higher power output, so my memory was correct
11:35 JDCodeIt       No change to the memory usage in the 0.5.0 client sitting at main menu for 30 minutes - still 991M
11:35 iska           hmm thats unefficient use of lv cables with hydros
11:37 cimbakahn      deltasquared, A long time ago I made a gorgeous engineering room deep under the ground with Hydro Electric.  Problem is, I can't remember if I did it on stormchaser3000's old server or on my own single player world.
11:37 deltasquared   iska: ¯\_(ツ)_/¯
11:37 deltasquared   I don't claim to be finding the 100% most compact layout :P
11:37 deltasquared   that said, doing a thing, one moment
11:38 iska           doesn show much of the cabiling but the top right corner shows the 4 hydro columns, under the protection block is cable column
11:38 iska           14:14 < deltasquared> JDCodeIt: you forgot this -->  /
11:38 iska           14:14 < deltasquared> :P
11:38 iska           https://cdn.discordapp.com/attachments/404052744421376001/415399495472513024/mt_hydroquarries_v2.jpg
11:38 iska           need to configure my putty, right click paste >.<
11:39 cimbakahn      deltasquared, I was just thinking, I do have the habit of saving minetest screenshots...... maybe I will look on my external hard drive and see if I have any screenshots there of the engineering room.
11:42 deltasquared   cimbakahn: anyways, wrt putting cables in the bottom, if you must do it that way: https://ptpb.pw/XNhi.png this setup still maxes out each generator. notice they're still raised
11:47 cimbakahn      deltasquared, I believe by staggering the hydro generators in a certain way I was able to space save.  And I believe I had the white cables coming up directly through the bottom of the hydro generators.
11:48 JDCodeIt       Client 0.5.0 memory - Inside client.cpp, function step() can make a call to addBlock which will call the cacheCleanup. But I doubt we are adding blocks while sitting at the main menu.
11:48 cimbakahn      deltasquared, I am looking through the screenshots on my external hard drive now.
11:49 deltasquared   cimbakahn: actually that sorta makes sense
11:49 deltasquared   JDCodeIt: I would more focus on where they are (not) removed again
11:54 cimbakahn      deltasquared, I believe that picture is a little similar to what I did.
12:37 JDCodeIt       Memory free 0.5.0 - It would seem at first glance, the Map and the MiniMap are independently managing map blocks - true?
12:42 JDCodeIt       ..and it seems the management inside Map has a timer to unload them eventually, but the implementation of MiniMap will never unload them.
12:43 JDCodeIt       ..unless you at some point call addBlock
12:52 cimbakahn      deltasquared.  Are you still here?  I did have pictures of the engineering room.  Here they are:  https://imgur.com/a/EvkL7
12:53 cimbakahn      Can anyone tell by looking at those pictures if I was on a server online, or on my single-player world?
13:12 iska           cimbakahn: looks like single-player because of stacks of 99 :)
13:13 iska           you probably dont have stack of batteryboxes in online server
13:18 cimbakahn      iska, I was just curious, because I found some Old Worlds on my external hard drive as well, so I thought I would teleport myself to the location in the first screenshot and each one of the Worlds.
13:18 iska           good idea
13:22 cimbakahn      iska, Oh!  Another thing.  If I was on stormchaser3000's old server (at the time), I was a moderator there, so I could have had many stacks of 99.
13:29 JDCodeIt       Memory usage client 0.5.0 - In the Menu loop, the_game is no longer running, so should the previous "run" have freed its map block caches on exit?
14:17 JDCodeIt       Hi all, just repeating the question in case any of you are able to answer: Considering memory usage client 0.5.0 - In the Menu loop, the_game is no longer running, so should the previous "run" have freed its map block caches on exit?
14:26 Krock          mapblocks should all be freed when returning to the mainmenu
14:27 Krock          however, I observed that returning to the mainmenu and starting a new minetest instance does not quite result in the same RAM usage
14:28 JDCodeIt       Chasing a lingering memory allocation today - starts with 38M, then after a short game, return to the menu with 991M still allocated.
14:29 deltasquared   it'd be useful if we could track different categories of memory allocation for debugging purposes (sub-allocators may have been the easiest trick, but... *shrug*)
14:29 deltasquared   inb4 patches welcome :P
14:30 deltasquared   nah, kidding. but that kind of change would require changes all over the place, most likely >_>
14:30 JDCodeIt       and function calls incur overhead of course
14:30 deltasquared   JDCodeIt: memory allocation is already overhead :P
14:31 deltasquared   like, there's structure traversals and likely cache misses all over the place. it's not like I'm suggesting every call to operator new be logged
14:59 cimbakahn      deltasquared, Hello again!
15:01 * deltasquared waves
15:02 cimbakahn      deltasquared, Well, I found 12 worlds on my external hard drive, and I teleported myself to those coordinates and found nothing in each and every one of them.  I bet the engineering room was on stormchaser3000's old server, or it was one of my old worlds that I deleted.
15:03 deltasquared   cimbakahn: was said older server taken down? I can't say I'm familiar with it
15:05 cimbakahn      deltasquared, Isn't there anything in any of these pictures that would give someone a clue if this was on a server online, or in a single player world ----> https://imgur.com/a/EvkL7
15:06 cimbakahn      deltasquared, stormchaser3000 has a new server now. The server I was talking about was his older one that no longer exists.
15:20 deltasquared   cimbakahn: your RTT: suggests it would be local
15:20 deltasquared   0.001, <1ms? sounds like local connection to me
15:24 cimbakahn      deltasquared, Thank you very much for helping me with the missing engineering room!  I guess I'll just have to build another one and do even better this time around, but next time make sure I don't lose it.
15:27 deltasquared   cimbakahn: I would plug a server I moderate buuuuuut.... probably breaking a rule somewhere ;)
15:27 deltasquared   and in all fairness technic on there is laggy as all hell
15:28 Krock          somewhere we have an issue about RTT not updating. Use the profiler graphs for more accurate values
15:28 cimbakahn      deltasquared, I've never had any problems with Technic.
15:29 cimbakahn      Krock, Hello!
15:29 deltasquared   cimbakahn: on VE-Survival, there's just so much of it. technic wasn't built to scale to many dozen thousands of cable nodes and such
15:29 Krock          hi cimbakahn
15:29 deltasquared   and a lot of machines
15:29 deltasquared   as a result, technic's ABMs get throttled hard
15:30 deltasquared   (everything else runs more or less the same, if not slightly unevenly/jittery, though mesecons gets the same treatment)
15:30 deltasquared   Krock: actually that reminds me, is per-mod ABM throttling a thing
15:30 deltasquared   or possible per-node, if my memory of how technic's power code works is correct
15:31 deltasquared   say some mod or an ABM in a given mod was using an inordinate amount of server time
15:31 Krock          the ABM handler does not know where the ABM was registered, so throttling it by mod isn't a thing
15:32 Krock          use the profiler to record the individual timings
15:32 Krock          > profiler.load = true
15:33 deltasquared   Krock: we have on this particular server, so we know what's being so slow. it may be it's own internal throttle-back then, because we have the wierd situation where vanilla furnaces out-perform even HV technic furnaces
15:33 deltasquared   wait, MV furnace? forgot the ranks of machines, damnit
15:35 Krock          vanialla furnaces use node timers, whereas technic may still use ABMs to update it
15:36 deltasquared   huh, ok, that could do it I guess, if the server is just overburdened that all ABM triggers slow down, but furnaces will still try to go off more or less on time?
15:36 deltasquared   I probably don't really know what I'm talking about here
15:41 cimbakahn      deltasquared, I read an article a few years ago.  A man was working on a code.  The code was gorgeous!  The code was the future.  With this code you could whittle down anything to 1/16th of its original size.  Do you understand what this means?  Unfortunately he died, and nobody was able to find the code that he was working on.  And I have been unable to find the article ever since then.  I should have bookmar
15:41 cimbakahn      ked the damn thing!  We need this code today!
15:44 deltasquared   cimbakahn: erm, context halp? what was size in this context and does it have anything to do with minetest :P
15:45 * Markow       wonders the same. What does it have anything to do with Minetest?
15:46 deltasquared   I wonder if he was referring to something like MC's chisels and bits mod (omg I loved that mod so much)
15:46 Markow         deltasquared: I haven't tried that mod yet.
15:46 cimbakahn      deltasquared, It has to do with anything that runs on any computer.  Any operating system, any program, any application etc etc..
15:46 deltasquared   cimbakahn: you can't make everything 1/16th of it's original size, some things are already highly compressed
15:47 deltasquared   the solution we have today: use the best compression for the data at hand
15:49 cimbakahn      deltasquared, As far as I can remember this code didn't have anything to do with compression.
15:50 deltasquared   cimbakahn: shrinking data into a smaller space is by definition compression :P
15:51 ThomasMonroe   deltasquared, define data :P
15:51 cimbakahn      deltasquared, I guess I'll just have to find an article about him somehow.  From time to time I still do Google searches trying to find information about the man and the code he was working on.  So far no luck.
15:52 deltasquared   ThomasMonroe: pony art
15:52 deltasquared   nah jk, but generally anything your computer can store
15:53 ThomasMonroe   lol
15:53 ThomasMonroe   ik XD
15:53 ThomasMonroe   that was more of a sarcstic comment :P
15:53 ThomasMonroe   sarcastic*
15:57 deltasquared   “y'know, important stuff, like p- errr art. yeah, just artwork. *cough*”
16:07 cimbakahn      Got to go.  Everyone have a fine day!
16:07 JDCodeIt       Sometimes there is a trade-off between easily maintainable code and speed.
16:08 deltasquared   JDCodeIt: true, but usually if you make it work first then make it work fast, you can have both
16:08 deltasquared   besides, I tend to find code written "with performance in mind" which abandons readability is often premature, and incorrect, optimisation
16:10 deltasquared   or, quick hacks don't solve anything in the end, don't do it
16:28 JDCodeIt       Yes, takes a long time to find the elegant way
16:35 JDCodeIt       Maybe found the memory issue. ClientMap is created by passing a pointer to Map created with new, but only calls the default destructors for the object. It never explicitly deleted as far as I can see.
16:39 deltasquared   JDCodeIt: interesting, I would advocate using an std::unique_ptr there
16:39 deltasquared   especially to store it internally
16:40 JDCodeIt       It's stored in a member variable - a pointer, but the destructor probably should have handled the delete.
16:41 deltasquared   JDCodeIt: if a unique_ptr was used to store it then it would almost certainly be so. that said, does ClientMap not call delete in it's constructor? *pulls up local clone*
16:42 deltasquared   ... wait what, but ClientMap *inherits* Map? *continues reading*
16:42 deltasquared   also, non-inline methods in a header file. *twitch*
16:43 JDCodeIt       ...you mean destructor of the member variable - only for non-variant ones, right?
16:44 deltasquared   JDCodeIt: did you mean MapBlock btw? because I can see an std::map of vectors (presumably mapblock coords) to MapBlock pointers
16:46 deltasquared   interestingly, ClientMap's destructor is defaulted, so while that would destroy the std::map, as it's just raw pointers to MapBlocks... hmm, they wouldn't get freed surely
16:49 deltasquared   but then again, raw pointers convey precisely nothing about the ownership situation.
16:49 deltasquared   which is precisely why their use for referencing objects is discouraged
16:50 JDCodeIt       in our case here, some function needs to take responsibility, so the question is where to delete
16:50 deltasquared   JDCodeIt: well it depends, I haven't figured out where the mapblocks *come from* or who else might be referencing them
16:51 deltasquared   shared_ptr can be a bit ouch in the event that it's not well defined when the lifetime should end
16:51 deltasquared   (that said, a threadlocal_shared_ptr with non-atomic refcounts shouldn't be too hard to write)
16:52 deltasquared   I'm a bit leery about going that route, though. shared_ptr-like solutions are almost always an admission of "I've lost track of who owns what"
16:55 JDCodeIt       I'm also not sure about the member initialization in the constructor. m_client is a pointer to Client, but in the initialization is treated like a varaible, even though nobody called new yet at that point
16:56 deltasquared   all I can say is, at times it is quite evident to me that minetest was originally written in a very... well, pre-C++11-y way.
16:56 deltasquared   JDCodeIt: wait what hold on
16:58 JDCodeIt       Yeah, check it out...
16:58 deltasquared   JDCodeIt: well the variable itself is a pointer and the constructor argument is a pointer, nothing wrong about it (bar again not documenting lifetimes)
17:00 JDCodeIt       Symantics means what in the initialization? m_client(client)
17:01 JDCodeIt       Does the mean copy the pointer?
17:02 deltasquared   JDCodeIt: yeah basically
17:03 deltasquared   they're both pointers, and the assignment operation for pointers just copies them by value
17:04 JDCodeIt       Since it is a pointer, if this class were to take responsibility for the pointer, then the destructor should call "delete m_client"
17:05 deltasquared   JDCodeIt: except that it is hard to tell who "owns" the pointed-to object here
17:05 deltasquared   if someone else holds a pointer and we delete it, BANG
17:06 deltasquared   that said, the naming of this class and it's purpose suggests it *should* take responsibility for them.
17:07 deltasquared   in which case, the correct solution would be making the map have a value type of std::unique_ptr (key type can remain the same)
17:07 deltasquared   then destroying the map would call the destructors on all those unique_ptrs which in turn deletes the objects
17:07 deltasquared   less error prone than having to iterate through the map and call delete manually
17:17 deltasquared   hmm, have to go get dinner.
17:33 IcyDiamond     ok so i turned my server into a 0.5 server
17:33 IcyDiamond     and im now announcing it to the list
17:44 JDCodeIt       Is there a reasone 0.5.0 only supports protocol 36?
17:45 IcyDiamond     why does mobf keep crashing on 0.5
17:46 JDCodeIt       What is in debug.txt?
17:46 IcyDiamond     2018-04-11 19:44:49: ERROR[Server]: MOBF: movement generator "probab_v2_mov_gen" not found!
17:46 IcyDiamond     oh k
17:46 IcyDiamond     is that a mod?
17:48 IcyDiamond     i sure cant find it
17:48 JDCodeIt       sapier has this on the mod Github - looks like there are newer versions available
17:49 JDCodeIt       Ran into same issue just now with fresh installs of latest mods from GitHub clones. Solved by switching to mobf_2_6_dev branch as @numberZero suggested. Thank you!
17:49 IcyDiamond     hm ok
17:50 JDCodeIt       At least that solved it for Guard13007
17:51 IcyDiamond     animals_modpack has no 2.6 support tho?
17:51 IcyDiamond     aw
17:51 rubenwardy     JDCodeIt: 0.5.0 is a major release which breaks network compatability
17:52 rubenwardy     (Minetest uses 0.Major.Minor, which is a bit stupid imo - but what it is)
17:52 rubenwardy     there's also a mod breakage - mods need to update their offset for player models
17:53 rubenwardy     for the most part mods won't be broken
17:53 rubenwardy     and worlds won't be at all
17:54 JDCodeIt       What is the upgrade path for the Players directory going to sqlite?
17:54 sofar          run the conversion from the cmdline
17:55 JDCodeIt       Cool.
17:55 sofar          I think it might even automatically do it at the end
17:55 rubenwardy     I recommended avoiding that
17:55 rubenwardy     until 0.5.0
17:55 rubenwardy     I found it to cause massive disk I/O
17:55 rubenwardy     (on my HDD)
17:56 rubenwardy     0.5.0 includes a small bug fix, not sure if the problem is completely fixed though
17:56 JDCodeIt       What is the disk i/o issue? fflush called too often?
17:56 rubenwardy     loads of -journal creations
17:57 rubenwardy     like, maybe up to 50 per save which is every 10(?) seconds
17:57 JDCodeIt       There are some settings to make sqlite less bullet-proof. Did you try it?
17:57 rubenwardy     shouldn't need to, it shouldn't write so much
17:58 rubenwardy     https://github.com/minetest/minetest/issues/6608
17:58 IcyDiamond     k whatever im not gonna start the server then
20:57 Viper          hi
20:58 Viper          is there any ETA of 0.5?
21:00 Fixer          when it is ready
21:00 Fixer          just use 0.4.16/0.4.17
21:00 Viper          Fixer: when devs plan to release 0.5 stable
21:00 Fixer          Viper: please consider installing https://github.com/cx384/storage_interface on your server
21:00 Fixer          Viper: iirc there is no clear date
21:01 rubenwardy     June/July ish
21:01 rubenwardy     could be later
21:02 Fixer          +1/+2/+N years later
21:02 deltasquared   rubenwardy: are there any blocking bugs at least? (forgot the github tag)
21:02 rubenwardy     we should totally do a HL3 on this
21:02 rubenwardy     just delay the date everytime someone asks
21:03 Fixer          rubenwardy: i'm more worried about ---
21:03 deltasquared   "can't pipe items out because of the pipeworks API" hmmmm
21:04 deltasquared   I'd have to see if I could ask the guy why this would be so
21:04 deltasquared   though, I'm less familiar with the item transport code than I am with the fluid pipe code
21:05 deltasquared   hmm, offski times
21:08 Viper          rubenwardy: nothing wrong with delay, as long no ugly bugs sneak into stable
21:08 rubenwardy     hopefully not
21:08 rubenwardy     I foresee 0.5.1 being very close to 0.5.0, to provide bug fixes
21:09 rubenwardy     close meaning a month rather than 6
21:18 Sokomine       MTBuilder: (hm, not there right now?): someone else reported a problem with the traders as well. i need to check it
21:40 rdococ         <rubenwardy> we should totally do a HL3 on this
21:40 rdococ         hehe
22:52 JDCodeIt1      Hi all, did some more searching for the memory issue in 0.5.0, but didn't find the culprit yet. Starting the client, joining a game exiting the game, then repeat has the following memory usage by minetest: 55MB, 1.252GB, 844MB, 1.400GB, 1.237GB, 1.496GB, 1.503GB, 1.567GB, 1.571GB. Yes, there were actually times returning to the menu resulted in higher memory usage.
23:50 paramat        !tell JDCodeIt1 thanks, are you able to open an issue in Github about this? it looks possibly like the mesh cache isn't cleared when exiting to menu, maybe because the player might return to the same world?
23:50 MinetestBot    paramat: I'll pass that on when JDCodeIt1 is around
23:53 MinetestBot    02[git] 04paramat -> 03minetest/minetest_game: Ore distribution: Deeper iron, diamond and mese block, tune gold (#2107) 138d8f2f7 https://git.io/vxArR (152018-04-11T23:51:56Z)