Time |
Nick |
Message |
00:31 |
|
shadowzone joined #minetest-dev |
00:34 |
|
Garmine joined #minetest-dev |
00:36 |
|
DFeniks joined #minetest-dev |
00:57 |
|
Megaf joined #minetest-dev |
01:38 |
|
Zeno` joined #minetest-dev |
01:42 |
|
Megaf joined #minetest-dev |
01:52 |
|
Megaf joined #minetest-dev |
02:10 |
ShadowNinja |
I'll merge #1671, #1534, and #1353 in a day or so if there aren't any concerns raised. They're just roting now and at least they'll get some exposure so any bugs can be found. |
02:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/1671 -- Update credits menu by ShadowNinja |
02:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/1534 -- Tweak core.serialize by ShadowNinja |
02:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/1353 -- Add strict module by ShadowNinja |
02:10 |
shadowzone |
Yikes |
02:10 |
ShadowNinja |
Those are fairly trivial, but I'd like to get my other, bigger, PRs merged soon. |
02:27 |
|
shadowzone joined #minetest-dev |
02:29 |
|
Chicken_shadow joined #minetest-dev |
02:37 |
|
shadowzone joined #minetest-dev |
02:42 |
|
shadowzone joined #minetest-dev |
02:47 |
Zeno` |
ShadowNinja, have you also looked again at #1826 ? |
02:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/1826 -- Fix for various Android build errors. Enable landscape rotation. by KodexKy |
02:49 |
|
shadowzone joined #minetest-dev |
02:52 |
|
shadowzone joined #minetest-dev |
02:52 |
Zeno` |
No Zeno in 1671. /me cries |
02:53 |
|
Chicken_shadow joined #minetest-dev |
03:09 |
Zeno` |
Actually should #1826 have some kind of tag to indicate that it needs to be applied before 0.4.11 is released? |
03:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/1826 -- Fix for various Android build errors. Enable landscape rotation. by KodexKy |
03:10 |
Zeno` |
s/tag/label |
04:23 |
|
selat joined #minetest-dev |
05:20 |
|
Garmine joined #minetest-dev |
05:20 |
|
Garmine joined #minetest-dev |
05:22 |
|
DuDraig joined #minetest-dev |
05:24 |
Zeno` |
I anyone able to review #1826 |
05:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/1826 -- Fix for various Android build errors. Enable landscape rotation. by KodexKy |
05:25 |
Zeno` |
It looks ok to me but I don't have an Android toolchain (or an Android for that matter) |
05:32 |
|
sol_invictus joined #minetest-dev |
05:40 |
|
darkrose joined #minetest-dev |
05:57 |
|
Wayward_One joined #minetest-dev |
05:57 |
|
Miner_48er joined #minetest-dev |
06:05 |
|
kaeza joined #minetest-dev |
06:06 |
|
selat joined #minetest-dev |
06:26 |
|
chchjesus joined #minetest-dev |
06:29 |
Zeno` |
Does anyone know about Travis builds? I.e. is #1850 correct and ok to merge? |
06:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/1850 -- Add gettext to Travis build by ShadowNinja |
06:30 |
Zeno` |
It looks fine but I don't want to be the one to break poor Travis :) |
06:30 |
sfan5 |
can't you see the ' All is well — The Travis CI build passed · Details' |
06:31 |
Zeno` |
well yes, but do those changes incorporate those changes? I guess they must |
06:31 |
sfan5 |
https://travis-ci.org/minetest/minetest/jobs/41409953#L107 |
06:31 |
sfan5 |
travis already picked up the new stuff |
06:32 |
Zeno` |
ok so it seems like a good idea then |
06:32 |
* Zeno` |
reads the output |
06:32 |
Zeno` |
Travis is quite clever |
06:33 |
|
Anchakor_ joined #minetest-dev |
06:51 |
|
Hunterz joined #minetest-dev |
07:40 |
hmmmm |
hey guys, aside from organization, are there any benefits at all to adding an include directive to minetest configuration files? |
07:42 |
Zeno` |
aside from organisation, probably not |
07:47 |
hmmmm |
and organization is a very flakey argument to begin with |
07:47 |
hmmmm |
you're never going to have enough settings to actually warrant multiple files |
07:48 |
hmmmm |
alright, I'm glad I thought about the 'why' before I started the 'do' |
07:48 |
Zeno` |
I can't remember why this came up? |
07:49 |
hmmmm |
me neither |
07:49 |
Zeno` |
Oh, ... hierarchy I think |
07:49 |
hmmmm |
you certainly don't need multiple files in order to have a settingsheirarchy |
07:49 |
Zeno` |
for mapgen params |
07:49 |
hmmmm |
if mapgen params really take up that much space, i can make a separate file for mapgen params |
07:49 |
Zeno` |
yeah I think there was ... meh, who cares what it was heh |
07:50 |
hmmmm |
yeah |
07:50 |
hmmmm |
I was thinking it over a bit more and the functionality of having multiple config files for a single Settings is actually difficult to add |
07:51 |
hmmmm |
not necessarily difficult, it's just that adding it would detract from the simplictic beauty of the Settings implementation |
07:51 |
hmmmm |
it's not the reading, it's the writing part that frustrates matters :) |
07:53 |
Zeno` |
yeah I remember you saying that |
08:00 |
|
kilbith joined #minetest-dev |
08:00 |
|
kahrl joined #minetest-dev |
08:06 |
|
zat joined #minetest-dev |
08:08 |
|
jin_xi joined #minetest-dev |
08:09 |
|
selat joined #minetest-dev |
08:09 |
Zeno` |
https://github.com/minetest/minetest/pull/1851/files#diff-18513665750ef5adf42b5ec29e14162eL2828 <-- that ifndef was there before I refactored the_game(). Can anyone familiar with android builds confirm whether it's correct or not? (i.e. see line 2827 and the difference) |
08:14 |
|
darkrose joined #minetest-dev |
08:22 |
|
ImQ009 joined #minetest-dev |
08:56 |
kahrl |
Zeno`: seems right to me |
08:56 |
kahrl |
see the note at the bottom of http://supertuxkart.sourceforge.net/User:Xapantu/Android |
08:57 |
Zeno` |
what note? |
08:57 |
Zeno` |
and what are you commenting on? :) |
08:57 |
kahrl |
"We can't se a visible cursor" |
08:57 |
Zeno` |
Maybe I should ask fewer questions hehe |
08:57 |
kahrl |
set* |
08:58 |
Zeno` |
I was more referring to the #ifndef __ANDROID__ vs. #ifndef ANDROID |
08:58 |
kahrl |
is there a difference? |
08:58 |
Zeno` |
I dunno, that's probably my question :) |
08:59 |
Zeno` |
It's just that a few lines above the line I linked to it's __ANDROID__ and where I linked to it's ANDROID |
08:59 |
Zeno` |
If there is no difference they should be the same to avoid people like me asking questions hehe |
08:59 |
kahrl |
ah, I remember some discussion about those two, but I don't remember any details |
09:00 |
Zeno` |
I'll leave it for now |
09:00 |
Zeno` |
better safe than sorry |
09:00 |
kahrl |
https://github.com/minetest/minetest/pull/1851/files#diff-18513665750ef5adf42b5ec29e14162eR2883 <-- this can be simplified a bit with rangelim |
09:01 |
Zeno` |
ugh, I even meant to do that. Thanks |
09:04 |
Zeno` |
err wait, I know why I didn't do it |
09:04 |
Zeno` |
rangelim() only works with s16 |
09:05 |
Zeno` |
oh |
09:05 |
Zeno` |
of course there are TWO rangelim()s |
09:09 |
Zeno` |
ok, changed to use rangelim |
09:09 |
Zeno` |
can I suggest that the function rangelim be removed and the function-like macro rangelim be renamed RANGELIM? |
09:10 |
|
Weedy joined #minetest-dev |
09:10 |
|
Weedy joined #minetest-dev |
09:10 |
Zeno` |
might have to change too many files though |
09:10 |
Zeno` |
But.. hmm, I do find it confusing |
09:14 |
kahrl |
Zeno`: huh, you're right |
09:14 |
kahrl |
I don't think that's intentional |
09:15 |
kahrl |
let's just remove the function |
09:18 |
kahrl |
it isn't even used |
09:21 |
Zeno` |
:D |
09:22 |
kahrl |
done :) |
09:27 |
Zeno` |
full speed ahead |
09:33 |
|
rickmcfarley joined #minetest-dev |
09:55 |
|
Du_Draig joined #minetest-dev |
09:55 |
|
ImQ009 joined #minetest-dev |
10:15 |
|
chchjesus__ joined #minetest-dev |
10:29 |
|
ImQ009 joined #minetest-dev |
11:07 |
|
ImQ009_ joined #minetest-dev |
11:14 |
|
ImQ009 joined #minetest-dev |
11:27 |
|
FR^2 joined #minetest-dev |
11:42 |
|
DuDraig joined #minetest-dev |
11:45 |
Zeno` |
kahrl, any luck with that silly playername business? |
12:23 |
Zeno` |
sfan5 |
12:23 |
sfan5 |
Zeno` |
12:23 |
Zeno` |
sorry, I was typing and hit enter :/ |
12:24 |
Zeno` |
sfan5, so #1850 looks ok? |
12:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/1850 -- Add gettext to Travis build by ShadowNinja |
12:25 |
Zeno` |
no matter... I can't merge that anyway |
12:25 |
Zeno` |
too hard with 2 commits |
12:25 |
sfan5 |
huh? |
12:25 |
sfan5 |
I agree to 1850 |
12:25 |
Zeno` |
<-- being lazy |
12:26 |
Zeno` |
*sigh*, ok I'll merge then because that's 3 core dev votes |
12:26 |
sfan5 |
what do you mean with 'too hard with 2 commits'? |
12:26 |
Zeno` |
nothing I'll leave it as 2... I was suddenly trying to be lazy heh |
12:37 |
|
Amaz joined #minetest-dev |
12:42 |
|
GrimKriegor joined #minetest-dev |
13:16 |
|
shadowzone joined #minetest-dev |
13:24 |
|
gravgun joined #minetest-dev |
13:24 |
Zeno` |
can I have some feedback on #1732 please? |
13:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/1732 -- Add (optional) client-side saving of server map to disk by sfan5 |
13:26 |
Zeno` |
My personal thoughts are that not allowing people to do it (and as mentioned they can do it with a hacked client anyway) is not a very good argument for not allowing it |
13:27 |
Zeno` |
I say this as a person who runs a server as well. Nothing (well, not a lot) on my server is created by me. Minetest is open source and I think that stuff like this should be allowed without people jumping through hoops and modifying their client |
13:28 |
gravgun |
Zeno`: I think it should be implemented, not necessarily used though. Caching map is no problem (as you mentionned, hacked clients). However I didn't look through the patch, does it save the whole map? |
13:28 |
Zeno` |
gravgun, only what the client has "seen" |
13:29 |
gravgun |
Zeno`: So it progressively saves the map? |
13:30 |
Zeno` |
yes |
13:31 |
Zeno` |
sfan5, save me looking at the source again... it's off by default right? |
13:32 |
sfan5 |
of course |
13:32 |
Zeno` |
I honestly don't have a problem with this patch |
13:32 |
gravgun |
Mmm, same opinion as ShadowNinja about creating a Server object; but on a non-code point of view, it'd be great. Also, why not add another parameters to specify save location (e.g. be able to save on a tmpfs for fast "caching") |
13:33 |
Zeno` |
I'm not sure caching and saving should be mixed into one pull request though |
13:34 |
Zeno` |
I mean, it's worthwhile, but if this was to be merged then the caching, IMO, should be something separate |
13:36 |
Zeno` |
At least, as it currently is, if there are bugs it only affects the saved map (no big deal if there's a bug) |
13:36 |
Zeno` |
I'll add my thumbs up to the PR, because I like it |
13:37 |
Zeno` |
:) |
13:39 |
gravgun |
(I put "caching" in quotes, that was just an exmaple, it's still an actual map save) |
13:41 |
Zeno` |
yeah, I dunno how useful "caching" would be without thinking some more but at least this also paves the way for that if it's useful |
13:42 |
Zeno` |
I guess the cache would have to somehow compare its state with the state of the received data so I'm not totally sure it would lead to any improvement |
13:43 |
Zeno` |
It might though, I dunno |
13:45 |
kahrl |
not yet re: <Zeno`> kahrl, any luck with that silly playername business? |
13:47 |
Zeno` |
that'd be right (I didn't check too much either though lol) |
13:48 |
Zeno` |
kahrl, spaces... you're driving me batty |
13:50 |
kahrl |
I just want to take this opportunity to fix those ;) |
13:51 |
|
VargaD joined #minetest-dev |
13:51 |
|
PilzAdam joined #minetest-dev |
13:53 |
|
VargaD_ joined #minetest-dev |
13:54 |
|
ImQ009 joined #minetest-dev |
13:55 |
kahrl |
ok, I think I'm done with the space pedantics |
13:57 |
|
Megaf joined #minetest-dev |
14:06 |
Zeno` |
:D |
14:06 |
Zeno` |
keep going kahrl... as you said they may as well be fixed now |
14:07 |
Zeno` |
ok, I've tested #1732 saving the map of my server and all seems good to me |
14:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/1732 -- Add (optional) client-side saving of server map to disk by sfan5 |
14:08 |
sfan5 |
Zeno`: can I merge? |
14:08 |
kahrl |
idea for determining whether anisotropic filtering makes textures blurred: render a checkerboard 16x16 texture into RTT and examine the histogram of the produced pixels |
14:09 |
Zeno` |
sfan5, the majority of the comments are positive right? |
14:09 |
Zeno` |
and we've just discussed it. Unless someone has an objection I can't see why not |
14:09 |
sfan5 |
Zeno`: as far as I know coredevs need to agree by IRC |
14:09 |
Zeno` |
IMO these things should be merged sooner rather than later |
14:10 |
Zeno` |
I agree then |
14:10 |
kahrl |
(this idea is for #1844 and #1848) |
14:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/1844 -- odd wield item glitch 2 |
14:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/1848 -- Use anisotropic_filtering config value in wieldmesh. by oleastre |
14:10 |
Zeno` |
sfan5, merge away :) |
14:10 |
sfan5 |
kahrl: are the effects of ansitropic filtering gfc card/driver specific? |
14:10 |
kahrl |
it appears so |
14:11 |
kahrl |
I guess it's a driver bug |
14:12 |
* kahrl |
brb |
14:13 |
sfan5 |
Zeno`: tip: people don't need to squash commits, the person merging them can squash them |
14:13 |
Zeno` |
kahrl, the problem with wield changes is that I didn't experience ANY ill effects from the start |
14:14 |
Zeno` |
sfan5, true |
14:14 |
Zeno` |
kahrl, so I can't comment on them at all :/ |
14:15 |
kahrl |
Zeno`: same here |
14:16 |
kahrl |
the cause for the black lines in the image in linked in #1848 is the Y slices in the extrusion mesh |
14:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/1848 -- Use anisotropic_filtering config value in wieldmesh. by oleastre |
14:17 |
kahrl |
s/ in / I / |
14:17 |
kahrl |
which are viewed at a very oblique angle in some parts of the wield animation |
14:18 |
Zeno` |
I haven't tested that PR |
14:18 |
kahrl |
best might be to tell the video card: "please render these slices, but only if the angle it's viewed from is less than blahblahblah degrees" |
14:19 |
kahrl |
I doubt there is such a material flag though... |
14:19 |
Zeno` |
how to do that though? |
14:19 |
kahrl |
probably impossible without shader tricks |
14:19 |
kahrl |
I can remove the Y slices but that's ugly too |
14:20 |
Zeno` |
yeah I dunno... I'm staying far away from it hehehe |
14:21 |
Zeno` |
the whole thing scares me because it was right from the start on my computer hehe |
14:21 |
kahrl |
maybe the wield animation could be modified so the angle is not as oblique |
14:22 |
|
shadowzone joined #minetest-dev |
14:32 |
|
Chicken_shadow joined #minetest-dev |
14:36 |
Megaf |
Hi everyone |
14:37 |
Megaf |
We believe that Minetest is coded for Irrlicht 1.7 |
14:37 |
Megaf |
What about changing it and optimizing to at lesat 1.8? Or even the upcoming 1.9 |
14:46 |
kaeza |
Megaf, it works on both 1.7 and 1.8 |
14:47 |
kaeza |
not sure if support for 1,9, assuming anything changes, is a priority |
15:06 |
|
chchjesus__ joined #minetest-dev |
15:07 |
Megaf |
kaeza: I know it works |
15:07 |
Megaf |
it has a bug with 1.7 actually |
15:07 |
Megaf |
but I mean, doesnt version 1.8 introduced some better feature or solve some limitation that could be useful to Minetest? |
15:10 |
|
PenguinDad joined #minetest-dev |
15:14 |
|
MinetestForFun joined #minetest-dev |
15:26 |
|
hmmmm joined #minetest-dev |
15:30 |
|
shadowzone joined #minetest-dev |
15:33 |
|
Hunterz joined #minetest-dev |
15:34 |
|
Hunterz1 joined #minetest-dev |
15:35 |
|
shadowzone joined #minetest-dev |
15:47 |
|
diemartin joined #minetest-dev |
15:50 |
Megaf |
Irrlicht log: JPEG FATAL ERROR in _tempreadfile: Wrong JPEG library version: library is 80, caller expects 62 |
15:50 |
Megaf |
15:47:24: ERROR[main]: Client: Cannot create image from data of file "bg_signs_lib.jpg" |
15:54 |
|
shadowzone joined #minetest-dev |
15:56 |
|
shadowzone joined #minetest-dev |
16:00 |
|
DuDraig joined #minetest-dev |
16:07 |
|
Amaz joined #minetest-dev |
16:11 |
|
OldCoder joined #minetest-dev |
16:41 |
|
Calinou joined #minetest-dev |
16:50 |
|
ImQ009 joined #minetest-dev |
16:51 |
|
SudoAptGetPlay joined #minetest-dev |
16:56 |
|
rubenwardy joined #minetest-dev |
17:04 |
|
SudoAptGetPlay left #minetest-dev |
17:14 |
|
Hunterz joined #minetest-dev |
17:24 |
|
Calinou joined #minetest-dev |
17:27 |
|
rickmcfarley joined #minetest-dev |
17:37 |
|
rubenwardy joined #minetest-dev |
17:47 |
ShadowNinja |
Comments on #1418? |
17:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/1418 -- Clean up rollback by ShadowNinja |
17:48 |
hmmmm |
looks good |
17:48 |
hmmmm |
but i have a question - why doesn't the rollback manager use the database abstraction layer? |
17:49 |
hmmmm |
also, if (itemdef) name = itemdef->getAlias(name); eww |
17:49 |
hmmmm |
the style is |
17:49 |
hmmmm |
if (itemdef) |
17:49 |
hmmmm |
itemdef->getAlias(name); |
17:50 |
hmmmm |
i hate when people put a control statement body on the same line. it's like they have something to hide |
17:51 |
ShadowNinja |
hmmmm: Database abstraction layer? |
17:51 |
hmmmm |
database.cpp |
17:52 |
ShadowNinja |
hmmmm: It's database os nothing like the map DB, so it can't use those classes. |
17:52 |
hmmmm |
then perhaps the classes should be extended |
17:52 |
ShadowNinja |
hmmmm: It stores actions, items, actors, etc each in a table. |
17:52 |
ShadowNinja |
hmmmm: The DB classes are just designed for v3s16 -> BLOB. |
17:53 |
hmmmm |
i've seen interest in a redis rollback manager anyway |
17:54 |
ShadowNinja |
hmmmm: You'd need a completely seperate API for it. Not all DB backends do things the same way. SQLite3 is pretty full-featured, but redis ony has k->v, and LevelDB aditionally only supports one table. |
17:55 |
hmmmm |
so the rollback manager uses different keys? |
17:56 |
celeron55 |
it's a completely separate system |
17:56 |
ShadowNinja |
hmmmm: Schema: http://pastebin.ubuntu.com/9100793/ |
17:57 |
celeron55 |
to which it was upgraded from an initial text-based system |
17:57 |
ShadowNinja |
Definitely not something that can be sanely emulated by redis or LevelDB. |
17:57 |
celeron55 |
and yes, it actually uses SQL unlike the map backend |
17:57 |
|
selat joined #minetest-dev |
17:58 |
hmmmm |
ahh, i see, you search by actor and by position |
18:00 |
ShadowNinja |
celeron55: Does it seem O.K. to you? |
18:02 |
ShadowNinja |
BTW, this might improve speed slightly. I made the pos limitations a little easier to optimize. |
18:02 |
ShadowNinja |
I haven't tested it though. |
18:02 |
celeron55 |
why is the itemdef parameter made optional? |
18:03 |
|
Krock joined #minetest-dev |
18:03 |
celeron55 |
seems like it can result in quite uncontrollable behavior as nothing defines when it is NULL and when not |
18:03 |
ShadowNinja |
celeron55: The rollback manager needs to read items without resolving aliases. |
18:04 |
|
shadowzone joined #minetest-dev |
18:04 |
celeron55 |
when? |
18:04 |
shadowzone |
hi celeron55 |
18:05 |
ShadowNinja |
celeron55: Line 680 or so. |
18:05 |
ShadowNinja |
(rollback.cpp) |
18:07 |
celeron55 |
okay i see; but doesn't this lead to bugs when people will obviously forget it in invocations of the itemstack deserialization in future code elsewhere |
18:08 |
celeron55 |
as it currently is, they can't forget it as it isn't optional |
18:08 |
celeron55 |
it at least needs a comment stating when it can be left out and when not |
18:08 |
ShadowNinja |
The percieved speed of rollback could be improved massively by changing the default limit to 1. That would make it resier to get the wrong player though. |
18:09 |
ShadowNinja |
celeron55: Well, it's still in the type signature. |
18:09 |
ShadowNinja |
I can add a comment though. |
18:09 |
celeron55 |
but nobody is explaining why it is there and why it is optional |
18:09 |
ShadowNinja |
"Use when you want aliases resolved" r so. |
18:10 |
celeron55 |
"Do not leave itemdef as NULL unless you are sure you do not want aliases to be resolved." |
18:10 |
celeron55 |
nobody will know whether they want that or not, so it's better to state what the default is supposed to be |
18:11 |
celeron55 |
and the ifs look horrible as hmmmm said |
18:12 |
ShadowNinja |
celeron55: Changed locally. |
18:13 |
celeron55 |
the rollbackmanager changes are quite obfuscated, i guess nobody can review those |
18:13 |
ShadowNinja |
RollbackManager is rather big. |
18:13 |
|
ImQ009 joined #minetest-dev |
18:14 |
ShadowNinja |
I guess getItemString should stay in the source file since it requires <sstream>. |
18:16 |
kaeza |
comments? https://github.com/kaeza/minetest/commit/fb8bc8913fb7c5f476fbb82086d08f20cc89e43e |
18:17 |
kaeza |
(part of builtin cleanup, still WIP, just posting here so devs can make suggestions while I work on it) |
18:18 |
Krock |
kaeza, I don't get what's better in the 1st file |
18:18 |
Krock |
chatcommands.lua |
18:18 |
celeron55 |
i don't like the way this moves a lot of implementation details into rollback.h |
18:18 |
celeron55 |
headers shouldn't contain implementations |
18:19 |
kaeza |
Krock, avoids creating a table every time the function is called |
18:19 |
celeron55 |
that header isn't included in a lot of places so it's not that bad but it could end up so, and then compile times will increase and everyone will cry and go away |
18:19 |
Krock |
kaeza, https://github.com/kaeza/minetest/commit/fb8bc8913fb7c5f476fbb82086d08f20cc89e43e#diff-a93e20fc47b20484bdc9d6f539b9d631R200 vector.floor() should be added instead |
18:19 |
Krock |
or even vector.round in this case |
18:19 |
Krock |
IMO |
18:20 |
ShadowNinja |
kaeza: facedir_to_dir is 1000000x clearer. :-) |
18:20 |
celeron55 |
it doesn't seem to be a necessary change at all, so why is the change there |
18:20 |
celeron55 |
(the move to rollback.h) |
18:20 |
kaeza |
Krock, in this case, it's faster to hold those in locals than create a table/vector every time |
18:20 |
ShadowNinja |
celeron55: rollback_interface.h implements everything that the restof the project sees. |
18:21 |
ShadowNinja |
I can move some things back if you prefer though. |
18:21 |
celeron55 |
ShadowNinja: where are the comments that state this clearly |
18:21 |
kaeza |
and since nodeupdate could be called potentially hundreds if not thousands of times, it shaves quite a bit of time |
18:21 |
ShadowNinja |
celeron55: Nowhere, I had to figure this out be asking you and looking around. |
18:23 |
celeron55 |
ShadowNinja: that is my last complaint, so if those are added, i'm happy with this |
18:23 |
celeron55 |
it could be done with file names even; just rollback.h -> rollback_internal.h and rollback_interface.h -> rollback.h |
18:25 |
celeron55 |
(yes, i will always bitch about header bloat; it's one of the most common and worst thing to mess up in C++) |
18:27 |
ShadowNinja |
BTW, we should probably have a defined header include order. It seems like the best method is local - global - system, because it helps to find missing includes. |
18:27 |
ShadowNinja |
^ That issue made me need to touch a bunch of files that depended on settings.h including debug.h, log.h, main.h, ... |
18:27 |
|
casimir joined #minetest-dev |
18:28 |
celeron55 |
yes, i agree with local, global, system because it allows reliably definining macros for system headers that sometimes need them |
18:29 |
celeron55 |
(it might bring up some problems though as every file uses a random-but-working-order currently) |
18:29 |
hmmmm |
really? |
18:29 |
hmmmm |
i've been doing system global local the whole while |
18:29 |
hmmmm |
:( |
18:30 |
celeron55 |
well, macros are the only actual reason for ordering them in any order, and those cause the preference of putting system stuff last |
18:30 |
celeron55 |
i hadn't thought about this some years ago but then stumbled upon this fact |
18:32 |
kaeza |
I've always used system-global-local as well, but now your comment makes a good point on doing the inverse, I guess. |
18:33 |
ShadowNinja |
hmmmm: Me too, but I searched for a ordering a while ago, and I didn't find any good reasons for that ordering other than it looks better (which it does IMO, but still). |
18:35 |
ShadowNinja |
celeron55: Look good now? |
18:37 |
ShadowNinja |
Hmmm, minor style issue in ItemStackRow... |
18:37 |
celeron55 |
well, you didn't do anything to my last concern |
18:38 |
ShadowNinja |
celeron55: What concern? |
18:38 |
celeron55 |
the concern about the headers |
18:39 |
celeron55 |
you can ignore it, but i will blame you when someone messes up with them |
18:39 |
ShadowNinja |
celeron55: I moved the internal stuff into the .cpp. |
18:39 |
ShadowNinja |
celeron55: And right not rollback.* is internal anyways (glob notation) |
18:39 |
ShadowNinja |
now* |
18:41 |
celeron55 |
why is rollback.h still including sqlite3.h? sqlite3's types aren't used in minetest's internal interfaces |
18:41 |
celeron55 |
i really hate C++'s private class members; they are the worst offenders in header bloat |
18:41 |
celeron55 |
they make people think you should put everything in a header because private will save you |
18:41 |
ShadowNinja |
celeron55: The sqlite3 and sqlite3_stmt types. |
18:42 |
ShadowNinja |
They're members. |
18:42 |
celeron55 |
whatever, i give up |
18:44 |
celeron55 |
i will still repeat that i hate it that "private" basically means "yes, nobody can't use this information, but i still want it to be bloating up my header with all its dependencies" |
18:45 |
ShadowNinja |
celeron55: It's also included in every instance, unlike the global system of before. But header bloct isn't an issue, _interface salves that and is what everything includes. |
18:45 |
ShadowNinja |
bloat* |
18:47 |
ShadowNinja |
celeron55: `touch src/rollback.cpp` only causes two files to be rebuilt, rollback.cpp, and server.cpp (it instantiates the manager). |
18:48 |
ShadowNinja |
touching _interface rebuilds about 25 files though. That seems like a lot. |
18:49 |
|
ShadowLadyXD joined #minetest-dev |
18:51 |
ShadowNinja |
I reduced it to 6. |
18:52 |
ShadowNinja |
celeron55: So, all good? |
18:53 |
ShadowNinja |
celeron55: Also, there's another reason for the ordering. One minute... |
18:54 |
|
shadowzone joined #minetest-dev |
18:56 |
ShadowNinja |
celeron55: http://pastebin.ubuntu.com/9101894/ |
19:05 |
celeron55 |
that isn't usually very effective in real code though, because many files include a long series of other files, and the first non-system one will include many system headers already |
19:05 |
celeron55 |
but yes, the chance of that increases |
19:06 |
ShadowNinja |
Comments on #1826? |
19:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/1826 -- Fix for various Android build errors. Enable landscape rotation. by KodexKy |
19:08 |
|
SudoAptGetPlay joined #minetest-dev |
19:16 |
|
Miner_48er joined #minetest-dev |
19:18 |
|
shadowzone joined #minetest-dev |
19:18 |
|
SudoAptGetPlay left #minetest-dev |
19:19 |
ShadowNinja |
RealBadAngel: Um, this isn't how your wallmounted rotation is supposed to work... https://mediacru.sh/lHLnnCgyzxoO.png |
19:19 |
shadowzone |
Lol |
19:20 |
VanessaE |
eep |
19:27 |
|
shadowzone joined #minetest-dev |
19:34 |
kaeza |
mod_profiling.lua is a real mess :/ |
19:34 |
kaeza |
https://github.com/kaeza/minetest/commit/e8f56cecc820348027b5d20229ddc5863d17e24b |
19:36 |
RealBadAngel |
ShadowNinja, please do read how torchllike works |
19:36 |
RealBadAngel |
this has nothing to do with wallmounted |
19:36 |
RealBadAngel |
ZERO |
19:36 |
ShadowNinja |
RealBadAngel: I'm not using torchlike. |
19:36 |
ShadowNinja |
I'm using 3D models with wallmounted. |
19:37 |
RealBadAngel |
so dont expect wallmounted to rotate torches like torchlike does |
19:37 |
VanessaE |
RealBadAngel: I think he means that the model doesn't stay "right side up". |
19:37 |
VanessaE |
regardless of what the model may be |
19:37 |
VanessaE |
if I put a wallmounted calendar there, the same problem would happen ") |
19:37 |
VanessaE |
:) |
19:38 |
RealBadAngel |
ShadowNinja, upload that mod code somewhere please, i will look for the probem |
19:38 |
RealBadAngel |
*problem |
19:39 |
ShadowNinja |
http://sprunge.us/XQPZ |
19:39 |
RealBadAngel |
http://i.imgur.com/hjtT1Xj.png |
19:39 |
RealBadAngel |
this is how wallmounted works for me |
19:40 |
shadowzone |
o.O |
19:41 |
ShadowNinja |
RealBadAngel: Well, not for me. |
19:42 |
kilbith |
the issue may come from the torch model itself maybe ? |
19:42 |
VanessaE |
it is notable that RBA's image depicts the same model on the "upright" surface as on the sides of the block |
19:43 |
VanessaE |
but ShadowNinja's image has a different model for those two situations. |
19:44 |
|
Hawk666 joined #minetest-dev |
19:45 |
RealBadAngel |
VanessaE, yes, thats the point of the wallmounted |
19:45 |
ShadowNinja |
VanessaE: Yes, but the side one seems rotated randomly, it's not just off by a constant ammount. |
19:46 |
RealBadAngel |
torchlike (current one) is something different, it draws one on the ground, another on the ceiling and 4 different at the walls |
19:46 |
VanessaE |
RealBadAngel: that's not torchlike. |
19:46 |
ShadowNinja |
Maybe I'm doing something wrong, but if so I don't know what. |
19:46 |
RealBadAngel |
ShadowNinja, i will re-check the rotation, but theres noting much to fiddle with |
19:46 |
VanessaE |
that's just a model that looks like a torch. totally unrelated. |
19:47 |
ShadowNinja |
^ |
19:47 |
RealBadAngel |
wallmounted is just axisdir |
19:47 |
RealBadAngel |
except for that current wallmounted values are messed up |
19:47 |
RealBadAngel |
0 is at ceiling, 1 bottom, etc |
19:48 |
ShadowNinja |
RealBadAngel: I tried to re-do the table and I think I came up with the same thing as you, but it's just not working. |
19:48 |
RealBadAngel |
imho we shall just fix the wallmounted |
19:48 |
ShadowNinja |
RealBadAngel: How are they messed up? They seem more logical than facedir since they're ordered by axis. |
19:49 |
RealBadAngel |
0 at the ceilng? |
19:49 |
RealBadAngel |
so you have to rotate your models (wallmounted ones) to be show correctly in inventory |
19:49 |
RealBadAngel |
otherwise they will be show upside down |
19:50 |
RealBadAngel |
0 always meant no rotation at all, standing on the bottom |
19:50 |
RealBadAngel |
why the heck wallmounted has to be different? |
19:51 |
RealBadAngel |
facedit IS ordered by axis |
19:51 |
|
cg72 joined #minetest-dev |
19:52 |
RealBadAngel |
top of the node points the axis |
19:52 |
RealBadAngel |
as your head, it points up |
19:53 |
|
ImQ009 joined #minetest-dev |
19:54 |
RealBadAngel |
wallmounted should be redefined to be just axisdir, so conversion should be just facedir/4 = wallmounted |
19:54 |
RealBadAngel |
or wallmounted*4 = facedir |
19:57 |
RealBadAngel |
ShadowNinja, anyway, until its fixed i will try to get your mod working, just a bit later, i need a nap now |
19:58 |
ShadowNinja |
RealBadAngel: Hmmm, I think I figured out the issue. |
20:03 |
RealBadAngel |
yes? |
20:07 |
ShadowNinja |
RealBadAngel: Close: https://mediacru.sh/192737be885b |
20:07 |
|
zat joined #minetest-dev |
20:07 |
ShadowNinja |
RealBadAngel: Your mushroms don't show that because they don't depend on orientation. |
20:08 |
ShadowNinja |
You can see it on them, but they don't depend on it. |
20:08 |
VanessaE |
RealBadAngel: try it with one of the slopes from my mesh test mod. |
20:10 |
|
khonkhortisan joined #minetest-dev |
20:15 |
kaeza |
last commit for builtin/game cleanup: https://github.com/kaeza/minetest/commit/1af70b8d0333103f0ba6530f04e11ec0996c83d1 |
20:16 |
|
monty joined #minetest-dev |
20:17 |
VanessaE |
kaeza: "are writing WORDS!" you blew the line! :) |
20:17 |
kaeza |
:( |
20:18 |
PenguinDad |
kaeza: is the setmetatable still needed? |
20:18 |
ShadowNinja |
RealBadAngel: Fixed it: static const u8 wm_to_6d[6] = {20, 0, 16+1, 12+3, 8, 4+2}; |
20:18 |
ShadowNinja |
(changes added as +%d) |
20:19 |
ShadowNinja |
RealBadAngel: You'll have to apply that to the mesh cache rotation code too though. |
20:19 |
kaeza |
PenguinDad, in voxelarea? yes |
20:19 |
ShadowNinja |
(Or better yet, unify the rotation to one place) |
20:21 |
PenguinDad |
Then I just don't see why it's needed right now |
20:22 |
ShadowNinja |
RealBadAngel: I have a commit ready, just check my rotation array and confirm. |
20:22 |
|
AnotherBrick joined #minetest-dev |
20:22 |
VanessaE |
you may want to revisit #1808 also then |
20:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/1808 -- Adjust the values of dirs1 and dirs2 so that rotate_and_place orients textures correctly by dvere |
20:24 |
VanessaE |
(though it's still my opinion that the guy using that code is just using it wrongly) |
20:27 |
kaeza |
PenguinDad, it is done so you can do local va = VoxelArea:new() va:foobar(); it's a common trick to implement OOP in Lua |
20:28 |
|
proller joined #minetest-dev |
20:33 |
|
khonkhortisan joined #minetest-dev |
20:47 |
|
shadowzone joined #minetest-dev |
20:48 |
|
proller joined #minetest-dev |
20:49 |
Sokomine |
thanks for adding the save-to-localmap function! i'm very glad it's finally included |
20:50 |
Sokomine |
now the only point where my version of mt still has to differ from the master branch is regarding commit 1b4908b i'd be very glad if a config option could be added to disable that "feature" there. and other players think similar |
20:51 |
Sokomine |
adding a single line would be sufficient to make it a config option i think |
20:55 |
|
exio4 joined #minetest-dev |
20:58 |
|
Miner_48er joined #minetest-dev |
21:07 |
|
chchjesus__ joined #minetest-dev |
21:08 |
|
Amaz joined #minetest-dev |
21:17 |
RealBadAngel |
ShadowNinja, if that works then ok |
21:18 |
RealBadAngel |
i think i was checkin that with nodes that didnt needed extra facedir rotations |
21:19 |
RealBadAngel |
mushrooms were symetrical to some degree, so i havent noticed the problem |
21:28 |
ShadowNinja |
kaeza: For your cleanup: make nodedef_default / craftdef_default "inherit" from a common ancestor (itemdef_default?) |
21:33 |
ShadowNinja |
Does #1843 look O.K? I've trimmed out the whitespace changes so it won't confilct with kaeza's cleanup. |
21:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/1843 -- Add setting to customise stack max by rubenwardy |
21:38 |
VanessaE |
oh that'll be handy. |
21:47 |
|
ShadowLadyXD joined #minetest-dev |
21:51 |
ShadowNinja |
sfan5: I think can remove that server-created-by-the-client ugliness in my SQLite3 pos split patch, since I removed the ServerMap dependency and ServerMap::saveBlock(MapBlock, Database) can be made static. :-D |
21:53 |
|
AnotherBrick joined #minetest-dev |
21:58 |
|
gravgun left #minetest-dev |
22:25 |
ShadowNinja |
sfan5: beginSave() starts queueing blocks to be written until endSave() is called. The client doesn't call endSave() until shutdown. That could cause a freeze when shutting down. |
22:35 |
|
shadowzone joined #minetest-dev |
22:45 |
|
ShadowLadyXD joined #minetest-dev |
22:51 |
|
chchjesus__ joined #minetest-dev |
22:57 |
|
NakedFury joined #minetest-dev |
23:13 |
|
AnotherBrick joined #minetest-dev |
23:21 |
|
shadowzone joined #minetest-dev |
23:24 |
|
zat joined #minetest-dev |
23:44 |
|
rickmcfarley joined #minetest-dev |