Time |
Nick |
Message |
00:01 |
VargaD |
sapier: I like the MutexedQueue changes, but I would remove the exception in the long run |
00:02 |
sapier |
it may be necessary if someone doesn't actually know if there's something in that queue but can't wait for it |
00:03 |
VargaD |
I would take the object in reference and return false when it is empty and we can't wait |
00:03 |
VargaD |
it is just bad (and very slow) to use exception for control flow |
00:04 |
sapier |
that's why I wouldn't do it that way too |
00:04 |
sapier |
no idea why exceptions are used as normal control flow throughout minetest |
00:05 |
VargaD |
it can be used, sometimes, but not in performance critical code |
00:05 |
VargaD |
a multi threded general propose queue shouldn't use it that way |
00:05 |
sapier |
right now that one is only used in single consumer environments where you can check the queue before but that's not a variant I'd encourage to use |
00:07 |
VargaD |
I know, your change is OK for now, it does slove the performance problem |
00:17 |
proller |
saving 31336 players files took 108 seconds IN SERVER THREAD |
00:17 |
sapier |
wow :-) |
00:18 |
VargaD |
thats a lot of players |
00:18 |
|
ShadowBot joined #minetest-dev |
00:19 |
|
diemartin joined #minetest-dev |
00:19 |
VargaD |
how much players do you have at a time? |
00:20 |
proller |
online max? |
00:21 |
VargaD |
yes, what is the max your server could handle? |
00:21 |
PilzAdam |
proller, if you want to fix that then fix the operator == for inventory |
00:21 |
proller |
maybe 100+ |
00:22 |
proller |
xyz record - 81 |
00:22 |
proller |
but lot of lags from locking |
00:22 |
proller |
and connection.cpp becomes crazy |
00:24 |
proller |
minetest without mods can 20-30 |
00:34 |
proller |
my opinion: in current state - development must be problem-oriented to solve most annoying things first |
00:39 |
|
RealBadAngel joined #minetest-dev |
00:40 |
sapier |
could you be more precise about locking and connection.cpp? |
00:41 |
RealBadAngel |
does anybody know where's the code that displays players names ingame? i mean nicks over player models |
00:42 |
proller |
code must contain 0 of JMutexAutoLock |
00:43 |
proller |
locks can be only inside containers |
00:43 |
proller |
exceps some special places |
00:44 |
proller |
containers must be inherited from std::[map, vector, ....] |
00:44 |
proller |
maybe find good NIH |
00:45 |
sapier |
lol |
00:46 |
proller |
server step must be split into 5-10 threads for every action |
00:47 |
sapier |
you know none of the std types is threadsafe? |
00:47 |
VargaD |
isn't it bad practive to inherit std containers? |
00:47 |
|
us_0gb joined #minetest-dev |
00:47 |
VargaD |
there are a lot of linking issues on windows |
00:48 |
proller |
sapier, "inherited from" and have same interface, but be thread safe |
00:48 |
sapier |
and if you had a look for my udp fixes you'd have seen I moved all lock to their containers |
00:49 |
sapier |
yet it's a tradeoff if the more fine granular you do locking the more time you spend in os doing the locking |
00:51 |
sapier |
without resonable benchmark it's hard to find the sweet spot |
00:51 |
VargaD |
if you need to make atomic change in more than one data strcture it isn't useful to have to locks in the data structures |
00:51 |
proller |
also blocks must have per-block locking |
00:52 |
VargaD |
moving locks to containers should be that hard rule |
00:52 |
thexyz |
sapier: define threadsafe |
00:52 |
sapier |
I guess I suggested this months ago |
00:52 |
sapier |
threadsafe ... any function is callable at any time by different threads without messing up internal data |
00:55 |
VargaD |
s/should/shouldn't |
00:57 |
thexyz |
I still don't understand you but I'd like to point out that it's perfectly fine to read from std containers from multiple threads so long as no one is writing |
00:57 |
sapier |
yes but how do you want to be sure noone is writing in that very moment? |
00:58 |
thexyz |
that's what readers-writer locks exist for |
00:58 |
sapier |
ok and now a more specific explanation how to do that in c++? |
00:59 |
sapier |
as far as I know we have semaphores and mutexes commonly available |
00:59 |
thexyz |
how to use pthread in c++ or what? anyway, that's going too far away because we probably will be able to solve all our performance issues without them |
01:00 |
sapier |
I'd be glad to have a lightweight lock available but as far as I know we haven't correct me if I'm wrong |
01:00 |
thexyz |
and for windows you can just use mutex in place of that since no one runs servers on windows anyway |
01:00 |
VargaD |
thexyz: it is still lock just readers writers lock |
01:01 |
thexyz |
am I saying it isn't? |
01:01 |
sapier |
I use mutex for locking but they aren't quite what I'd call lightweight |
01:01 |
thexyz |
of course rwlock will have more overhead |
01:02 |
VargaD |
are you sure that currently in minetest the main problem is the locks? |
01:02 |
thexyz |
it depends on whether we read more than write |
01:02 |
thexyz |
from more threads |
01:02 |
thexyz |
VargaD: yes, and single threaded model |
01:02 |
thexyz |
I had a feeling that everything thinks it's under an envlock |
01:02 |
sapier |
thexyz you allways talk about your famous rwlock can you explain to me what you're talking about? |
01:03 |
thexyz |
what exactly do you want from me? |
01:03 |
thexyz |
I'm just saying that it should be considered |
01:03 |
sapier |
I want to know what you're talking about? |
01:03 |
thexyz |
sure thing http://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock |
01:04 |
VargaD |
minetest use a thin layer that hides platform differences and that doesn't have readers writes lock implementation |
01:04 |
VargaD |
so first we need to implement it, or use a library that already has |
01:04 |
sapier |
so you throw some random generic concept in and expect us to know what you want? |
01:04 |
VargaD |
that was the problem with the monitor |
01:05 |
thexyz |
no, I expect you to try to use your brain, to be honest |
01:05 |
thexyz |
and as I have already said this is definitely not the main problem |
01:05 |
thexyz |
just something to consider |
01:05 |
sapier |
I don't have your brain I don't know your ways of thinking ;-) |
01:05 |
thexyz |
I'm sure you have some brain |
01:05 |
VargaD |
calm down, we need to work together :) |
01:05 |
thexyz |
so you could use some way of thinking |
01:06 |
VargaD |
first we need to have a readers writers lock implementation |
01:06 |
thexyz |
fir we need to separate our threads |
01:07 |
VargaD |
and have a place where we can replace lock with readers writes lock |
01:07 |
sapier |
no I don't have some brain ... that's why I'm leaving that discussion right now ... just throwing in something you may have read somewhere without even looking if it isn't already done that way (at some places) is useless |
01:07 |
sapier |
that rwlock is nothing more/less than a special way of using mutexes |
01:07 |
thexyz |
yeah, sure, because you of course know better whether I just read about it somewhere |
01:07 |
thexyz |
anyway! |
01:08 |
sapier |
I hate it if ppl randomly throw in design patterns without REALY thinking about what they're good for |
01:08 |
VargaD |
of course rwlock can be implemented with mutex, actually it is implemented with mutex |
01:08 |
sapier |
it's just a design pattern not a special lock |
01:09 |
sapier |
most experienced programmers use it without even thinking about how it's called ;-) |
01:09 |
thexyz |
yeah, sure |
01:10 |
sapier |
and yes usually design patterns are usefull ... that's why someone did the work writing them down |
01:10 |
thexyz |
this could be useful in map since we read more often that write |
01:10 |
thexyz |
if you want some examples |
01:11 |
VargaD |
yes |
01:11 |
sapier |
I usually don't look for where I could add a pattern but look at a problem and find a solution for it |
01:11 |
thexyz |
that's how it happened for me that time |
01:11 |
thexyz |
but since you're the head of server/client/env now it seems I'll leave that for you to decide |
01:12 |
thexyz |
and network stuff too |
01:12 |
PilzAdam |
the subsystem thing isnt approved yet, I guess |
01:12 |
sapier |
I'll not stick to tcp/udp if someone has a good suggestion |
01:12 |
thexyz |
but if someone has a suggestion you'll just tell them it's worse than tcp/udp |
01:12 |
sapier |
and PilzAdam is right too |
01:12 |
thexyz |
but of course you're not stick to it |
01:12 |
sapier |
no I wont |
01:13 |
sapier |
in fact I plan to evaluate enet too |
01:13 |
sapier |
as second alternative to tcp |
01:13 |
VargaD |
thexyz: it just means the he will be responsible for that subsystem, he accepts possible your pull request |
01:14 |
VargaD |
a veteran blizzard devloper has writtem his thoughts about game network libraries it might be wort to read it: http://www.codeofhonor.com/blog/choosing-a-game-network-lib |
01:16 |
sapier |
interesting |
01:16 |
thexyz |
yeah well network library isn't the main problem compared to the nih syndrome at least |
01:17 |
thexyz |
I'm fine with that suggested subproject separation thing, at least it's going to be fun this way |
01:17 |
sapier |
guess you're not docmatic on insisting to use a external lib for anything ;-) |
01:18 |
thexyz |
when I talk about rwlock I usually mean it in the following way: "hey you probably don't know about this thing which it's possible to make a great use of in our code" |
01:19 |
sapier |
lets first decide who really will be responsible for this until then discussion is wast of time |
01:19 |
thexyz |
because as we've figured out, that's true and you didn't know about it |
01:19 |
RealBadAngel |
so, anybody know where i can find the code for showing players nicks above their models? |
01:19 |
sapier |
ok thexyz I may have missunderstood your intentions about rwlock |
01:20 |
sapier |
there are lots of crazy pieces of code in there trust me I've seen creepy things on fixing connection.cpp ... and looking at the diff there's not a single beeing left on same position |
01:20 |
sapier |
+line |
01:21 |
sapier |
e.g. passing return value by exception .... |
01:21 |
sapier |
I haven't removed all of it but it should be done |
01:22 |
PilzAdam |
RealBadAngel, content_cao.cpp:1015 |
01:23 |
VargaD |
Good night, it is getting quite late here... |
01:24 |
RealBadAngel |
PilzAdam, thx |
01:43 |
Sokomine |
i'm still unable to play with latest git on redcrabs server. thought that problem got solved? |
01:44 |
Sokomine |
(the map data is not shown - there's only grey fog) |
01:48 |
|
sapier left #minetest-dev |
02:10 |
|
Miner_48er joined #minetest-dev |
02:20 |
|
kvitkovski joined #minetest-dev |
02:54 |
|
Jordach joined #minetest-dev |
02:55 |
Jordach |
we've got a large problem: builddaft made it into the apple app store - https://forum.minetest.net/viewtopic.php?pid=123648#p123648 |
03:00 |
ShadowNinja |
Someone find their DCMA form. |
03:06 |
VanessaE |
RealBadAngel: oh PLEASE PLEASE fix that font :) |
03:09 |
RealBadAngel |
font? |
03:12 |
VanessaE |
[12-30 20:17] <RealBadAngel> so, anybody know where i can find the code for showing players nicks above their models? |
03:13 |
RealBadAngel |
ah that, i was lookin for that for another reason |
03:13 |
VanessaE |
oh ok |
03:14 |
RealBadAngel |
im tryin to display distance to waypoints on HUD |
03:17 |
RealBadAngel |
lookin for easy way to calculate screen position of visible waypoint |
03:17 |
RealBadAngel |
and cant find anything usable |
03:46 |
kahrl |
RealBadAngel: camera.getCameraNode()->getViewMatrix() and getProjectionMatrix()? |
03:58 |
|
bas080 joined #minetest-dev |
04:02 |
RealBadAngel |
Kahrl, in Lua |
04:03 |
RealBadAngel |
if those matrices could be exposed to Lua it would be easy |
04:07 |
RealBadAngel |
i need it for single point, if waypoint is in player view range, get screen coords to display there distance to that point |
04:18 |
kahrl |
RealBadAngel: the server doesn't even know the client's fov so good luck |
04:31 |
RealBadAngel |
i do have, position, camera look dir, distance to the point |
04:31 |
RealBadAngel |
it should be something like this: http://freespace.virgin.net/hugo.elias/routines/3d_to_2d.htm |
04:54 |
kahrl |
RealBadAngel: maybe you can adapt isBlockInSight and just use a fixed fov (like the block sending code does anyway) |
04:56 |
RealBadAngel |
kahrl, good idea |
04:58 |
RealBadAngel |
anyway HUD api is incosistent, when defining HUD element "position" field is used |
04:59 |
RealBadAngel |
but when changing element theres no such field, but "pos" |
04:59 |
RealBadAngel |
trying to change "postion" field, results in setting "number" field to 0 |
05:00 |
kahrl |
there was an issue about that |
05:00 |
kahrl |
pull request, in fact |
05:00 |
kahrl |
#1060 |
05:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/1060 |
05:01 |
RealBadAngel |
definitely thats it |
05:01 |
RealBadAngel |
it has to be merged |
05:02 |
kahrl |
iirc there was some controversy about compatibility |
05:02 |
RealBadAngel |
theres nothing like compability there, its just broken |
05:03 |
kahrl |
I'm not sure, I didn't follow that discussion |
05:03 |
RealBadAngel |
it took me an hour to find out why my code is not working |
05:03 |
RealBadAngel |
api doc uses "position" |
05:04 |
RealBadAngel |
setting the hud element uses "postion" |
05:04 |
RealBadAngel |
why changing should use "pos" ?? |
05:04 |
RealBadAngel |
its just a bug |
05:05 |
RealBadAngel |
not to mention that try to use "position" changes some other field instead of desired one |
05:06 |
VanessaE |
so this hasn't been merged yet......why? |
05:06 |
kahrl |
RealBadAngel: how does that happen? |
05:07 |
kahrl |
VanessaE: http://irc.minetest.ru/minetest-dev/2013-12-21#i_3507720 |
05:07 |
ShadowNinja |
I agree that that should be changed now. (But my working dir is full and I'm busy ATM) |
05:08 |
kahrl |
ok, so let's merge it |
05:08 |
kahrl |
RealBadAngel: do you want to do it? |
05:08 |
VanessaE |
and herein lies the root problem you were trying to figure out. Little shit like that ^^^ should simply have been merged, and if it breaks something, just fix those things?> |
05:08 |
VanessaE |
s/you /you guys, earlier, / |
05:11 |
kahrl |
why does hud_change default to HUD_STAT_NUMBER anyway? |
05:12 |
RealBadAngel |
kahrl, i cant atm |
05:12 |
kahrl |
RealBadAngel: I'll do it |
05:20 |
|
nore joined #minetest-dev |
05:36 |
|
OldCoder joined #minetest-dev |
06:00 |
|
OldCoder joined #minetest-dev |
06:36 |
|
smoke_fumus joined #minetest-dev |
06:39 |
|
OldCoder joined #minetest-dev |
07:11 |
|
darkrose joined #minetest-dev |
08:41 |
|
nore joined #minetest-dev |
08:55 |
|
mrtux joined #minetest-dev |
09:02 |
sfan5 |
celeron55: maintainers for each subsystem is ok with me, I'm only afraid this might slow down development generally |
09:05 |
|
Calinou joined #minetest-dev |
09:43 |
|
sapier joined #minetest-dev |
09:46 |
|
Evolykane joined #minetest-dev |
09:46 |
sapier |
sfan5 can you explain why you are afraid it could slow down development? |
09:48 |
sfan5 |
there need to be more people to get something merged |
09:48 |
sfan5 |
more -> a specific core dev vs. 2 core devs |
09:49 |
sapier |
true, but right now it's hard to find two core devs beeing interested enough to merge something ... with maintainers there is someone beeing responsible, no matter if that special pull interessts her/him or not |
09:50 |
sapier |
so in common case she/he does at least have to comment "no because of ..." or "fix this that and that ..." ... of course that'd be case in an ideal world only, there will be glitches in real world |
09:52 |
sapier |
but of course your fears might be true too |
10:03 |
|
proller joined #minetest-dev |
10:05 |
|
john_minetest joined #minetest-dev |
10:15 |
celeron55 |
i would gladly remove sapier from server/client/env and low-level network if there was anyone else to put there |
10:15 |
celeron55 |
but as long as there isn't, then sapier will handle it; i don't like sapier's way of arguing either |
10:16 |
celeron55 |
probably nobody likes |
10:18 |
sapier |
I'm always open for suggestion how to do it better celeron55 :-) |
10:20 |
celeron55 |
i fully agree that it's a shitty issue and i'm personally waiting for something that would really poke the balance towards the other |
10:22 |
sapier |
I don't even know what this could be, all solutions are quite close. some have benefits there others there and none of those issues is free of subjective preference |
10:24 |
sapier |
as far as I know the "completely new" option wasn't suggested by anyone |
10:26 |
sapier |
the worst thing about the old one isn't the protocol itself but it's implementation ... yet it's not gonna be perfect on fixed implementation |
10:26 |
proller |
enet is new |
10:26 |
sapier |
enet isn't new |
10:26 |
celeron55 |
in the end i put sapier on those subsystems because i do think sapier can choose it sanely; it's just that people won't like him doing that 8) |
10:27 |
sapier |
thanks ... so I'm the bad guy :-) |
10:27 |
sapier |
no problem ;-) |
10:27 |
celeron55 |
so who's on the democracy subsystem? we could ask him to arrange a community voting and see if the community prefers compatibility over cleanliness |
10:28 |
sapier |
my intention is to keep compatibility to old clients AND initiate transition to a new better protocol |
10:28 |
celeron55 |
personally i really don't know |
10:28 |
celeron55 |
and i doubt anyone knows here |
10:28 |
celeron55 |
we should be doing what the community wants in the end |
10:29 |
sapier |
if you get payed 10 times the money competitiors get payed just because you guarantee compatibility for 20 years you know it isn't overrated ;-) |
10:29 |
celeron55 |
sapier: it's a game |
10:29 |
sapier |
yes so why do you complain if we can have everything? ;-) |
10:30 |
sapier |
it's common agreement we need to switch to a new better protocol ... that's more then we agreed months ago ... so I see (slow) progress |
10:30 |
celeron55 |
the thing is, minetest wasn't originally designed for compatibility, making that very messy |
10:30 |
sapier |
another few months and we may agree to what protocol |
10:30 |
VargaD |
sapier's networking improvements might improve a lot, ha at least done a fair code cleanup in network code that can a base to further rafactoring |
10:30 |
celeron55 |
if it was, we'd have no issues whatsoever |
10:31 |
proller |
sapier, it's a game with 100 active users |
10:31 |
celeron55 |
VargaD: i like to think it as being away from some other useful work |
10:31 |
sapier |
yes but just jumping to something new without understanding will just drive us into same issues in some months |
10:31 |
celeron55 |
john_minetest: that's not an issue; the issue is maintainability |
10:32 |
celeron55 |
sapier: you've said that enough times already; it's time to figure out whether it's the case or not |
10:32 |
celeron55 |
saying it doesn't help at all and just pauses the discussion for a moment |
10:32 |
sapier |
true any idea how to proofe one ore another without waiting 4 years? |
10:32 |
proller |
sapier, do not touch everything while you not understanding |
10:33 |
sapier |
proller replacing something isn't "not touching" its moreover most extreme case of touching ;-) |
10:34 |
sapier |
is there any reason to believe compatibility will have reasonable influence to performance? |
10:34 |
celeron55 |
i already said it likely won't |
10:35 |
sapier |
maintainability is an issue true... but it's for limited time only as even I want to get rid of the old protocol |
10:35 |
sapier |
I only disagree with that hard transition |
10:35 |
celeron55 |
sapier: well okay; so what is your view on freeminer using an other protocol then? |
10:36 |
celeron55 |
it's irrelevant? i'm kind of okay if it is, but it has implications |
10:36 |
sapier |
I don't care about freeminer thexyz as well as proller said they don't have any intention to push back any patch ... I won't do work twice because those two fork in incompatible way |
10:37 |
VargaD |
changing to a protocol nowdays that does not support ivp6 is a mistake |
10:37 |
sapier |
I'd prefere to have a compatible protocol but if that means reimplementing any of their changes forgett it |
10:37 |
celeron55 |
there's at least one real-life example of a project forking incompatibly and the main project still merging everything; it's ffmpeg (the compatible original) and libav (the nasty fork) |
10:38 |
celeron55 |
i don't know how much work ffmpeg has to do because of that, and those surely are larger projects with commercial interests though |
10:38 |
sapier |
if there are usefull features and they are mergable I will do that of course, but if merging means doing same work again .... no |
10:38 |
celeron55 |
VargaD: thexyz's and prollers view on that is that it's trivial to modify enet to support ipv6 |
10:39 |
celeron55 |
they haven't done that though |
10:39 |
sapier |
I didn't understand this same way celeron55 |
10:41 |
celeron55 |
i guess sapier has a decision there then; i won't argue anymore |
10:42 |
sapier |
don't expect final decision to be done next few days ... as I guess thexyz won't provide a minetest compatible enet branch for verififcation I guess I need to do this myself |
10:43 |
sapier |
btw celeron55 you need to declare the subsystem maintainer thing to be active by some time |
10:44 |
VargaD |
but we also have other choices: POCO C++, Boost ASIO |
10:45 |
sapier |
as far as I know anything containing the word "boost" is out ... am I wrong about that? |
10:45 |
celeron55 |
VargaD: those aren't real choices due to various reasons; don't bother :P |
10:45 |
VargaD |
why? (I'm curious) |
10:46 |
sapier |
using boost without using it everywhere isn't usefull ... and boost does incompatible code changes all the time ... at least that's what I remember |
10:46 |
celeron55 |
many of us hate boost; it's made in the exact opposite way of minetest |
10:47 |
celeron55 |
boost is like another language; you either use it everywhere or not |
10:47 |
celeron55 |
POCO seems quite obscure and is a similar thing IIRC |
10:47 |
VargaD |
yes it seems similar |
10:47 |
celeron55 |
if either of those is used, then a decision should be made to migrate the whole codebase to use the chosen one |
10:48 |
celeron55 |
= yeah not how, forget it |
10:48 |
celeron55 |
now* |
10:48 |
celeron55 |
and as i understand they don't provide any actual protocol |
10:48 |
celeron55 |
they just wrap TCP and UDP |
10:48 |
celeron55 |
which sapier's code already does just fine |
10:49 |
sapier |
I'd not call it "fine" right now |
10:49 |
celeron55 |
i'm sure it wraps TCP fine |
10:49 |
celeron55 |
the other part you'd have to do with boost or poco too |
10:50 |
|
Calinou joined #minetest-dev |
10:50 |
sapier |
true |
10:55 |
celeron55 |
oh, and; before taking the subsystem thing into use, i want to hear what hmmmm has to say about it |
10:58 |
celeron55 |
he doeosn't do really any work anymore, but as long as he is assigned to mapgen, it matters (i wonder who else it could be) |
10:59 |
celeron55 |
well proller has worked on that stuff; i bet he doesn't want to, or people generally don't want that |
11:01 |
celeron55 |
i think kahrl would be qualified for anything, but dunno if he wants to |
11:02 |
celeron55 |
we've accumulated quite many of these people who know stuff but don't want to use their time |
11:02 |
celeron55 |
our best bet would be to re-motivate them somehow |
11:10 |
|
werwerwer joined #minetest-dev |
11:18 |
|
Jordach joined #minetest-dev |
11:27 |
|
jin_xi joined #minetest-dev |
11:31 |
|
iqualfragile joined #minetest-dev |
12:10 |
kahrl |
I could manage one of the smaller subsystems if needed |
12:11 |
kahrl |
the question would be which one |
12:11 |
kahrl |
maybe the "black irrlicht magic" subsystem? :P |
12:11 |
VanessaE |
hah |
12:13 |
sapier |
kahrl it'd be unfair to count that as volonteering for graphics subsystem isn't it? |
12:13 |
kahrl |
yes it would ;) |
12:19 |
celeron55 |
that isn't only about technical issues though; it also involves deciding what looks good and appropriate |
12:20 |
celeron55 |
but it trust kahrl to ask someone about that! |
12:21 |
celeron55 |
i'm changing myself to kahrl there; i want to spread these around as much as possible initially |
12:22 |
celeron55 |
it will result in two things: 1) nobody gets overloaded with work, and 2) it will show faster if there is a built-in problem in this |
12:23 |
|
Evolykane joined #minetest-dev |
12:23 |
celeron55 |
s/but it/but i/ |
12:25 |
kahrl |
celeron55: I meant "yes, it would be unfair" |
12:25 |
kahrl |
I'm kind of terrible at graphics... |
12:25 |
kahrl |
also the graphics subsystem will probably have the most controversial pull requests, not sure if I have the energy for that |
12:25 |
celeron55 |
then i'm switching you and me around |
12:26 |
celeron55 |
now you're on startup/config 8) |
12:27 |
kahrl |
sounds better :) |
12:30 |
kahrl |
which subsystem do utility fixes go to? (such as #1054) |
12:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/1054 |
12:32 |
celeron55 |
i think startup/config |
12:32 |
celeron55 |
it's kind of the "core of the core" |
12:32 |
kahrl |
I'd rename it to startup/config/util then |
12:33 |
celeron55 |
renamed |
12:38 |
celeron55 |
i propose a new subsystem: android port |
12:38 |
sapier |
hopefully those core parts don't need to be touched very often |
12:39 |
kahrl |
for the graphics subsystem, maybe we could ask some people currently outside the dev team (Taoki?) |
12:39 |
celeron55 |
because someone has to make an android port happen; we can't just let that proprietary project to take hold of all of android |
12:40 |
celeron55 |
kahrl: i think it's fine that i keep it for now |
12:41 |
kahrl |
android port would be sfan5... guess that's up to him |
12:44 |
sfan5 |
what about iOS? Buildcraft is out on iOS too |
12:44 |
celeron55 |
it too; but it's less important |
12:44 |
VanessaE |
celeron55: proposal: Android port happens at the same time as you do whatever it is that is gonna end up breaking compatibility with that illegal fork. |
12:45 |
sfan5 |
for iOS we would need $99 (dev account) and a proper mac device anyway |
12:45 |
celeron55 |
VanessaE: maybe |
12:45 |
VanessaE |
thexyz already made some inroads toward that end |
12:45 |
VanessaE |
(albeit with freeminer) |
12:47 |
VanessaE |
the way I figure it, play on the probability of people downloading a program, seeing that it doesn't work anymore, and going "this sucks!" and just uninstalling it. |
12:47 |
VanessaE |
not knowing it's minetest. meanwhile, the REAL minetest works fine, sits next to it in the play store, getting all the downloads. |
12:47 |
VanessaE |
at least until you know who forks it again. |
12:47 |
celeron55 |
that won't be started before we actually have an android port though |
12:47 |
VanessaE |
yeah |
12:49 |
celeron55 |
sfan5: donations will easily cover that once it's ready |
12:49 |
celeron55 |
i mean, the $99 |
12:49 |
celeron55 |
(a device is a problem though) |
12:50 |
celeron55 |
but ios isn't important compared to android |
12:50 |
kahrl |
is it legal to distribute LGPL code via itunes now? |
12:51 |
celeron55 |
as far as i know, apple doesn't care and users don't care |
12:51 |
celeron55 |
some zealots may care |
12:53 |
kahrl |
I just remember that VLC story |
13:00 |
thexyz |
yes, and the problem was is that some dev was against it |
13:00 |
thexyz |
err, s/is// |
13:00 |
thexyz |
both apple and other devs didn't care |
13:11 |
celeron55 |
i wonder if porting to sailfish would be easy |
13:11 |
|
ImQ009 joined #minetest-dev |
13:12 |
celeron55 |
all the other stuff is probably easily available, but i don't know if irrlicht can open up a window on it, as it uses wayland |
13:12 |
sfan5 |
sdl2 has recently gained support for wayland and irrlicht can use sdl |
13:12 |
celeron55 |
and the android port of irrlicht has probably many unnecessary changes |
13:13 |
celeron55 |
does regular irrlicht contain opengl ES support? |
13:13 |
sfan5 |
no |
13:14 |
celeron55 |
does the android port compile to regular gnu/linux? |
13:14 |
celeron55 |
(as sailfish is) |
13:14 |
celeron55 |
it'd need ES version of irrlicht that runs on gnu/linux... |
13:15 |
sfan5 |
I'm pretty sure it does |
13:15 |
celeron55 |
i actually happen to have the jolla phone (which sucks as a phone but is a fun toy); it runs buildcraft just fine |
13:16 |
sfan5 |
but it'd require changing some things because it currently uses #if(n)def __ANDROID__ |
13:17 |
|
ImQ009 joined #minetest-dev |
13:22 |
celeron55 |
where's the newest version of irrlicht's android port available? |
13:22 |
celeron55 |
is it https://gitorious.org/irrlichtandroid? |
13:24 |
proller |
https://svn.code.sf.net/p/irrlicht/code/branches/ogl-es |
13:27 |
sfan5 |
the one on gitorious is inofficial |
13:27 |
celeron55 |
that svn one looks more familiar |
13:28 |
sfan5 |
the makefile of the ogles one does not work |
13:28 |
sfan5 |
it expects you to either use Xcode (iOS) or use the NDK (Android) |
13:28 |
proller |
but it contain lot of WTF defines and very hard to compile under linux/arm |
13:28 |
sfan5 |
http://dev.minetest.net/Android << contains the makefile I used for building without NDK |
13:29 |
|
EvergreenTree joined #minetest-dev |
13:29 |
|
EvergreenTree joined #minetest-dev |
13:31 |
thexyz |
don't forget that you'll have to patch irrlicht http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=49410 |
13:32 |
thexyz |
and there's some work here https://github.com/xyzz/freeminer/tree/android |
13:32 |
thexyz |
and todo https://github.com/freeminer/freeminer/issues/10#issuecomment-30752049 |
14:00 |
|
PilzAdam joined #minetest-dev |
14:03 |
celeron55 |
hmm, does this support es2 at all |
14:03 |
celeron55 |
there's no es1 on this thing |
14:04 |
celeron55 |
oh yeah it does |
14:31 |
|
darkrose joined #minetest-dev |
14:31 |
|
darkrose joined #minetest-dev |
14:35 |
|
daswort joined #minetest-dev |
14:58 |
|
Zeitgeist_ joined #minetest-dev |
15:30 |
|
hmmmm joined #minetest-dev |
15:39 |
|
ImQ009 joined #minetest-dev |
15:54 |
|
OldCoder joined #minetest-dev |
16:07 |
|
smoke_fumus|2 joined #minetest-dev |
16:08 |
|
nyuszika7h joined #minetest-dev |
16:09 |
|
Calinou joined #minetest-dev |
16:24 |
|
salamanderrake joined #minetest-dev |
16:31 |
|
kaeza joined #minetest-dev |
16:32 |
|
RealBadAngel joined #minetest-dev |
16:35 |
|
OldCoder joined #minetest-dev |
16:42 |
sfan5 |
celeron55: do you know of a way to add linking flags at the end of the linker command without cmake touching them? |
16:47 |
celeron55 |
sfan5: how does it touch them? |
16:47 |
sfan5 |
it removed -Wl,-Bstatic |
16:48 |
celeron55 |
no way i guess; you need to configure it to not remove those |
16:48 |
celeron55 |
uh... maybe |
16:48 |
|
NakedFury joined #minetest-dev |
16:48 |
celeron55 |
what does that even do? |
16:49 |
sfan5 |
I need to link libcrystax statically |
16:49 |
sfan5 |
(because that is not a standard lib on android) |
16:50 |
celeron55 |
if you have a .a file of it (or similar static library file), just give that to the linker |
16:50 |
celeron55 |
it's how static linking is usually done |
16:50 |
celeron55 |
just like any object file |
16:51 |
celeron55 |
hmm |
16:51 |
celeron55 |
like TARGET_LINK_LIBRARIES(foo libcrystax.a) |
16:51 |
sfan5 |
I'm not sure but I think it didn't work when I used the .a |
16:51 |
sfan5 |
I'll try after cmake finishes building |
16:52 |
celeron55 |
if it doesn't work, you could try something like this http://www.cmake.org/pipermail/cmake/2009-February/026777.html |
16:52 |
sfan5 |
I have two ways to put linker flags at the front of the linker now |
16:52 |
celeron55 |
it'll make your build system totally unportable and hated by everyone though |
16:52 |
|
OldCoder joined #minetest-dev |
16:53 |
celeron55 |
i'm having fun time with building irrlicht for sailfish |
16:53 |
celeron55 |
i raped the build system completely and now it turns out the code is actually broken for X11+ES2 combination 8) |
16:55 |
celeron55 |
it builds code that wants to use _ZN3irr5video18createOGLES2DriverERKNS_27SIrrlichtCreationParametersERNS0_17SExposedVideoDataEPNS_2io11IFileSystemE, but the function it creates is _ZN3irr5video18createOGLES2DriverERKNS_27SIrrlichtCreationParametersEPNS_2io11IFileSystemEPNS0_15IContextManagerE |
16:56 |
|
OldCoder joined #minetest-dev |
16:56 |
sfan5 |
try ogles1, the ogles2 driver does not work (atleast on iOS) |
16:56 |
|
OldCoder joined #minetest-dev |
16:56 |
celeron55 |
sfan5: sailfish doesn't support ogles1 |
16:56 |
sfan5 |
:O |
16:56 |
sfan5 |
linking to the .a does not work |
16:56 |
|
kahrl joined #minetest-dev |
16:56 |
sfan5 |
but statically linking to the .so works *confused look* |
16:56 |
celeron55 |
or, hmm |
16:57 |
celeron55 |
maybe ogles2 is backwards compatible enough... i guess i'll have to see |
16:57 |
celeron55 |
sfan5: how does it not work |
16:58 |
sfan5 |
Error(dlopen): Cannot load library: soinfo_relocate(linker.cpp:976): cannot locate symbol "___runetype" referenced by "libminetest.so"... |
16:58 |
celeron55 |
(but this thing doesn't have ogles1 headers at all; i'll have to try replacing the references to those with references to es2 headers) |
16:58 |
sfan5 |
^ output of small program I wrote to load the library |
16:59 |
sfan5 |
I guess I'm out of luck |
16:59 |
sfan5 |
I tried all ways |
17:04 |
sfan5 |
I added double quotes and now the linker says '' dl: No such file or directory '' |
17:04 |
sfan5 |
wtf cmake |
17:05 |
celeron55 |
did you see my link? |
17:05 |
sfan5 |
yes |
17:05 |
sfan5 |
already tried that |
17:05 |
sfan5 |
ooh |
17:06 |
celeron55 |
have you tried something involving separate_arguments() |
17:06 |
sfan5 |
no |
17:07 |
sfan5 |
set(PLATFORM_LIBS -landroid -llog -Wl,-Bstatic -lcrystax -Wl,-Bdynamic ${CMAKE_DL_LIBS}) -> cmake touches my flags |
17:07 |
sfan5 |
set(PLATFORM_LIBS -landroid -llog "-Wl,-Bstatic -lcrystax -Wl,-Bdynamic" ${CMAKE_DL_LIBS}) -> cmake doesn't touch them |
17:08 |
sfan5 |
I don't understand why cmake does this, but it works.. |
17:08 |
celeron55 |
you might have to create a custom command like how i once implemented a precompiled header: https://gist.github.com/celeron55/d4e5dac516742442babe |
17:09 |
celeron55 |
you can grab all the parameters that go in regular linking but construct the final command yourself |
17:09 |
celeron55 |
but if that already works, then whatever |
17:11 |
celeron55 |
looks like sailfish doesn't have everything in es1 that irrlicht wants |
17:11 |
celeron55 |
for example glClientActiveTexture seems to be missing |
17:12 |
celeron55 |
umm... wait what |
17:12 |
sfan5 |
can't you compile libGLESv1 for sailfish? |
17:12 |
sfan5 |
WTF cmake |
17:12 |
celeron55 |
i guess i can just define that and hope that it's actually found in some library |
17:13 |
sfan5 |
if the double quotes include a normal lib at the front it puts it 2 times into the linker command |
17:13 |
celeron55 |
there's a header for doing exactly that; glext.h irrlicht itself |
17:13 |
celeron55 |
+in |
17:13 |
sfan5 |
if the double quotes don't include a normal lib at the front it puts it once into the linker command |
17:13 |
celeron55 |
(umm... but that's not a wise one to use now) |
17:18 |
celeron55 |
bah, no, this es1 isn't going to work |
17:28 |
|
Weedy_lappy joined #minetest-dev |
17:57 |
iqualfragile |
yo! how is release-stuff going? |
18:02 |
|
jin_xi joined #minetest-dev |
18:07 |
|
VargaD_ joined #minetest-dev |
18:11 |
|
smoke_fumus joined #minetest-dev |
18:23 |
ShadowNinja |
So a section maintainer can decide how much approval is needed (this simple fix can be merged, this controversial change will need agreement from a few other devs)? And should I add tags for the sections on GitHub? |
18:24 |
|
book` joined #minetest-dev |
18:45 |
|
Zeitgeist_ joined #minetest-dev |
18:45 |
|
Zeitgeist_ joined #minetest-dev |
18:57 |
celeron55 |
ShadowNinja: i'm waiting for comments from hmmmm |
18:57 |
ShadowNinja |
Alright. |
18:58 |
celeron55 |
we should probably decide some ways of working on github |
18:58 |
celeron55 |
eg. add a comment "subsection x" or "subsections x, y, z" to all pull requests and issues |
18:59 |
celeron55 |
or maybe with tags... dunno |
19:03 |
ShadowNinja |
Tags would be better, comments are really for discussion and, well, comments. |
19:17 |
|
khonkhortisan joined #minetest-dev |
19:44 |
hmmmm |
a "section maintainer"? |
19:44 |
hmmmm |
we need to clearly define sections first of all |
19:45 |
hmmmm |
if you'd like to formalize that |
19:45 |
hmmmm |
but it's starting to look a bit like the way the Linux kernel is maintained, no? :) |
19:45 |
hmmmm |
no, I want 0.4.9 to be out very soon(tm) |
19:46 |
hmmmm |
the christmas launch was a failure because I guess of me, and so is the new year's release |
19:46 |
hmmmm |
it doesn't need to be though |
19:46 |
hmmmm |
if the current master is in a stable state we can release |
19:46 |
hmmmm |
we need multiple people working on it in order to make a release though.. |
19:48 |
ShadowNinja |
We need the serverlist fixed first. /me makes a issue |
19:48 |
hmmmm |
also, thank you pilzadam for removing the FPS from the window name |
19:49 |
hmmmm |
you must assume that any UI operations are very slow... I'll be willing to bet the reason why that was problematic is because it added to a UI operation queue and waited on it |
19:50 |
hmmmm |
(that's on Windows, anyway) |
19:51 |
hmmmm |
for Xfce I bet it's implemented like... |
19:51 |
sapier |
did anyone already investigate the serverlist issue? |
19:51 |
hmmmm |
gtk_threads_enter(); gtk_window_set_title(blahblah); gtk_threads_exit(); |
19:52 |
sapier |
I've read multiple ppl writing about it but by now noone (including me) seemed to be really interested enough to investigate |
19:52 |
ShadowNinja |
sapier: No. |
19:52 |
sapier |
guess everyone thought someone else would do it ;-) |
19:52 |
ShadowNinja |
The fix worked for Vanessa, but not for me. |
19:52 |
sapier |
do you know what's wrong? any error in communication? curl/non-curl? |
20:01 |
hmmmm |
https://github.com/minetest/minetest/commit/25b1cca4150a9f78b05b98afee71a97fd052df71 |
20:04 |
sapier |
the serverlist problem shadowninja has |
20:05 |
sapier |
hmmmm that one isn't added yet? |
20:05 |
hmmmm |
well |
20:05 |
hmmmm |
I just added it now, it was sitting for a week |
20:05 |
sapier |
oops |
20:06 |
ShadowNinja |
I haven't run it with --info and my server's busy now... |
20:09 |
hmmmm |
so do you guys want to make a release tonight? |
20:10 |
sapier |
without shadow validating this one is fixed? |
20:10 |
hmmmm |
I'm sure that'll happen soon... |
20:10 |
hmmmm |
but I mean we should make sure people who do the debian repo updating and windows compiling etcetera are ready |
20:12 |
sapier |
tonight? it's less then 3 hours to 2014 here :-) I do have some fireworks to burn down :-))) |
20:12 |
hmmmm |
grggrg |
20:13 |
sapier |
the real smoky ones ;-) |
20:13 |
hmmmm |
alright, we'll do it 'whenever' then |
20:13 |
hmmmm |
it's new year's somewhere in the world on the hour |
20:13 |
sapier |
but as far as I know I've been not that much involved in release by now |
20:13 |
hmmmm |
I need to get more involved with minetest in general.... I've been fading away it's like |
20:14 |
hmmmm |
and there's so much that needs to get done |
20:16 |
|
us_0gb joined #minetest-dev |
20:35 |
celeron55 |
hmmmm: i have selected the "subsystems" based on what things can be relatively easily pointed to consist of certain files |
20:35 |
celeron55 |
some things are bound to overlap, but not much |
20:36 |
celeron55 |
but, you agree to the overall idea? |
20:36 |
celeron55 |
do you agree to be responsible for the mapgen? |
20:36 |
celeron55 |
what that means is that you have to ultimately decline or accept changes to it |
20:39 |
celeron55 |
(you were pre-selected because you know the mapgen best) |
20:39 |
hmmmm |
why does it have to be formalized? what's wrong with the way things are right now? |
20:40 |
celeron55 |
partially this is a solution to the "proller problem" where stuff gets infinitely ignored from the contributor's standpoint |
20:41 |
hmmmm |
to speak freely |
20:42 |
hmmmm |
a lot of proller's stuff was ignored on purpose because it was just too much of a headache |
20:42 |
celeron55 |
of course it was |
20:42 |
hmmmm |
really poor design and everything, you'd have to spend just as much time as you would coding it yourself to get it the right way |
20:42 |
celeron55 |
but when the next proller comes, this gives much more incentive to just turn him down before it becomes bad |
20:43 |
|
sapier1 joined #minetest-dev |
20:43 |
celeron55 |
also i think it's time to check if some other organizational structure would work better than the current one |
20:43 |
|
EvergreenTree joined #minetest-dev |
20:43 |
|
EvergreenTree joined #minetest-dev |
20:43 |
hmmmm |
if you move into this subsystem maintainer model then it'd be a different organizational structure |
20:44 |
celeron55 |
that's what i just said |
20:44 |
hmmmm |
no, you said it as if they were two separate things |
20:44 |
hmmmm |
one follows the other directly |
20:44 |
celeron55 |
there was a huge amount of talk about this in the past 24 hours; read the logs if interested |
20:44 |
hmmmm |
ehhhhh |
20:44 |
hmmmm |
log reading.... |
20:44 |
sapier1 |
*smile* the good old communication problem again |
20:45 |
celeron55 |
"ehh.... doing anything" |
20:45 |
hmmmm |
I'll work on it over the next couple hours I guess |
20:45 |
hmmmm |
well yeah |
20:45 |
celeron55 |
we'll put the stuff in a wiki in the upcoming days if nothing serious comes to block this |
20:45 |
celeron55 |
(it's obvioysly bad to just refer to some log) |
20:46 |
sapier1 |
I guess noone has an idea who is padding active object messages with 4 null bytes prior transmission? ;-) |
20:47 |
|
Calinou joined #minetest-dev |
20:47 |
sapier1 |
not all of course that'd be too easy just some of them |
21:10 |
sapier1 |
hmm seems that bug is in master too it just doesn't cause anything without an additional bug I made in tcp implementation |
21:10 |
sapier1 |
I found mine but no idea where the second one is |
21:58 |
specing |
Is it possible for the client to "detect" that a placed/digged block hasn't been "confirmed" by the server? |
21:59 |
specing |
I'm assuming that when someone places a block, the action gets sent to the server which then provides some form of feedback to the client, am I right? |
22:02 |
specing |
Would it be possible to visually tag these blocks so that you know not to rely on them being there |
22:02 |
specing |
It would help at bridge-building immensely |
23:09 |
VargaD_ |
Happy new year |
23:49 |
|
djdduty_ joined #minetest-dev |