| Time |
Nick |
Message |
| 01:15 |
hmmmm |
celeron55: what is 'if(!dst_can_put_count != -1){' supposed to do in inventorymanager.cpp:376? |
| 04:20 |
|
Bad_Command joined #minetest-dev |
| 04:20 |
|
Bad_Command joined #minetest-dev |
| 06:26 |
|
sfan5_ joined #minetest-dev |
| 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*/<code here> 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:48 |
|
saschaheylik joined #minetest-dev |
| 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:36 |
|
Calinou joined #minetest-dev |
| 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 |
|
sfan5 joined #minetest-dev |
| 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:41 |
|
Calinou joined #minetest-dev |
| 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:10 |
|
Calinou joined #minetest-dev |
| 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:33 |
|
hmmmm joined #minetest-dev |
| 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:30 |
|
saschaheylik_ joined #minetest-dev |
| 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/ |
| 23:55 |
|
BloodyFire joined #minetest-dev |
