Time Nick Message 01:15 hmmmm celeron55: what is 'if(!dst_can_put_count != -1){' supposed to do in inventorymanager.cpp:376? 06:30 celeron55 hmmmm: ehm... that looks wrong 06:30 hmmmm you have an extra ! in there 06:30 hmmmm and did you really mean for it to be initialized to 0xffff? 06:32 hmmmm wait actually, while you're here, i need to ask you a few style questions: 06:32 hmmmm i've began dividing up the_game() into several, sensibly-sized subroutines but it requires making some of the variables that were local to be global - i noticed you vary quite a bit between prefixing globals with g_ and not 06:33 hmmmm what would you want them to be? 06:33 celeron55 g_; but i don't think i'll accept a version of game.cpp made with globals 06:34 hmmmm it's nonsensical to believe that you'll have multiple instances of a client 06:34 celeron55 also can you point to a global variable that does not have g_? 06:34 celeron55 i don't remember any of such 06:36 celeron55 hmmmm: yes but re-initializing a game is way more robust if the state is stored in a class; now the state is stored in a function, which is handy too 06:36 hmmmm ah found it 06:37 hmmmm main.cpp, main_settings and main_profiler 06:37 hmmmm there might be others, those are just two i've found 06:37 celeron55 they are not exposed anywhere else than the single source file 06:37 celeron55 thus g_ doesn't really matter 06:37 hmmmm so more accurately, g_ is for a global ment to be exposed via a header 06:38 hmmmm well, all globals that are actually global are exposed through a header 06:38 hmmmm so that's a moot point 06:38 hmmmm you switch between if(){ and if()\n{ 06:38 celeron55 ehm... well, kind of; if you use that definition, then "local globals" are "static variables" 06:38 hmmmm what's with that? what should i follow? 06:40 celeron55 i nowadays use if()\n{ when there is much stuff in the block so that \n doesn't cause much overhead in number of lines, or if the condition is so large it makes it much cleaner 06:41 hmmmm there are many cases where if()\n{ } is encasing a single-line body 06:41 hmmmm i find that it bloats the code 06:41 celeron55 where? 06:42 hmmmm lots of stuff in the_game() 06:42 hmmmm if(server != NULL) 06:42 hmmmm { 06:42 hmmmm /commented out code here 06:42 hmmmm sever->step(dtime); 06:42 hmmmm } 06:42 hmmmm another blank line here 06:42 hmmmm another multiline comment here 06:43 hmmmm i really don't mean to be harsh 06:45 celeron55 i don't think especially that part matters at all, as it is one of the things having the fewest lines in there yet it does like most of the stuff; but obviously they are so because there has been other code in there 06:45 hmmmm i don't think there needs to be as many comments around, especially after they've been subdivided into smaller functions - instead of \n/*\n\tProfiler\n*/ it could be something like profiler = profiler_init(); or something, which will be quite self-documenting 06:45 hmmmm eh, it's more about consistency 06:45 hmmmm if there's a style thing you don't like, you'll just change it to your liking anyway, right? 06:46 celeron55 but yes, nowadays i use more like "/* Profiler */" for topic-like comments and "// rtfm" for some explanations 06:46 hmmmm i want to write code so that you won't have to go through all of it and make a million changes before you merge, but at the same time it's good to not be anal about the style matching perfectly (perhaps) or maybe if the style were easier to immitate if it had more consistency (preferred) 06:46 celeron55 you can get rid of the /*\none-line\n*/ stuff 06:47 celeron55 (using that way) 06:47 hmmmm also when do you decide to make a new code block without a control structure? those sorts of things feel misleading and add more indentation than is necessary 06:47 hmmmm if this were a C90 source i'd be more understanding, but it's not 06:47 celeron55 i'm just extremely lazy reworking coding style; i don't like commits that don't actually change anything 06:48 hmmmm well 06:48 hmmmm there's a bug in the_game() somewhere that i need to fix, but before i can fix that, it needs to get more managable 06:48 celeron55 i add a code block when i expect to have stuff that i don't want to have a larger scope for 06:51 hmmmm are you aware that your keyboard input handling code can only handle one key per frame? 06:52 celeron55 no 06:52 hmmmm if you removed the 'elses' from those 'else ifs' in that huge chain, it'd fix that 06:52 celeron55 apparently it is so :-D 06:52 celeron55 obviously yes 06:53 hmmmm oh i also wanted to ask you, the first thing that jumped out at me today: what's the point of the filecache? 06:53 celeron55 what filecache 06:53 hmmmm filecache.cpp 06:54 hmmmm it's a directory with a bunch of files with the SHA1 of their contents, and it's presumably there to speed things up by not having to fetch them the 'hard' way ... ? 06:54 celeron55 it's used in managing the mod-defined media files that the server sends to the client 06:54 hmmmm oh 06:54 hmmmm i thought the client was the one that handled those 06:54 celeron55 which should be kind of guessable 06:54 hmmmm i didn't realize the server sent textures and sounds* 06:55 celeron55 you can play on a server without having any "game" and any mods installed on the client 06:56 hmmmm that's pretty neat.. 06:57 celeron55 anyway, you can "fix" the scopes that are not really needed if you want to 06:57 hmmmm what is farmesh? can the end user use it in any way? 06:57 sfan5 yes 06:57 celeron55 it's an experimental way of drawing a very guessy landscape to very far 06:57 sfan5 enable_farmesh = 1 in the config file 06:58 hmmmm ahhhhh 06:58 hmmmm it's not enabled by default 06:58 celeron55 it does not really work in the general case, and it is horribly unoptimized, and it doesn't even look good... except at night sometimes 06:59 hmmmm oh yeah 07:00 hmmmm i want to have a 'generating map' screen like in Minecraft - totally optional, of course. a user-specified number of blocks in each direction is pregenerated around player's origin upon making a new map 07:00 hmmmm the problem is that when you get dumped into a new map, then it starts generating the map. you don't really know where to explore first because nothing exists yet 07:01 hmmmm unless you have a really fast computer and generating terrain is fast 07:02 celeron55 that is quite nontrivial 07:03 celeron55 let's not thing about it now 07:03 celeron55 think* 07:03 hmmmm i know... maybe you can hide the game from drawing and instead have a loading screen while the game is running and not accepting input (but the player sits there just letting terrain generate) 07:04 hmmmm I saw you moved some of the mapgen back into the engine 07:05 celeron55 eh? 07:05 celeron55 i haven't moved any mapgen code from anywhere to anywhere in a LONG time 07:05 hmmmm no? 07:05 hmmmm i could've sworn you had more than just ore and papayrus being spawned in lua 07:05 hmmmm maybe i'm confusing it with something else 07:07 celeron55 anyway - the original problem was splitting game.cpp, and my opinion still is that the game state should be stored in a deletable structure; if not the stack as in a function, then most likely a class because this is C++ 07:08 hmmmm no, you made a good point and i agree, what will be globals should probably be instance variables 07:08 celeron55 yes, more specificially an instance of a class 8) 07:09 hmmmm so like, what, class GameState? 07:09 hmmmm GameInstance 07:09 hmmmm TheGame 07:11 celeron55 i guess it can be just Game 07:12 hmmmm ok 07:12 celeron55 that is not used and is not likely to be used for anything else anyway 07:13 hmmmm another reason why the_game ought to go on a diet is because i suspect it seriously trashes the icache 07:14 celeron55 why wouldn't something else doing the same things do that? 07:15 celeron55 isn't there a tool in valgrind for that? 07:15 hmmmm because look at how big it is.. all the actual rendering code is probably very compact since it's SIMDy sort of stuff 07:15 hmmmm i dunno 07:15 celeron55 cachegrind it is called, i see 07:15 hmmmm have you ever done any profiling? 07:16 hmmmm i mean hardcore profiling 07:16 hmmmm slash optimizing 07:16 celeron55 depends on what you call hardcore 07:17 hmmmm like sat down with a piece of code for hours and made it as fast as possible 07:18 hmmmm probably not possible at the level of abstraction you're working with though.. your code probably spends something like 80% of the time pointer-chasing 07:18 celeron55 that doesn't sound too useful to me, but some for some things not a small amount of time has been used for optimization 07:19 celeron55 which does fullfill your definition 07:19 hmmmm i tend to do it when i'm bored 07:19 celeron55 -some 07:20 hmmmm also unrelated, but when you have do { } while(0); for the purpose of using break;, don't you think that's a sign it's time for a separate function? 07:20 * VanessaE wanders in 07:20 celeron55 if the block of code isn't needed anywhere else, no i don't 07:20 hmmmm =/ 07:20 hmmmm that kind of attitude leads to the 2000 LoC monsters 07:23 celeron55 well not exactly 07:23 celeron55 the problem with those things in game.cpp is that other functions can't directly access the local variables of the_game() 07:23 celeron55 if you put those in a class, you'll have easy time putting them in functions 07:24 celeron55 which in some cases just obfuscates code because you don't know what instance variables are used in whatever method call 07:24 celeron55 but anyway 07:25 hmmmm classification is good 07:26 hmmmm if that big bunch of instance variables is subdivided into even smaller subclasses, that'll help performance too 07:27 hmmmm because your actual structure in memory for that class will exist longer in the cache because it's smaller 07:28 celeron55 the only reason that can use cache more efficiently is that if the class mainly uses it's own instance variables, which are at the same place in memory, rather than the_game() using a few of it's huge number of variables from a larger memory footprint 07:30 celeron55 there isn't very much of persistent variables in the_game though, probably like 1kB 07:30 celeron55 like, on the stack 07:30 hmmmm yeah, true.. still kind of big though 07:30 hmmmm scary to say the least 07:30 hmmmm heh, what's up with the for (;;) { if (device->run() == false || kill == true) break; ? 07:31 hmmmm i'll fix that... 07:33 hmmmm / Event manager EventManager eventmgr; <---- i know that's definitely an event manager. 07:34 hmmmm haha, i'll shut up about this and just do it 07:34 hmmmm but tomorrow because it's 3:30am 07:34 celeron55 those kinds of comments are like topics 07:34 celeron55 they separate code into meaningful pieces 07:35 hmmmm they were not /**/ 07:35 hmmmm they should be though, no? 07:35 celeron55 as you can see, there are many managers in there, each taking VERY different amounts of code to create 07:35 celeron55 well yes, they could 07:57 celeron55 hmmmm: oh by the way 07:58 celeron55 hmmmm: if you want to improve performance CPU-wise, there is one part of whole Minetest that is a horrible CPU hog for no good reason 07:58 hmmmm ? 07:58 celeron55 hmmmm: it is the selection of map data to be sent from the server to the clients 07:58 hmmmm i'll take a look 07:59 celeron55 i don't know how horrible it exactly is, but it's... ehm... i don't even want to look at it 08:00 celeron55 here is some related work https://github.com/DavidMikeSimon/minetest/commits/client_requests_blocks 08:00 VanessaE I was about to ask about that. 08:01 celeron55 i don't know how much in a workable state that is; but at least he removed multiple important parts of the code while doing it 08:01 celeron55 (which need to be put back in) 08:03 celeron55 of course moving the selection from the server to the client instead of just fixing the existing way is completely overkill, but it might be better otherwise 08:03 celeron55 not sure 08:32 saschaheylik celeron55: you mean blocks being sent that are actually way too far away to matter? 08:32 celeron55 no 08:32 saschaheylik well they are 08:32 celeron55 depends on your render distance 08:33 saschaheylik there are chunks being loaded first that wont remotely be visible 08:33 celeron55 but the calculation of what to send wastes CPU 08:34 saschaheylik i think it should place highest priority on the chunks immediately next to the player and on those that are visible 08:34 saschaheylik and then continue loading those further away 08:34 celeron55 it does 08:34 saschaheylik when i saw it some of the furthest were being loaded first 08:37 VanessaE I have noticed an oddity in the loading of chunks, but I don't know how to classify it 08:37 celeron55 in some situations that might happen, for example if the map generator has already generated them but hasn't yet generated a closer one, or if you have moved and the system hasn't yet gotten to check what now is closest to you 08:38 celeron55 generating or loading from disk, actually 08:38 VanessaE celeron55: indeed I've seen something like that: sometimes I can see chunks loaded that depict part of the inside of a distant structure *before* the outside has been loaded. 08:40 celeron55 i don't think it can ever be perfect because it is such a dynamic system, but i guess it could be improved from what it is now 08:41 celeron55 it does work and doesn't crash, which tends to suffice, though 08:42 VanessaE well for example, on redcrab.sueret.net:30401, there is a "lava pyramid". If the mapgen has to reload the area, sometimes I can see the trees and other objects inside the pyramid before the wall between them and me has been loaded (IOW, more data is being received than I should need at that point) 08:43 celeron55 anyway, it should be rewritten because it is badly designed and then we will have completely different glitches 08:45 celeron55 saschaheylik: as you can see, there is pretty much an infinite number of things to work on even if nothing actually new is made 8) 08:45 celeron55 (which hopefully doesn't surprise you) 09:04 saschaheylik yeah sure 09:05 saschaheylik it would be easier if we had more people 09:06 saschaheylik maybe some "advertising" on game dev boards or whatever couldn't hurt 09:09 celeron55 it will hurt more than help unless there is a clear plan AND and existing framework on which people can code 09:10 saschaheylik right, plan first. what do you mean by framework on which people can code? 09:10 saschaheylik there is code. i can code on code. 09:11 celeron55 it's hard to simultaneously code on the same code unless the code on which you're coding is designed to accomodate that 09:12 celeron55 basically, everybody needs to be working on a different module-kind of a thing 09:13 saschaheylik so how would we go about making it more "contributable" ? 09:13 saschaheylik "making everything a module-kind of thing" is rather vague 09:14 celeron55 it is intended to be vague 09:14 saschaheylik but i can't act on vague 09:15 saschaheylik do you have something like an example of the desired outcome? 09:15 celeron55 the answer completely depends on what you would want the contributors to do 09:15 saschaheylik what is there contributors are not doing 09:16 saschaheylik well we could avoid the problem by being organized about who is working on what and when 09:16 saschaheylik redundancy isnt very useful anyways 09:18 celeron55 alternating the person who actively codes and having others think and plan is sometimes a good way of doing things, but it requires people who already are quite familiar with the codebase 09:18 celeron55 i have liked working with a single other person on minetest like that 09:19 saschaheylik i can imagine. 09:19 saschaheylik we could surely split the "team" in groups and pairs 09:20 celeron55 but really, adding more people does not mean more progress 09:20 saschaheylik depends on what they are doing 09:20 celeron55 unless they can work 99% independently of each other 09:20 saschaheylik if they try to all work with all others at the same time that wont work 09:20 saschaheylik but if we split them in teams and assign tasks 09:20 celeron55 which we are not going to achieve, EXCEPT in one thing: if they just add content by using the Lua interface 09:21 celeron55 it has been designed exactly for that, people adding stuff independently 09:21 celeron55 and it does work for that 09:21 saschaheylik of course there has to be some planning as to what the particular "tasks" are 09:22 celeron55 for all this, there needs to be a goal, and for making the goal, we need to know beforehand how much resources we are going to have 09:23 celeron55 in addition to actually having a proper idea and stuff 09:23 saschaheylik we can't establish a better organized and scalable way of working with each other without knowing what we are going to work on? 09:23 saschaheylik i disagree 09:24 celeron55 well yes we can, i guess - but it will be kind of only "on paper" until there is a goal 09:24 celeron55 and people aren't likely to come in without a clue of a goal 09:26 celeron55 also, creating a goal with a large random group of people is not a good idea; unless they are extraordinarily creative people, only something very generic will come out of it, because it just averages everybody's opinions 09:26 celeron55 it can be good for utility software, but not for a game 09:27 saschaheylik the group of people is not random 09:27 celeron55 but a large random group of people can work on a pre-set goal 09:27 saschaheylik its the group of people which responded best to whatever "advertisement" we posted 09:27 celeron55 yes, and the advertisement has the, or a part of the, goal 09:27 celeron55 which they start to follow 09:28 celeron55 which makes them not random 09:31 celeron55 if the goal would be adding buildable entities to minetest, there should already exist a base framework for that made by somebody familiar with much of the existing design - then people can add all kinds of functionality on top of that without interfering with each other, at least ideally 09:32 VanessaE I'm curious about something, since this came up again. 09:33 saschaheylik VanessaE: go on. 09:33 VanessaE a "buildable entity" would be a custom block built by the user that does something unusual? 09:33 celeron55 no. 09:33 saschaheylik mobile reations made from blocks 09:33 saschaheylik *creations 09:34 saschaheylik like a car for example 09:34 VanessaE ok 09:35 VanessaE the reason I asked is, in recent versions of the Animals mod, the author figured out a way to abuse the game's ability to wield an object and then drop it, such that now it bears rudimentary 3d mobs, without any changes to the core game code. 09:35 VanessaE couldn't that same exploit be massaged to do the same for these buildable entities? 09:35 Calinou a real mob system NEEDS core game code modifications, else it will always be inefficient. 09:35 celeron55 at some point we need to move into a mode where people will design the details and code it, and everybody tries to not ask anything from anyone - that is the way you get stuff done 09:35 Calinou you should not use exploits to make efficient mods 09:36 saschaheylik celeron55: that is why we need "working procedures" that keep everyone organized 09:37 saschaheylik lists of steps to follow that end everyone up working friction-less 09:37 saschaheylik something like this should've been done a long time ago 09:38 saschaheylik seeing that this is a problem of all open soruce projects 09:38 celeron55 well, feel free to write a proposal, in here for example: http://minetest.net/wiki/doku.php?id=dev:proposals 09:38 Calinou there's a workflow proposal on the wiki 09:38 celeron55 Calinou: eh 09:38 celeron55 it's mostly completely unrelated and old as hell 09:38 celeron55 Calinou: the way you can help things get organized is stfu or gtfo 09:38 VanessaE I'm just trying to think of ways to reduce the amount of code needed to create that feature "officially" is all. 09:40 celeron55 saschaheylik: this i call the "minetest chaos development scheme" 8) 09:40 celeron55 saschaheylik: and yes, i don't like it 09:40 saschaheylik oh im familiar with that one, having worked as a consultant for a major telecom firm 09:41 saschaheylik it's why i left 09:41 saschaheylik im just wondering why no other open source project started developing a system of development 09:42 celeron55 saschaheylik: i just can't make it into anything else without somebody else who is actually capable of doing engine work; kahrl disappeared after half a year of being awesome - you might be the one another that the project needs; dunno 09:42 celeron55 i'm quite a pessimist 8) 09:43 celeron55 saschaheylik: if you have just one lead developer and everybody else mostly tinker with very small things or content only, you get only ridiculed if you try to set up anything like that 09:43 saschaheylik in the world i am used to, you get ridiculed for anything smart 09:43 celeron55 with kahrl i developed mostly as a pair, independently of the community; it was plenty of development speed for me, and due to that we now have the Lua API 09:45 celeron55 ANYWAY, go ahead and propose something in particular; chances are it'll be useful 09:45 saschaheylik k i will 09:46 celeron55 i won't hesitate to kick you in the ass if it doesn't look like so, though 8) 09:46 VanessaE I can vouch for that! 09:46 saschaheylik i do prefer the existance of constructive criticism 09:47 * VanessaE still bears boot marks from recent ass-kickings ;-) 09:48 VanessaE really though, there is another problem you are both overlooking 09:48 saschaheylik probably not only one 09:49 celeron55 i am overlooking a million problems all the time 09:49 celeron55 i couldn't do anything otherwise 09:49 VanessaE well, one in particular stands out. c55, I've already brought it up with you before and as I recall you agreed somewhat grudgingly: code, features, etc. contributed from outside the core team are just as important, if only to those people, as code written by you and others. 09:50 celeron55 ...wut? 09:50 saschaheylik did anyone say differently? 09:50 VanessaE well that didn't come out to clearly. 09:50 VanessaE what I meant is, "useless", "horrible" and similar comments are *not* constructive. 09:51 VanessaE something you consider useless might end up floating to the top of a "most desired features" list one day. 09:52 celeron55 eh 09:53 celeron55 that shall be all i'll reply to that 09:53 saschaheylik i think the idea was to focus on those things that contribute most to the game experience right now 09:53 saschaheylik rather than things that could be considered eastereggs or whatever 09:54 saschaheylik which are a waste of productivity 09:54 VanessaE saschaheylik: of course. But the problem is, how do you define "contributes to the experience"? 09:54 celeron55 saschaheylik: how is that relevant for now? 09:54 celeron55 VanessaE should stop, she is just clogging up the discussion 09:54 saschaheylik right 09:56 VanessaE celeron55: I rest my case. 10:02 celeron55 the awesomest discussion is no discussion with mutual agreement 8) 10:09 VanessaE says the guy who dons his chanop status after 4 minutes of idle channel... 10:09 VanessaE :) 10:10 celeron55 i like being suspicious 10:10 celeron55 umm... dubious... or whatever 10:11 celeron55 this language has too many words! 10:16 VanessaE To be honest, as if I wasn't anyway, I'm hesitant to say anything anymore. Besides, there are only 171,000 or so words. Should be a piece of cake :-) 10:22 celeron55 i considered answering something more particular to that, but wont, because it would only cause more asshurtery; just don't say anything for now 10:22 VanessaE ok. 10:23 celeron55 it is unfortunate, but there is no solution to it; i just am not interested at all of things you tend to have in mind 10:27 VanessaE Which is why I've taken to doing what you asked and just filing github issues as they come up. 11:49 saschaheylik what if the world is a single object which can "split" itself in multiple parts of itself, each of which capable of having a different location associated with it 11:51 saschaheylik i mean if we start splitting cubes into 8 smaller parts of them 11:51 celeron55 not going to work 11:51 saschaheylik we are not far from splitting them diagonally to make cornerpieces 11:51 saschaheylik which is not far from splitting in any direction 11:52 saschaheylik why not? 11:52 celeron55 now you are talking of two separate things, as far as i can tell 11:52 saschaheylik well, visibly they are seperate 11:53 saschaheylik but having the same parent universe-object-node 11:54 saschaheylik actually as far as the game is concerned they could probably be treated as 2 completely different objects 11:55 celeron55 i don't really get what you are trying to achieve 11:55 saschaheylik if we have one cube 11:56 saschaheylik and slice it so we have just as many part-cubes for it to contain the shape of the game world 11:56 saschaheylik (all parts that are air have type:air) 11:56 celeron55 that does not sounds like you had thought about how it would translate to actual code at all 11:56 celeron55 -s 11:57 saschaheylik a cube that can be split and combined 11:57 saschaheylik a quadtree 11:57 saschaheylik uuh 11:57 saschaheylik octree 11:57 celeron55 the reason why you can make a large voxel world like mine* has is only because it is a simple and light-to-handle lienar array 11:57 celeron55 linear* 11:58 saschaheylik but you have to store one voxel object per smallest measure of space possible required 11:58 celeron55 yes i do, and it is fine to me 11:59 celeron55 if you want to do something else, better start an another project; this one isn't going to get changed that way - that is way too fundamental a change 12:00 saschaheylik if it has to be changed at all 12:01 saschaheylik no idea how to explain this 12:01 saschaheylik but its too interesting not to think about 12:03 celeron55 i am quite fed up with all kinds of minecraft-octree sillyness; for example reddit is full of it and nobody actually gets anything done with it because it's just infeasible 13:15 celeron55 oh, this exists https://github.com/matttpt/minetest/commits/commands-to-lua 13:18 celeron55 i guess i'll merge it 13:19 celeron55 altough i should release 0.4.2 as stable before doing that... ehm... well, let's just hope there aren't bugs 13:20 Calinou +1... lua commands are far better for moddability 13:25 celeron55 i like matttpt, he just went and converted all the commands to lua a bit after i explained why i wanted his /mods command in lua, and his code seems of reasonable quality 14:05 BloodyFire celeron55: Is there a current todo list or something I can throw a look on while learning stuff for an exam? :> 14:13 celeron55 holy shit this merging and bugfixing is tiring 14:15 celeron55 BloodyFire: not really, but if you're into bugfixing, fix this https://github.com/celeron55/minetest/issues/187 14:17 celeron55 or well, there is the issue list (https://github.com/celeron55/minetest/issues) and then there is http://minetest.net/wiki/doku.php?id=roadmap:roadmap and http://minetest.net/wiki/doku.php?id=dev:random_things_by_celeron55 14:17 celeron55 but if you want to be useful, try #187 14:51 BloodyFire What's the preferred way of checking for free space? One could write a temporary file or check the free space with something OS specific. 14:52 BloodyFire Like posix_fallocate() on Linux and GetDiskFreeSpaceEx() on Windows. 15:11 celeron55 you just write a temporary file, and if it doesn't file, move it (using filesystem commands, not file writing commands) over the file that actually is the destination 15:11 celeron55 eh 15:11 celeron55 s/doesn't file/doesn't fail/ 15:12 celeron55 that is how all proper software do it 15:12 celeron55 a move function needs to be added to filesys.{h,cpp} for that 15:22 BloodyFire Alright, sounds logical. 16:44 hmmmm I just opened up server.cpp and i see this DSTACK(__FUNCTION_NAME) everywhere 16:45 celeron55 debug.h 16:45 hmmmm i know 16:45 celeron55 it's kind of a legacy thing, it's not really used these days 16:45 hmmmm it's just that every single call, a new classs is being made, a snprintf is being called 16:45 hmmmm which makes another class 16:45 celeron55 it only exists in functions that have large overhead 16:45 hmmmm and all this other stuff 16:45 celeron55 never in small quick ones 16:47 hmmmm alright 16:48 celeron55 the debug stack has proven to be basically completely useless though 16:48 celeron55 maybe i'll remove it some day 16:49 hmmmm but i was just going to mention, if you want a nice backtrace, you have a lot of options such as libbacktrace and nested exception handlers, all of which are very lightweight 16:53 hmmmm i'm kind of concerned with serializeString 16:54 hmmmm we don't know how std::string stores its data - that's implementation dependent. so if it used wide characters, that would potentially be dangerous by accessing unaligned memory 16:55 hmmmm actually, that's not too likely 16:55 hmmmm unless it uses UTF32 or something 16:55 hmmmm nevermind 16:56 celeron55 for std::string the type of a character is always known 16:56 celeron55 std::wstring can be 16 or 32-bit though... ehm... i think 16:57 hmmmm ah 16:57 hmmmm i figured it was more or less like a black box 16:57 celeron55 which basically sucks and we should get rid of all the std::wstring usages except those that are used for interfacing with irrlicht, which happens to use wide strings 16:57 celeron55 std::string is basically an array of bytes which always places a 0 at the end of the data 16:58 celeron55 it can be used for anything 17:02 hmmmm erm, the server tells the client when to play sounds and stop them!? 17:03 celeron55 mods can play arbitrary sounds at arbitrary positions, and then there are sounds defined by definitions that the client knows when to play 17:03 celeron55 the client can only act based on "static" definitions because it does not run any mod code 17:04 hmmmm why not? 17:04 hmmmm if i were doing this i would probably have the client download the lua scripts 17:04 celeron55 because minetest 0.4 has been designed as such 17:05 celeron55 it is always safe to go on a server and mods have access to everything lua can do 17:05 celeron55 and it has proven to work well 17:06 celeron55 everything, including that, was considered, but this is what i and kahrl ended up doing 17:06 hmmmm ok 17:07 hmmmm what happens if the server throws a ServerError in step()? 17:07 celeron55 dunno 17:07 hmmmm at that point, m_step_dtime is still locked, right? 17:07 hmmmm well nevermind that 17:07 celeron55 lol 17:07 celeron55 no it is not locked 17:07 hmmmm i personally think that at some point, that mutex should be removed and it should be just an atomic operation 17:08 celeron55 aaargh 17:08 celeron55 why? 17:08 celeron55 it's done like once in 50 or 100 milliseconds, a single mutex at that interval gives no overhead 17:08 celeron55 stop stopping into details like that, that is not productive AT ALL 17:09 hmmmm it all adds up 17:09 celeron55 you can't add up something that rare to anything in a program of this size 17:10 celeron55 you're looking into the wrong places 17:10 hmmmm anyway i am 17:10 celeron55 there are performance hogs in the code 17:10 celeron55 you are assuming very wrongly if you think the CPU usage is caused by that small things 17:10 hmmmm i was looking for the part where the server selects the map data 17:10 hmmmm and these sorts of things just pop out at me 17:10 celeron55 seriously 17:11 celeron55 i'll not talk to you anymore if you don't focus on things that matter 17:11 celeron55 i need to choose how to spend my time 17:11 celeron55 and surely you don't have infinite time at your hands either 17:13 hmmmm notice that i said 'at some point' - i hope you don't believe that i thought it was of critical importance 17:13 celeron55 i don't think that one should be cared about _ever_ 17:14 hmmmm well 17:14 hmmmm locks every 2 milliseconds sounds bad to me, sort of 17:14 celeron55 it's every 50 or 100 or even 200, depending on server configuration 17:15 hmmmm what is dtime measured in? 17:15 celeron55 there are locks that lock WAY more often than that 17:15 hmmmm not milliseconds? 17:15 celeron55 seconds 17:15 hmmmm oh 17:15 celeron55 time in minetest is always in floating-point seconds 17:15 celeron55 ....except in where it isn't 17:15 celeron55 but anyway 17:15 hmmmm that's probably good to know 17:16 hmmmm when it isn't, it's not a float then? 17:16 celeron55 usually so 17:16 darkrose lol 17:17 hmmmm alright so what am i looking at here 17:17 hmmmm SendBlockNoLock? 17:17 hmmmm er rather, SendBlocks 17:17 celeron55 Server::SendBlocks and RemoteClient::GetNextBlocks 17:18 celeron55 (the former calls the latter) 17:19 hmmmm yeah that's pretty bad 17:19 hmmmm i assume the performance hit is really caused by the two locks in combination with the sort operations and what not 17:19 celeron55 it's the horriblest thing in minetest i know of (depending a few priorization factors, though) 17:21 celeron55 also note where it is called 17:21 celeron55 Server::SendBlocks 17:21 celeron55 and where Server::AsyncRunStep is called 17:22 celeron55 oh dog 17:22 celeron55 i didn't remember it was this bad 17:24 hmmmm this is going to take a while 17:24 hmmmm there's no clear, obvious fix for it 17:25 celeron55 the algorithm for sending blocks needs to be pretty tight 17:26 saschaheylik arguing with non-programmers can be so exhausting 17:26 celeron55 it needs to be able to respond to player movements quite quickly (it is responsible for triggering map generation too) yet it needs to be able to fill the connection with data when there is nothing special happening 17:26 celeron55 the latter with minimal load 17:27 hmmmm don't tell me that this is the code responsible for the map generation stalling 17:27 hmmmm oh man 17:27 celeron55 ehm... no it isn't? 17:27 hmmmm it's not? 17:27 celeron55 or depends 17:27 celeron55 map generation is slow because generating a shitload of voxels meaningfully is slow 17:27 hmmmm well when i would play minetest, i'd go up to the edge of the map, and it'd just sit there 17:27 hmmmm and i'd have to look downward to minimize draw time 17:27 hmmmm and i'd just have it sit there for like a minute or two 17:28 celeron55 sit there never ending or sit there for unnicely long? 17:28 hmmmm and maybe by the time i got back the map would be generated 17:28 hmmmm well you see 17:28 celeron55 okay, then it can be because of that code 17:28 hmmmm most of the time it was just unnicely long 17:28 hmmmm there was a time when it was never ending though 17:28 hmmmm i disabled the mud flow from the map gen and the map gen was super fast 17:28 hmmmm except when i got up to the edge 17:29 celeron55 unnicely long time can be because of map generation being heavy, but a bit more than that (or if you look at the CPU graph, you'll notice easily) can be because of that code 17:29 hmmmm and in this one instance there was no cpu time being taken up 17:29 hmmmm it was just sitting there 17:29 hmmmm that is a more rare case though 17:29 celeron55 i have seen it, but it is quite rare 17:29 hmmmm but completely unacceptable. 17:29 hmmmm if we find it that'll be great 17:29 saschaheylik celeron55: do you know where i can find the part where the tools are being "extruded" from images when you connect to a server? 17:30 celeron55 saschaheylik: the_game() calls something in client which calls something in ItemDefManager 17:30 saschaheylik ok thx 17:31 celeron55 updateTexturesAndMeshes 17:57 saschaheylik does the profiler measure the time it takes to join a server? 17:59 saschaheylik cal 17:59 saschaheylik celeron55: 18:17 saschaheylik guess it doesnt 18:57 saschaheylik_ VanessaE: are you sure the extrusion process takes that long? 18:58 saschaheylik_ because i dont really notice anything 19:02 saschaheylik_ also im dont think it could much be avoided 19:05 celeron55 you need to use huge textures (512px) on a huge number of items (hundreds) to have problems 19:05 celeron55 the extrusion is very simple and has been designed for the regular 16x16 textures 20:04 sfan5 making minetest compatible with lua 5.2.1 seems to be a lot of work: http://pastie.org/4462278 21:19 BloodyFire Does anyone know how to append a file to another using linux filesystem calls? 21:20 celeron55 ehm... append? 21:27 BloodyFire I try to get one file out of two separate files withoug an additional copy. 21:28 BloodyFire Because if you write a temporary file to check the disk space and then copy it at the end of the original file, you've got two copies of the same file and needs additional disk space. 21:29 BloodyFire So I hoped there is anything that shifts inodes a little bit to do it the effective way. :D 21:29 BloodyFire *need 21:29 celeron55 eh 21:29 celeron55 that is not going to work 21:30 celeron55 the point of writing the complete contents into a file and then moving it over the other is that the other will be deleted and the filename of the deleted one will just be made to link to the newly written data 21:30 celeron55 writing of data elsewhere is not to check if there is space, it is to WRITE THE DATA. 21:34 BloodyFire I'm too tired right now. So, you don't need the old file? You could simply rewrite both, env_meta.txt and ipban.txt? 21:34 BloodyFire *files 21:41 BloodyFire I thought it's all about checking for disk space and if writing fails or not, but if it's only about replacing the old file that way it's really simple. Somehow I've overcomplicated it. 21:42 celeron55 you write first, then delete the old file 21:42 celeron55 if you open the old file for writing, it is first deleted, then you try writing it 21:43 celeron55 -> problem 21:46 BloodyFire Yeah, I've understood. It's all about keep the original file if something fails, right? Haha, and I really looked for a kernel hacking stuff to join two files to a single one. :D 21:46 BloodyFire Alright, I'm definetly too tired. 21:46 BloodyFire s/a// 21:48 BloodyFire s/keep/keeping/