| Time |
Nick |
Message |
| 00:05 |
|
Miner_48er joined #minetest-dev |
| 00:18 |
ShadowNinja |
~tell sapier Can you check https://plus.google.com/u/0/b/116830764303517937720/113166754097327759829/posts/KuYZoBrim82 ? |
| 00:18 |
ShadowBot |
ShadowNinja: O.K. |
| 00:19 |
|
cisoun joined #minetest-dev |
| 00:19 |
cisoun |
Hey. |
| 00:22 |
cisoun |
celeron55: I'm managing the Google+ page of Minetest (since 2011) and ShadowNinja told me I should transfer you its ownership. Interested ? |
| 00:30 |
ShadowNinja |
This should fix ^: http://ix.io/a5H |
| 00:40 |
|
proller joined #minetest-dev |
| 01:06 |
VanessaE |
ok, progress report on the current state of the network code, without the pull request sapier mentioned wanting shadow and I to try: with round about 30 users online, the map loader/emerge thread starts to lag rather badly - BUT things like chat, building/digging etc are working just fine. |
| 01:06 |
VanessaE |
and the total CPU, disk and network bandwidth have plenty of headroom left, so it's not any kind of hardware bottleneck, at least not at the server end. |
| 01:07 |
RealBadAngel |
so what about #1112 ? can we merge it? |
| 01:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/1112 -- New HUD element - waypoint. by RealBadAngel |
| 01:07 |
VanessaE |
(and these are 30-odd active, real players, not a bunch of bots) |
| 01:11 |
VanessaE |
inb4 pr0ller mentions that fm can do 10x as many players before emergethread starts to lag. |
| 01:12 |
VanessaE |
it seems to be directly related to the number of players who are downloading new media, as before. |
| 01:12 |
kaeza |
FM can do 20x with 1% CPU usage! |
| 01:12 |
kaeza |
anyway, any more comments on crouching? |
| 01:13 |
VanessaE |
but it's hard to be sure, since I can't directly monitor downloads vs. regular usage. i can only go by what my network graph showed for the periods where the lag got bad. |
| 01:13 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/stats.html |
| 01:16 |
|
diemartin joined #minetest-dev |
| 01:24 |
|
salamanderrake joined #minetest-dev |
| 01:44 |
kaeza |
I'm trying to implement a `kick_player' method, and have a question about style: is it better to have a std::vector<u16> listing the peer IDs to disconnect each step, or add a bool field to RemoteClient and check that? |
| 01:44 |
kaeza |
(vector in Server) |
| 01:46 |
|
cisoun left #minetest-dev |
| 01:48 |
kaeza |
I guess calling DenyAccess from a Lua C function is not really safe... |
| 02:11 |
kahrl |
kaeza: I think sapier just restructured the way players and clients are stored, but that isn't merged yet |
| 02:11 |
kahrl |
so it might be better to wait on that |
| 02:11 |
kahrl |
(or start from his branch) |
| 02:30 |
kaeza |
ah I'll wait for him to finish his thing; it's not much work anyway :P |
| 02:30 |
kaeza |
thanks kahrl |
| 02:56 |
|
zat joined #minetest-dev |
| 03:01 |
ShadowNinja |
Or rather, this should fix it: ,,(tell sapier I made this patch for it http://ix.io/a5V does it look good?) |
| 03:01 |
ShadowBot |
ShadowNinja: O.K. |
| 03:11 |
|
AllegedlyDead joined #minetest-dev |
| 03:33 |
|
zat joined #minetest-dev |
| 03:47 |
|
salamanderrake joined #minetest-dev |
| 05:24 |
|
khonkhortisan joined #minetest-dev |
| 05:27 |
|
Neological joined #minetest-dev |
| 07:21 |
celeron55 |
cisoun (if you read the logs): I don't use google+ and i am definitely not interested |
| 07:44 |
RealBadAngel |
celeron55, hi. so can we merge #1112 ? |
| 07:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/1112 -- New HUD element - waypoint. by RealBadAngel |
| 08:13 |
|
werwerwer_ joined #minetest-dev |
| 08:48 |
|
us_0gb joined #minetest-dev |
| 09:15 |
|
us_0gb joined #minetest-dev |
| 09:46 |
|
darkrose joined #minetest-dev |
| 09:47 |
|
proller joined #minetest-dev |
| 10:18 |
|
rsiska joined #minetest-dev |
| 10:39 |
|
ImQ009 joined #minetest-dev |
| 11:14 |
|
ImQ009_ joined #minetest-dev |
| 11:19 |
|
ImQ009 joined #minetest-dev |
| 11:54 |
|
Weedy_lappy joined #minetest-dev |
| 12:05 |
|
ImQ009 joined #minetest-dev |
| 12:21 |
|
ImQ009 joined #minetest-dev |
| 12:26 |
|
Weedy_lappy joined #minetest-dev |
| 12:26 |
|
Weedy_lappy joined #minetest-dev |
| 12:27 |
|
Weedy_lappy joined #minetest-dev |
| 12:39 |
|
mrtux joined #minetest-dev |
| 12:45 |
|
EvergreenTree joined #minetest-dev |
| 12:45 |
|
EvergreenTree joined #minetest-dev |
| 12:53 |
|
mrtux joined #minetest-dev |
| 13:07 |
|
mrtux joined #minetest-dev |
| 13:17 |
|
mrtux joined #minetest-dev |
| 13:27 |
|
proller joined #minetest-dev |
| 13:27 |
|
troller joined #minetest-dev |
| 13:34 |
|
hmmmm joined #minetest-dev |
| 13:39 |
|
OldCoder joined #minetest-dev |
| 13:39 |
VanessaE |
ha! someone tried the signs "${text}" exploit on my server. FAIL |
| 13:45 |
|
dzho joined #minetest-dev |
| 13:48 |
|
ImQ009 joined #minetest-dev |
| 13:51 |
|
OldCoder joined #minetest-dev |
| 13:55 |
|
rsiska joined #minetest-dev |
| 13:58 |
|
bas080 joined #minetest-dev |
| 14:08 |
|
PilzAdam joined #minetest-dev |
| 14:20 |
|
rsiska joined #minetest-dev |
| 14:32 |
|
RealBadAngel joined #minetest-dev |
| 14:41 |
RealBadAngel |
celeron55, are you here? |
| 14:47 |
|
zat joined #minetest-dev |
| 14:55 |
xyz |
VanessaE: fail? why? |
| 14:55 |
xyz |
it only depends on client version |
| 15:00 |
VanessaE |
xyz: because if you're smart, you keep on top of bug fixes? ergo, the exploit should fail. |
| 15:00 |
VanessaE |
oh right. |
| 15:01 |
VanessaE |
> users |
| 15:01 |
VanessaE |
> smart. |
| 15:01 |
VanessaE |
what WAS I thinking. |
| 15:06 |
sfan5 |
VanessaE: ${text} exploit? I'd like to know more |
| 15:07 |
VanessaE |
sfan5: I don't know much about it. some recursion bug, crashes some clients when they try to parse the text. |
| 15:07 |
VanessaE |
(I thought it affected servers, originally) |
| 15:10 |
sfan5 |
ah |
| 15:17 |
|
Yepoleb joined #minetest-dev |
| 15:18 |
xyz |
lolno |
| 15:19 |
xyz |
if you're smart you're using stable version of software |
| 15:19 |
VanessaE |
stable == buggy.... |
| 15:19 |
VanessaE |
if minetest's history is anything to go by. |
| 15:19 |
VanessaE |
every one of us here knows that. |
| 15:20 |
xyz |
well |
| 15:20 |
xyz |
if you're smart and don't know much about minetest |
| 15:20 |
xyz |
i mean, everywhere else you're supposed to use stable versions of software |
| 15:21 |
VanessaE |
yes, perhaps. |
| 15:21 |
xyz |
i'd call it confirmation bias |
| 15:21 |
xyz |
i'm sure most of people use stable builds |
| 15:21 |
xyz |
(it's similar to saying everybody who plays minetest uses linux) |
| 15:21 |
VanessaE |
they don't? ;) |
| 15:22 |
xyz |
well if you consider android |
| 15:22 |
xyz |
although the app got pulled |
| 15:22 |
xyz |
or something like that |
| 15:22 |
VanessaE |
I dunno, somehow or another I seem to get more tablent users every day |
| 15:22 |
VanessaE |
they're coming out of the fucking woodwork. |
| 15:22 |
VanessaE |
tablet* |
| 15:23 |
VanessaE |
I guess because the iOS client is still out there |
| 15:27 |
xyz |
ask them |
| 15:28 |
VanessaE |
waste of time :-/ |
| 15:28 |
VanessaE |
what I DO know is most of them are *paying* for it |
| 15:28 |
VanessaE |
which pisses me off. |
| 15:29 |
VanessaE |
<insert generic anti-capitalist/pro-communist rant here> |
| 15:30 |
xyz |
why? |
| 15:31 |
VanessaE |
because the game was meant to be free. |
| 15:31 |
xyz |
define free |
| 15:31 |
VanessaE |
I refuse to argue semantics, you know very well which definition I am referring to. |
| 15:32 |
VanessaE |
if it were meant to be commercial, it already would be by now. |
| 15:32 |
xyz |
no I don't |
| 15:32 |
xyz |
it's perfectly fine to sell GPL'd LGPL'd software and you know it |
| 15:32 |
VanessaE |
besides which, did we already forget that this for-pay version is an illegal fork? under US copyright law, as I understand how it works, that makes it 10x as illegal as it otherwise would be. |
| 15:33 |
VanessaE |
no, it isn't, if it's in violation of the license to begin with |
| 15:33 |
xyz |
i bet it'd be hard to prove it's in violation |
| 15:34 |
VanessaE |
probably hard to prove, sure. But then again, it didn't seem to actually take that much to get it pulled from Google Play. |
| 15:34 |
VanessaE |
I guess no one has approached Apple yet. |
| 15:34 |
xyz |
we still don't know why was it pulled |
| 15:34 |
VanessaE |
yeah I know |
| 15:35 |
|
NakedFury joined #minetest-dev |
| 15:35 |
VanessaE |
I assumed the initial response was automatic/boilerplate and that someone had finally reviewed the DMCA claim for real. |
| 15:35 |
xyz |
they reported to me that they've taken care of it |
| 15:35 |
xyz |
but then the app reappered |
| 15:36 |
xyz |
+a |
| 15:36 |
xyz |
not just the app, but three of them or so |
| 15:36 |
xyz |
and then after a week or so everything got down |
| 15:36 |
xyz |
well, I honestly don't care about apple |
| 15:37 |
xyz |
and if they just pull the apps instead of releasing the source (which I kind of hoped they'd do) then I see no point in doing that |
| 15:37 |
xyz |
it'll only piss users off |
| 15:38 |
VanessaE |
maybe they were re-pulled automatically. you know, duplicate/re-violation detection? |
| 15:38 |
VanessaE |
but you're ultimately right, if they'd just release up-to-date, buildable source, no one would complain |
| 15:38 |
VanessaE |
(at least about the legality of it) |
| 15:39 |
VanessaE |
I'll still bitch about the interface, but that's only because my users do |
| 15:39 |
xyz |
when I contacted google and pointed that the dev reposted those apps they said to open another claim |
| 15:39 |
xyz |
when I did they once again asked to prove that this indeed is an illegal use |
| 15:39 |
xyz |
then I thought "fuck it" and didn't reply |
| 15:42 |
VanessaE |
that's what I meant by boilerplate, I think the "prove it" part is automatic isn't it? |
| 15:42 |
VanessaE |
they must get thousands, perhaps tens of thousands of DMCA complaints per day |
| 15:42 |
VanessaE |
surely they've automated that |
| 15:43 |
xyz |
no, only the first reply is automatic |
| 15:43 |
xyz |
which says something like "we're processing your request wait a week or so" |
| 15:44 |
xyz |
the second time they also asked for a screenshot |
| 15:44 |
xyz |
"of the allegedly infringing content as it appears in the application in question" |
| 15:44 |
xyz |
well then it got boring |
| 15:44 |
VanessaE |
hm |
| 15:44 |
VanessaE |
well this kinda stuff can't be expected to be interesting |
| 15:46 |
VanessaE |
actually, that's not entirely true |
| 15:46 |
VanessaE |
I suppose some copyright cases could get interesting |
| 15:47 |
VanessaE |
like that whole apple/samsung patent case. or SCO vs... IBM was it? for a while there anyway. |
| 15:55 |
|
book` joined #minetest-dev |
| 16:18 |
|
Jordach joined #minetest-dev |
| 16:33 |
|
john_minetest joined #minetest-dev |
| 16:38 |
|
iqualfragile joined #minetest-dev |
| 16:40 |
|
Weedy_lappy joined #minetest-dev |
| 16:40 |
|
Weedy_lappy joined #minetest-dev |
| 16:43 |
|
Jordach joined #minetest-dev |
| 16:44 |
|
EvergreenTree joined #minetest-dev |
| 16:44 |
|
EvergreenTree joined #minetest-dev |
| 16:55 |
|
sapier joined #minetest-dev |
| 16:57 |
sapier |
ShadowNinja http://ix.io/a5V seems to be correct |
| 17:00 |
sapier |
kaeza if you use RemoteClient you have to lock client list while you use it |
| 17:01 |
sapier |
I suggest looking at 1116 it changes quite a lot about client handling |
| 17:02 |
sapier |
I wonder if vanessae's 30 player lag is result of number of blocks emerged |
| 17:03 |
VanessaE |
I believe it is. |
| 17:03 |
VanessaE |
because it's *only* the emergethread that lags, and even ordinary block loading (not mapgen). |
| 17:04 |
VanessaE |
server commands (e.g. /status) and incoming/outgoign chat don't lag during that time |
| 17:04 |
sapier |
node digging? |
| 17:04 |
VanessaE |
s/emergethread/loading of the map data/ |
| 17:04 |
VanessaE |
even digging/placing nodes seems to behave nodmallt. |
| 17:04 |
VanessaE |
normally* |
| 17:05 |
xyz |
what map backend do you use? |
| 17:05 |
VanessaE |
sqlite. |
| 17:05 |
sapier |
it'd be interesting to know if there are other packets on lower prio channels as blocks |
| 17:06 |
sapier |
obviously node digging is at higher priority |
| 17:07 |
sapier |
if digging nodes is fast, it's not exactly lag but a send priority issue |
| 17:07 |
sapier |
but I don't know how you could verify digging is really fast as prediction hides it |
| 17:08 |
sapier |
you could try increasing "max_packets_per_iteration" but this increases jitter at benefit of per peer throughput |
| 17:09 |
VanessaE |
sapier: I can only assume the placement is fast based on how much was still there when I signed off and back on again to try to combat the map-not-wanting-to-load issue |
| 17:09 |
sapier |
ok |
| 17:09 |
VanessaE |
that is to say, it was all still there save for the last couple of nodes I placed, and my sign off/on was only a few seconds. |
| 17:10 |
VanessaE |
meanwhile, the map was failing to load 30 seconds on. |
| 17:11 |
sapier |
a client side wireshark dump of this situation would be interesting |
| 17:11 |
VanessaE |
I might do later if it gets into this situation again |
| 17:12 |
sapier |
if I'm here I can do it myself but you might have to trigger me |
| 17:12 |
VanessaE |
I expect a similar situation in about 8 hours |
| 17:12 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/stats.html |
| 17:12 |
VanessaE |
you can see yesterday's peaks were between ~1800 and 2000 or so, EST |
| 17:12 |
VanessaE |
it's now about 1212 EST |
| 17:13 |
VanessaE |
(the big spike at 0800 was the daily backup cycle) |
| 17:14 |
sapier |
hmm you could add a ram usage statistic ;-) |
| 17:14 |
VanessaE |
I thought about it. :) |
| 17:15 |
sapier |
this would show packet queuing ... and therefore you could see texture downloads quite easy |
| 17:17 |
VanessaE |
I guess just a generic "total used", "buffers", and "cached" would be sufficient. |
| 17:18 |
sapier |
used and swap usage might be usefull ... cached ... as fat as I know linuy uses any free memory for disc cache so this number isn't very usefull |
| 17:20 |
sapier |
a friend of mine once implemented a read ahead feature for processing large data ... just to see a speedup of exactly 0 ... because of linux builtin disc prefetch mechanisms already did this before |
| 17:20 |
VanessaE |
there's 512MB of swap in the machine, but with 8GB of RAM, of which more than half is usually free, only 29MB of that swap is used :) |
| 17:20 |
sapier |
yes I didn't expect swap to be anything else then store for rarely used memory pages |
| 17:27 |
|
rubenwardy joined #minetest-dev |
| 17:27 |
|
grrk-bzzt joined #minetest-dev |
| 17:31 |
sapier |
VanessaE if you want to know which threads are using cpu you could apply this patch https://gist.github.com/sapier/8602068 |
| 17:31 |
sapier |
it's linux only |
| 17:32 |
sapier |
after this you will see thread names as well as per thread cpu usage if you enter "top -H -p <pid>" |
| 17:34 |
VanessaE |
per-thread, as in per-mod? or just per-some-generic-internal-minetest-thread? |
| 17:34 |
sapier |
no |
| 17:35 |
sapier |
per thread as in emerge thread server thread receive thread send thread |
| 17:35 |
VanessaE |
right, so the latter :) |
| 17:35 |
VanessaE |
still, that could be useful |
| 17:35 |
VanessaE |
why not just merge that? (with appropriate ifdef's) |
| 17:36 |
sapier |
I don't know how to do this on windows so I can't do a official pull request right now ... and I'd have to think about names in this case too as they're cut of right now |
| 17:36 |
sapier |
e.g. async threads are all named identical ... they should have their number at end |
| 17:37 |
sapier |
but of course those are minor things |
| 17:37 |
sapier |
I could add a setThreadName to porting ... but someone would complain why this fct is empty for windows ;-) |
| 17:37 |
sapier |
os specific ifdefs in other places then porting are crap |
| 17:38 |
sapier |
at least for a feature that unimportant |
| 17:42 |
Jordach |
someone might wanna deal with THIS again; https://itunes.apple.com/us/app/minetest./id717384883?mt=8 |
| 17:45 |
Jordach |
you might also want to poke Gambit from the forums, his pack has been stolen |
| 17:45 |
xyz |
wtf |
| 17:45 |
xyz |
i don't think it's even minetest |
| 17:46 |
xyz |
did someone test it? |
| 17:46 |
Jordach |
afaik, Gambit's stuff is CC-BY-ND-NC |
| 17:46 |
Jordach |
and that mapgen is minetest's i know that |
| 17:46 |
sapier |
that "sheep" seems to be a simplemob |
| 17:47 |
rubenwardy |
Doesn't matter. It uses our name. |
| 17:47 |
rubenwardy |
Has anyone legally registered "Minetest" as a trademark? |
| 17:47 |
Jordach |
btw, MC textures are stolen |
| 17:47 |
Jordach |
i'll poke Mojang too |
| 17:47 |
xyz |
rubenwardy: lol |
| 17:48 |
rubenwardy |
Yeah, I wouldn't expect anyone too |
| 17:48 |
sapier |
you don't need to officially register a trademark in a lot of countrys |
| 17:48 |
xyz |
the 3rd pic is definitely not minetest |
| 17:48 |
Jordach |
yeah |
| 17:48 |
xyz |
http://a1.mzstatic.com/us/r30/Purple/v4/7e/e8/30/7ee830f7-eb46-effa-adbb-ccd0bb746569/screen568x568.jpeg |
| 17:48 |
Jordach |
xyz, i'll poke Mojang about it |
| 17:48 |
xyz |
why? |
| 17:48 |
sapier |
true the sky doesn't match |
| 17:49 |
Jordach |
xyz, it's their IP |
| 17:49 |
Jordach |
which the MC textures happen to BE |
| 17:49 |
xyz |
no, I mean, why do you care? |
| 17:49 |
xyz |
also did you dl it and cra^W check that they really use them? |
| 17:50 |
Jordach |
xyz, their presence will have BC developers killed once and for all |
| 17:50 |
xyz |
I don't understand |
| 17:50 |
xyz |
why do you want to contact mojang |
| 17:50 |
xyz |
what will you say |
| 17:50 |
xyz |
hi i found this game which has one screenshot which looks a bit like your game |
| 17:50 |
rubenwardy |
I think you should, as long as they don't sue US by mistake. |
| 17:50 |
Jordach |
xyz, copyright infringement |
| 17:51 |
xyz |
inb4 celeron55 gets sued |
| 17:51 |
xyz |
well that'll sure be fun |
| 17:51 |
Jordach |
xyz, the engine part |
| 17:51 |
xyz |
hm? |
| 17:51 |
Jordach |
cannot* |
| 17:51 |
Jordach |
we know for a fact that this isn't legal via the LGPL |
| 17:51 |
xyz |
did you download it? |
| 17:51 |
Jordach |
xyz, no |
| 17:51 |
xyz |
then you should stop being so gigantic faggot |
| 17:51 |
Jordach |
why would i pay those tards who made BC |
| 17:52 |
xyz |
how can you know without even downloading it? |
| 17:52 |
sapier |
you don't have a proof so be very very carefull |
| 17:52 |
Jordach |
xyz, there's a image with the MC farming texturews |
| 17:52 |
xyz |
and this proves that it's based on Minetest how exactly? |
| 17:52 |
Jordach |
with G4JC's almost MC pack |
| 17:53 |
rubenwardy |
1) Check that they do infringe the copyright (buy and check). 2) If so, send email to Mojang, stating the problem, and making sure the Minetest community is not affected. |
| 17:53 |
xyz |
haha |
| 17:53 |
rubenwardy |
Or just file a complaint/ DMCA with Apple |
| 17:53 |
rubenwardy |
easier |
| 17:53 |
xyz |
you guys sure have nothing better to do |
| 17:53 |
xyz |
well then have fun, I guess? |
| 17:54 |
rubenwardy |
!title https://forum.minetest.net/viewtopic.php?pid=127211#p127211 |
| 17:54 |
ShadowBot |
rubenwardy: Forum message — Minetest Forums |
| 17:54 |
rubenwardy |
no, it's not |
| 17:54 |
rubenwardy |
no, it's not |
| 17:54 |
rubenwardy |
no, it's not |
| 17:54 |
rubenwardy |
!title https://forum.minetest.net/viewtopic.php?pid=127211#p127211 |
| 17:54 |
ShadowBot |
rubenwardy: Forum message — Minetest Forums |
| 17:54 |
rubenwardy |
^ ShadowNinja |
| 17:55 |
PilzAdam |
rubenwardy, this is not #minetest |
| 17:55 |
rubenwardy |
Yep. That was to xyz. |
| 17:55 |
rubenwardy |
And it is on topic, ish |
| 17:57 |
xyz |
what? |
| 17:57 |
xyz |
also I don't think you can just file DMCAs left and right |
| 17:59 |
rubenwardy |
or do a cease and desist notice. |
| 18:00 |
PilzAdam |
we should have a seperate channel for this, since its not really core dev related; maybe #minetest-ripoffs |
| 18:00 |
rubenwardy |
lol |
| 18:03 |
rubenwardy |
http://translate.minetest.ru/projects/minetest/core/ is down |
| 18:04 |
rubenwardy |
lol |
| 18:10 |
* sfan5 |
throws the GEMA at john_minetest |
| 18:20 |
sapier |
VanessaE I know what happens in your case |
| 18:21 |
sapier |
You've got >30 clients, this reduces max packets per step to 1000/30 -->34 packets. therefore if you receive just a single position update from each client per step no other unreliable data can be sent to this peer within this step |
| 18:23 |
sapier |
set it to 2000 to handle about 60 clients |
| 18:25 |
sapier |
hmm not exactly 2000 is only enough for ~45 |
| 18:26 |
sapier |
you need almost 4000 to handle 60 clients |
| 18:26 |
|
Calinou joined #minetest-dev |
| 18:26 |
sapier |
network load increases n² |
| 18:31 |
|
Jordach joined #minetest-dev |
| 18:57 |
|
NakedFury joined #minetest-dev |
| 19:04 |
|
smoke_fumus joined #minetest-dev |
| 19:46 |
|
EvergreenTree joined #minetest-dev |
| 19:47 |
|
EvergreenTree joined #minetest-dev |
| 20:06 |
daswort |
is there a DB where i can look which crafts are already in use by mods? |
| 20:12 |
sapier |
no |
| 20:12 |
|
anadon joined #minetest-dev |
| 20:12 |
anadon |
Hey, I've gotten deep into re-factoring the code, and am running into some trouble. How is src/activeobject.h generated? |
| 20:12 |
sapier |
I don't think we have any generated code |
| 20:13 |
sapier |
"deep into re-factoring" sounds like a lot of changes? |
| 20:13 |
anadon |
could you run find for that file on your repo then? It doesn't seem to be in mine. |
| 20:13 |
anadon |
The build system is touchy on my machine so I'm working on improving it. |
| 20:13 |
sapier |
src/activeobject.h |
| 20:13 |
anadon |
which is a whole lot of hurt. |
| 20:14 |
anadon |
mhm |
| 20:14 |
anadon |
weird |
| 20:14 |
anadon |
ok, must have made a rm mistake. |
| 20:14 |
sapier |
you are aware of refactoring huge parts of minetest doesn't improve chances for merge of a change? |
| 20:14 |
|
troller joined #minetest-dev |
| 20:14 |
|
proller joined #minetest-dev |
| 20:16 |
sapier |
It's even hard for core devs getting support for refacoring small parts ;-) |
| 20:18 |
|
Calinou joined #minetest-dev |
| 20:35 |
|
salamanderrake joined #minetest-dev |
| 20:42 |
xyz |
anadon: can your changes be seen somewhere? |
| 20:45 |
|
sapier1 joined #minetest-dev |
| 20:55 |
anadon |
xyz: they are too mangled for me to let on someone else. |
| 20:55 |
anadon |
I'll be back on tonight if you want to talk about it. |
| 20:55 |
anadon |
(classes) |
| 20:55 |
sapier1 |
what do you intend to do? |
| 21:03 |
|
anadon joined #minetest-dev |
| 21:11 |
xyz |
anadon: alright, although I'm even more curious now! |
| 21:11 |
xyz |
meanwhile, a patch https://github.com/freeminer/freeminer/commit/edd354b83be0fe72f7da85cdaca8e47301cf64dd |
| 21:11 |
|
OldCoder joined #minetest-dev |
| 21:12 |
ShadowNinja |
anadon: Could you provide more details? We wouldn't want you to waste your time if we can't accept it... |
| 21:13 |
sapier |
xyz is 5.0 the trigger time? |
| 21:13 |
xyz |
yes |
| 21:13 |
xyz |
it's slightly-bigger-than-default (2.0) |
| 21:14 |
xyz |
before if you connect to server too fast (in less than 2 seconds, singleplayer game) you won't receive any blocks for those 2 seconds |
| 21:14 |
sapier |
what do you think about adding a define this way we wouldn't have to change two locations. 5.0 <-> 2.0 is a factor of 2.5? slightly? :-) |
| 21:15 |
sapier |
I did a lot of changes in this area lets see if this still does what it does before |
| 21:15 |
sapier |
-does +did |
| 21:15 |
xyz |
yup, y'know float comparisons are inaccurate |
| 21:15 |
xyz |
well you can change it to 1337.0 |
| 21:16 |
sapier |
yes but not as inaccurate as 2.5 ;-) |
| 21:16 |
xyz |
sfan5: that's not how you fork Irrlicht |
| 21:16 |
xyz |
sfan5: what I propose is: |
| 21:16 |
sfan5 |
xyz: svn2git crashed |
| 21:16 |
xyz |
really? |
| 21:16 |
xyz |
well, anyway |
| 21:16 |
sfan5 |
yes |
| 21:16 |
sapier |
and we compare for >= (at least I hope so) |
| 21:16 |
xyz |
you clone it with svn2git to separate branch |
| 21:16 |
xyz |
then merge to master |
| 21:16 |
xyz |
and then keep separate branch in sync and merge it to master when needed |
| 21:17 |
xyz |
sapier: are you seriously going to argue on such simple small thing? |
| 21:17 |
sapier |
no no don't get me wrong I'm not arguing ;-) |
| 21:17 |
xyz |
sfan5: well if you're fine with what I suggest I can try it |
| 21:18 |
sfan5 |
yes, i'm fine with it |
| 21:18 |
xyz |
although I'm not sure if I want to contribute to that your repo :P |
| 21:18 |
|
Miner_48er joined #minetest-dev |
| 21:20 |
sapier |
why the hell does git patch think this change is in SetBlocksNotSent? |
| 21:21 |
xyz |
you could've changed it by hand D: |
| 21:22 |
sapier |
confusing patch ... not it's content put the patch surroundings ;-) |
| 21:23 |
xyz |
sfan5: well, I guess that'll take a bit of time |
| 21:23 |
sapier |
hmm maybe we should fix the issue mentioned here. there's no sane reason why this thread should be restarted |
| 21:23 |
* sfan5 |
has enough time |
| 21:24 |
xyz |
maybe |
| 21:25 |
hmmmm |
hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm xyz, that's not a very good idea |
| 21:25 |
hmmmm |
that might cause a race condition |
| 21:25 |
hmmmm |
that is, starting emerge threads immediately |
| 21:27 |
|
Gethiox4 joined #minetest-dev |
| 21:27 |
sapier |
we shouldn't rely on some sleep delays to avoid race conditions |
| 21:28 |
hmmmm |
wait, what..? doesn't that delay starting emerge threads? |
| 21:28 |
hmmmm |
and the delay seems to be 0 by default, not 5 |
| 21:28 |
hmmmm |
er not 2 |
| 21:29 |
hmmmm |
see a lot of freeminer changes seem to be tweaks to settings that modify the behavior of already established interfaces that aren't really solutions to problems |
| 21:29 |
sapier |
if I interpret code correct and haven't missed another starting location emerge thread is started 2 seconds after server thread in current version |
| 21:29 |
* hmmmm |
looks |
| 21:29 |
hmmmm |
lol i get home from a week of code to do more code |
| 21:29 |
sapier |
which is quite arbitrary ... why 2 not 5 or 10? |
| 21:30 |
hmmmm |
i don't know. a lot of this stuff is arbitrary to begin with. |
| 21:30 |
sapier |
but I guess it's a startup delay in worst case. If there's a race condition it should be handled by a sync point |
| 21:31 |
hmmmm |
ahhh i see what it does |
| 21:31 |
hmmmm |
5.0 is not how long it takes for the emergethread to trigger |
| 21:31 |
hmmmm |
it's the initialization of the counter that's greater than the interval |
| 21:31 |
hmmmm |
really all it needs to be is 2.0 |
| 21:32 |
hmmmm |
but this is a meaningless patch |
| 21:32 |
hmmmm |
the emergethreads are started immediately |
| 21:32 |
sapier |
yes but I'd prefere to use a synchornisation point if there's a race condition and start this thread only once |
| 21:32 |
hmmmm |
in fact that block of code in asyncrunstep is dead |
| 21:32 |
hmmmm |
as in it doesn't do anything |
| 21:33 |
hmmmm |
you modified it sometime ago it seems, but it was useless before then too |
| 21:33 |
hmmmm |
ever since I redid the emergethreads |
| 21:33 |
hmmmm |
it was a hacky "fix" to a bug that was gone for quite some time, and now people misconstrued it as the starting point for the emerge thread |
| 21:33 |
sapier |
:-) ok lets remove it ... removing bugs by removing code is best way to do it ... as you don't have to look for the bugs |
| 21:33 |
xyz |
they don't start immediately |
| 21:34 |
xyz |
since this patch fixes it |
| 21:34 |
sapier |
maybe we should start them immediatly? |
| 21:34 |
sapier |
could be a bug introduced by switch from simple to jthread |
| 21:34 |
hmmmm |
let's see |
| 21:35 |
sapier |
I guess I have interpreted this to be starting location too |
| 21:36 |
hmmmm |
emergemanager is created right after the serverthread is created, mapgens are initialized, environment is initialized |
| 21:36 |
* hmmmm |
blinks |
| 21:36 |
hmmmm |
initMapgens() doesn't start the associated emergethread? |
| 21:37 |
hmmmm |
wtf |
| 21:37 |
hmmmm |
in any case the environment needs to be initialized before the emergethreads are started |
| 21:39 |
sapier |
good to know. I intend to cleanup server stap by step as it seems to have more dead code in there |
| 21:39 |
hmmmm |
the serverthread isn't started in the Server ctor |
| 21:40 |
hmmmm |
oh the server initialization is pretty order-critical |
| 21:40 |
hmmmm |
we need to collaborate together on that one |
| 21:40 |
hmmmm |
also it's a huge mess |
| 21:40 |
hmmmm |
i'd like to do some cleanup of my own |
| 21:40 |
hmmmm |
except with environment initialization and how it binds together with the emergethread |
| 21:41 |
sapier |
yes I'm thankfull for any help in there as it will save me some days of trial and error |
| 21:42 |
sapier |
I've added proper client state handling in #1116 but it's still quite experimental if you have time to review the changes you're welcome |
| 21:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/1116 -- Add proper client initialization by sapier |
| 21:42 |
xyz |
oh i also wanted to propose another patch |
| 21:42 |
sapier |
just propose it ;-) |
| 21:44 |
sapier |
does anyone know how to give a name to a windows thread? |
| 21:45 |
hmmmm |
lol. http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx |
| 21:45 |
hmmmm |
undocumented yet documented |
| 21:46 |
hmmmm |
that is incredibly hacky looking |
| 21:46 |
sapier |
true |
| 21:46 |
hmmmm |
(is that what you meant by name? or did you mean like a named pipe or something) |
| 21:46 |
sapier |
but lots of win32 code looks hacky to me :) |
| 21:47 |
sapier |
no the thread itself like used in linux to show threadnames in top -H -p <pid> |
| 21:47 |
hmmmm |
oh.. this is for debugging purposes |
| 21:47 |
hmmmm |
I don't think you could have thread names in windows... |
| 21:47 |
sapier |
:-/ so we can add a empty dummy for windows only :-/ |
| 21:48 |
xyz |
https://github.com/freeminer/freeminer/commit/bdf9ae3739c0a42fa62851f72a256cb065215229#diff-ad60d65b34e16a3319296bb5d683acd6R983 https://github.com/freeminer/freeminer/commit/ca356c53f38640eae7f2d58f9f1c5f887a4acbf4 |
| 21:50 |
hmmmm |
hmm don't see the heap-use-after-free in the firsto ne |
| 21:51 |
hmmmm |
also I think that's a bad idea to delete the environment before clients are deleted |
| 21:52 |
xyz |
it's a bad idea why? |
| 21:52 |
sapier |
because player is read from env |
| 21:53 |
sapier |
if anyone calls a function triggering player usage in between it's gonna crash |
| 21:54 |
sapier |
I've reduced player usage but I didn't make sure it's never used ... and I don't know where all those functions are called from .... almost everyone has a copy of server class pointer |
| 21:54 |
sapier |
same for env pointers |
| 21:54 |
hmmmm |
that's because everybody needs one |
| 21:54 |
xyz |
ah now i'm not sure if my changes don't introduce another possible heap-use-after-free |
| 21:55 |
hmmmm |
what's the first heap-use-after-free...? |
| 21:55 |
xyz |
anyway, ~ServerEnvironment calls ~ServerMap which calls ServerMap::save which calls ServerMap::saveMapMeta which goes to EmergeManager::setParamsToSettings |
| 21:55 |
sapier |
shouldn't we cleanup this mess by adding adding proper encapsulation? not at once but step by step |
| 21:56 |
hmmmm |
ahhh. |
| 21:56 |
hmmmm |
that's pretty hidden |
| 21:56 |
sapier |
most time "player" is only used to fetch it's name from ... I had to move the name to RemoteClient for delaying player appearance maybe we can use this name at some locations where player is used by now |
| 21:57 |
xyz |
yea so hidden it happens every time so.. |
| 22:00 |
|
john_minetest left #minetest-dev |
| 22:00 |
xyz |
although map probably should be deleted after both environment and emergemanager |
| 22:01 |
|
salamanderrake joined #minetest-dev |
| 22:02 |
hmmmm |
hmm |
| 22:03 |
hmmmm |
I think a better way of fixing this would be to remove setParamsToSettings from saveMapMeta |
| 22:03 |
hmmmm |
or is it |
| 22:04 |
hmmmm |
too tired to think straight :( |
| 22:06 |
hmmmm |
honestly the mapgen params should be in Map |
| 22:06 |
hmmmm |
but they aren't because that's not what gets passed along to the emergethreads |
| 22:06 |
hmmmm |
but anyway yes, i agree, the emergemanager should be deleted a lot later than it is currently as lots of things depend on it |
| 22:07 |
hmmmm |
emergethreads should be stopped, clients deleted, then the environment gets deleted |
| 22:07 |
hmmmm |
and then after all that emergemanager gets deleted |
| 22:07 |
hmmmm |
the whole point of deleting the emeregmanager early in the shutdown process like that is to stop the threads anyway |
| 22:13 |
|
john_minetest joined #minetest-dev |
| 22:13 |
|
john_minetest left #minetest-dev |
| 22:27 |
sapier |
does anyone know why there are reliable as well as unreliable active object messages? |
| 23:03 |
|
anadon joined #minetest-dev |
| 23:13 |
|
EvergreenTree joined #minetest-dev |
| 23:13 |
|
EvergreenTree joined #minetest-dev |
| 23:31 |
ShadowNinja |
xyz: Can you add a favicon to the wikis? |
| 23:31 |
xyz |
later |
| 23:33 |
xyz |
and send me the favicon too |
| 23:36 |
ShadowNinja |
xyz: The Minetest logo, same as the forum. |
| 23:39 |
kahrl |
sapier: I guess unreliable is meant for movement and reliable is for long-term state changes? |
| 23:56 |
sapier |
hmm maybe can't see it from data beeing sent ... the message itself isn't dissected |
