| 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 |
|
Mallot1 joined #minetest-dev |
| 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 <ostream> |
| 00:30 |
hdastwb |
I also see a macro called myfloor in numeric.h; it looks like exactly the same thing that std::floor from <cmath> 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 <typename T> 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:55 |
|
Mallot1 left #minetest-dev |
| 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 = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x99170b4 "Hello World!"}} |
| 01:06 |
hmmmm |
but yeah, easier debugging - lol |
| 01:06 |
hmmmm |
no idea what planet he's from |
| 01:08 |
|
Weedy joined #minetest-dev |
| 01:08 |
|
Weedy joined #minetest-dev |
| 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. {<iterator<std::random_access_iterator_tag,int,int,int*,int&>> = {<No data fields>}, _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… |
| 02:44 |
|
khonkhortisan joined #minetest-dev |
| 03:56 |
|
Mallot1 joined #minetest-dev |
| 04:31 |
|
Taoki[mobile] joined #minetest-dev |
| 05:11 |
|
smoke_fumus joined #minetest-dev |
| 06:45 |
|
neko259 joined #minetest-dev |
| 07:27 |
|
Calinou joined #minetest-dev |
| 07:43 |
|
Taoki[mobile] joined #minetest-dev |
| 07:46 |
|
darkrose joined #minetest-dev |
| 08:26 |
|
ffoxin joined #minetest-dev |
| 08:43 |
|
neko259 joined #minetest-dev |
| 09:01 |
|
Jordach joined #minetest-dev |
| 09:02 |
|
EdB joined #minetest-dev |
| 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) |
| 09:52 |
|
Calinou joined #minetest-dev |
| 09:54 |
|
Taoki[laptop] joined #minetest-dev |
| 10:49 |
|
PilzAdam joined #minetest-dev |
| 11:04 |
|
sapier joined #minetest-dev |
| 11:13 |
|
Taoki[laptop] joined #minetest-dev |
| 11:18 |
|
Calinou joined #minetest-dev |
| 11:25 |
|
Taoki[laptop]_1 joined #minetest-dev |
| 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:46 |
|
Taoki[laptop] joined #minetest-dev |
| 11:53 |
|
Zeg9 joined #minetest-dev |
| 11:55 |
|
RealBadAngel joined #minetest-dev |
| 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 |
| 12:20 |
|
qwrwed__ joined #minetest-dev |
| 12:40 |
|
BlockMen joined #minetest-dev |
| 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:27 |
|
serengeor joined #minetest-dev |
| 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 |
|
Jordach joined #minetest-dev |
| 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 |
|
Zeg9 left #minetest-dev |
| 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 |
|
salamanderrake joined #minetest-dev |
| 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:36 |
|
Zeg9 joined #minetest-dev |
| 14:50 |
|
Jordach joined #minetest-dev |
| 14:52 |
celeron55_ |
merging upstream into pull requests? i hope not |
| 14:59 |
proller |
squashed! |
| 15:14 |
|
Calinou joined #minetest-dev |
| 15:42 |
|
hmmmm joined #minetest-dev |
| 15:55 |
|
rubenwardy joined #minetest-dev |
| 16:08 |
|
sapier1 joined #minetest-dev |
| 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:35 |
|
mrtux joined #minetest-dev |
| 16:47 |
|
Zeg9 joined #minetest-dev |
| 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? |
| 17:01 |
|
sapier3 joined #minetest-dev |
| 17:06 |
|
BlockMen left #minetest-dev |
| 18:40 |
|
salamanderrake joined #minetest-dev |
| 19:17 |
|
Anchakor_ joined #minetest-dev |
| 19:18 |
|
hmmmmm joined #minetest-dev |
| 19:19 |
|
ecube joined #minetest-dev |
| 19:26 |
|
around joined #minetest-dev |
| 19:26 |
|
around joined #minetest-dev |
| 19:34 |
|
sapier1 joined #minetest-dev |
| 19:51 |
|
hdastwb joined #minetest-dev |
| 20:06 |
|
Anchakor joined #minetest-dev |
| 20:11 |
|
around joined #minetest-dev |
| 20:12 |
|
sapier1 joined #minetest-dev |
| 20:29 |
|
proller joined #minetest-dev |
| 20:37 |
|
darkrose joined #minetest-dev |
| 20:37 |
|
darkrose joined #minetest-dev |
| 20:49 |
|
around joined #minetest-dev |
| 21:15 |
|
aoper joined #minetest-dev |
| 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 |
| 21:40 |
|
sapier1 left #minetest-dev |
| 22:08 |
|
hdastwb joined #minetest-dev |
| 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 |
| 23:33 |
|
Naked joined #minetest-dev |
