Time Nick Message 00:00 hdastwb I think it's also kind of stupid to not be "too C++y" when one is coding in C++ anyway; it's not like we're going to port the engine to C any time soon 00:01 Exio4 what is the next thing you will suggest? telling the devs to read "Design Patterns"? 00:04 hdastwb I would suggest allowing coding against the current standard instead of the old one, since it defines "nullptr" as a typesafe alternative to both 0 and NULL (which is likely only in the C++ standard for C compatibility), which often mean the same thing 00:04 Exio4 hmmmm: ^ 00:04 hdastwb but that's already been rejected since Debian is still using and older version of GCC 00:05 Exio4 the idea is waiting for having that standard everywhere 00:06 Exio4 when you compile that in an oldstable debian release after its EOL, that means you can start using C++11 00:08 hdastwb I also don't understand the hostility towards iterators; they're tools specifically for iterating things, so it makes sense to use them for their purpose 00:09 hdastwb unless the drawback is the messy syntax and overly-long types that the old C++ standard forces on one, which all dissolve with auto and ranged-for 00:13 kahrl I wrote an algorithm using std::list and iterators recently; when I saw the code after I was done, I rewrote it using std::vector and integer indices 00:14 kahrl because there were comments all over the place why this-or-that iterator is still valid after mucking about with the different lists 00:15 Exio4 now it is the time when he will say "but, if we use the new standard, the code would look amazingly nice!" 00:15 kahrl sure, now technically the algorithm is O(n^2) instead of O(n), but n is in the single digits 00:15 kahrl Exio4: heh 00:16 hdastwb iterators are out of place when used in algorithms that might invalidate them; I'm talking more about simple iteration that doesn't change the size of containers or things like that 00:17 hdastwb vector is also better in many cases than list anyway as it stores things more compactly, but it is also much harder to invalidate a list iterator 00:18 kahrl well, the only way to implement that particular algorithm in O(n) was with linked lists, and iterators are the only reasonable way to store "indices" into them 00:23 hdastwb in the link above, I would concur that there's no better way to shorten LVL without serious debugging rearrangement (though macros that rely on local names are ugly), but PPOS should really be redefined as an overload to ostream& operator<<(ostream&, v3s16), in which case v3s16's could be printed "directly" without a macro around them 00:23 Exio4 Avoid operator overloading like the plague. 00:25 hdastwb yet, this operator overloading is the standard way of adding output capability to user-defined types; it's well-defined and can simplify code immensely 00:25 kahrl I guess ostream overloads for v3s16 and v3f wouldn't hurt much 00:26 hdastwb it's like banning people programming in Java from defining tostring for their classes 00:26 kahrl it's kind of stupid that currently each cpp file defines its own PP() or PPOS() macro 00:26 Exio4 kahrl: isn't there any "common-defines" file? 00:26 Exio4 iirc there was one 00:27 kahrl there are many :P 00:27 Exio4 well 00:27 Exio4 if there are many who was the one defining "PP" and "PPOS" inside the file :P 00:27 kahrl irrlichttypes_bloated.h perhaps 00:28 kahrl or directly in irr_v3d.h 00:29 kahrl well the ostream variant would mean that those would have to include 00:30 hdastwb I also see a macro called myfloor in numeric.h; it looks like exactly the same thing that std::floor from defines 00:32 hdastwb yup, and then there's the swap macro which is about the same thing as std::swap, only not supporting move semantics 00:34 kahrl hdastwb: http://irc.minetest.ru/minetest-dev/2013-06-22#i_3155376 00:37 hdastwb I mainly use clang and g++; I often assume that C++ compilers work as they should… 00:37 kahrl never assume that, especially if you want your code to work on windows... 00:38 Exio4 how is the C++11 support in MSVC btw? 00:38 Exio4 from 1 to 100 i guess about -1473 or so, not? 00:38 Exio4 s/not/no/ 00:39 PilzAdam Exio4, you should ask "How is the C++ support in MSVC" and the answer would be "moderate" 00:39 kahrl Exio4: if I had to guess, NaN 00:39 Exio4 haha 00:41 hdastwb I had a beta version of the compiler that seemed to have fair C++11 support, though I hardly ever used it since I couldn't figure out where the command-line interface was… 00:42 hdastwb I'm more of a MinGW person myself 00:43 Exio4 mingw means not-directx support 00:44 hdastwb indeed 00:44 kahrl Exio4: just use a precompiled irrlicht 00:44 Exio4 would that work? 00:45 Exio4 i'm barely a linux dev :P 00:45 kahrl people have been compiling minetest with mingw so it seems to work 00:45 hdastwb binary compatibility between C++ compilers is not really assumed… 00:45 PilzAdam kahrl, my mingw builds dont have directx 00:45 kahrl hrm 00:45 kahrl do you compile irrlicht, too? 00:45 PilzAdam no 00:46 PilzAdam using the official win build 00:49 hdastwb here's how I think SWAP should be redefined when C++11 is accepted: template inline void SWAP(T& a, T& b) {T temp{move(a)}; a = move(b); b = move(temp);} 00:50 hdastwb if move semantics are implemented correctly, that should even be relatively cheap when swapping large vectors 00:55 hdastwb in the mean time, its usage could easily be simplified by defining the temporary to be of type "decltype(x)" rather than having to pass in the type as well as the arguments every time that it's called 00:56 hdastwb (or by just using templates, which will determine types automatically, only evaluate their operands once, and require more strongly that the arguments actually be of the same type) 00:56 hmmmm all this is great, but, how does it make minetest better? 00:57 hmmmm i'm sorry but it just looks and feels completely unproductive 00:58 hmmmm C++11 is a standard, of course.... but it's one that not everything supports. we worry about supporting things rather than using snazzy new features from the newest standard 00:58 hmmmm and i'm sorry, the auto thing is just plain stupid - it changes the meaning of an already established keyword 00:58 hmmmm that is not good at all 00:59 hdastwb but it does make generic programming much easier 01:00 hmmmm iterators are discouraged because of all the unnecessarily verbose syntax, the const_iterator vs. iterator nonsense, not knowing if an iterator is still valid, blah blah, blah blah blah 01:00 hmmmm getting all elements from an std::map - perfectly fine. no problem there. 01:00 hmmmm getting all elements from a std::vector - not acceptable when there's a more idomatic, intuitive way to accomplish this 01:00 hdastwb yes, and auto directly addresses the verbose syntax 01:01 hdastwb iterators are rather idiomatic; they're used in most if not all of the standard algorithms 01:01 hmmmm idiomatic in a C way 01:01 hdastwb we're not coding in C 01:01 hmmmm i don't know about *you*, but we use C++ as a superset of C with some convenient features 01:01 hmmmm you want to use C++ as an entirely different language 01:02 hmmmm with our way, it's easier to set a limit on which subset of C++ we're using 01:02 Exio4 i like that idea ^ 01:03 hdastwb C++ is an entirely different language; it contains many good features that make for increased readability, easier debugging, and better code that are not even remotely conceivable in C 01:05 hdastwb for instance, templates and the vast superiority of a correctly implemented templated sort to a C-style one 01:05 hmmmm if you want to use C++ in that manner, that's fine for your own projects, just please don't try to shoehorn an entirely different style into an already established codebase owned by no particular person 01:06 kahrl I don't know about you, but I find "Hello World!" easier during debugging than _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x99170b4 "Hello World!"}} 01:06 hmmmm but yeah, easier debugging - lol 01:06 hmmmm no idea what planet he's from 01:10 hdastwb I consider more well-defined types and object lifecycles (RAII) to make for easier debugging because they can eliminate errors or cause them to at least be pointed out earlier 01:10 kahrl or 42 vs. {> = {}, _M_current = 0xc7e44589} 01:14 hdastwb for instance, it's quite a bit easier to leak a FILE* than it is to leak an ifstream 01:14 kahrl RAII can be good and bad 01:14 kahrl one of the bad things about it that it causes much deeper ties between your objects' lifetimes 01:15 kahrl +is 01:17 hdastwb …and yet there are many times when your objects' lifetimes should automatically have deeper ties 01:17 Exio4 you need to code either ALL the code in that way, or using it in a C-way 01:18 Exio4 if you don't do that, it will end in a fucking pain to manage 01:18 kahrl RAII doesn't help much when many of the objects are allocated during one (video) frame and destroyed during another 01:20 hdastwb how about keeping the objects in a container outside of the video frame code and managing them there? 01:20 kahrl how else would you keep them? 01:21 hdastwb allocated individually on free store, I would assume 01:21 kahrl well, they are allocated individually and something manages the pointers 01:22 Exio4 pointers are too C-ish then 01:22 hdastwb they are to some extent; there are such things as unique_ptr 01:23 kahrl "smart" pointers won't be considered 01:23 hdastwb do they take the fun out of hunting leaks? 01:25 kahrl well I'm getting bored of this, but I haven't seen a case where they made code look better and easier to understand 01:26 kahrl really, http://xkcd.com/1171/ with s/regular expressions/smart pointers/ 01:29 hdastwb As a C++ programmer, I assumed that the goal was idiomatic C++ code; it seems that the project is actually striving for idiomatic C code with allowances for C++ features when the C is too ugly 01:29 Exio4 C++ "super cool features" are more syntatic sugar to the C ways actually used, mostly 01:30 kahrl not to mention that C++ before 11 has only the auto_ptr which has terrible semantics 01:47 hdastwb Anyway, I just thought that many of the coding conventions are counter-intuitive for production of idiomatic code, but since the aim is for idiomatic code in a different language than I thought it referred to it makes more sense now 01:48 hdastwb and since I have no experience with C, I'm afraid I'm not going to be able to help with engine things… 09:22 VanessaE kahrl: remember the black textures in the inventory that happened when I deleted those several lines like you asked? It's happening in git HEAD now, and I cloned/recompiled fresh just to be sure. Only happens if preload visuals is turned on. 09:26 VanessaE so deleting those lines had no effect, it must have already been an issue and I just hadn't noticed it at the time. 09:26 VanessaE (well, no effect on the black textures anyway) 11:45 PilzAdam sapier, https://gist.github.com/PilzAdam/6048325 11:45 PilzAdam but I wasnt using the modmanager at all 11:46 PilzAdam why is it downloading stuff then? 11:55 RealBadAngel hi 11:56 RealBadAngel anything against https://github.com/minetest/minetest/pull/841 ? 11:58 Calinou does it work? if yes, then merge it 11:58 proller +1 11:58 proller nobody know how it works 8) 12:00 RealBadAngel it seems to work, tested it with furnaces 12:01 proller commit! 12:09 proller and i want to merge it - https://github.com/minetest/minetest/pull/830/files 12:13 RealBadAngel kinda mixed content, isnt it? 12:14 proller its all for one thing 12:15 RealBadAngel weather? 12:16 proller yes 12:20 RealBadAngel proller, you should rebase it 12:20 proller of course 13:02 PilzAdam RealBadAngel, works fine for me 13:16 RealBadAngel PilzAdam, you mean the fix i pushed? 13:20 RealBadAngel i will have to add at some point some calculations to this piece of code 13:20 RealBadAngel normal is already calculated there, i neet binormal and tangent also 13:21 RealBadAngel way better to calculate such things in cpp than in shaders 13:21 RealBadAngel *need 13:42 proller time_speed = 864000 # my eyes! 13:46 proller 365 days too long for season cycle with default time_speed = 72 13:47 proller 120 game hours 13:49 Calinou talking about that, why not change default day_night cycle to that it is 24 minutes? 13:49 Calinou would make more sense 13:51 proller now day-night per 20 minutes 13:53 proller but wait 180 days for next winter - too lon 13:53 proller g 13:54 proller i think year must cycle in 4-6 hours 13:54 Jordach thats too fast 13:54 proller 12 hours ? 13:54 proller game hours 13:55 proller peoples play 1-2-3 hours 13:55 RealBadAngel why dont use system clock to get seasons? 13:55 Exio4 RealBadAngel: system clock would do nothing 13:55 proller * except Calinou, he can grief 6 hours per day ;) 13:56 RealBadAngel lets say one week IRL would be a season in game 13:56 RealBadAngel so month would become a year 13:56 Exio4 i don't actually like that though 13:57 Exio4 proller: 120 game hours for that? 13:57 Exio4 what is "game" hours, hours inside the game? 13:57 proller player real hours 13:57 proller must play 120 hours to look fuul year cycle 13:57 Exio4 say real, not game then 13:57 PilzAdam you really think people play that long? oO 13:58 proller Exio4, ok 13:58 RealBadAngel make it independent from time played 13:58 Exio4 proller: let change the "virtual year" to only 24hours so, not the speed time itself 13:58 RealBadAngel this way if some1 havent played for some time can be suprised that so much time passed in game 13:59 PilzAdam what many games do is 1 day equals 1 season 13:59 RealBadAngel and the seasons changed, winter came and crops are gone 13:59 RealBadAngel 1 day is too fast 13:59 RealBadAngel seasons mean different constructions, crops etc 13:59 Exio4 well, that is true too 13:59 RealBadAngel let the player play a few days in winter 14:00 Exio4 but it is an irl day 14:00 proller ok. its must be configurable 14:00 Exio4 hehe 14:00 PilzAdam of course it will be configureable 14:00 RealBadAngel im talkin about 1 irl week for a season 14:00 PilzAdam but we need a sane default value 14:00 PilzAdam RealBadAngel, are you kidding? 14:00 RealBadAngel definitely not 14:00 proller i'm vote for 6 real hours for year 14:01 RealBadAngel im voting for server congiguration setting :) 14:01 Exio4 i vote for 1 irl day / year 14:01 proller RealBadAngel, with real week - its hars too sight season changes for player 14:01 PilzAdam RealBadAngel, you have no idea how people play Minetest in singleplayer, do you? 14:01 proller and! 14:01 Exio4 or 4 irl / year and make it have 4 seasons 14:01 proller season now place-depended 14:01 RealBadAngel i played mc singleplayer world for over a year, so i do :P 14:01 proller 1 year = 3000 nodes by x 14:02 proller you can walk to another season 14:02 proller ant is sloowly moving 14:03 PilzAdam it would be best if we just had static biomes 14:03 RealBadAngel static is boring :P 14:03 proller biome have initial heat, season change it to + -30..+30 14:04 proller if biome have -40 - its will be forever winter with max temp -10 14:04 proller if +40 - will newer snow 14:04 RealBadAngel so you wanna make palm beach in range 0 to 60? :) 14:04 PilzAdam changing the season will destroy the buildings of players 14:05 proller PilzAdam, how? 14:05 proller snow is melting 14:05 proller water is evaporating 14:05 PilzAdam an ice palace will just melt 14:05 proller no changes 14:05 PilzAdam farms will be destroyed 14:05 proller yes!! and its cool 14:05 RealBadAngel and thats what i was talkin about 14:05 PilzAdam what you want to do is meta-griefing 14:06 proller farms now heat-independed 14:06 RealBadAngel so they shall last longer 14:06 proller and you can make closed farms 14:06 RealBadAngel for players to have time to build, use it and keep in mind that winter will come 14:06 proller or warm farms with torches 14:08 Exio4 a proper way for making all of this would be having a "heat" value for every node and make stuff based on that 14:08 Exio4 how are you making it? 14:08 RealBadAngel with longer times player playin a few hours per day will have time to develop season dependent things and use them 14:08 RealBadAngel and of course he can move to warmer/colder areas any time 14:09 RealBadAngel but around his "base" there will be current season for a while 14:09 Exio4 what "temperature scale" uses MT for that? 14:09 Exio4 something madeup? 14:10 proller in todo - make season temp range configured in biome 14:10 RealBadAngel i think it shall be predefined 14:10 RealBadAngel min/max temp per season 14:10 RealBadAngel around the globe areas vary in temperature ranges 14:10 PilzAdam all this weather stuff would be perfect material for a fork 14:11 RealBadAngel everything that you dont agree is labeled fork ;) 14:11 proller Exio4, every node - need additional s8 per node in storage 14:11 RealBadAngel cmon, we know ur tricks for quite a while 14:12 Exio4 proller: exactly, it is a problem, 14:12 Exio4 and if you don't use something like that, it is practically not the right way 14:12 Exio4 it is using lots of hardcoded ABMs + adding APIs for getting that stuff 14:13 RealBadAngel we are talkin now what engine should allow, not what default minetest_game should contain 14:13 Exio4 Merge remote-tracking branch 'upstream/master' into weather … 14:13 Exio4 proller: did you seriously do it 14:15 proller yes, i have shortcup for git 14:15 proller git ups 14:15 proller merges upstream to me 8-P 14:15 proller and i will squash it 14:16 Exio4 you should use rebase, not merge 14:16 Exio4 you will fuck up the commits now 14:17 proller abm's for speed 14:17 proller they use groups 14:18 Exio4 i don't get that 's 14:52 celeron55_ merging upstream into pull requests? i hope not 14:59 proller squashed! 16:09 proller hmmmm, https://github.com/minetest/minetest/pull/830/files 16:09 proller with cache and better seasons 16:14 sapier1 PilzAdam modstore caches modlist upon initialization ... this is done on init ... which seems to be run on menu startup ... I guess this might be a reason for menu start up to slow down. More interesting is why do you get an error? 16:25 celeron55_ hmmmm, kahrl, Exio4: you seemed to forget in your arguments the fact that some of Minetest's codebase is still remains from the time when it was a goal for MT to use irrlicht as the main library rather than the C++ standard library (in the spirit of irrlicht, as it doesn't use std:: stuff either) 16:26 celeron55_ so really i would prefer for some of the oldest stuff to be migrated over time to something saner 16:26 celeron55_ but indeed it doesn't really "make minetest better" 16:27 celeron55_ (it's the reason why there really isn't any hurry) 16:28 celeron55_ i should add "C++11 zealots" to the "list of the kinds of people celeron55 hates" 16:31 celeron55_ also, i suggest that stuff like the "auto" type for iterators and the for(:) loop would be added to the unwritten "use when all the supported compilers support them, because it would be crazy to not to" 16:32 celeron55_ +list 16:59 BlockMen is resizeHotbar() ( https://github.com/minetest/minetest/blob/master/src/hud.cpp#L334 ) also called when the builtin is disabled (by flags) and with player:hud_add("bla bla") a costum one is added? 21:16 aoper why is the startup menu done in lua, but the pause menu is in C++? Should the pause menu be ported to lua? 21:19 sapier1 there's no in game lua support atm without it pause menu can't be done in lua 21:23 sapier1 using same engine as for main menu isn't possible as in game lua should be able to execute lua code transmitted by server too. this requires extreme care to protect user against malicious servers 21:30 aoper could it run in a seperate instance of lua? 21:31 sapier1 yes it will run a separate instance of lua. but lua isn't designed to create a sandbox so this sandbox needs to be specialy prepared 21:37 PilzAdam too hacky? https://gist.github.com/PilzAdam/6050091 21:38 sapier1 after with 0? 21:39 PilzAdam no, waiting one env step for the engine to update the lighting so the entity isnt black at creation 23:14 Exio4 there should be a "wait_for_env" or so :P 23:14 Exio4 for not using the "hacky 0" 23:15 PilzAdam minetest.after(0, ...) is not hacky at all 23:15 Exio4 is it documented? iirc it wasn't