| Time |
Nick |
Message |
| 00:19 |
|
acerspyro joined #minetest-dev |
| 00:24 |
|
Exio4 joined #minetest-dev |
| 00:31 |
|
sapier left #minetest-dev |
| 01:38 |
|
zat joined #minetest-dev |
| 02:12 |
|
shadowzone joined #minetest-dev |
| 02:32 |
hmmmm |
hey Zeno, aws wondering why you implemented gamma settings the way you did and not using IrrlichtDevice::setGammaRamp() |
| 02:33 |
|
MinerDad joined #minetest-dev |
| 02:46 |
|
OldCoder joined #minetest-dev |
| 02:55 |
|
prozacgod joined #minetest-dev |
| 03:13 |
|
gregorycu joined #minetest-dev |
| 03:58 |
|
DFeniks joined #minetest-dev |
| 05:16 |
|
Player_2 joined #minetest-dev |
| 05:30 |
|
Miner_48er joined #minetest-dev |
| 05:45 |
|
paramat joined #minetest-dev |
| 05:48 |
paramat |
#2103 is perhaps ready for merge |
| 05:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/2103 -- Lua-api.txt: Document that paramtype=light is essential for a light source to spread its light by paramat |
| 05:58 |
paramat |
hi hmmmm a simple plains biome (grasses, flowers) for mgv5/7 has just been added to MTgame, would you like me to remove builtin_biome? |
| 05:59 |
hmmmm |
sure |
| 06:01 |
hmmmm |
it would probably be a smarter idea to move builtin_biome to minimal |
| 06:02 |
paramat |
okay |
| 06:12 |
paramat |
currently mgv5 has mandatory caves carved in the base terrain loop, i think i should separate cave carving into it's own optional function and run that after biome surface material is added. currently biome surface material is placed in tunnels (oops) |
| 06:15 |
hmmmm |
ahh, yeah, you should respect MG_CAVES... |
| 06:22 |
|
apdapreturns joined #minetest-dev |
| 06:23 |
|
MinerDad joined #minetest-dev |
| 07:13 |
hmmmm |
heh hrmm |
| 07:13 |
hmmmm |
anybody ever see a segfault caused by a bogus value in a vptr table? |
| 07:14 |
hmmmm |
I tried compiling the irrlicht example #5 and that happens to me |
| 07:15 |
gregorycu |
Are you sure if was a bogus value in the vptr table, or was it a bad "this" pointer? |
| 07:15 |
hmmmm |
absolutely sure it was a bad vtable entry |
| 07:16 |
hmmmm |
3irr3gui13CGUIScrollBarD1Ev> 0x800d32d80 <_ZTv0_n48_N3irr3gui13CGUIScrollBarD |
| 07:16 |
hmmmm |
0Ev> |
| 07:16 |
hmmmm |
0x80102a3d0 <_ZTVN3irr3gui13CGUIScrollBarE+464>: 0xfffffffffffffe88 |
| 07:16 |
hmmmm |
0xfffffffffffffe88 |
| 07:16 |
hmmmm |
erm |
| 07:16 |
hmmmm |
that was meant to be more readable than that |
| 07:16 |
gregorycu |
No idea |
| 07:17 |
hmmmm |
crashes right here: http://sourceforge.net/p/irrlicht/code/HEAD/tree/trunk/examples/05.UserInterface/main.cpp#l252 |
| 07:18 |
hmmmm |
well it's not a fluke since it happened with g++48 too |
| 07:18 |
gregorycu |
No idea |
| 07:19 |
gregorycu |
Umm.... |
| 07:19 |
gregorycu |
Is this a shared object, or a lib? |
| 07:20 |
hmmmm |
hah |
| 07:20 |
hmmmm |
well let's put it this way, it's not a compiler bug |
| 07:21 |
gregorycu |
You'd get this type of shit, if you were using a shared lib (dynamic loaded) |
| 07:21 |
gregorycu |
Where the shared lib didn't match the headers you used |
| 07:22 |
hmmmm |
ahh |
| 07:22 |
hmmmm |
let's try removing the "-I/../../include" |
| 07:23 |
hmmmm |
and it works |
| 07:23 |
hmmmm |
you're awesome :) good job recognizing that |
| 07:23 |
gregorycu |
It's my job |
| 07:24 |
gregorycu |
Which I have to go back to tomorrow after 20 days off |
| 07:24 |
hmmmm |
:( |
| 07:24 |
hmmmm |
is it soul crushing? |
| 07:25 |
gregorycu |
What will be soul crushing is all the emails, and also trying to get back on track with what I was doing 20 days ago |
| 07:25 |
|
MinerDad joined #minetest-dev |
| 07:25 |
gregorycu |
My memory is shit |
| 07:26 |
hmmmm |
going to work 'tomorrow', eh? you sound australian |
| 07:26 |
hmmmm |
aha, hostname confirms |
| 07:26 |
gregorycu |
I certainly am |
| 07:27 |
gregorycu |
Zeno and I make sure the Australian quota is met in this project |
| 07:27 |
hmmmm |
you australians are always a day ahead of us americans |
| 07:27 |
hmmmm |
literally :p |
| 07:28 |
gregorycu |
If it makes you feel better, when the Armageddon comes, we'll be the first to go |
| 07:37 |
|
Hunterz joined #minetest-dev |
| 07:44 |
paramat |
okay hmmmm #2036 is tested and ready for review |
| 07:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/2036 -- Builtin: Remove builtin_biome.lua. Minimal: Add simple biome to default/mapgen.lua. Remove indev mapgen ores by paramat |
| 07:52 |
|
Calinou joined #minetest-dev |
| 07:53 |
paramat |
also #2103 if my documentation of paramtype="light" is correct |
| 07:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/2103 -- Lua-api.txt: Document that paramtype=light is essential for a light source to spread its light by paramat |
| 07:56 |
|
nore joined #minetest-dev |
| 08:11 |
paramat |
nore mgv5/v7 and the biome API are not stable yet, perhaps they will be at next stable release. however i'm about to start adding optional snow biomes to mgv6 if you and sfan5 still want them |
| 08:13 |
nore |
I do :) |
| 08:14 |
nore |
it would be good to have pines and snow by default in _game... |
| 08:15 |
nore |
btw, if you make snow biomes, I suggest you to make two different ones: one with few trees and one like a forest |
| 08:18 |
paramat |
yes i would like to have taiga and tundra: cold and wet, cold and dry |
| 08:19 |
paramat |
as a mirror image of jungle and desert |
| 08:21 |
paramat |
also, i am working on a full set of biomes for v5/v7 with new tree schematics, hopefully for next stable. what is in MTgame currently is just temporary |
| 08:22 |
nore |
oh, and how have you done with the trees? did you generate dozens of pinetrees and then saved them as as many schematics? |
| 08:29 |
paramat |
haven't started tree schematics yet. most will use the randomised node feature of schematics, but snowy pines may done differently |
| 08:29 |
paramat |
.. because the per-node randomisation cannot place a snow node on every leaf node |
| 08:30 |
Calinou |
+nore> btw, if you make snow biomes, I suggest you to make two different ones: one with few trees and one like a forest |
| 08:30 |
Calinou |
this is very important |
| 08:31 |
paramat |
taiga can be split into forest and clearings by the tree perlin noise, i could even use that noise to vary tree density? |
| 08:31 |
|
selat joined #minetest-dev |
| 08:32 |
Calinou |
yes, noise to vary tree density would be good |
| 08:32 |
Calinou |
although make it so that normal forests behave this way too |
| 08:32 |
paramat |
yes vary tree density by noise, i find that essential to look good |
| 08:32 |
Calinou |
(for consistency) |
| 08:32 |
paramat |
that might break old worlds a little though (not much) |
| 08:33 |
paramat |
actually the discontinuity won't be ugly.. |
| 08:33 |
paramat |
so yes i agree |
| 08:34 |
Calinou |
so that we have highly forested areas, scarcely forested ones, and not-at-all forested ones |
| 08:34 |
Calinou |
forests wouldn't be a separate biome anymore, which is good for simplicity |
| 08:35 |
Calinou |
we'd have just plains/desert/tundra |
| 08:35 |
Calinou |
and trees/cacti on them |
| 08:38 |
paramat |
tundra is apparently cold, dry and barren, no trees, perhaps a new 'permafrost' node. then also i plan to add icesheet only in the very coldest areas |
| 08:39 |
paramat |
or, tundra could be rocky, no dirt at all, just thin snow |
| 08:42 |
Calinou |
keep dirt |
| 08:43 |
Calinou |
we could have ice lakes sometimes |
| 08:46 |
paramat |
yes icesheet on water in extreme cold |
| 08:59 |
|
kilbith joined #minetest-dev |
| 09:04 |
|
paramat left #minetest-dev |
| 09:05 |
|
jluc joined #minetest-dev |
| 09:14 |
|
MinerDad joined #minetest-dev |
| 09:14 |
|
Krock joined #minetest-dev |
| 09:20 |
Krock |
why is that function there? https://github.com/minetest/minetest/blob/master/src/guiTable.cpp#L326 |
| 09:37 |
|
ImQ009 joined #minetest-dev |
| 09:47 |
|
kilbith joined #minetest-dev |
| 10:08 |
|
sapier joined #minetest-dev |
| 10:16 |
|
paramat joined #minetest-dev |
| 10:19 |
paramat |
nore, sfan5 https://github.com/minetest/minetest_game/pull/399 |
| 10:19 |
|
paramat left #minetest-dev |
| 10:26 |
|
cib0 joined #minetest-dev |
| 10:28 |
nore |
game#399 was the fastest-merged PR :) |
| 10:28 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/399 -- Return to original water sink speed for player by paramat |
| 10:28 |
sfan5 |
yeah |
| 10:33 |
Calinou |
the eleventh world war is over!! |
| 10:35 |
sapier |
main.cpp L1612 ... things like that should be hidden within the porting layer ... or the function name is wrong if this can be done anywhere else then on x too |
| 10:40 |
puhfa |
hey, you guys aware that memory is leaking something fierce especially when handling bunch of entities? |
| 10:40 |
puhfa |
managed to actually crash my system when both 4 gb ram and pagefile where filled with cobble after only 30 mins of running the client |
| 10:41 |
puhfa |
0.4.11-64 windows build from the website |
| 10:46 |
|
ImQ009 joined #minetest-dev |
| 10:56 |
sfan5 |
ShadowNinja: having blocker and high priority labels on an issue doesn't make sense, blockers are always high priority |
| 10:59 |
sapier |
sfan5 can you explain to me why fixing a feature not even beeing officially supported is not "low priority" ... and moreover why (you) removed the "low priority" flag in total but kept medium and high? |
| 11:00 |
sfan5 |
sapier: every issue that is not high or medium priority is automatically low priority |
| 11:00 |
sfan5 |
we don't need a label for that |
| 11:00 |
sapier |
because you believe we don't need it? |
| 11:00 |
sfan5 |
what do we need it for? |
| 11:01 |
sapier |
if you don't have it consequence is everything not beeing medium or high will be LOW |
| 11:01 |
sfan5 |
what should the default priority for issues be? |
| 11:02 |
nore |
medium priority? |
| 11:02 |
sapier |
imho low is a flag for things that are a bug but are at "glitch" level like "would be nice to fix but doesn't actually do any harm" |
| 11:02 |
sapier |
e.g. a invalid warning message for example |
| 11:03 |
sfan5 |
maybe we should remove the medium label and add the low label back |
| 11:03 |
sapier |
maybe at least I don't really have feeling what medium is supposed to be |
| 11:04 |
sapier |
we can't add a desctiption to labels on github can we? |
| 11:04 |
sfan5 |
no |
| 11:05 |
sapier |
guess it'd make things way more easy if we knew what a label was supposed to mark |
| 11:05 |
sapier |
I'd suggest keeping the medium label as it's at some issues right now but not using it any longer |
| 11:30 |
|
exio4 joined #minetest-dev |
| 11:49 |
gregorycu |
The default priority is null |
| 11:49 |
gregorycu |
Which means it hasn't been assigned a priority |
| 11:49 |
|
SudoAptGetPlay joined #minetest-dev |
| 11:49 |
gregorycu |
Surely you want to explicitly categorise things, and have some way of knowing which things have not been categorised |
| 11:50 |
SudoAptGetPlay |
Hi, how can I register someone pointing at an other player (to fire an hud element) |
| 12:11 |
|
MinetestForFun joined #minetest-dev |
| 12:12 |
puhfa |
3 Gb in less than 20 min :| |
| 12:12 |
puhfa |
so restart is needed twice in an hour |
| 12:12 |
puhfa |
is this a known issue? |
| 12:12 |
sapier |
puhfa: what version are you using? |
| 12:13 |
puhfa |
now tried the previous one, 0.4.10 stable |
| 12:13 |
puhfa |
cant really say if the latest stable is any better |
| 12:13 |
sapier |
so 0.4.10 uses that much memory? |
| 12:13 |
puhfa |
yes. but the thing is, i am deliberately spamming this entities |
| 12:14 |
puhfa |
using a pipeworks machine |
| 12:14 |
puhfa |
with entities* |
| 12:14 |
sapier |
well in this case stop spamming ;-) |
| 12:14 |
kahrl |
sounds like a case of "doctor, it hurts when I do this" :P |
| 12:14 |
puhfa |
the leak will still be there, stalking. what if it attacks me when im asleep? : |
| 12:15 |
sapier |
kahrl: true yet we could have issues with handling a entitiy overload scenario too |
| 12:15 |
puhfa |
and the machine is no lets-break-all-clients thing, just an ore processor |
| 12:16 |
sapier |
pipeworks merely abuses some of minetests mechanisms it's not a surprise it trigger issues never happening with regular usage |
| 12:16 |
puhfa |
id say using pipeworks counts as regular usage these days |
| 12:16 |
sapier |
I don't |
| 12:17 |
puhfa |
anyway, i am getting serialization errors once in a while here, might be related |
| 12:17 |
gregorycu |
Hmm... |
| 12:17 |
gregorycu |
What does pipeworks spam? |
| 12:17 |
sapier |
pipeworks main issue is it doesn't handle minetests activity range |
| 12:18 |
sapier |
activity range concept is by design incompatible to what pipeworks does |
| 12:18 |
gregorycu |
Maybe so |
| 12:18 |
gregorycu |
But what does it spam? |
| 12:18 |
puhfa |
oh, forgot to mention, i keep the map block always loaded when i use the tubes |
| 12:18 |
|
SudoAptGetPlay left #minetest-dev |
| 12:18 |
puhfa |
might help narrowing it down |
| 12:18 |
sapier |
which is even worse because that feature is flaged "use at your own risk" |
| 12:18 |
puhfa |
gregorycu: i am just using it a lot |
| 12:20 |
gregorycu |
So, there is no reason for the memory usage to increase |
| 12:20 |
puhfa |
so does this mean youre not interested in trying to fix it, even though its a memory leak? |
| 12:20 |
sapier |
well if you force load a block and add more and more entities memory increases that's quite natural |
| 12:20 |
gregorycu |
Is that what is happening here? |
| 12:21 |
puhfa |
um, the old objects should disappear but they still stay in memory |
| 12:21 |
nore |
pipeworks tries not to spam unloaded blocks with entities |
| 12:21 |
puhfa |
they arent freed properly |
| 12:21 |
gregorycu |
The definition of a memory leak does not included entities that deliberately hang around |
| 12:21 |
puhfa |
no they dont. they spawn, hang in there for a while and then supposedly disappear. except they wont |
| 12:21 |
sapier |
maybe, I guess at some point you're startung to build up client <-> server message queues too as the number of entities causes a lot of communication |
| 12:22 |
gregorycu |
Right, but let's not quickly assume it's a dodgy mod |
| 12:22 |
puhfa |
basically its just transporting items from one inventory to another via a short tube |
| 12:22 |
sapier |
this is a guess, but I'd not be surprised if you could cause a runnaway effect |
| 12:23 |
sapier |
btw if you overload entity system client server could get out of sync too |
| 12:23 |
puhfa |
that could be the cause, yes. someone probably should test running pipeworks machines with little traffic but for a long time |
| 12:23 |
sapier |
maybe client thinks a entity dropped on server is still present resulting in it hanging around on client inifinite |
| 12:24 |
puhfa |
tried some noclipping, no visible entities |
| 12:24 |
sapier |
puhfa: yes maybe, you just have to find someone willing to fix pipeworks bugs |
| 12:24 |
kahrl |
so there are a lot of places that could be the cause |
| 12:24 |
kahrl |
I think this means this needs to be investigated with massif (which I have to admit to have no clue how to use) |
| 12:25 |
gregorycu |
wtf is that? |
| 12:25 |
kahrl |
gregorycu: a part of valgrind |
| 12:25 |
sapier |
massif is a heap profiler |
| 12:25 |
gregorycu |
ahh ok |
| 12:26 |
sapier |
you can find where "not lost" memory is stored |
| 12:26 |
gregorycu |
I'll grab pipeworks, and have a play |
| 12:29 |
puhfa |
sapier: i am not saying pipeworks is perfect, i just think i found a memory leak while using it |
| 12:29 |
puhfa |
no matter how twisted the mod is, it causes the engine to misbehave |
| 12:30 |
sapier |
android sdk is crap ... if you wanna use version specific styles you have to increase target api to highest style you wanna support ... resulting in not having any check about your specified min api level still would work |
| 12:30 |
puhfa |
anyway, in summary: lots of entities spawned and destroyed, no chunks loaded or unloaded, lots of inventory movements |
| 12:30 |
sapier |
puhfa: a memory leak is lost memory ;-) I don't think we have lost memory here |
| 12:31 |
gregorycu |
What makes you think that |
| 12:31 |
puhfa |
uh, okay |
| 12:31 |
puhfa |
anyways, allocated memory is not freed |
| 12:31 |
gregorycu |
sapier doesn't speak for everyone |
| 12:31 |
puhfa |
this is what is happening |
| 12:31 |
puhfa |
whatever you want to call it |
| 12:31 |
sapier |
I did a lot of memory leak checking the last week I found and fixed a few, none related to entities at all |
| 12:31 |
kahrl |
well, let's see what massif is showing |
| 12:32 |
sapier |
I'm with kahrl I guess the memory is just stalled somewhere |
| 12:32 |
gregorycu |
Stalled? |
| 12:32 |
sapier |
yet It's still a hypothesis nothing proven |
| 12:32 |
gregorycu |
What is stalled memory? |
| 12:32 |
puhfa |
wouldnt that be a memory leak then? :) |
| 12:32 |
sapier |
nope |
| 12:33 |
kahrl |
gregorycu: meaning there's still a pointer to it (e.g. it's in a queue), but the server can't keep up with processing that queue |
| 12:33 |
sapier |
by definition a leak is unreachable memory |
| 12:33 |
gregorycu |
It doesn't have to be unreachable |
| 12:33 |
gregorycu |
It just has to be never used again |
| 12:33 |
sapier |
in order to be a leak it has to be unreachable |
| 12:33 |
puhfa |
well if the client doenst ever use that pointer, seems pretty unreachable to me |
| 12:33 |
sapier |
effect of stalled and unreachable is same of course yet it's a big difference |
| 12:33 |
puhfa |
okay |
| 12:34 |
gregorycu |
That's how some algos find memory leaks |
| 12:34 |
sapier |
it's easy to find unreachable memory but stalled memory may require certain circumstances to happen |
| 12:34 |
sapier |
e.g. massive entity overload by pipeworks ;-) |
| 12:35 |
gregorycu |
The engine should be robust to handle this usecase |
| 12:35 |
sapier |
well maybe the engine is if you don't enable hacks like forceloading blocks |
| 12:35 |
kahrl |
an easy test would be: let the pipeworks machine do its thing for a while, then stop it, and see if the memory usage goes down |
| 12:35 |
gregorycu |
If puhfa isn't going out of his way, and bad shit is happening... |
| 12:36 |
gregorycu |
Is there a pipeworks tutorial somewhere? |
| 12:36 |
sapier |
yes kahrl and disable forceloading if the machine is that small it's not required |
| 12:37 |
gregorycu |
What does forceloading do? |
| 12:37 |
gregorycu |
I thought it simulated a player standing somewhere |
| 12:37 |
sapier |
disable activity mechanism for a certain block keeping it active |
| 12:37 |
gregorycu |
Why should that have an impact on anything? |
| 12:37 |
sapier |
gregorycu: in theory yes but I don't know how it's been implemented |
| 12:38 |
gregorycu |
Indeed, ok, give me a few min |
| 12:38 |
sapier |
if there's a bug in this hack It could interfer with regular entity handling |
| 12:38 |
|
T4im1 joined #minetest-dev |
| 12:39 |
Krock |
interesting. FPS drop frm 40 to 20 when placing a node but drawtype stays at 3 |
| 12:39 |
Krock |
s/drawtype/drawtime |
| 12:40 |
|
T4im joined #minetest-dev |
| 12:40 |
sapier |
I don't believe fps drop if you place a single node |
| 12:40 |
Krock |
it actually happens |
| 12:41 |
sapier |
what os? |
| 12:41 |
Krock |
windows 5.1 |
| 12:41 |
Krock |
screenshots coming |
| 12:41 |
sapier |
btw drawtime does only contain the time to draw the scene all logics is done out of this timer |
| 12:41 |
|
crazyR joined #minetest-dev |
| 12:42 |
sapier |
fps == 1s / ((time to do logics) + drawtime) |
| 12:42 |
sapier |
-s |
| 12:42 |
|
jluc joined #minetest-dev |
| 12:43 |
sapier |
yet placing a single node should cause any noticeable change |
| 12:43 |
Krock |
http://imgur.com/TwRu0Vs,F05GWPr,GmRepng |
| 12:44 |
Krock |
1) normal 2) placed 1 node 3) places 2 nodes |
| 12:46 |
Krock |
interesting. it's gone now when the older chunks got unloaded by the client |
| 12:46 |
sapier |
did you wayt for fps to settle down prior taking the first screenshot? |
| 12:46 |
sapier |
grrr what the heck am I typing |
| 12:47 |
puhfa |
hmm, thats happened to me too |
| 12:47 |
puhfa |
mainly if i am placing the nodes very high |
| 12:47 |
puhfa |
i suspect it is just generating shadows |
| 12:47 |
sapier |
Krock what machine are you running this at? |
| 12:47 |
Krock |
Athlon 64 4000+ 2.4 GHz single core, 2 GB ram |
| 12:47 |
puhfa |
Krock: is the ground block below you loaded? because then ive seen this too |
| 12:47 |
sapier |
drawtime doesn't change so if there ain't a bug in drawtime calculation fps drop is caused by some server action |
| 12:48 |
Krock |
Radeon X300 graphics card |
| 12:48 |
sapier |
hmm windows 5.1 is windows xp am I right? |
| 12:48 |
Krock |
puhfa, now they're unloaded and problem is solved |
| 12:48 |
Krock |
sapier, yes |
| 12:49 |
sapier |
you're lucky on radeon x200 minetest won't even start ;-) |
| 12:49 |
Krock |
how come? |
| 12:49 |
sapier |
I don't know |
| 12:49 |
puhfa |
it happens to me if the blocks below me are loaded and theres plenty of distance (height) |
| 12:49 |
puhfa |
so shadows? |
| 12:49 |
sapier |
tried it once on my old laptop ... never took time to find out |
| 12:50 |
sapier |
krock's drop isn't related to graphics |
| 12:50 |
|
fz72 joined #minetest-dev |
| 12:50 |
puhfa |
no, i mean lighting calculations |
| 12:50 |
Krock |
it looks like something is calculated.. and that something uses much CPU |
| 12:50 |
Krock |
yeah. maybe lighting |
| 12:50 |
sapier |
looks like unloading blocks takes some cpu time, enough to cause a fps drop ... light calculations might be a reason yes |
| 12:51 |
|
MinerDad joined #minetest-dev |
| 12:52 |
|
Kodexky joined #minetest-dev |
| 12:52 |
Krock |
so if lightening would be calculated with the GPU, I would get drawtype spikes |
| 12:53 |
sapier |
in theory yes, but gpu can't calculate the node light |
| 12:53 |
sapier |
well maybe using gpgpu capabilities |
| 12:54 |
sapier |
but not as in 3d graphics lighting |
| 12:54 |
Kodexky |
Hi sapier. |
| 12:54 |
Kodexky |
Nice to meet you. |
| 12:54 |
sapier |
thanks Kodexky |
| 12:55 |
kahrl |
well I definitely see some optimization opportunities in Map::propagateSunlight |
| 12:55 |
sapier |
do you wanna do gpgpu coding kahrl? ;-) |
| 12:55 |
Kodexky |
please forgive, but on 25235a4 shouldn't BS be 1 for that to work? |
| 12:55 |
kahrl |
huh why |
| 12:56 |
kahrl |
I mean the getBlockNoCreate call is only needed at the start and when y is crossing a mapblock boundary |
| 12:56 |
kahrl |
and should be changed to getBlockNoCreateNoEx as well |
| 12:56 |
sapier |
oops |
| 12:56 |
sapier |
you're right Kodexky |
| 12:57 |
Kodexky |
ok, i thought i was more too sleepy |
| 12:57 |
Kodexky |
-more |
| 12:58 |
sapier |
fixed |
| 12:58 |
Kodexky |
cool :) now to fix the sleepy part... |
| 12:59 |
celeron55 |
Kodexky: umm hello, i guess you came here due to my message |
| 13:00 |
Kodexky |
hi celeron55, yes in part. |
| 13:03 |
Kodexky |
sorry just remembered the forum and went checking, im very slow right now. |
| 13:04 |
celeron55 |
it looks like we have many poeple who are working on some android specific parts of minetest, i wonder of people feel okay with the current amount of coordination or whether there should be clearer goals |
| 13:04 |
Kodexky |
being honest i'm not too comfortable on irc, im just trying to like it |
| 13:05 |
celeron55 |
this channel is often a complete chaos, i totally get it if someone doesn't like it |
| 13:06 |
celeron55 |
Kodexky: what do you prefer the most over IRC? there is a bit of ongoing discussion over this too |
| 13:08 |
sapier |
who else is working on android celeron55? |
| 13:08 |
Kodexky |
im quite fine using mail, people breaths and thinks a little more before submiting. |
| 13:08 |
Kodexky |
the delay is the problem of course. |
| 13:09 |
sapier |
I'd be more concerned about the amount of mails Kodexky |
| 13:09 |
celeron55 |
sapier: Kodexky has done some pull requests, and one other guy on the forum that i never heard of before seems to have a lot of work put to it |
| 13:09 |
sapier |
guess I should have a look at forum? |
| 13:10 |
celeron55 |
this reply: https://forum.minetest.net/viewtopic.php?p=167371#p167371 |
| 13:11 |
celeron55 |
how do we combine these efforts to give the best result to users |
| 13:11 |
sfan5 |
that guy released minetest on ouya |
| 13:12 |
celeron55 |
well Kodexky's pull requests are perfectly fine - what i'm concerned in that case is for example duplicate work |
| 13:13 |
sapier |
well I spent about 6 hours of work for trash yesterday because of ppl not beeing able to actually test prior complaining do you really assume duplicated work is an issue? |
| 13:13 |
celeron55 |
well true, it generally isn't |
| 13:14 |
sapier |
where's that pull request? |
| 13:14 |
sfan5 |
sapier: if you're talking about the font stuff, it looks like it wasn't really clear what the problem was and what needs to be changed |
| 13:14 |
Kodexky |
lets make a list of current and choose from there |
| 13:14 |
celeron55 |
i'm not referring to any existing problem; also all those PRs have been merged |
| 13:14 |
sapier |
the menu mockup is interesting but I'm not sure if it'd work on a smartphone with this orientation |
| 13:15 |
celeron55 |
do we just tell to ezraanderson that his patches are welcome and he should submit PRs of them? |
| 13:15 |
celeron55 |
or should we make a list of goals for the android port |
| 13:15 |
celeron55 |
and then say PRs for those will be accepted |
| 13:15 |
sapier |
some goals would at least help to make us move towards same direction |
| 13:16 |
sapier |
we've got a pr for most of them already |
| 13:17 |
Kodexky |
both, id really like to take a look at what ezraanderson has done, and a roadmap stating requirements as a priority. |
| 13:17 |
celeron55 |
a wiki page to describe goals and constraints for android development maybe |
| 13:18 |
celeron55 |
(constraints like what techniques are acceptable for implementing better menus) |
| 13:18 |
sapier |
Kodexky: if you're talking about that post the only major things not yet merged is the hw image scaling and the help system |
| 13:18 |
gregorycu |
puhfa: You there? |
| 13:19 |
Kodexky |
just curiosity. :) |
| 13:19 |
sapier |
for hw scaling I suggest doing this little bit more precise just render at 320x480 for everyone seems crude to me :-) there are plenty of devices capable of running mt on native resolution |
| 13:20 |
Kodexky |
dont make it mandatory. |
| 13:20 |
puhfa |
gregorycu: yeah |
| 13:20 |
puhfa |
sup? |
| 13:20 |
Kodexky |
and low requirements option. |
| 13:20 |
gregorycu |
puhfa: How do I make this continually output items? |
| 13:21 |
Kodexky |
many games have that |
| 13:21 |
gregorycu |
I have two chests linked by two pipes |
| 13:21 |
puhfa |
um, you could use blinky plants from mesecons |
| 13:21 |
sapier |
Kodexky: that's what I meant with "more precise" |
| 13:21 |
gregorycu |
with two filter-injector |
| 13:21 |
gregorycu |
blinky plants... ok |
| 13:21 |
Kodexky |
ok |
| 13:22 |
puhfa |
i was using technic machines that auto-inject their contents |
| 13:22 |
sapier |
yet his patch doesn't contain any support do en/disable this so we'd have to add that interface prior merge |
| 13:22 |
|
Amaz joined #minetest-dev |
| 13:22 |
gregorycu |
I was searching for "clock" and "pulsar", I should have searched for "blinky plant" |
| 13:22 |
sapier |
guess that's a minor issue |
| 13:22 |
celeron55 |
sapier, Kodexky: would you contribute to an android roadmap wiki page if there was one? |
| 13:22 |
puhfa |
gregorycu: logical, aint it? :) |
| 13:22 |
sapier |
celeron55 every now and then yes ... but I don't like wiki very well I always forget about my password there |
| 13:23 |
celeron55 |
can you think of something better |
| 13:23 |
celeron55 |
IRC certainly isn't good for keeping track of goals and progress |
| 13:23 |
celeron55 |
just milestoned issues on github? |
| 13:23 |
sapier |
nope ... it's not a wiki problem but a "i need 5 different passwords for minetest alone" issue ;-) |
| 13:24 |
sapier |
actuall it's 6 |
| 13:24 |
sapier |
wiki forum github irc android keystore android cert |
| 13:24 |
puhfa |
gregorycu: btw, i had like 32 machines injecting stuff every abm, so thats the scale we are talking about. might not happen with a single chest+blinky config |
| 13:24 |
sapier |
hmm what's number 6 ... |
| 13:25 |
gregorycu |
sweet jesus... |
| 13:25 |
sapier |
lol |
| 13:25 |
puhfa |
what. i told you guys i was spamming the cobble out of it |
| 13:25 |
gregorycu |
Why is it a fucking plant |
| 13:25 |
sapier |
causing overload intentionally and complain about memory usage later ;-) |
| 13:25 |
puhfa |
32 actually makes sense. what with the 32 inventory slots and the like |
| 13:25 |
sapier |
puhfa: sounds more like a benchmark then regular usage |
| 13:26 |
Kodexky |
im for the milestones on github |
| 13:26 |
puhfa |
i like to push my limits... |
| 13:26 |
gregorycu |
32 is nothing |
| 13:26 |
puhfa |
anyway, still, even when theres an overload, it should free the entities |
| 13:26 |
sapier |
well guy guess you found out you're over it |
| 13:26 |
puhfa |
or perhaps have some kind of timeout that auto-destroys them |
| 13:26 |
celeron55 |
sapier: are you fine with milestone issues on github? |
| 13:26 |
sapier |
yes would be a good solution too |
| 13:27 |
sapier |
I have to do some real life work now I'll be back in about 2-3h |
| 13:27 |
|
sapier left #minetest-dev |
| 13:27 |
celeron55 |
okay, that can be the way to write down goals for android then |
| 13:29 |
|
younishd joined #minetest-dev |
| 13:29 |
celeron55 |
anyway, there doesn't seem to be any real issues so i'm not going to mess with this more |
| 13:30 |
celeron55 |
if everyone is too lazy write down any goals, there are plenty of small issues to be solved in any case |
| 13:32 |
Kodexky |
let me think it again, after talking to my pillow... i just burned myself with a cigarette :s |
| 13:32 |
Kodexky |
not quite functional right now. |
| 13:33 |
celeron55 |
s/too lazy write down/too lazy to write down/ |
| 13:35 |
Kodexky |
well, it's been a pleasure. guess we can go with the details later. |
| 13:36 |
Kodexky |
now i need to rest. |
| 13:36 |
Kodexky |
see ya |
| 13:37 |
celeron55 |
good night, or something 8) |
| 13:47 |
gregorycu |
puhfa: My initial thoughts are that there is a leak here |
| 13:48 |
gregorycu |
The only other think worth mentioning is that I have a CPU kinda pegged at 100% |
| 13:48 |
gregorycu |
Or near abouts |
| 13:50 |
puhfa |
high cpu usage kinda makes sense, lots of entities to handle and i am not worried about that |
| 13:51 |
puhfa |
anyway, when the entities disappear from view, they should leave the ram as well |
| 13:51 |
gregorycu |
Well, if the CPU usage means that there is something queueing somewhere... |
| 13:51 |
gregorycu |
The entities are particles if I am not mistaken |
| 13:51 |
puhfa |
did you get any serialization errors due to having too many entities around? |
| 13:52 |
gregorycu |
No, but I only have about 10 pumps going |
| 13:52 |
puhfa |
i think i actually had ~64 nodes injecting stuff constantly |
| 13:52 |
puhfa |
but those entities were supposed to be short-lived |
| 13:53 |
puhfa |
i have seen this happen before and so have others |
| 13:53 |
puhfa |
i brought it up because this was the first time my system actually crashed because of it |
| 13:53 |
T4im |
it always seemed to me, that the cpu only spikes around the time it tries to swap around gigabytes of that entityleaking… i.e. more as a side effect… |
| 13:53 |
T4im |
but I might be wrong |
| 13:54 |
T4im |
it is a very common occurrence, yes |
| 13:54 |
puhfa |
well, when using certain mods at least |
| 13:54 |
T4im |
and not just on technic runnign servers, its just most noticeable there |
| 13:55 |
T4im |
actually pipeworks running server we should say |
| 13:58 |
|
FR^2 joined #minetest-dev |
| 13:58 |
gregorycu |
hmmm... |
| 13:58 |
gregorycu |
Could be particles |
| 13:59 |
gregorycu |
I'll do tests tomorrow |
| 13:59 |
puhfa |
i dunno. lua-side they can have all sorts of properties stamped onto them |
| 13:59 |
puhfa |
oh |
| 13:59 |
puhfa |
nevermind |
| 13:59 |
kilbith |
sfan5: what's that font name ? http://i.imgur.com/7EcOO.png |
| 13:59 |
sfan5 |
no idea |
| 14:00 |
sfan5 |
jordach made that screenshot |
| 14:00 |
|
nore joined #minetest-dev |
| 14:06 |
|
roniz joined #minetest-dev |
| 14:07 |
fz72 |
I found a memory bug: when I leave a world the memory doesn't get free |
| 14:55 |
|
fz72 joined #minetest-dev |
| 15:04 |
|
casimir joined #minetest-dev |
| 15:05 |
casimir |
It seems with the new sorting the server list is easy to manipulate. |
| 15:07 |
sfan5 |
casimir: the old sorting was as easy to manipulate too |
| 15:07 |
|
proller joined #minetest-dev |
| 15:08 |
casimir |
Yes. But now I made it up to the third place on the list, without effort. |
| 15:10 |
sfan5 |
what do you mean |
| 15:12 |
|
selat joined #minetest-dev |
| 15:13 |
casimir |
Before my server was very unknown, with only one or two players at max. Now it almost hits max clients for no other reason than the sorting. |
| 15:14 |
casimir |
1. It seems my server is in the same data center (or near by) as the masterserver. ping = 1 |
| 15:15 |
casimir |
2. Second guests are disallowed, so only full players get counted, and they give more points. |
| 15:15 |
casimir |
3. I increased the server time just to test if it is possible to manipulate the list. ;) |
| 15:17 |
casimir |
Then choose your max clients to be 127 and let it run for at least an hour. |
| 15:18 |
sfan5 |
regarding 1) servers.minetest.net is in amsterdam at waveride/edis, your server is in amsterdam at digitalocean |
| 15:18 |
sfan5 |
2 is expected behaviour |
| 15:18 |
casimir |
3 Should be changed. |
| 15:19 |
sfan5 |
why? |
| 15:19 |
casimir |
It just profits those who know about it. In the long run every one will increase the game_time to be above 8 months. |
| 15:21 |
|
Wayward_One joined #minetest-dev |
| 15:21 |
sfan5 |
the plan was to allow older servers (more stable) to be at the top |
| 15:22 |
sfan5 |
the plan wasn't that server owners increase the age of their world by editing some files |
| 15:23 |
casimir |
Yes. That's the problem. |
| 15:23 |
casimir |
(btw. I will turn mine back to the normal time) |
| 15:23 |
sfan5 |
how do you suggest to solve this |
| 15:24 |
casimir |
Just don't count the time. |
| 15:27 |
sfan5 |
casimir: 64 bytes from 178.62.146.72: icmp_seq=1 ttl=60 time=0.954 ms the ping isn't even 1ms |
| 15:28 |
sfan5 |
casimir: take a look at http://servers.minetest.net it doesn't count the time anymore |
| 15:28 |
Wayward_One |
would it be possible to measure how long a server has been around externally? like say, how long it's been on the server list? |
| 15:30 |
Wayward_One |
externally meaning not affected by someone editing the age of their world |
| 15:30 |
sfan5 |
yes |
| 15:30 |
sfan5 |
but that would require extra code |
| 15:31 |
Wayward_One |
hmm |
| 15:35 |
|
kaeza joined #minetest-dev |
| 15:40 |
|
sapier joined #minetest-dev |
| 15:49 |
VanessaE |
hmmmm: two more reports of corrupted blocks for you, |
| 15:49 |
VanessaE |
[01-11 10:38] <Gael-de-Sailly> http://i.imgur.com/vJsYIRx.png |
| 15:49 |
VanessaE |
[01-11 10:49] <lordawe> I DO see cubes: http://i.cubeupload.com/tmTtli.png |
| 15:50 |
casimir |
Thank you sfan5, it now went down to 9th place. Amazing to see how a relative small change leads to ab bigger change in a chaotic system. (The chaos part here are the players.) |
| 15:50 |
sfan5 |
well |
| 15:50 |
sfan5 |
it depends when you looked at the serverlist |
| 15:51 |
sfan5 |
i tweaked it a bit |
| 15:51 |
casimir |
what else have you done? |
| 15:51 |
sfan5 |
casimir: http://sprunge.us/UfXg?diff |
| 15:53 |
sfan5 |
hm |
| 15:56 |
sfan5 |
made another change |
| 15:57 |
sfan5 |
shouldn't be so bad for servers with lower average_players now |
| 15:58 |
sfan5 |
hm |
| 15:58 |
sfan5 |
still not ideal |
| 15:59 |
sapier |
sfan5 "It's broken" ;-P |
| 15:59 |
sfan5 |
? |
| 16:01 |
|
crazyR joined #minetest-dev |
| 16:01 |
casimir |
Keep it simple |
| 16:03 |
sfan5 |
yup |
| 16:03 |
sfan5 |
i think this is good |
| 16:07 |
kahrl |
so those windmill clusters |
| 16:07 |
kahrl |
are they caused by 8621e6de5d? |
| 16:09 |
|
cib0 joined #minetest-dev |
| 16:09 |
kahrl |
I don't see where new_data is initialized in addArea() |
| 16:10 |
kahrl |
the loops just copy the old data but where is the rest of new_data initialized |
| 16:10 |
sapier |
isn't the whole area initialize by memset? at least do I rememer it beeing that way |
| 16:11 |
kahrl |
there is no memset on new_data |
| 16:11 |
sapier |
strange |
| 16:11 |
kahrl |
there is one for new_flags but that doesn't matter |
| 16:12 |
kahrl |
perhaps PilzAdam was right ;) http://irc.minetest.ru/minetest-dev/2014-12-24#i_4077862 |
| 16:13 |
sapier |
well the area copy/add code is tricky I learned this the hard way too |
| 16:14 |
sapier |
what's the voxel.cpp change?????? |
| 16:14 |
sapier |
who did agree to this? |
| 16:15 |
sapier |
if compiler does align to 4/8 for arrays this might fail completely |
| 16:15 |
kahrl |
I don't remember who did |
| 16:16 |
sapier |
I've to check this once again it's so crude I'm not sure it may work by accident |
| 16:16 |
sapier |
at least on some compilers |
| 16:19 |
sapier |
no what that's just wrong |
| 16:19 |
sapier |
a MapNode constuctor ain't called if no MapNode element is created |
| 16:21 |
kahrl |
well the idea was to avoid calling the MapNode constructor |
| 16:21 |
kahrl |
because calling it is slower than not calling it |
| 16:21 |
kahrl |
but not calling it is undefined behaviour, so... |
| 16:21 |
sapier |
well if this is supposed to create a list of pointers to MapNodes constuctor won't be called anyway |
| 16:21 |
sapier |
if it's supposed to create an array of MapNodes the new code doesn't allocate enough memory |
| 16:22 |
sapier |
because sizeof(pointer) != sizeof(MapNode) |
| 16:22 |
kahrl |
sizeof(*new_data) == sizeof(MapNode) |
| 16:23 |
sapier |
wait dereferenciate a pointer for sizeof? does this work? |
| 16:23 |
kahrl |
yes |
| 16:23 |
sapier |
stange way of writing code |
| 16:24 |
kahrl |
it's less prone to being missed in case someone changes the type that is pointed to |
| 16:24 |
sapier |
well if this conforms standard it'd be correct |
| 16:24 |
sapier |
maybe but way more hard to read |
| 16:24 |
kahrl |
I don't find it hard to read |
| 16:25 |
sapier |
what about a memset(new_data,0, new_size * sizeof(*new_data)) |
| 16:25 |
kahrl |
it's an idiom in C (where you actually need to pass something like that to malloc often) |
| 16:26 |
|
MinerDad joined #minetest-dev |
| 16:26 |
kahrl |
shouldn't it be initialized to CONTENT_IGNORE? |
| 16:26 |
sapier |
hope 0 is CONTENT_IGNORE |
| 16:26 |
kahrl |
though it was initialized to CONTENT_AIR before, I don't know if and how that worked |
| 16:26 |
kahrl |
nope, 0 is whatever is registered first by a mod |
| 16:27 |
kahrl |
CONTENT_IGNORE is 127 |
| 16:27 |
sapier |
ok then this optimization is just crap |
| 16:27 |
sapier |
we need to have defined values in there. If we can't use a memset we can use the constructor too |
| 16:27 |
kahrl |
agreed |
| 16:29 |
sapier |
As I said it's not first time I made a similar mistake too |
| 16:33 |
kahrl |
anyway let's wait for Zeno`, maybe he can explain how it works :) |
| 16:33 |
sapier |
yes it's broken and wont get different if we don't do anything maybe we miss something |
| 16:35 |
VanessaE |
fwiw those big clusters of errant nodes aren't limited to windmills |
| 16:35 |
VanessaE |
if that helps any |
| 16:36 |
VanessaE |
here's the one that happened the other day on one of my servers: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2001102015%20-%2001%3a03%3a25%20AM.png |
| 16:36 |
VanessaE |
you can see where normal mapgen ops even took place after the errant mapblocks were created (the trees and plants on top, and even mudflow) |
| 16:43 |
|
hmmmm joined #minetest-dev |
| 16:50 |
|
Calinou joined #minetest-dev |
| 17:16 |
sapier |
celeron55: I can't implement the upscaling feature, I'd have to touch formspec code and I'm not gonna do this ahain |
| 17:22 |
celeron55 |
we seriously need to rework or replace formspecs to be based on a proper design with clearly defined behavior |
| 17:22 |
celeron55 |
this is unbearable |
| 17:24 |
celeron55 |
https://forum.minetest.net/viewtopic.php?p=167434#p167434 |
| 17:24 |
celeron55 |
i could try to hook these guys up to this task, assuming they're competent enough |
| 17:24 |
celeron55 |
they want a proper UI themselves too in any case |
| 17:25 |
celeron55 |
it's just that whether they are willing to spend 75% of their time thinking about networking when they could just hack something that works specifically for their project |
| 17:26 |
sapier |
I'm not gonna do this celeron55 I've already had enough trouble, I'm gonna support in designing it but I'll not code it |
| 17:26 |
celeron55 |
i think i'll have to ask what these guys have in mind |
| 17:28 |
sapier |
for those hw scaling the issue is formspec uses the actual screen size to be placed which is faked by the scaling change |
| 17:30 |
kilbith |
http://kenney.itch.io/voxus |
| 17:31 |
kilbith |
(no mention of Minetest yet...) |
| 17:31 |
sapier |
I'm not sure if those guys would be right they're designing their game I'd be worried about them having a limited point of view |
| 17:36 |
sapier |
btw I don't even think formspec language is that bad, it's some historic inconsistencys but for a gui system not supporting dynamic layout and containers it is quite suitable |
| 17:36 |
sapier |
it's implementation, to be more precise the positioning is, is inconsistent and broken |
| 17:37 |
sapier |
and for containers and dynamic layout we'd need a designer tool anyway |
| 17:38 |
celeron55 |
voxus looks professional, but i'm yet to see any actually interesting content |
| 17:38 |
sapier |
those guys seem to be skilled designers true |
| 17:41 |
sapier |
I wonder if that guy suggesting the hw scaling did try it |
| 17:42 |
sapier |
either I'm doing something different or irrlicht support for this is quite broken |
| 17:42 |
|
Ritchie joined #minetest-dev |
| 17:43 |
celeron55 |
and yes, i agree that the basic concept of formspecs is fine but 1) limiting, and 2) there are way too many historical problems |
| 17:43 |
sapier |
I fully agree to point 2 ;-) |
| 17:44 |
sapier |
as of code fixing it would be simple but I'm almost sure it'd cause major political issues |
| 17:44 |
|
ImQ009 joined #minetest-dev |
| 17:44 |
celeron55 |
did Zeno say he has experience of making UI systems? |
| 17:44 |
sapier |
yes he did |
| 17:45 |
celeron55 |
i wonder what kind of exactly |
| 17:45 |
sapier |
but he didn't wanna say anything about him doing the formspec redesign |
| 17:47 |
sapier |
ok seems like the irrlicht issues I just mentioned are due to changeing those parameters after creation of context .. guess I have to find a way to make them parameters of device creation |
| 17:50 |
sapier |
nice latest irrlicht version contains support for reading assets |
| 17:50 |
sapier |
maybe we can skip copying our textures to sdcard soon |
| 17:52 |
celeron55 |
gah, i hate thinking about this |
| 17:52 |
celeron55 |
everything is an absolute mountain of work and people's expectations are too high |
| 17:55 |
celeron55 |
doing anything is not rewarding at all |
| 17:55 |
sapier |
come on celeron55 everything is fine ;-) |
| 17:55 |
sapier |
almost |
| 17:56 |
celeron55 |
no, almost nothing is, and i can't help it |
| 17:56 |
celeron55 |
well the world isn't ending, but otherwise |
| 17:56 |
sapier |
crap I just tried to fix my system irrlicht header instead of the one within android deps :-) |
| 17:58 |
celeron55 |
one day i tried to imagine how to mix up minetest and buildat in a useful way |
| 17:58 |
celeron55 |
the end result was that it makes no sense and would be absolutely awful to make work in the first place |
| 17:59 |
sapier |
as often |
| 17:59 |
celeron55 |
yeah it's generally where these thought experiments go |
| 17:59 |
celeron55 |
directly in the trash |
| 18:00 |
celeron55 |
an another thing is that i would like to replace irrlicht with urho3d in minetest |
| 18:01 |
VanessaE |
O_o |
| 18:01 |
celeron55 |
and also take into use buildat's client-side lua wrapper of urho3d's gui system |
| 18:01 |
sapier |
wouldn't this just exchange the problems we know about by problems we'd still have to find out? |
| 18:01 |
celeron55 |
it's pretty functional i must say |
| 18:02 |
celeron55 |
yeah, it would immediately bring in some issues like not being able to support very old GPUs |
| 18:03 |
celeron55 |
would have to find out first how many users would be affected |
| 18:03 |
celeron55 |
but it would solve a lot of issues too |
| 18:03 |
sapier |
define "very old"? |
| 18:04 |
celeron55 |
older than opengl 2 |
| 18:04 |
exio4 |
is there any gpu out there that can run minetest right now with that ogl version? |
| 18:05 |
celeron55 |
of course it requires some specific extensions instead of that version so it's more complicated than that |
| 18:06 |
sapier |
so basicaly anything below geforce 7 |
| 18:06 |
celeron55 |
EXT_framebuffer_object and EXT_packed_depth_stencil |
| 18:06 |
celeron55 |
or something like that |
| 18:06 |
sapier |
which is about 2005 |
| 18:07 |
sapier |
I'd guess intel required some more time to get opengl2 support |
| 18:07 |
|
rubenwardy joined #minetest-dev |
| 18:07 |
celeron55 |
my old laptop (the famous one that i made MT on) runs irrlicht on opengl 1.4 |
| 18:07 |
celeron55 |
so that's out |
| 18:08 |
celeron55 |
also virtualbox doesn't support those extensions |
| 18:09 |
celeron55 |
basically every 3D game has required those for ten years now though |
| 18:09 |
celeron55 |
every proper one :P |
| 18:09 |
sapier |
well intel wasn't as lazy as I expected their first ogl2 is 2005 too |
| 18:10 |
sapier |
basically we're talking about limiting minetest to hw newer then 10 years |
| 18:10 |
sapier |
with even some newer hardware not working |
| 18:10 |
sapier |
does urho3d support android? |
| 18:10 |
Calinou |
would Urho3D support shaders as well as Irrlicht currently does? |
| 18:11 |
celeron55 |
sapier: it does |
| 18:11 |
celeron55 |
Calinou: it's unable to operate without shaders |
| 18:11 |
sapier |
is it official or would we have to do as much as we'd have to do for irrlicht? |
| 18:11 |
Calinou |
ah, that's OK |
| 18:12 |
celeron55 |
sapier: it officially supports android |
| 18:13 |
sapier |
ok so by now no "no-go" issue ... what do we get if we switch? |
| 18:13 |
celeron55 |
its build system probably needs to be reworked for minetest though, and it's not available as a distro package anywhere, and the author does not recommend anyone to package it |
| 18:13 |
Calinou |
that's a rather big problem |
| 18:13 |
celeron55 |
it's a bit of a binary focused build system |
| 18:14 |
sapier |
that's nothing for the positive list celeron55 ;-) |
| 18:14 |
celeron55 |
because it's made for traditionally distributed binary games and not for open source projects |
| 18:14 |
celeron55 |
(but it's MIT licensed itself) |
| 18:15 |
sapier |
I guess estimating switching the engine would cost about half a year to a year ain't overestimating |
| 18:15 |
celeron55 |
sapier: well... we for example get a Lua interface to every part of urho3d |
| 18:15 |
sapier |
we'd need quite big improvements to justify doing this |
| 18:15 |
celeron55 |
which may or may not be helpful |
| 18:16 |
sapier |
I'm not sure if this would be a benefit, it'd be way more we'd have to secure ;-) |
| 18:16 |
celeron55 |
that's the problem, there will never be anything that can be just plugged in place of irrlicht and which happens to do exactly what we want |
| 18:17 |
celeron55 |
i mean, i haven't properly gone through this evaluation myself either |
| 18:17 |
sapier |
nope don't get me wrong that's not what I expect. No matter if it's irrlicht or any other engine we had right now switching it is a lot of work. It's only reasonable if the new engine is way more better |
| 18:17 |
celeron55 |
it would probably be quite a cultural shock to those used to how minetest builds |
| 18:18 |
sapier |
e.g. if the new engine would provide whole gui including description language, that'd make me think about a switch |
| 18:18 |
est31 |
why not use html |
| 18:18 |
est31 |
instead of formspecs |
| 18:18 |
sapier |
html doesn't specify the "active" part |
| 18:19 |
est31 |
no javascript |
| 18:19 |
|
rubenwardy joined #minetest-dev |
| 18:19 |
est31 |
but you can send forms |
| 18:19 |
est31 |
and have buttons |
| 18:19 |
celeron55 |
sapier: it provides a fully lua-controllable gui, which i use in buildat (the project that i have abandoned due to too much work) by sending the client some lua and running it in a sandbox |
| 18:19 |
est31 |
and you have 100% finished rendering engines |
| 18:19 |
sapier |
yes that's what makes html at least somehow fit to our current design |
| 18:19 |
celeron55 |
the gui has some dynamic layouting features |
| 18:19 |
est31 |
html has css |
| 18:19 |
est31 |
(and other layouting features too) |
| 18:20 |
sapier |
to be honest I don't wanna programm a gui in lua manually ;-) |
| 18:20 |
Calinou |
libRocket eats tons of CPU |
| 18:20 |
sapier |
especally if it's dynamic layout |
| 18:20 |
sapier |
things like that require a designer tool |
| 18:22 |
celeron55 |
http://fpaste.org/168382/00535142/ |
| 18:22 |
sapier |
but gui was just an example there could be other benefits worth it too |
| 18:22 |
celeron55 |
here's some gui code in an experimental thing running on buildat |
| 18:22 |
celeron55 |
you probably guessed it looks like that |
| 18:22 |
celeron55 |
it's pretty much what an OOP gui system will always look like |
| 18:23 |
sapier |
yes but still you can write simple guis that way but nothing complex |
| 18:23 |
sapier |
it's like programming qt manually ... yes it is possible yet noone does it |
| 18:23 |
sapier |
except some crazy ones maybe |
| 18:24 |
celeron55 |
well, qt has QML which can only be programmed manually |
| 18:24 |
sfan5 |
<VanessaE> here's the one that happened the other day on one of my servers: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2001102015%20-%2001%3a03%3a25%20AM.png |
| 18:24 |
celeron55 |
but it's more of a formspec-flavoured thing |
| 18:24 |
sapier |
qtdesigner? |
| 18:24 |
sfan5 |
it's a piece of art |
| 18:24 |
celeron55 |
QML is a separate language |
| 18:24 |
VanessaE |
sfan5: this by you is art? heh |
| 18:24 |
celeron55 |
i think qtdesigner is only for reqular qt, at least last time i checked it was |
| 18:25 |
sapier |
yes but for what I remember qml was added recently I'm quite sure they'll add a designer tool soon |
| 18:25 |
celeron55 |
well yeah, it might be that they will add it |
| 18:25 |
celeron55 |
anyway, if we want a gui that isn't programmed in that way, then we have no other option than to write it ourselves or just clean up formspecs a bit |
| 18:26 |
celeron55 |
or a lot |
| 18:26 |
sapier |
http://doc.qt.digia.com/qtcreator-2.3/creator-using-qt-quick-designer.html |
| 18:26 |
sapier |
I'm not against a gui programmed that way I just wanna have a designer for it too ;-) |
| 18:27 |
sapier |
we could rename formspec to mtfl ... and fix the historic issues ;-) |
| 18:28 |
celeron55 |
well, urho3d supports xml too, but irrlicht does that too |
| 18:28 |
celeron55 |
i actually originally attempted to make some menus in minetest in irrlicht xml (before Lua); it was awful |
| 18:28 |
celeron55 |
you don't get complete control with it |
| 18:29 |
sapier |
Are you sure we'd get full control by urho3d? |
| 18:29 |
celeron55 |
nope |
| 18:29 |
celeron55 |
i'm not advocating urho3d's xml at all |
| 18:30 |
sapier |
At best we'd use something exisiting. html(subset) qml the gtk ui stuff (don't know how they call it) |
| 18:30 |
celeron55 |
things always get awful at the point when you have to center a menu on the screen and keep it centered when the window is resized and then if you want to make some HUD with it, god forbid |
| 18:30 |
sapier |
but thats quite a lot of work |
| 18:31 |
sapier |
right now I'd be fine with irrlicht findig the correct ui element for my touch events ;-) |
| 18:31 |
sfan5 |
why would we even use html? |
| 18:31 |
|
est31 joined #minetest-dev |
| 18:31 |
celeron55 |
could we just remove UI |
| 18:31 |
sfan5 |
and who'll write the html parser (hint: html is not xml) |
| 18:31 |
celeron55 |
just make all menus as nodes in the game |
| 18:32 |
celeron55 |
the main menu could be a world too! |
| 18:32 |
sapier |
I'd love to see this celeron55 |
| 18:33 |
sfan5 |
hm |
| 18:33 |
sfan5 |
mh |
| 18:33 |
est31 |
sfan5 others. We just need to figure out how to get a renderer display content in front of ours |
| 18:34 |
est31 |
there are a couple of permissively licensed html renderers |
| 18:34 |
sfan5 |
random idea: you could make the redis backend connect to a remote redis server (that is read-only) and have like a continously updated tutorial world that way [or you could just do thing the normal way] |
| 18:34 |
celeron55 |
html is not a gui language, it's awful doing that job |
| 18:34 |
sfan5 |
est31: do you want to make minetest depend on webkit? |
| 18:34 |
est31 |
um yea |
| 18:35 |
sapier |
html is a form language at best |
| 18:35 |
celeron55 |
conclusion: UI is insane, i don't understand why anyone would want to touch it |
| 18:36 |
rubenwardy |
Doing the UI would interest me, but Minetest's code is insane. |
| 18:36 |
rubenwardy |
Especially formspecs etc |
| 18:37 |
celeron55 |
also i will respect sapier's insanity a lot if he still is willing to do *anything* to even design anything related to formspecs, lol |
| 18:38 |
celeron55 |
i'm going to just live with what we have, it's absolutely not worth the effort to touch it |
| 18:38 |
sapier |
well I'm gonna step back a few steps for some time ... I've been to close to quiting completely yesterday |
| 18:38 |
sapier |
at least step back from formspec topic |
| 18:39 |
celeron55 |
do you still happen to remember that the current networking implementation is a temporary solution until it is decided whether enet is good enough? 8) |
| 18:41 |
* celeron55 |
imagines sapier is running away screaming at about 500 meters from his computer by now |
| 18:41 |
sapier |
I know ... yet nobody ever did even try what I provided neither tcp nor enet implementation |
| 18:42 |
sapier |
well at least the fixed version I had so much trouble to get in seems to work quite stable |
| 18:42 |
celeron55 |
the whole thing was a stupid mess like usually |
| 18:42 |
celeron55 |
but it seems by now that freeminer has proven that enet works well |
| 18:42 |
rubenwardy |
It would be good to be able to do size[width()/2;height()/2] or something like that |
| 18:43 |
sapier |
Well I don't doubt enet works |
| 18:43 |
Calinou |
Freeminer has enet, how well does it work there? |
| 18:43 |
Calinou |
does it really provide lower ping? |
| 18:43 |
sfan5 |
who rewrites the server ping code in the server list when we switch to enet? |
| 18:44 |
sapier |
I don't think it's providing less latency |
| 18:44 |
celeron55 |
how do we test this |
| 18:45 |
sapier |
I don't know I never was able to benchmarks enet's latency or jitter as it just lies about it |
| 18:45 |
celeron55 |
what's the general case where people complain of lag? |
| 18:45 |
sapier |
at least it did |
| 18:45 |
celeron55 |
a busy server hosted with a low-bandwidth connection? |
| 18:45 |
sapier |
a jitter of 0ms is just impossible |
| 18:45 |
sfan5 |
sapier: depends on the connection |
| 18:46 |
sapier |
not even ping manages to get exactly 0.0 ;-) |
| 18:46 |
|
proller joined #minetest-dev |
| 18:50 |
sapier |
If you guys like to test it I'm gonna rebase the enet code, it's most likely not a big deal as whole network stack is built for replacing the low level protocol |
| 18:50 |
|
proller joined #minetest-dev |
| 18:51 |
celeron55 |
last time you said something in networking was easy you used weeks to create the current monster implementation 8) |
| 18:51 |
sapier |
nope I built tcp and enet in parallel same time |
| 18:52 |
celeron55 |
well if it's easy, go ahead |
| 18:52 |
celeron55 |
then remind us here every day that we need a way to test it |
| 18:52 |
VanessaE |
will the existence of it break old clients?> |
| 18:52 |
sapier |
formspec android and network protocol same time? are you sure you wanna be that insane |
| 18:53 |
sapier |
If we do it the way I implemented enet code it's gonna be possible to run both protocols in parallel |
| 18:54 |
sapier |
at different ports of course |
| 18:54 |
celeron55 |
well we will certainly drop the old protocol after a version that supports both |
| 18:54 |
sapier |
that's how I intended to do the transition |
| 18:54 |
VanessaE |
that's fine |
| 18:54 |
VanessaE |
I only ask because...well...you said you need testers/. |
| 18:55 |
VanessaE |
and I've got several production servers that could be users as long as old clients can still play normally. |
| 18:55 |
celeron55 |
yes, that seems somewhat useful for testing, altough i wonder how much the bandwidth competition between the protocols affects the result |
| 18:55 |
VanessaE |
used* |
| 18:56 |
sapier |
well you shouldn't mix it on testing ;-) |
| 18:59 |
VanessaE |
well one of those servers is expressly intended for testing. |
| 19:00 |
VanessaE |
I can move it to the enet port (or whatever) and let you all go at it there |
| 19:00 |
VanessaE |
it's not heavily modded, just technic and plantlife (and they're mostly already played out) so it'll respond as fast as any other server should. |
| 19:00 |
sapier |
yet it's not really usefull to compare enet to our current protocol. Anything but enet beeing better would be a surprise |
| 19:01 |
sapier |
comparing enet to tcp would be way more open ;-) |
| 19:12 |
Calinou |
TCP for real-time games? |
| 19:12 |
Calinou |
enet was written because TCP was slow… |
| 19:12 |
sapier |
Calinou: do you really think enets "reliable" communication is faster then tcp? ;-) |
| 19:13 |
Calinou |
nope |
| 19:13 |
Calinou |
but TCP makes everything reliable (AFAIK), which maybe isn't what you want… |
| 19:13 |
Calinou |
is TCP programming easier or harder than UDP? |
| 19:13 |
Calinou |
switching to TCP may simplify the code, if that is the case |
| 19:14 |
sapier |
well if we did use tcp we'd have to use a mixed mode protocol |
| 19:14 |
sapier |
partial udp partial txp |
| 19:14 |
sapier |
tcp |
| 19:15 |
sapier |
about as complex as udp, but way more fast if you wanna transmit large data |
| 19:15 |
sapier |
e.g. textures |
| 19:15 |
Calinou |
ah, right |
| 19:15 |
Calinou |
if you do that, be sure to make an announcement, so that people update their port forwardings |
| 19:15 |
|
MinerDad joined #minetest-dev |
| 19:15 |
sapier |
if I remember correct it's been about factor 100 to current and still about factor 10 compared to enet |
| 19:16 |
sapier |
no 100 was compared to old implementation current is quite a lot faster ... yet not capable to beat enet |
| 19:29 |
celeron55 |
i think enet would be a good compromise between simplicity and performance |
| 19:30 |
celeron55 |
it's going to max out the general internet connection anyway |
| 19:31 |
celeron55 |
or, i mean, average |
| 19:34 |
|
johnnyjoy left #minetest-dev |
| 19:34 |
|
johnnyjoy1 joined #minetest-dev |
| 19:35 |
VanessaE |
celeron55: define "average" |
| 19:35 |
VanessaE |
here, that could mean 5 Mbps (sadly) |
| 19:36 |
celeron55 |
dunno, probably under 1MB/s |
| 19:36 |
Calinou |
this would make remote server more redundant |
| 19:36 |
est31 |
64 kb is enough :D |
| 19:36 |
Calinou |
if we can reach 1 MB/s |
| 19:36 |
|
jluc joined #minetest-dev |
| 19:37 |
celeron55 |
i think the goal should be making it redundant |
| 19:37 |
celeron55 |
so let's make sure to test that as one of the first things |
| 19:41 |
Calinou |
yeah, it's good not to need a Web server |
| 19:41 |
Calinou |
initially that was an hack |
| 19:41 |
|
johnnyjoy1 left #minetest-dev |
| 19:42 |
sapier |
Calinou: right now webserver is even slower then directly downloading textures |
| 19:45 |
|
PilzAdam joined #minetest-dev |
| 19:59 |
|
crazyR joined #minetest-dev |
| 20:07 |
PilzAdam |
sapier, is it intentional that the mainmenu now scales with the window size? |
| 20:09 |
sfan5 |
PilzAdam: probably intentional (still looks bad IMO) |
| 20:10 |
VanessaE |
intentional, but a patch was proposed already |
| 20:11 |
VanessaE |
https://gist.github.com/sapier/846662f8f8aecaff166a |
| 20:11 |
VanessaE |
this, I think it was. |
| 20:11 |
sapier |
true |
| 20:15 |
rubenwardy |
http://rubenwardy.github.io/minetest_doc/chapters/releasing.html |
| 20:15 |
rubenwardy |
oops |
| 20:17 |
Calinou |
“protection†|
| 20:17 |
Calinou |
copyright is not protection |
| 20:17 |
Calinou |
it's a vicious term :/ |
| 20:18 |
Calinou |
just my two 0.02 € |
| 20:18 |
Calinou |
wrong channel anyway |
| 20:19 |
sapier |
damn |
| 20:19 |
sapier |
I never ever experienced some code just working after rebase |
| 20:22 |
sapier |
celeron55 https://github.com/sapier/minetest/tree/network_addon_enet_6 ;-) rebase completed |
| 20:23 |
|
crazyR joined #minetest-dev |
| 20:23 |
sapier |
don't expect it to be polished there are a few parts missing yet everything required for testing is in there |
| 20:27 |
|
acerspyro joined #minetest-dev |
| 20:29 |
sapier |
#2111 ... no comment |
| 20:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/2111 -- Problems with building |
| 20:34 |
sapier |
kilbith: fixed or still open ? https://github.com/minetest/minetest/issues/2077 |
| 20:34 |
|
ezraanderson joined #minetest-dev |
| 20:35 |
kilbith |
regarding the general complaining actually, still open. |
| 20:35 |
sapier |
so formspec is still broken? |
| 20:35 |
ezraanderson |
+sapier, do me input positions, x & y are in the wrong spot? |
| 20:36 |
sapier |
ezraanderson: yes that's what seems to happen if I press somewhere the gui acts somewhere else |
| 20:36 |
kilbith |
sapier, not broken, that's not the subject of the issue |
| 20:36 |
ezraanderson |
give me 5, minutes, I have never tried it on an android phone |
| 20:37 |
sapier |
sorry for asking kilbith I'm already getting headache again ... can you please settle this with Zeno and vanessae? |
| 20:37 |
sapier |
ah and sfan5 of course |
| 20:37 |
kilbith |
could you just try the suggestion of VanessaE yesterday ? (pixels = points/72*DPI) |
| 20:37 |
sapier |
nope |
| 20:38 |
sapier |
to get this done I'd have to touch almost any part of formspec |
| 20:38 |
|
OldCoder joined #minetest-dev |
| 20:38 |
sapier |
result would be another variant |
| 20:39 |
kilbith |
so you consider the current state as your best result you can do ? |
| 20:39 |
kilbith |
(honestly) |
| 20:39 |
sapier |
especially as I don't even exactly understand what pixels is meant because points/72*dpi will return some float value |
| 20:40 |
sapier |
I already said two days ago I'm not gonna tune anything at current code the only further work for formspec I have provided was reverting back to 0.4.9 style ... which wasn't accepted too |
| 20:41 |
sapier |
if I interpret vanessae's suggestion correct it's already implemented that way |
| 20:41 |
kilbith |
we'll discuss further with Zeno to see how things can evolve |
| 20:41 |
|
MinetestForFun joined #minetest-dev |
| 20:42 |
sapier |
do it this way |
| 20:45 |
kilbith |
well, actually it's no longer really an issue (chat bug, header violation by tabs etc.) nor a good result either |
| 20:45 |
kilbith |
so i guess i can close it |
| 20:46 |
sapier |
define "good result"? |
| 20:47 |
kilbith |
oh no, not again :'( |
| 20:47 |
sapier |
well you're using those subjective terms ;-P |
| 20:47 |
acerspyro |
Could be the politics "good result" expression, too. |
| 20:48 |
kilbith |
my humble suggestions actually is to define 0.85 as default scaling and make the fonts a little more fat |
| 20:49 |
kilbith |
but yeah, Irrlicht sucks for that |
| 20:49 |
sapier |
well I don't care about forst one |
| 20:49 |
sapier |
but I thought I'd have made clear we can't make this font more fat we'd have to exchange the font |
| 20:51 |
kilbith |
initially, the user don't have to bother with .conf or strafe the settings tabs of click for adjust the scaling |
| 20:51 |
kilbith |
so you should consider 0.85 as default |
| 20:52 |
VanessaE |
kilbith: just change your default font face. |
| 20:52 |
VanessaE |
font_path = /home/vanessa/.minetest/fonts/DejaVuSans.ttf |
| 20:52 |
VanessaE |
mono_font_path = /home/vanessa/.minetest/fonts/DejaVuSansMono.ttf |
| 20:52 |
VanessaE |
in minetest.conf |
| 20:52 |
VanessaE |
point them to fonts that look good for you |
| 20:52 |
kilbith |
i normally don't have to bother changing the font face |
| 20:53 |
acerspyro |
Setting up the game should be easier than this. |
| 20:53 |
acerspyro |
I agree. |
| 20:53 |
sapier |
suggestions please not agreements ;-) |
| 20:53 |
kilbith |
that ain't user-friendly |
| 20:54 |
kilbith |
and a good game normally is for relax |
| 20:55 |
sapier |
hmm we could sell mintest bundled to a pc including screen this way we could be sure it looks exaclty like it looks for us ;-) |
| 20:55 |
acerspyro |
Dynamic font size? |
| 20:55 |
sapier |
I know about a huge company doing it this way ... works quite good for them |
| 20:56 |
|
proller joined #minetest-dev |
| 20:56 |
acerspyro |
Strangely, I don't recall having to change the font size in any other game... |
| 20:57 |
acerspyro |
I only play OSS stuff, btw. |
| 20:57 |
sapier |
acerspyro: do you HAVE to do it here? |
| 20:57 |
acerspyro |
I would love to |
| 20:58 |
sapier |
well that's great because I can't remember any game where you even CAN change the font ;-) |
| 20:58 |
acerspyro |
Cube 2 games |
| 20:58 |
sapier |
I don't think there's alot of text in those games ;-) |
| 20:58 |
acerspyro |
There's the chat, the death messages, the info messages... |
| 20:59 |
sapier |
doesn't change the fact minetest already supports more features then most other games ;-) |
| 21:00 |
acerspyro |
Wrong |
| 21:00 |
acerspyro |
You can't even move your head. |
| 21:01 |
sapier |
I don't remember head beeing related to fonts |
| 21:01 |
acerspyro |
You changed the subject to the fact that MT supports more features than any other game |
| 21:01 |
acerspyro |
While it can't do chat colors either, afaik |
| 21:02 |
sapier |
I was talking about fonts only |
| 21:02 |
sapier |
no need to switch topic as we always have been talking about fonts |
| 21:13 |
kilbith |
i just tester the DejaVuSans font and the result is worse than before : https://lut.im/8Yv98312/sxTeGIFP |
| 21:13 |
kilbith |
tested* |
| 21:13 |
kilbith |
awful |
| 21:14 |
kilbith |
unless if you're strongly myopic |
| 21:15 |
acerspyro |
omg dem static menus |
| 21:15 |
VanessaE |
kilbith: gui_scaling is set back to normal? |
| 21:15 |
acerspyro |
y u no dynamic GUI? |
| 21:15 |
kilbith |
yep, scale cleaned in .conf |
| 21:15 |
kilbith |
at 1.0 in that screenie |
| 21:15 |
VanessaE |
kilbith: then just turn the font size down. obviously DPI isn't detected correctly on your machine |
| 21:16 |
VanessaE |
font_size = 10 |
| 21:16 |
VanessaE |
mono_font_size = 10 |
| 21:16 |
VanessaE |
see what that does |
| 21:17 |
VanessaE |
(just guessing based on your screenshot) |
| 21:18 |
kilbith |
https://lut.im/oT1V4QFS/rEY80DIE |
| 21:18 |
VanessaE |
ok I was close. try 12 instead of 10 |
| 21:18 |
VanessaE |
better yet, 14 |
| 21:18 |
VanessaE |
I'm curious. |
| 21:19 |
kilbith |
14 : https://lut.im/dkgG99hQ/iXLrfP6h |
| 21:20 |
VanessaE |
ok then for you I guess 12 or 13 would be about right. |
| 21:20 |
kilbith |
and i repeat : i normally don't have to bother with .conf like that. the average user won't. |
| 21:20 |
acerspyro |
^The words I couldn't find |
| 21:20 |
VanessaE |
sure, but first we need to find out the difference between you and what "should" happen |
| 21:20 |
acerspyro |
"The average user won't" |
| 21:22 |
VanessaE |
(I wanna know why kilbith's fonts are coming up ~50% larger than they should be to begin with) |
| 21:22 |
kilbith |
well, 13 is nice : https://lut.im/Gn68MNiK/sCQy8y8B |
| 21:23 |
VanessaE |
kilbith: yeah, that's about consistent with what should normally be - and you're sure you're at git HEAD now? |
| 21:23 |
sapier |
kilbith: are you on linux or windows? |
| 21:23 |
acerspyro |
sapier: facepalm for you sie |
| 21:23 |
Calinou |
he's not on Windows, look at window decorations |
| 21:23 |
acerspyro |
sir* |
| 21:24 |
VanessaE |
I can't begin to guess what distro or DE that even is.. |
| 21:24 |
acerspyro |
Unless LXDE has been ported to Windows... |
| 21:24 |
kilbith |
VanessaE: was testing on latest launchpad build - but i can test with Git HEAD, it'd identical |
| 21:24 |
sapier |
or he uses some lxde theme |
| 21:24 |
acerspyro |
VanessaE: It's LXDE, looks like Mint |
| 21:24 |
kilbith |
sapier: Lubuntu 14.04 |
| 21:24 |
acerspyro |
Or another Ubuntu variant |
| 21:24 |
VanessaE |
kilbith: latest launchpad build? how old is that anyway? |
| 21:24 |
sapier |
is lubuntu still x11? |
| 21:24 |
kilbith |
about 20h |
| 21:24 |
acerspyro |
VanessaE: very. |
| 21:25 |
acerspyro |
:P |
| 21:25 |
Calinou |
yes, sapier |
| 21:25 |
sapier |
20h :-) |
| 21:25 |
Calinou |
almost all distributions use Xorg by default |
| 21:25 |
kilbith |
https://code.launchpad.net/~minetestdevs/+archive/ubuntu/daily-builds/+packages |
| 21:25 |
sapier |
well that's ancient |
| 21:25 |
Calinou |
does Minetest run on Wayland or Mir (without compatibility layers) anyway? |
| 21:25 |
kilbith |
22h old to be exact |
| 21:25 |
sapier |
Calinou: that's gonna change soon |
| 21:25 |
acerspyro |
0.4.11 came to OpenSUSE's repos about a day after its release. |
| 21:26 |
kilbith |
sfan5 seems use the same default font as me too |
| 21:26 |
sfan5 |
Calinou: i don't think it does |
| 21:27 |
sapier |
22h is quite useless to discuss about while we're about to fix it you meed latest HEAD to be able to participate the discussion |
| 21:27 |
VanessaE |
and 22h ago, who even knows how old the commits are that went into it? |
| 21:27 |
sapier |
Calinou: compatibility layers just provide compatibility not necessary same behaviour |
| 21:27 |
kilbith |
always trying to invalidate my problems, eh ;) |
| 21:27 |
VanessaE |
kilbith: basic tenet of science ;) |
| 21:28 |
kilbith |
https://github.com/minetest/minetest/commits/master |
| 21:28 |
VanessaE |
"Make me a liar, Fish!" (Dr. Ellie Arroway, "Contact") |
| 21:28 |
kilbith |
^ latest build built after b7c... |
| 21:28 |
kilbith |
so your remark is irrelevant sapier |
| 21:29 |
sapier |
if it's b7c0e4b3336ef5bdb0bdd6baa3257787886b2c73 your build should be fine to discuss the issue |
| 21:30 |
kilbith |
the followed commits concerned android only |
| 21:30 |
sapier |
then try to find out why it's looking that different for you |
| 21:30 |
kilbith |
but ok, i'll compile right now |
| 21:31 |
sapier |
I suggest debug build and RUN_IN_PLACE to have commit in screenshots as well as be sure no other minetest.conf file is used |
| 21:31 |
kilbith |
sure |
| 21:31 |
kilbith |
hmm, debug build ? |
| 21:32 |
sapier |
-DCMAKE_BUILD_TYPE=Debug |
| 21:32 |
Calinou |
sapier, thanks for increasing step height on Android! |
| 21:32 |
sapier |
Calinou: I don't know why this wasn't done some time ago the suggestion was there for about half a year |
| 21:52 |
kilbith |
what's the... https://lut.im/mcavuaCy/Mr01yp1u first starting, not even a .conf generated, and the scaling is iniatially perfect O.o |
| 21:52 |
kilbith |
Vanessa, sapier ^ |
| 21:53 |
sapier |
ok now build release to make sure it's not behaving different for you |
| 21:53 |
sapier |
DCMAKE_BUILD_TYPE=Release |
| 21:53 |
kilbith |
'k |
| 21:54 |
VanessaE |
ok then we know you had something bad in your conf |
| 21:54 |
VanessaE |
(because I run a debug build) |
| 21:54 |
sapier |
he does do this right now to |
| 21:55 |
VanessaE |
oh right |
| 21:55 |
VanessaE |
misread. I need new glasses or eyes or something. |
| 21:55 |
kilbith |
no, my previous Git build (2 days ago) with RUN_IN_PLACE=1 behaved like the launchpad build |
| 21:55 |
sapier |
well I need a new keyboard it's always missing or exchanging keys |
| 21:55 |
kilbith |
with a virgin .conf |
| 21:55 |
sapier |
2 days ago is quite old |
| 21:59 |
VanessaE |
it's interesting to note that his locale reverted to english.. |
| 22:12 |
kilbith |
Release build, initial display : https://lut.im/LmYdSk31/KT1qKG0M |
| 22:12 |
kilbith |
^ sapier |
| 22:13 |
VanessaE |
lgtm. |
| 22:13 |
kilbith |
thats just similar |
| 22:13 |
sapier |
looks like current head is fine? |
| 22:14 |
kilbith |
yes, fine :) |
| 22:14 |
sapier |
is it possible that dayly build uses some config file you missed? |
| 22:14 |
kilbith |
so i take off what i said to you, it's a good work and i close my issue |
| 22:15 |
VanessaE |
well wait |
| 22:15 |
VanessaE |
sapier's question is valid |
| 22:15 |
VanessaE |
what is the buildbot on launchpad doing to fuck up the fonts? |
| 22:16 |
kilbith |
but there's still a zone of mystery : yesterday i removed my .conf before installing the latest .deb, this .deb has been built before the android commits only, and i still had those monstruous fonts... |
| 22:16 |
kilbith |
X-files.mp3 |
| 22:18 |
VanessaE |
now who gets to merge sapier's fixed-size-formspecs gist? :) |
| 22:20 |
|
MinerDad joined #minetest-dev |
| 22:22 |
VanessaE |
sapier: I know you don't want to touch formspecs but imho the best way to solve the entire mess is a revamped formspec language (whatever form it takes - HTML, XML, formspec tables, who knows) but with a slightly different method of summoning them |
| 22:23 |
VanessaE |
just like with two network stacks, the old way could be marked deprecated, read-only like you suggested, and be discontinued some day in the far future |
| 22:23 |
VanessaE |
or link against QT ;) |
| 22:26 |
sapier |
he just told the current variant is fine if he doesn't like the one after freverting those changes I'll have to do this discussion again. I provided the code. It's up to someone else to decide if it's supposed to be that way. |
| 22:26 |
VanessaE |
sapier: right. the fonts are good in 99% of cases now I think. |
| 22:46 |
acerspyro |
The hand item should really be the player's arm with the skin on it, like in Minecraft. The potato is just really weird. |
| 22:47 |
sapier |
mt != mc |
| 22:48 |
ezraanderson |
:) |
| 22:48 |
|
n4x joined #minetest-dev |
| 22:51 |
ezraanderson |
mt > mc ? |
| 22:52 |
acerspyro |
sapier: you really need to make a book on killing conversations you don't want to take place. You're really good at it .-. |
| 22:59 |
sapier |
If I were good at it it'd not have taken 5 days to settle that dispute |
| 23:01 |
VanessaE |
sapier: to be fair, most of that time was wasted due to time zone differences |
| 23:01 |
VanessaE |
lemme rephrase that |
| 23:02 |
VanessaE |
most of that wasted time* |
| 23:02 |
sapier |
considering this dispute beein spread across three continents that's been one of the factors true |
| 23:03 |
VanessaE |
I'd say it was the main factor |
| 23:03 |
VanessaE |
it's hard enough to get two people to agree on anything here as it is :) |
| 23:03 |
VanessaE |
(that's when they're already together) |
| 23:04 |
VanessaE |
then we have kilbith's issue caused by launchpad's build being somehow botched |
| 23:04 |
sapier |
I wouldn't say it's main factor but lets let it stay what it is ... history |
| 23:05 |
VanessaE |
yeah |
| 23:21 |
celeron55 |
i would love to see what a mailing list would do to these discussions |
| 23:22 |
celeron55 |
i'm not a fan of them, but from a practical standpoint it would seem like it would encourage actually thinking things and not just shouting what comes to mind |
| 23:25 |
celeron55 |
well, or, we could just try to move onto the forum |
| 23:27 |
celeron55 |
dunno, i'll probably do nothing to achieve any of this; just a thought |
| 23:54 |
|
acerspyro joined #minetest-dev |
| 23:54 |
|
sapier left #minetest-dev |
