| Time |
Nick |
Message |
| 00:02 |
TBC_x |
so est31, does client->create_player_on_auth_success indicate that the client just connected to the server? |
| 00:03 |
TBC_x |
because the only place it gets set is in handleCommand_Init() |
| 00:04 |
est31 |
TBC_x, the commit that added the flag was a57d83b4 |
| 00:05 |
TBC_x |
yes |
| 00:05 |
TBC_x |
is it necessary? |
| 00:05 |
est31 |
its a bugfix commit |
| 00:05 |
est31 |
yes it is neccessary |
| 00:06 |
est31 |
create_player_on_auth_success is true if the player's resources should be allocated on auth success |
| 00:06 |
est31 |
this is only required when you have default passwords |
| 00:06 |
TBC_x |
I'm trying to reduce (almost) permanently stored temporary variables |
| 00:07 |
est31 |
its needed for the auth, after auth it can be removed |
| 00:08 |
TBC_x |
it is better to ask than leave broken code behind |
| 00:16 |
TBC_x |
I want to convert RemoteClient class to POD structure |
| 00:16 |
TBC_x |
it should be possible |
| 00:41 |
hmmmm |
:) i'm so happy i'm not the one releasing |
| 01:01 |
|
twoelk joined #minetest-dev |
| 01:21 |
|
twoelk joined #minetest-dev |
| 01:36 |
* VanessaE |
peeks in |
| 01:36 |
VanessaE |
did I miss all the fun then? :) |
| 02:30 |
|
sgtbigman joined #minetest-dev |
| 02:56 |
|
Siva_Machina left #minetest-dev |
| 02:59 |
|
Siva_Machina joined #minetest-dev |
| 03:00 |
|
Hunterz joined #minetest-dev |
| 03:42 |
|
Siva joined #minetest-dev |
| 03:50 |
|
Siva-Android joined #minetest-dev |
| 04:21 |
|
OldCoder joined #minetest-dev |
| 04:29 |
|
Sketch2 joined #minetest-dev |
| 04:33 |
|
Sketch2 joined #minetest-dev |
| 04:45 |
|
tuy joined #minetest-dev |
| 04:50 |
|
Siva_Machina joined #minetest-dev |
| 05:10 |
|
Siva joined #minetest-dev |
| 05:42 |
|
Hunterz joined #minetest-dev |
| 05:49 |
|
nrzkt joined #minetest-dev |
| 06:12 |
|
Siva-Android joined #minetest-dev |
| 06:35 |
|
Siva_Machina joined #minetest-dev |
| 06:40 |
|
Siva joined #minetest-dev |
| 07:10 |
|
Calinou joined #minetest-dev |
| 07:26 |
|
Gael-de-Sailly joined #minetest-dev |
| 07:40 |
|
nore joined #minetest-dev |
| 07:48 |
|
nrzkt joined #minetest-dev |
| 07:51 |
|
emptty joined #minetest-dev |
| 07:52 |
|
rubenwardy joined #minetest-dev |
| 08:00 |
|
Yepoleb_ joined #minetest-dev |
| 08:00 |
rubenwardy |
paramat doesn't have the `developer` rank on the forum: https://forum.minetest.net/memberlist.php?mode=viewprofile&u=3380 |
| 08:31 |
|
Siva_Machina joined #minetest-dev |
| 08:48 |
|
julienrat joined #minetest-dev |
| 08:53 |
|
julienrat left #minetest-dev |
| 08:56 |
|
twoelk joined #minetest-dev |
| 08:57 |
|
Amaz joined #minetest-dev |
| 09:01 |
|
err404_ joined #minetest-dev |
| 09:20 |
|
julienrat joined #minetest-dev |
| 09:39 |
|
ElectronLibre joined #minetest-dev |
| 10:00 |
|
julienrat joined #minetest-dev |
| 10:17 |
|
julienrat left #minetest-dev |
| 10:20 |
|
kilbith joined #minetest-dev |
| 10:21 |
kilbith |
please someone update that page : http://www.minetest.net/download |
| 10:24 |
|
H-H-H joined #minetest-dev |
| 10:25 |
|
emptty joined #minetest-dev |
| 10:40 |
|
Donillo joined #minetest-dev |
| 11:04 |
|
julienrat joined #minetest-dev |
| 11:05 |
|
julienrat1 joined #minetest-dev |
| 11:07 |
|
julienrat joined #minetest-dev |
| 11:07 |
|
julienrat2 joined #minetest-dev |
| 11:12 |
|
julienrat joined #minetest-dev |
| 11:16 |
|
julienrat1 joined #minetest-dev |
| 11:22 |
|
julienrat1 left #minetest-dev |
| 11:22 |
TBC_x |
what is an average size of mapblockmesh? |
| 11:22 |
rubenwardy |
sounds like i |
| 11:23 |
rubenwardy |
*sounds like Irrlicht wizardry and dark magic |
| 11:24 |
TBC_x |
I am asking because big subgames are ramming RAM |
| 11:25 |
TBC_x |
and I've noticed that item visuals are generated as mapblock meshes unless I'm wrong |
| 11:38 |
|
Darcidride joined #minetest-dev |
| 11:40 |
|
Zeitgeist_ joined #minetest-dev |
| 11:55 |
|
Siva joined #minetest-dev |
| 11:56 |
|
sgtbigman joined #minetest-dev |
| 12:01 |
|
Gael-de-Sailly joined #minetest-dev |
| 12:07 |
|
proller joined #minetest-dev |
| 12:33 |
|
WSDguy2014 joined #minetest-dev |
| 12:52 |
|
proller joined #minetest-dev |
| 13:27 |
|
zupoman joined #minetest-dev |
| 13:40 |
|
johnwayne1986 joined #minetest-dev |
| 13:57 |
|
emptty joined #minetest-dev |
| 14:18 |
|
hmmmm joined #minetest-dev |
| 14:55 |
|
julienrat joined #minetest-dev |
| 14:58 |
|
H-H-H joined #minetest-dev |
| 15:10 |
|
Hunterz joined #minetest-dev |
| 15:16 |
|
proller joined #minetest-dev |
| 15:38 |
|
Gael-de-Sailly joined #minetest-dev |
| 15:46 |
|
Samson1 joined #minetest-dev |
| 15:47 |
VanessaE |
hmmmm: what's the general level of interest here in getting off of irrlicht? |
| 15:47 |
hmmmm |
high. |
| 15:47 |
VanessaE |
wait. |
| 15:47 |
VanessaE |
it would seem that zeno has completed his abstraction. |
| 15:47 |
VanessaE |
he's got MT working with Ogre. |
| 15:47 |
hmmmm |
wow! |
| 15:48 |
VanessaE |
he says he's not ready to make it public yet. guess some polishing still needed. |
| 15:49 |
VanessaE |
I'm trying to drag him back over here |
| 15:49 |
nore |
this is impressive |
| 15:49 |
VanessaE |
[08-21 11:48] <Zeno`> I'm not ready to make it public yet |
| 15:49 |
VanessaE |
[08-21 11:48] <Zeno`> it runs but it's not great. So much shit code to replace |
| 15:49 |
VanessaE |
[08-21 11:49] <Zeno`> when I do it won't be a PR ;) |
| 15:49 |
VanessaE |
[08-21 11:49] <Zeno`> way too big for a PR |
| 15:51 |
VanessaE |
it'll be a fork because.... [08-21 11:51] <Zeno`> because I can't keep up with syncing it |
| 15:52 |
VanessaE |
[08-21 11:52] <Zeno`> seriously, I am probably 7-8 weeks off making it public |
| 15:52 |
VanessaE |
[08-21 11:52] <Zeno`> and then I will |
| 15:52 |
nore |
wouldn't it be possible, once it is done, to make a week-long freeze |
| 15:53 |
nore |
sync the code, merge it |
| 15:53 |
nore |
and then resume development normally, so we still have it? |
| 15:54 |
nore |
it would be sad if we threw all this code away |
| 15:54 |
VanessaE |
[08-21 11:54] <Zeno`> neither am I... I don't know how it can be merged. It probably can, but it's too much work for me |
| 15:55 |
|
rubenwardy joined #minetest-dev |
| 16:02 |
VanessaE |
he says he will push it to a repo tomorrow. |
| 16:02 |
VanessaE |
he wants to run through it one last time, just to make sure his code isn't any worse than MT ;) |
| 16:02 |
|
emptty joined #minetest-dev |
| 16:04 |
celeron55 |
well, just let zeno finish his unsynced code |
| 16:06 |
VanessaE |
well in any case he says it's quite late for him, and he's booted into windows at the moment, else I guess he'd have released it now. |
| 16:07 |
VanessaE |
he says that he was going to release anyway, but now his plans have been "accelerated" since at least a couple people in here are interested in it. |
| 16:07 |
celeron55 |
also... i'm not going to say i'm impressed until i actually see it. but once i do, i probably am |
| 16:07 |
VanessaE |
heh |
| 16:11 |
celeron55 |
(i mean, i kind of know how much work that is, because i've been looking into doing the same thing with urho3d, though which would be way more insane) |
| 16:11 |
VanessaE |
well he did say that this ended up being a lot more involved than he first figured |
| 16:11 |
celeron55 |
it's insane. that's how i would describe it |
| 16:11 |
VanessaE |
heh |
| 16:19 |
celeron55 |
also i must say coding instead of arguing on IRC is a good plan |
| 16:23 |
|
leat joined #minetest-dev |
| 16:25 |
hmmmm |
nice |
| 16:25 |
hmmmm |
honestly I'm impressed too |
| 16:26 |
|
Player_2 joined #minetest-dev |
| 16:26 |
hmmmm |
this is the kind of stuff that will push us closer to 1.0.0 |
| 16:26 |
nore |
I am impressed too |
| 16:27 |
rubenwardy |
if it works |
| 16:27 |
rubenwardy |
:P |
| 16:27 |
nore |
(I remember when I tried to remove map size limit, it was difficult, and this must have been much harder) |
| 16:27 |
rubenwardy |
It's very impressive |
| 16:28 |
VanessaE |
nore: you DO realize what you've just done, right? :) |
| 16:28 |
nore |
what did I do ? |
| 16:29 |
nore |
well, except saying I was impressed |
| 16:29 |
VanessaE |
nore: "well I tried to A, but he did B and B was MUCH harder." Ergo, you now have to do A ;) |
| 16:29 |
nore |
hm... |
| 16:29 |
nore |
so that means I have to try again to remove map limit ? :s |
| 16:30 |
VanessaE |
yes. :-) I'm of course kidding, as there seems to be no real call for that. |
| 16:30 |
nore |
I remember that the old code segfaulted often |
| 16:30 |
nore |
for a quantity of reasons, most of which I couldn't find :( |
| 16:35 |
|
nrzkt joined #minetest-dev |
| 16:38 |
|
julienrat joined #minetest-dev |
| 16:39 |
|
sfan5 joined #minetest-dev |
| 16:43 |
|
wischi joined #minetest-dev |
| 16:46 |
TBC_x |
what limits the world size? just irrlicht? |
| 16:46 |
hmmmm |
the data types in the v3s16 structure |
| 16:46 |
VanessaE |
the fact that 16-bit typoes were used |
| 16:46 |
VanessaE |
types* |
| 16:46 |
hmmmm |
typos lol |
| 16:46 |
VanessaE |
lol |
| 16:47 |
TBC_x |
imho that could be worked around using spatial location |
| 16:47 |
VanessaE |
well given the number of typos I've made over the users, you'd need a u16 to store them :D |
| 16:47 |
VanessaE |
G*d damn it |
| 16:47 |
VanessaE |
over the YEARS. |
| 16:48 |
TBC_x |
and I was earlier talking about asynchronous world simulation |
| 16:50 |
TBC_x |
and I think that client would be even satisfied by v3s8 type |
| 16:50 |
TBC_x |
if anyone is crazy enough to do that |
| 16:53 |
H-H-H |
lol"16 bit typos |
| 17:01 |
|
julienrat joined #minetest-dev |
| 17:03 |
|
Taoki joined #minetest-dev |
| 17:08 |
|
Taoki joined #minetest-dev |
| 17:24 |
* Sketch2 |
imagines Luigi as a typo. instead of #ff0000 for Mario's red, they put in #00ff00 and got green |
| 17:26 |
rubenwardy |
hmmmm, https://forum.minetest.net/viewtopic.php?f=6&t=13081 |
| 17:26 |
rubenwardy |
About OOM |
| 17:27 |
hmmmm |
ohh man :) |
| 17:27 |
hmmmm |
>Current Lua memory usage: 44 MB |
| 17:27 |
VanessaE |
well that kinda blows away the theory that it was Sokomine's markers mod :P |
| 17:28 |
hmmmm |
no it's sokomine's markers mod as well |
| 17:28 |
VanessaE |
ok |
| 17:28 |
hmmmm |
there are a ton of different reasons why this could happen |
| 17:28 |
rubenwardy |
all of those mods use noise, which is why I though it was noise |
| 17:28 |
hmmmm |
Sketch: unlikely, the NES used NTSC color codes. |
| 17:29 |
hmmmm |
dammit |
| 17:29 |
rubenwardy |
Why didn't this crash before? |
| 17:29 |
hmmmm |
this is most likely a luajit problem |
| 17:30 |
VanessaE |
hmmmm: I dunno...someone calling it "4.13" doesn't strike me as the sort of person who would be using luajit |
| 17:30 |
hmmmm |
don't windows builds come with luajit? |
| 17:30 |
|
Taoki joined #minetest-dev |
| 17:30 |
VanessaE |
the unofficial ones do |
| 17:30 |
hmmmm |
hmm |
| 17:30 |
VanessaE |
but I'm not sure if the official ones do. |
| 17:31 |
Sketch2 |
it was a joke. they might not have used hex to represent the color, but the idea is still sound. |
| 17:32 |
hmmmm |
:) |
| 17:32 |
TBC_x |
will see whether the OOM will happen after I fix the heap corruption |
| 17:32 |
hmmmm |
lol |
| 17:33 |
hmmmm |
this is so messed |
| 17:33 |
|
julienrat joined #minetest-dev |
| 17:34 |
|
julienrat1 joined #minetest-dev |
| 17:36 |
TBC_x |
I wish that fix could work without messing the code so deep but I don't know any other correct way |
| 17:42 |
VanessaE |
bbl |
| 17:52 |
|
Krock joined #minetest-dev |
| 17:53 |
|
Calinou joined #minetest-dev |
| 17:59 |
|
paramat joined #minetest-dev |
| 18:00 |
paramat |
hmmmm see https://forum.minetest.net/viewtopic.php?p=187847#p187847 |
| 18:04 |
VanessaE |
hmmmm, kahrl: two more indirect calls for "simple" shaders, just fyi. |
| 18:05 |
VanessaE |
s/calls/requests/ |
| 18:21 |
paramat |
pathv6alt has 9 2D noises, so all those have perlinmap z dimension != 1, consuming lots of memory |
| 18:22 |
* VanessaE |
begins to worry a little |
| 18:22 |
VanessaE |
biome_lib has three or four perlin noises... though they're not the same sort of calls as you're using |
| 18:23 |
|
Gael-de-Sailly joined #minetest-dev |
| 18:23 |
paramat |
you use perlinmaps? |
| 18:24 |
VanessaE |
I use the PerlinNoise() call to get them |
| 18:24 |
VanessaE |
so probably not even the same thing |
| 18:25 |
paramat |
correct, no need to worry |
| 18:25 |
VanessaE |
and get_perlin() in one case. |
| 18:25 |
VanessaE |
ok, just checking |
| 18:26 |
paramat |
it's the bulk perlinmaps that consume much memory |
| 18:26 |
VanessaE |
yeah |
| 18:26 |
VanessaE |
so no worries here then |
| 18:27 |
VanessaE |
typical usage in my case: https://github.com/VanessaE/biome_lib/blob/master/init.lua#L203-L209 |
| 18:28 |
paramat |
yes the pre-perlinmap method |
| 18:28 |
VanessaE |
ok |
| 18:29 |
VanessaE |
some day I will probably update to the newer method, but not now :) |
| 18:29 |
VanessaE |
anyway bbl for real this time |
| 18:40 |
|
paramat left #minetest-dev |
| 18:43 |
|
OldCoder joined #minetest-dev |
| 18:50 |
|
Taoki joined #minetest-dev |
| 19:04 |
Donillo |
does LuaJIT make troubles? |
| 19:04 |
Donillo |
I am using it only at server |
| 19:09 |
|
casimir joined #minetest-dev |
| 19:14 |
|
MinetestForFun joined #minetest-dev |
| 19:20 |
Calinou |
rarely |
| 19:26 |
|
Taoki joined #minetest-dev |
| 19:55 |
|
Siva joined #minetest-dev |
| 20:12 |
|
est31 joined #minetest-dev |
| 20:13 |
est31 |
TBC_x, what precisely is the heap corruption about? |
| 20:22 |
TBC_x |
it is the way of how is RemoteClient accessed |
| 20:22 |
TBC_x |
without a mutex inside packet handlers |
| 20:23 |
est31 |
so its a race condition ... between? |
| 20:23 |
TBC_x |
between server thread and emerge thread |
| 20:23 |
nrzkt |
emerge thread doesn't give packet. |
| 20:23 |
est31 |
TBC_x, why does emerge thread access remoteclient? |
| 20:23 |
nrzkt |
please learn to read code properly and stop insert mutex where not needed. |
| 20:24 |
nrzkt |
Packets are read from ConnectionReceiveThread into a mutexqueue. |
| 20:24 |
nrzkt |
Stop use gedit and please use a good EDI to follow code, like VS, Eclipse or QTCreator. |
| 20:25 |
|
Krock joined #minetest-dev |
| 20:26 |
TBC_x |
I'll look that up |
| 20:29 |
est31 |
EDIs are too heavy, slow and sluggish |
| 20:29 |
est31 |
they distract IMO |
| 20:29 |
est31 |
but fortunately everybody is free to choose what tools they want |
| 20:30 |
kahrl |
what's an EDI? |
| 20:30 |
est31 |
french for IDE? |
| 20:30 |
kahrl |
oh, yeah |
| 20:30 |
kahrl |
Environnement de développement intégré |
| 20:30 |
est31 |
sometimes they swap letters |
| 20:31 |
est31 |
french name for UNO is ONU :) |
| 20:31 |
nrzkt |
IDE is IDE in french |
| 20:31 |
est31 |
https://fr.wikipedia.org/wiki/Organisation_des_Nations_unies |
| 20:31 |
nrzkt |
no it's EDI .. i inverted it :p |
| 20:32 |
nrzkt |
because everybody in france said IDE and nobody use EDI :p |
| 20:32 |
nrzkt |
UNO is a good card game :D |
| 20:33 |
est31 |
germans say VN, but only at the website of the foreign ministry |
| 20:33 |
est31 |
everywhere else they say UN |
| 20:33 |
nrzkt |
xD |
| 20:33 |
Krock |
nrzkt +1 |
| 20:34 |
nrzkt |
for the IDE it's very good to track bugs, everybody is free, but for mutexes, concurrent threading etc, IDE are the most pratical to catch those bugs because you can see easily the whole call tree for a variable |
| 20:36 |
TBC_x |
oh yeah, server thread and emerge thread stepping over each other at SetBlocksNotSent |
| 20:36 |
nrzkt |
there is a queue for that with a mutex too if i remember. |
| 20:37 |
nrzkt |
and there is the m_env mutex for that also |
| 20:37 |
nrzkt |
please be sure of what you said. |
| 20:39 |
TBC_x |
what mutexes are hold when packet handler runs? |
| 20:39 |
nrzkt |
packet handlers are called by server thread |
| 20:40 |
nrzkt |
in the main loop |
| 20:41 |
TBC_x |
so I assume that calling packet handler body don't hold any mutex |
| 20:41 |
TBC_x |
on itself |
| 20:41 |
nrzkt |
why do you want to call a mutex on ServerThread for ServerThread itself ? |
| 20:42 |
TBC_x |
It looks like m_clients mutex is not held when it should be because there is concurrent access from emerge thread |
| 20:42 |
nrzkt |
look at EmergeThread m_clients calls then |
| 20:43 |
TBC_x |
http://sprunge.us/YUZU |
| 20:43 |
TBC_x |
had to dig it up in logs |
| 20:45 |
est31 |
can I push https://github.com/est31/minetest/commit/4b0f8096601224b4716e4d655217fe203aac848c |
| 20:46 |
est31 |
would be interesting for nrzkt to backport for his play store builds as well |
| 20:47 |
TBC_x |
what led me to believe that it is caused from conucrrency of emerge thread and server thread is because I have noticed that when there is extracted RemoteClient with getClient() the usage of the client is not guarded by any mutex and any thread theroetically can call Server::SetBlocksNotSent() which does lock clients but it is useless because packet handlers don't lock clients |
| 20:48 |
nrzkt |
est31: okay for me |
| 20:48 |
|
proller joined #minetest-dev |
| 20:48 |
nrzkt |
i haven't do the play store build yet but i will use this commit okay |
| 20:48 |
est31 |
pushed |
| 20:49 |
est31 |
nrzkt, it should be doable to use the commit without backporting, as the "continue with -dev" commit doesnt affect the android build process |
| 20:49 |
nrzkt |
TBC_x: please look at the m_env mutex, it can be the protector for the whole thing |
| 20:50 |
nrzkt |
est31: yes |
| 20:50 |
|
OldCoder joined #minetest-dev |
| 20:50 |
nrzkt |
the client version is in AndroidManifest, the ID is the most import, other things are not important |
| 20:51 |
TBC_x |
do you mean that I should add m_env lock to SetBlocksNotSent() ? |
| 20:51 |
nrzkt |
TBC_x i don't said that, i said m_env protect many and many things |
| 20:51 |
nrzkt |
and it's the lock used generally between emerge and server threads |
| 20:52 |
est31 |
well, its better to be lock free than to restructure entire files |
| 20:52 |
est31 |
err |
| 20:52 |
est31 |
its better to have locks than to restructure entire files |
| 20:52 |
nrzkt |
:) |
| 20:52 |
est31 |
but lock freedom is good as well |
| 20:53 |
TBC_x |
that would have to be done once anyway |
| 20:53 |
nrzkt |
lock freeing a so huge project is... death |
| 20:53 |
nrzkt |
lock freeing is not as easy as mutexes. Minetest should be rewrote heavily to have this |
| 20:54 |
TBC_x |
freeminer "fixed" this problem using individual RemoteClient mutex and shared_ptr |
| 20:55 |
TBC_x |
I would rather do more rewriting that keeping this abomination |
| 20:55 |
nrzkt |
shared_ptr couldn't be use by minetest atm, we are c++89 |
| 20:55 |
TBC_x |
I don't even suggest it |
| 20:56 |
est31 |
nrzkt, that even is a reason to use shared_ptr |
| 20:56 |
TBC_x |
it is not |
| 20:56 |
est31 |
err |
| 20:56 |
nrzkt |
i didn't said taht |
| 20:56 |
est31 |
thats an acually valid argument for switching to c++11 |
| 20:57 |
est31 |
I dont care that we can write for loops shorter with the : now |
| 20:57 |
est31 |
thats syntactic sugar |
| 20:57 |
est31 |
but shared_ptr is a really interesting feature |
| 20:57 |
TBC_x |
shared_ptr is a patch |
| 20:58 |
TBC_x |
literally |
| 20:58 |
TBC_x |
or a carpet |
| 20:58 |
TBC_x |
to hide problems underneath |
| 21:02 |
TBC_x |
imho |
| 21:03 |
TBC_x |
unless it is used on immutable data |
| 21:05 |
est31 |
well yes, using shared_ptr for sharing data between threads is not enough |
| 21:05 |
est31 |
but if both just read, everything is ok |
| 21:06 |
kahrl |
what is the point of shared_ptr if everyone just reads? |
| 21:06 |
kahrl |
(I don't count deleting the object as just reading) |
| 21:07 |
est31 |
I do :) |
| 21:07 |
est31 |
but yeah, generally its not good to count it as reading |
| 21:08 |
TBC_x |
If you have for example a texture used in multiple places |
| 21:08 |
est31 |
the only thing shared_ptr protects you from is the deletion race condition |
| 21:08 |
est31 |
everything else is kept unprotected |
| 21:08 |
est31 |
you have to keep that in mind |
| 21:09 |
TBC_x |
shared state is evil |
| 21:09 |
TBC_x |
shared mutable state |
| 21:10 |
est31 |
? |
| 21:11 |
TBC_x |
it is error prone |
| 21:11 |
est31 |
well yes, multithreading is error prone |
| 21:12 |
est31 |
but its hard to do in a fast way without sharing data |
| 21:14 |
TBC_x |
you need to have clearly defined ownership |
| 21:14 |
est31 |
you need to share data in some way |
| 21:14 |
est31 |
otherwise you have separate programs |
| 21:15 |
est31 |
but yes, race conditions are race conditions, and evil |
| 21:15 |
est31 |
if you mean that |
| 21:17 |
TBC_x |
hmm... ownership... I meant lifetime |
| 21:19 |
TBC_x |
sharing mutable data should be done using agents |
| 21:19 |
TBC_x |
i count queues in |
| 21:20 |
TBC_x |
if you know what I mean |
| 21:21 |
TBC_x |
race conditions are just innocent creatures |
| 21:22 |
TBC_x |
spawned by higher evil |
| 21:24 |
TBC_x |
my changes remove the single TODO in clientiface.h |
| 21:26 |
|
Siva_AndroIRC joined #minetest-dev |
| 21:30 |
|
ElectronLibre left #minetest-dev |
| 21:33 |
|
H-H-H joined #minetest-dev |
| 21:34 |
|
Sketch2 joined #minetest-dev |
| 21:42 |
hmmmm |
as a general rule of thumb: |
| 21:42 |
hmmmm |
DON'T USE SHARED_PTR |
| 21:42 |
hmmmm |
if you find yourself needing to, your thing is probably designed the wrong way |
| 21:42 |
TBC_x |
that is basically what I wanted to say |
| 21:43 |
est31 |
I admit I dont have the experience with shared ptr to really judge it |
| 21:44 |
TBC_x |
I have noticed that reference counting is usually used in places without properly defined lifetimes or ownership |
| 21:45 |
est31 |
its like saying "i dont use a while loop, because I like for loops so much" |
| 21:46 |
rubenwardy |
for(;cond;) |
| 21:46 |
rubenwardy |
:( |
| 21:49 |
TBC_x |
sometimes I get mad when I can't use a for loop |
| 21:49 |
TBC_x |
I don't mean that I use `for (;;)` |
| 21:53 |
TBC_x |
I dislike while loops where I have to use ++i inside while body |
| 21:58 |
|
Siva joined #minetest-dev |
| 21:59 |
|
Siva joined #minetest-dev |
| 22:03 |
|
Niebieski joined #minetest-dev |
| 22:23 |
|
Siva_Machina joined #minetest-dev |
| 22:29 |
|
H-H-H joined #minetest-dev |
| 22:34 |
|
Taoki joined #minetest-dev |
| 22:50 |
VanessaE |
wow mgv7 produces an awful lot of those square, black shadows |
| 22:51 |
VanessaE |
particularly when an l-systems tree is spawned at mapgen time |
| 22:51 |
VanessaE |
(I was curious how plantlife + moretrees behaves) |
| 22:54 |
VanessaE |
example: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-08-21_18-54-03.png |
| 22:56 |
hmmmm |
hrm |
| 22:56 |
hmmmm |
to me, that looks like an interaction between mgv7 and a misbehaving mod that uses luavoxelmanip |
| 22:56 |
VanessaE |
can't be. |
| 22:56 |
VanessaE |
only moretrees, plantlife, unified inventory, and minetest_game here. |
| 22:56 |
hmmmm |
if mapgen v7 raw gave that kind of output there'd be lots to be concerned about |
| 22:56 |
hmmmm |
it has to be moretrees causing it |
| 22:57 |
VanessaE |
and at least moretrees and plantlife do not use lua vmanips |
| 22:57 |
hmmmm |
yeah but moretrees uses lsystem trees |
| 22:57 |
VanessaE |
true. |
| 22:57 |
VanessaE |
this reminds me a lot of that glitch we had a while back with mgv6 |
| 22:57 |
VanessaE |
when spawning a tree from a sapling would cause shadows |
| 22:58 |
VanessaE |
despite the lighting bug, the terrain is interesting |
| 22:59 |
VanessaE |
holy crap there's stuff extending way up past the clouds with this map :) |
| 22:59 |
VanessaE |
(it's my usual test map, decided to delete the map.sqlite and switch the mapgen to v7 just to putter around) |
| 23:04 |
Wayward_One |
I notice those shadows also when using the ruins mod from blockmen's wasteland game |
| 23:32 |
|
sgtbigman joined #minetest-dev |
| 23:34 |
VanessaE |
paramat: snow coverage on pines seems to have minor map chunk edge issues (not very visible in the world but you can see it in the minimap) |
| 23:43 |
|
paramat joined #minetest-dev |
| 23:43 |
* VanessaE |
hides |
| 23:44 |
paramat |
yeah i noticed that too |
| 23:44 |
paramat |
hehe |
| 23:44 |
VanessaE |
you've created some epic terrain here |
| 23:44 |
paramat |
something to do with pines overgenerating across chunk borders |
| 23:44 |
VanessaE |
see above (logs) about the lighting glitch being triggered by lsystem trees |
| 23:44 |
paramat |
saw that |
| 23:46 |
paramat |
something to do with moretrees plus mgv7 |
| 23:46 |
VanessaE |
mmhmm |
| 23:46 |
VanessaE |
it's a race condition |
| 23:47 |
VanessaE |
if the relevant land and its air above has had "enough" time to fully generate, the tree appearing there seems to not cause a problem |
| 23:52 |
paramat |
l-system trees use 'updateLighting', that's known to be buggy |
| 23:53 |
paramat |
the shadow bugs are worse in mgv7 than mgv6? |
| 23:54 |
VanessaE |
yes |
| 23:54 |
VanessaE |
WAY worse |
| 23:54 |
VanessaE |
in v6 they almost don't happen in practice |
| 23:54 |
paramat |
mgv5/v7 use a different mapgen calcLighting to mgv6, might be relevant |
| 23:56 |
paramat |
hmmmmm added a 4-argument calcLighting for mapgens that overgenerate, as v5/v7 do |
| 23:57 |
|
wischi joined #minetest-dev |
