| Time |
Nick |
Message |
| 00:40 |
|
Taoki joined #minetest-dev |
| 00:51 |
VanessaE |
celeron55: still want me to try that 0.3 map? it's explored enough for a basic test at least. |
| 00:52 |
VanessaE |
oh, aside: 0.3.3 with HDX 512px is way faster than 0.4.x with 256px |
| 00:53 |
VanessaE |
does that mean anything to you? |
| 00:58 |
|
Taoki joined #minetest-dev |
| 02:02 |
|
zat1 joined #minetest-dev |
| 02:08 |
|
EvergreenTree joined #minetest-dev |
| 02:14 |
VanessaE |
well I brought that world over. 0.4.4 with minetest_game, no mods, all graphics setting turned off so that it resembles 0.3.3 as closely as possible (e.g. no shaders, 2d clouds, no fancy trees, no aniso/mipmap/trilin, no nuthin'), 0.4-git gets about 1/3 of the performance 0.3.3. |
| 02:17 |
|
general3214 joined #minetest-dev |
| 02:18 |
VanessaE |
or close to it. 0.3.3: 60 fps with a view range of ~300 and tree-overloaded terrain. 0.4-git, 35-50 fps, view range of 235, over comparable but not-quite-so-overloaded terrain from the same map. |
| 02:19 |
VanessaE |
depending on where I look, and this is really simple terrain, my fps and view range drop lower, perhaps 35 fps and a range of < 200 |
| 02:20 |
VanessaE |
0.3.3 was running 512px HDX, 0.4-git is running 256px HDX |
| 02:20 |
VanessaE |
there is *definitely* a huge regression somewhere. |
| 02:29 |
VanessaE |
on my creative server, looking north from the spawn (the "acid test"), with 0.4-git and everything turned off that I can possibly turn off except for smooth lighting (since 0.3.3 had that turned on), unlock my max and wanted fps and unlock the min/max view range... 36 fps with a view range of 103, and the scenery is fairly simple as minetest worlds go. |
| 02:32 |
VanessaE |
and that's with pilzadam's VBO patch btw. |
| 02:35 |
VanessaE |
when I turn all my usual settings back on, but leave the fps and view range settings unlocked, it goes to ~38 fps at a view range of 58. |
| 02:35 |
VanessaE |
so I lose a lot because of my settings, but even the lowest settings at 256px can't compete with 0.3.3's default settings and 512px, so something's wrong. |
| 03:06 |
|
loggingbot_ joined #minetest-dev |
| 03:06 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 03:07 |
hmmmm |
any comments or concerns before I push? |
| 03:07 |
* VanessaE |
shrugs |
| 03:08 |
VanessaE |
I have no concerns |
| 03:08 |
VanessaE |
but I could raise holy hell and it wouldn't matter, since I ain't a core dev :) |
| 03:09 |
VanessaE |
note for the logs, since loggingbot didn't catch it: hmmmm is talking about pushing 7fa1b96c and fec65d04 from https://github.com/kwolekr/minetest/commits/master |
| 03:10 |
hmmmm |
well I'd rather get some kind of feedback before I do it |
| 03:10 |
VanessaE |
lemme pull it real quick. |
| 03:11 |
VanessaE |
hm |
| 03:12 |
VanessaE |
doesn't compile for me. |
| 03:12 |
VanessaE |
http://pastebin.com/njG2yt5P |
| 03:15 |
ShadowNinja |
I notice minetest_game doesn't have a 0.4.8 milestone. Should I add one? |
| 03:15 |
VanessaE |
ShadowNinja: good idea. |
| 03:18 |
VanessaE |
hm, looks like it was fec65d04 that broke it. |
| 03:19 |
ShadowNinja |
VanessaE: Can you confirm the trees-without-leaves bug? (I wouldn't be surprised as that code is terribly messed up) |
| 03:20 |
VanessaE |
ShadowNinja: cy1 reported same on my server but lemme check with git HEAD. |
| 03:21 |
* VanessaE |
waits for them to grow. |
| 03:21 |
VanessaE |
yup, they're busted. |
| 03:21 |
VanessaE |
checked in singleplayer, git HEAD, minetest_game |
| 03:30 |
VanessaE |
hmmmm: *poke* |
| 03:39 |
|
mrtux joined #minetest-dev |
| 04:11 |
VanessaE |
my G*d why is the mese pick SO SLOW now? |
| 04:11 |
VanessaE |
(it's about the same speed as the hand) |
| 04:19 |
ShadowNinja |
VanessaE: It got nerfed on non-stone nodes when diamond was added |
| 04:19 |
VanessaE |
ugh :-/ |
| 04:19 |
ShadowNinja |
(Actually it got nerfed on all nodes) |
| 04:20 |
VanessaE |
for me, diamond and mese picks seem to be about the same speed on any nodes they're used on |
| 04:21 |
VanessaE |
mese is special, imho, and should be elevated back to the fastest tool in the game |
| 04:21 |
ShadowNinja |
Of course really diamond should be wood-level. Like obsidian is a fragile volcanic glass... |
| 04:22 |
ShadowNinja |
^ I agree. |
| 04:22 |
ShadowNinja |
But diamond is more "special". |
| 04:22 |
VanessaE |
or rather, fastest *set* of tools. |
| 04:22 |
VanessaE |
bah, diamond is a normal material. mese is specific to minetest |
| 04:22 |
ShadowNinja |
(Acording to PilzAdam) |
| 04:23 |
VanessaE |
diamond is hard, but brittle. it should cut fast but wear out fast too |
| 04:23 |
VanessaE |
mese is supposed to be practically magical. the only thing faster than a mese pick should be a maptools admin pick |
| 04:24 |
ShadowNinja |
Agreed. |
| 04:27 |
hmmmm |
alright there ya go |
| 04:27 |
hmmmm |
it should work now vanessae |
| 04:27 |
VanessaE |
trying... |
| 04:32 |
VanessaE |
it builds and works. the hex value pluggen in should translate directly to a value, yes? |
| 04:33 |
VanessaE |
plugged-in* |
| 04:33 |
hmmmm |
it gets 'translated' when you start the game |
| 04:33 |
VanessaE |
0x8000 -> 32768? nope.avi. it became 17424951366025516154 |
| 04:33 |
hmmmm |
odd |
| 04:33 |
VanessaE |
well, #8000 rather. |
| 04:34 |
hmmmm |
um, #8000 is not the format of hex I accept |
| 04:34 |
hmmmm |
why would you expect that? |
| 04:34 |
VanessaE |
o9h hell |
| 04:34 |
VanessaE |
I read that wrong :P |
| 04:34 |
|
Warr1024 joined #minetest-dev |
| 04:34 |
VanessaE |
that's better. |
| 04:34 |
VanessaE |
0x works as expected. |
| 04:34 |
VanessaE |
this is good, I think. |
| 04:35 |
VanessaE |
(I mentally translated "hex" into "#" because I was thinking about formspec color codes :P ) |
| 04:36 |
VanessaE |
I like that it remembers the last seed entered |
| 04:36 |
hmmmm |
i suppose it would be worth adding # for hex as well if people expect it |
| 04:36 |
VanessaE |
naw, it was just a brain-o |
| 04:37 |
Warr1024 |
only for hex values of exactly 6 (or 8) digits :-) |
| 04:38 |
VanessaE |
hmmmm: now if you wanted to be a showoff, you'd accept $ syntax also :D |
| 04:38 |
VanessaE |
0x8000 -> $8000 |
| 04:39 |
hmmmm |
that's pretty confusing |
| 04:40 |
hmmmm |
see, in HTML the # prefix means hex |
| 04:40 |
hmmmm |
(or does it mean color? shrug) |
| 04:40 |
hmmmm |
in 6502 assembly and many others of the era, $ means hex |
| 04:40 |
hmmmm |
in 6502, # means numerical constant |
| 04:40 |
VanessaE |
it's 6502/Motorola syntax |
| 04:40 |
VanessaE |
yeah |
| 04:40 |
hmmmm |
so like |
| 04:40 |
hmmmm |
I can't possibly have both of them represent hex |
| 04:40 |
hmmmm |
that's bordering on ridiculous |
| 04:41 |
VanessaE |
heh |
| 04:41 |
kaeza |
don't forget &H8000 |
| 04:41 |
kaeza |
:P |
| 04:41 |
hmmmm |
FUCK vb |
| 04:41 |
kaeza |
:< |
| 04:42 |
hmmmm |
but anyway 0x is pretty universal, no? |
| 04:42 |
Warr1024 |
so basically putting any shit in front of or behind a number makes it hex. |
| 04:42 |
VanessaE |
oh sure. |
| 04:42 |
VanessaE |
Warr1024: what, no love for octal? :) |
| 04:42 |
Warr1024 |
let's not forget 0644 for octal :-D |
| 04:42 |
hmmmm |
or the 0o prefix |
| 04:43 |
hmmmm |
(i honestly forget what uses that) |
| 04:44 |
VanessaE |
oh also, # is only a numeric constant, but you still have to indicate hex with a $ also. LDA #$20 for example. |
| 04:44 |
Warr1024 |
I think I've seen hex done with just an x prefix. |
| 04:44 |
VanessaE |
at any rate, 0x is fine. the $ thing was meant tongue-in-cheek |
| 04:45 |
|
mrtux joined #minetest-dev |
| 04:46 |
hmmmm |
ohh.... was it a really good idea to move tree growing and grass abms out to lua |
| 04:46 |
hmmmm |
they were there for speed |
| 04:48 |
VanessaE |
aside from trees having been broken by doing so, the benchmarks suggested that on average it would only impose like a 0.01% penalty |
| 04:48 |
VanessaE |
(or 0.1%, I forget which) |
| 04:49 |
VanessaE |
Warr1024: verilog uses x"1234" for hex. |
| 04:50 |
hmmmm |
i'd have to see it to believe it |
| 04:50 |
VanessaE |
er VHDL does I mean |
| 04:50 |
Warr1024 |
good lua code isn't that much slower than decent c/c++ code. |
| 04:50 |
hmmmm |
ol |
| 04:50 |
hmmmm |
lol* |
| 04:50 |
VanessaE |
I thought that notation seemed odd (I've programmed a bit in verilog)... there's rather a large difference between the two :) |
| 04:51 |
hmmmm |
if that were true why did we spend like an eternity moving things back into C++ as an api for lua to call |
| 04:52 |
VanessaE |
hmmmm: well I guess in this case it's because the speed gain wasn't worth losing the ability to override the sapling growth |
| 04:52 |
Warr1024 |
hmmmm: I don't know. As I understand it, more than 99% of my CPU is spent running c code anyway, not lua. |
| 04:52 |
Warr1024 |
in fact, it's almost all that mesh building stuff. |
| 04:52 |
hmmmm |
if that were really the main problem, i'd rather add something in to override sapling growth |
| 04:53 |
hmmmm |
warr1024, but that's the client eating that CPU, not the server. |
| 04:53 |
Warr1024 |
yeah, the server doesn't eat cpu until it's mapgen time. |
| 04:53 |
hmmmm |
and Lua needs to lock the environment and so on while it's doing whatever, so the entire server basically comes to a halt |
| 04:54 |
ShadowNinja |
The difference was 130ms to 150ms. And sapling spawning doesn't have to be terribly fast because of it's low interval and chance. |
| 04:54 |
VanessaE |
hmmmm: wouldn't the proper solution there be to find ways not to lock the environment? |
| 04:54 |
Warr1024 |
that's only really a problem with bad lua code, though... |
| 04:54 |
hmmmm |
vanessae, contact sapier about that |
| 04:54 |
hmmmm |
:p |
| 04:54 |
VanessaE |
yeah yeah I know :P |
| 04:55 |
hmmmm |
ahh oh wow we got new core devs |
| 04:55 |
hmmmm |
when did that happen |
| 04:55 |
VanessaE |
a few days ago |
| 04:55 |
ShadowNinja |
~3 days ago. |
| 04:56 |
hmmmm |
shows how much i've been out of it |
| 04:56 |
VanessaE |
well you had shit to do |
| 04:56 |
hmmmm |
not really, at this point it's just that i'm not doing anything at all |
| 04:56 |
hmmmm |
completely unmotivated |
| 04:56 |
VanessaE |
ugh. don't I know that. |
| 04:58 |
ShadowNinja |
I'm trying to get a err unc passed to lua_pcall(get tracebacks for obscure crashes). Should I just add a global function to s_base, pr is there a way to/should I use member functions? |
| 04:59 |
ShadowNinja |
errfunc* |
| 05:05 |
|
general3214 joined #minetest-dev |
| 05:07 |
ShadowNinja |
s_base.cpp 136 and 137 have to be added before all lua_pcall()s basically. |
| 05:16 |
hmmmm |
true |
| 05:17 |
hmmmm |
a method is a function just the same as a global, it'd just be trickier to get it registered |
| 05:17 |
hmmmm |
unless you're really confident you know what you're doing with the lua crap i'd avoid it |
| 05:18 |
ShadowNinja |
hmmmm: What do you think would be the best way to do this? loadScript_ErrorHandler is currently static. |
| 05:19 |
ShadowNinja |
gcc complains about using members. |
| 05:19 |
hmmmm |
I don't really see what's wrong with a global error handler like that |
| 05:19 |
|
salamanderrake joined #minetest-dev |
| 05:19 |
ShadowNinja |
Alright, but perhaps it should be remaned? |
| 05:20 |
ShadowNinja |
renamed* |
| 05:20 |
hmmmm |
eh.. please leave it |
| 05:23 |
|
werwerwer_ joined #minetest-dev |
| 05:24 |
hmmmm |
https://github.com/proller/minetest/commit/5df0621a661a9b36a8626d5d9e52590e588e5309#diff-18513665750ef5adf42b5ec29e14162eL1321 |
| 05:24 |
hmmmm |
proller |
| 05:25 |
hmmmm |
nvm disregard that |
| 05:25 |
hmmmm |
it's initialized elsewhere |
| 05:48 |
|
darkrose joined #minetest-dev |
| 05:48 |
|
darkrose joined #minetest-dev |
| 05:55 |
VanessaE |
um, was something about overall formspec handling changed in one of these last few commits? |
| 05:56 |
VanessaE |
suddenly, Unified Inventory's formspec (which uses custom background images) is being overlaid by the squares for the various inventory slots. |
| 05:57 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2012:56:15%20AM.png |
| 05:58 |
hmmmm |
https://github.com/minetest/minetest/commit/25edae00ea1d5a9af4a6599fc7c200bb810fbd49 |
| 05:58 |
hmmmm |
it seems like someone reworked formspecs |
| 05:58 |
VanessaE |
annnd...broke them. |
| 06:03 |
VanessaE |
I wonder if that ^^^ commit is also why creative mode duplicates tools/weapons when you move them around in the inventory? |
| 06:03 |
hmmmm |
why don't you revert to the one before it and find out? |
| 06:04 |
VanessaE |
eh, that one seems to be a Unified Inventory bug actually. |
| 06:04 |
VanessaE |
doesn't happen with the default creative |
| 06:07 |
VanessaE |
checking the formspec issue |
| 06:26 |
|
Ritchie joined #minetest-dev |
| 07:13 |
VanessaE |
rebased my 6d facedir pull. |
| 08:06 |
|
smoke_fumus joined #minetest-dev |
| 08:21 |
|
Akien joined #minetest-dev |
| 09:54 |
|
ImQ009 joined #minetest-dev |
| 09:56 |
|
proller joined #minetest-dev |
| 10:02 |
|
werwerwer joined #minetest-dev |
| 11:21 |
|
EvergreenTree joined #minetest-dev |
| 11:33 |
|
werwerwer joined #minetest-dev |
| 11:44 |
|
proller joined #minetest-dev |
| 12:27 |
|
zat joined #minetest-dev |
| 12:35 |
|
proller joined #minetest-dev |
| 12:41 |
|
proller joined #minetest-dev |
| 12:41 |
|
troller joined #minetest-dev |
| 12:41 |
|
Akien joined #minetest-dev |
| 12:59 |
troller |
https://github.com/minetest/minetest/pull/983 |
| 13:03 |
|
BlockMen joined #minetest-dev |
| 13:05 |
BlockMen |
VanessaE, its not broken. The difference is that item slots are always drawn now, but if you dont like them you can set the color transparent, like that:""istcolors[#8880;#C0C0C0]", see lua-api for more details ;) |
| 13:06 |
BlockMen |
s/"/l |
| 13:21 |
|
hmmmm joined #minetest-dev |
| 13:33 |
|
BlockMen left #minetest-dev |
| 14:00 |
|
sfan5[iPod] joined #minetest-dev |
| 14:08 |
|
iqualfragile joined #minetest-dev |
| 14:45 |
|
SpeedProg joined #minetest-dev |
| 14:48 |
|
jojoa1997 joined #minetest-dev |
| 14:58 |
|
general3214 joined #minetest-dev |
| 15:05 |
|
proller joined #minetest-dev |
| 15:08 |
proller |
hmmmm, need to approve https://github.com/minetest/minetest/pull/892 |
| 15:16 |
|
smoke_fumus|2 joined #minetest-dev |
| 16:08 |
|
Akien joined #minetest-dev |
| 16:19 |
|
proller joined #minetest-dev |
| 16:29 |
|
PilzAdam joined #minetest-dev |
| 16:36 |
PilzAdam |
ShadowNinja, FYI the diamond tools were hmmmm's idea |
| 16:37 |
VanessaE |
diamond wasn't a bad idea, but mese should still be the fastest. |
| 16:37 |
VanessaE |
and at its present speed, it's WAY too slow |
| 16:37 |
VanessaE |
at least on non-stone nodes. |
| 16:38 |
PilzAdam |
of course you need mese shovel/axe for non-stone nodes |
| 16:38 |
|
VanessaE joined #minetest-dev |
| 16:39 |
VanessaE |
bah |
| 16:39 |
VanessaE |
ctrl-A, you schmuck, not ctrl-Q. |
| 16:40 |
VanessaE |
anyway, I guess it's not so bad, but really, a mese pick on wood or dirt is nearly as slow as the hand |
| 16:41 |
VanessaE |
I understand the need for balance of course. |
| 16:41 |
PilzAdam |
its not "nearly" as slow, its exactly the same speed |
| 16:41 |
ShadowNinja |
I've fixed VanessaE's no-backtrace issue(I just have to apply it to a few more functions). Example output now: http://pastebin.ubuntu.com/6365584/ |
| 16:41 |
VanessaE |
a shovel should be faster than a pick on dirt, but nearly instant, compared to a few seconds? |
| 16:42 |
VanessaE |
that's what I mean by way too slow |
| 16:42 |
PilzAdam |
the system we use in minetest_game is that every tool just defines the digging time for one special group (i.e. cracky for picks), all the other times are taken from the hand |
| 16:42 |
VanessaE |
a mese pick is supposed to be FAST on everything. Maybe slower than using a more appropriate tool, sure, but as slow as the hand is not right at all. |
| 16:43 |
PilzAdam |
ah, you got that wrong, the mese pick is supposed to be fast on stone only |
| 16:43 |
PilzAdam |
since its a pick |
| 16:43 |
VanessaE |
"supposed to be" == "how it historically has behaved" |
| 16:44 |
VanessaE |
I don't mean it needs to be massively overpowered like the 0.3.3 pick was :) |
| 16:44 |
PilzAdam |
things have changed |
| 16:44 |
VanessaE |
know. |
| 16:44 |
VanessaE |
I know* |
| 16:45 |
* VanessaE |
shrugs |
| 16:46 |
proller |
ShadowNinja, undefined, ? |
| 16:46 |
proller |
http://servers.minetest.net/ |
| 16:47 |
ShadowNinja |
Hmmm, I thought humanTime had a check for that. It seems to work for age... |
| 16:48 |
ShadowNinja |
proller: Oh, add "return seconds;" after the for loop in humanTime. |
| 16:49 |
proller |
and maybe add popular ? |
| 16:49 |
ShadowNinja |
proller: Or rather "return seconds + 's';". |
| 16:49 |
proller |
ok |
| 16:50 |
proller |
http://minetest.setun.net:8000/ |
| 16:54 |
|
smoke_fumus joined #minetest-dev |
| 16:55 |
VanessaE |
with so many servers in the list, we've got a bad selection bias going on now |
| 16:56 |
VanessaE |
less-popular servers end up down off the bottom of the list, and people don't like to scroll |
| 16:56 |
VanessaE |
so the less popular ones have less chance to improve that rank |
| 16:57 |
VanessaE |
maybe they should be in order my ping time or uptime or something? |
| 16:57 |
VanessaE |
by* |
| 16:57 |
proller |
ping now useless, need to make processing ping packet by serverthread |
| 16:58 |
proller |
for player - better to play on full server |
| 16:59 |
VanessaE |
that means a mostly empty server will never get full. |
| 17:00 |
VanessaE |
maybe just randomize the list order then each time the client is started. |
| 17:00 |
VanessaE |
or alpha order by the server name |
| 17:00 |
VanessaE |
or alpha/numeric order by IP |
| 17:01 |
VanessaE |
just something that is not tied to the number of users on the server. |
| 17:02 |
ShadowNinja |
VanessaE: This should fix your traceback issue: http://ix.io/8UP |
| 17:02 |
|
Gethiox3 joined #minetest-dev |
| 17:03 |
proller |
http://minetest.setun.net:8000/ - now with players: players/limit average/top |
| 17:03 |
ShadowNinja |
It starts, but I might have added the function to the stack incorrectly of something like that, so it should be tested on a real server for a bit. |
| 17:03 |
VanessaE |
proller: change the header also. |
| 17:03 |
proller |
it will toooo long 8( |
| 17:04 |
VanessaE |
proller: two lines, duh :) |
| 17:04 |
VanessaE |
ShadowNinja: ok, I'll apply it |
| 17:04 |
proller |
f5 |
| 17:05 |
VanessaE |
proller: good, but put something other than a space between the two pairs, or display those pairs on separate lines also |
| 17:06 |
proller |
f5 |
| 17:06 |
VanessaE |
meh |
| 17:07 |
VanessaE |
put 'em on separate lines. |
| 17:08 |
|
sapier joined #minetest-dev |
| 17:10 |
proller |
no, splitting lines too bad |
| 17:10 |
VanessaE |
why? |
| 17:10 |
VanessaE |
it's already split in the description column. |
| 17:10 |
sapier |
VanessaE I wonder why your performance evaluations give that different result to mine |
| 17:10 |
VanessaE |
it won't change the overall table formatting. |
| 17:10 |
proller |
not everywhere |
| 17:10 |
proller |
only on small screen |
| 17:11 |
proller |
if larger 1150px - in one line |
| 17:11 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2012:10:53%20PM.png |
| 17:11 |
proller |
https://github.com/proller/minetest/commit/a8e78b76f6d32f7f77bddf4919ebbdf445d4dc9e |
| 17:11 |
VanessaE |
^^^^ 1280x1024 screen |
| 17:12 |
VanessaE |
that's how small it has to get to keep each entry on one line (firefox 25) |
| 17:12 |
VanessaE |
ShadowNinja: your patch is in service now. |
| 17:13 |
sapier |
hmmm lua doesn't need to lock the environment it's broken design why the environment needs to be locked |
| 17:13 |
proller |
will commin if no objections ^^^ |
| 17:13 |
VanessaE |
sapier: how do your results differ from mine (and what results, anyay?) |
| 17:13 |
celeron55 |
it would be better to not make subcolumns with commas |
| 17:14 |
sapier |
http://imgur.com/bfMsr3r,1ProJQP#1 |
| 17:14 |
celeron55 |
but make them actual columns or subcolumns (which is done by making them visually different to a "full" column) |
| 17:14 |
sapier |
those results I posted them yesterday 23:20 |
| 17:14 |
sapier |
for me minetest 0.3.2 performance is almost exactly same as 0.4.7 |
| 17:14 |
proller |
celeron55, too many columns |
| 17:15 |
sapier |
there's even a small + for 0.4.7 yet not enough to really count it |
| 17:15 |
VanessaE |
sapier: ah, right. didn't see. yeah, for me the difference is stark, almost jarring. |
| 17:15 |
ShadowNinja |
VanessaE: I seem to have missed a few uses of lua_pcall, but most should be covered. |
| 17:15 |
sapier |
that's what I wanna find out ... it may give a hint where to look for the regression you suffer from |
| 17:17 |
VanessaE |
ShadowNinja: I'm sure we'll find out shortly :P |
| 17:17 |
VanessaE |
in fact, lemme see if I can force that one assert. |
| 17:17 |
sapier |
whyt do you want to cover shadow? |
| 17:18 |
sapier |
VanessaE what os and graphics card graphics api do you run minetest? |
| 17:19 |
VanessaE |
sapier: Linux, OpenGL 4.3.12614, ATI HD 6870. |
| 17:19 |
proller |
next step to servers list - make page about every server with full info |
| 17:20 |
sapier |
ok I've got nvidia graphics ... maybe we need someone to check if this is a relevant difference |
| 17:22 |
|
Calinou joined #minetest-dev |
| 17:23 |
sapier |
hmm my old laptop is ati graphics ... I'm gonna try |
| 17:24 |
VanessaE |
ShadowNinja: your changes weren't enough to produce a backtrace from the vector lib. Is there some change I need to make there also? |
| 17:25 |
VanessaE |
(I'm using the technic chainsaw + item_drop bug as a basis) |
| 17:28 |
|
salamanderrake joined #minetest-dev |
| 17:30 |
|
EvergreenTree joined #minetest-dev |
| 17:38 |
ShadowNinja |
VanessaE: Must have been one of the pcalls I missed. Lemme get this to compile and I'l give you an updated patch. |
| 17:38 |
VanessaE |
ok |
| 17:39 |
sapier |
shadow you did push the error function right in front of the pcall ? |
| 17:40 |
ShadowNinja |
sapier: No, I push it at the begining of the function. Should I push it there? |
| 17:42 |
sapier |
depends on what you're doing pcall from c++ main loop or pcall from lua-c++ call |
| 17:43 |
sapier |
the lua stack handling isn't exactly easy to understand so if you don't exactly know what you're doing you most likely will do wrong ... I learned this the hard way ;-) |
| 17:43 |
ShadowNinja |
Should it be before on a Lua->C++ call? With a lua_pop() after? |
| 17:44 |
ShadowNinja |
Drat: PANIC: unprotected error in call to Lua API (bad argument #8 to '?' (function expected, got string)) |
| 17:44 |
sapier |
if you're in main loop it's done this way no idea what is correct if you do a c++ -> lua --> c++ ->lua call |
| 17:45 |
sapier |
that's what happens if you messed up stack |
| 17:46 |
ShadowNinja |
Yea, I guesed. Lemme see if I can find where this heppened... |
| 17:46 |
sapier |
I already tried to fix those lua calls but didn't spend much time on it when I didn't succeed immediatly |
| 17:49 |
sapier |
VanessaE where did you get 0.3.3 from? |
| 17:49 |
VanessaE |
sapier: from the Minetest git repo, 0.3-stable branch |
| 17:50 |
sapier |
ok so not 0.3.2 tag but 0.3 branch thx |
| 17:50 |
VanessaE |
yup |
| 17:51 |
VanessaE |
"Minetest-c55 0.3.3" is what it reports in the game anywaty |
| 17:51 |
VanessaE |
anyway* |
| 17:53 |
VanessaE |
fps seems more variable now than before, but it definitely performs better than 0.4.x for me |
| 17:53 |
ShadowNinja |
Alright, fixed it. c_content.cpp or c_internal.cpp. sapier: can you figure out how I should add the errfunc to script_run_callbacks? |
| 17:54 |
ShadowNinja |
The errfunc is named script_error_handler. |
| 17:55 |
sapier |
no I don't know how to do that I'd have to look same way you'd have to look and I'm looking for vanessaE's performance issues |
| 17:56 |
VanessaE |
sapier: for example, I'm holding a solid 30 fps with a view range of 287 over complex, tree-overloaded terrain right now in 0.3.3 |
| 17:56 |
VanessaE |
(with default textures) |
| 17:57 |
sapier |
VanessaE I don't expect typical 0.4 to be faster then 0.3 as noone will avoid using 0.4 features yet if one avoids it it should be almost as fast as 0.3 ... as this doesn't seem to be true for your environment I try to figure out why |
| 17:57 |
ShadowNinja |
VanessaE: Any better? (Probably not though) https://github.com/ShadowNinja/minetest/tree/pcall_errfunc |
| 17:58 |
sapier |
did you have a look at my screenshots vanessae? is that situation comparable to what you test? |
| 17:59 |
VanessaE |
sapier: hold, I'm doing another test. |
| 17:59 |
VanessaE |
ShadowNinja: gimme a few mins. |
| 18:07 |
VanessaE |
oh sure, NOW it's gonna make a liar out of me! |
| 18:07 |
sapier |
ok with exatly same view I have about 50% more frames in 0.4 than in 0.3 |
| 18:07 |
sapier |
at least in some situations |
| 18:08 |
VanessaE |
as soon as these damn clouds move out of the way of the f5 I'll upload screenshots. |
| 18:09 |
sapier |
at least on nvidia gtx260 0.4 has slightly better performance than 0.3 |
| 18:10 |
sapier |
wait irrlicht 1.7.3 |
| 18:10 |
sapier |
do you have 1.8? |
| 18:11 |
VanessaE |
0.3.3: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2012:59:39%20PM.png |
| 18:11 |
VanessaE |
0.4-git http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2001:09:38%20PM.png |
| 18:11 |
VanessaE |
and it's 1.8 for the 0.4-git build, 1.7.3 for the 0.3.3 build |
| 18:11 |
VanessaE |
the 0.4-git build has several patches on it to help with client fps |
| 18:12 |
VanessaE |
(vbo, strip the fps from the title bar, etc) |
| 18:12 |
ShadowNinja |
https://github.com/minetest/minetest/pull/954 <-- Wasn't this intentionally disabled? And why was it if so? |
| 18:12 |
sapier |
maybe it's not a minetest 0.3 -> minetest 0.4 but a irrlicht 1.7 -> irrlicht 1.8 problem? |
| 18:13 |
VanessaE |
sapier: could be. when I posted the initial report, both were running 1.7.x |
| 18:13 |
sapier |
what framerate is 0.4.7? |
| 18:13 |
|
werwerwer_ joined #minetest-dev |
| 18:13 |
VanessaE |
but why does 0.3.3 perform better with 512px textures than 0.4-git does with 256px? |
| 18:13 |
ShadowNinja |
Can someone else agree #934? |
| 18:13 |
sapier |
vanessa it doesn't ;-) |
| 18:13 |
VanessaE |
0.4 was pushing 60 fps, hence the "liar" part. |
| 18:13 |
sapier |
at least not generaly |
| 18:14 |
VanessaE |
sapier: in a few mins I will try it again, just to be 100% sure. |
| 18:15 |
VanessaE |
ShadowNinja: reset back to my local HEAD, added your revised patch, compiling it now. |
| 18:15 |
sapier |
I'm currently testing on radeon xpress 200m ... same libs for both builds |
| 18:16 |
sapier |
sorry if this sounds rude but I consider comparing builds with different libs useless for performance comparison |
| 18:16 |
|
Jordach joined #minetest-dev |
| 18:17 |
VanessaE |
ShadowNinja: still not enough to get a backtrace. |
| 18:18 |
ShadowNinja |
:-| |
| 18:18 |
sapier |
I forgot how to enable fly ... yes I know "again" ... can someone help me? |
| 18:19 |
ShadowNinja |
sapier: Are you familiar enough with Lua to fix this? Or do you know someone that is? |
| 18:20 |
sapier |
I guess I could find out how to fix it but it's not a thing to be done in 5 min for me .. I would've already done if it was |
| 18:20 |
sapier |
fly? ;-) |
| 18:21 |
VanessaE |
*sigh* now my computer is gonna make a big liar out of me *grumble loudly* |
| 18:22 |
ShadowNinja |
sapier: There are just a few calls to go, I got most of them. |
| 18:23 |
ShadowNinja |
Alright, read_items done. |
| 18:25 |
sapier |
shadow it's NOT just a view calls to go it's doing it without messing lua stack ;-P |
| 18:25 |
VanessaE |
0.3.3, HDX 512: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2001:22:19%20PM.png |
| 18:25 |
VanessaE |
0.4=-git, HDX 512: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2001:24:18%20PM.png |
| 18:25 |
ShadowNinja |
Yes. |
| 18:25 |
sapier |
great I can't test on my old laptop it instantly crashes 0.4 |
| 18:26 |
VanessaE |
(fps was respectable then, comparable to 0.3.3) |
| 18:26 |
ShadowNinja |
VanessaE: I notice a different bug: "Minetest [Main Menu]" |
| 18:26 |
VanessaE |
ShadowNinja: I removed the fps display from the titlebar. gives me a couple fps gain. |
| 18:26 |
sapier |
0.4.7 seems to be faster as your view distance is bigger |
| 18:27 |
sapier |
especialy xfce seems to behave quite ugly for title bar updates |
| 18:29 |
sapier |
VanessaE maybe you misinterpret 0.4 beeing slower because in usual environment it actually is slower ... not because of regression but because of new features require more cpu power |
| 18:29 |
sapier |
or graphics power |
| 18:30 |
sapier |
everything I found out by now give 0.4 a slight performace benefit to 0.3 (and your screenshots seem to show same) |
| 18:30 |
VanessaE |
sapier: and notice how complex the terrain is. Now, watch what happens when I go into my creative server, exact same settings as in the screenshot above: |
| 18:30 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2001:29:54%20PM.png |
| 18:30 |
VanessaE |
35 fps in that shot. |
| 18:31 |
sapier |
yes? with quite a lot more non 1 block meshes |
| 18:32 |
sapier |
I'd guess there are a lot of those meshes within viewing range but yet hidden by others in that screenshot too |
| 18:32 |
VanessaE |
maybe a few - streetlamps, some mesecons, some slabs. whoop-de-doo. |
| 18:33 |
sapier |
guess 0.3 would behave as bad as 0.4 if this was possible there ... seems to be a generic fault of the way minetest (0.3/0.4) is doing rendering ... at least thats best explantation that matches the results |
| 18:33 |
ShadowNinja |
sapier: Moving around the insertion only changes the error message. Any help? |
| 18:34 |
sapier |
if you do add a function to stack within a lua called c++ you mess up the stack you need to make sure it's exactly same as before |
| 18:35 |
sapier |
so if yo do a pcall afterwards you need to push parameters for that call AFTER the error handler |
| 18:35 |
sapier |
if you pass parameters from outer lua call to a inner one you even need to pop the parameters push the error handlers and push back the parameters |
| 18:36 |
VanessaE |
now watch what happens when I view that map with no content at all: |
| 18:36 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2001:35:20%20PM.png |
| 18:36 |
sapier |
that'S why I didn't do it it's quite easy to mess it up |
| 18:36 |
VanessaE |
(it's an older version of the map before the structure to the right was finished) |
| 18:36 |
VanessaE |
60fps in this map. |
| 18:36 |
sapier |
I guess 60 is same as 0.3? |
| 18:37 |
VanessaE |
yes |
| 18:37 |
|
Zeitgeist_ joined #minetest-dev |
| 18:37 |
VanessaE |
like I said, today my computer wants to make a big liar out of me. |
| 18:37 |
sapier |
I guess this prooves 0.4 not having a regression but 0.4 design to be bad for features that have been added |
| 18:38 |
sapier |
yet 0.4 design is same as 0.3 design ;-) |
| 18:38 |
sapier |
no VanessaE it's good we did this investigation so we know we should be extremely carefull to add more complexity to our sceens as we already hit performance borders of our engine design |
| 18:39 |
sapier |
now where are the 3d engine guys we need a better engine design! ? ;-) |
| 18:41 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2001:40:26%20PM.png |
| 18:41 |
sapier |
what does 934 actually do? |
| 18:41 |
VanessaE |
60 fps in this shot, exactl same map files, roughly the same position, pitch and yaw, and I made to load up as much map as I could possily expect to see in each case. |
| 18:42 |
sapier |
but obviously different blocks loaded |
| 18:42 |
VanessaE |
you can't tell me that it takes 8 times as much GPU power to display the "real" world as it takes to display the "no content" world, since the GPU doesn't really give a shit what it is displaying |
| 18:42 |
sapier |
my best guess is this is a clipping issue |
| 18:43 |
VanessaE |
clipping? |
| 18:43 |
sapier |
hidden things beeing rendered/processed where they shouldn't be processed |
| 18:43 |
VanessaE |
I figured that's what you meant. |
| 18:44 |
sapier |
actually the gpu gives a lot if it has to display 4*100*x or 400*100*x polygons ;-) |
| 18:44 |
VanessaE |
under that black street is a bunch of heavy nodebox-based items (pipes, mesecons, some other stuff). If I can't see it, the GPU shouldn't be wasting its time with it |
| 18:45 |
VanessaE |
it's the only possible explanation. |
| 18:45 |
sapier |
yes it shouldn't be wasting the time but who is actualy building the scene? that's not done by gpu |
| 18:46 |
VanessaE |
well sure, but surely the CPU isn't sitting there building and sending meshes constantly is it |
| 18:46 |
ShadowNinja |
I've tried inserting the function in multiple places... sapier: Where should I put the function given this stack? <return value = nil><table><are1><arg2>...<argN> |
| 18:47 |
VanessaE |
(as in re-sending the whole local map for every frame) |
| 18:47 |
sapier |
I don't know I havent done much with 3d engine by now |
| 18:47 |
ShadowNinja |
arg1* |
| 18:47 |
sapier |
shadow I'm not exactly sure I did understand lua stack fully I'm far from qualified to give errro free answers ;-) |
| 18:48 |
* ShadowNinja |
tries using rand(1, lua_gettop(L)) |
| 18:48 |
sapier |
if I would try to fix this I would have to do it by trial and error to learn more about stack behaviour too |
| 18:49 |
sapier |
LOL |
| 18:49 |
sapier |
are you crazy? |
| 18:49 |
sapier |
you do understand what a stack is shadow? |
| 18:50 |
sapier |
those numbers you get from lua_gettop() are quite similar to the memory adresses you see in debuger backtrace |
| 18:51 |
ShadowNinja |
sapier: Yes, I have a basic understanding of how the Lua stack works. |
| 18:51 |
sapier |
you can't get a random memory address and expect it do do anything sane |
| 18:51 |
ShadowNinja |
sapier: Yes, that was a joke. ;-) |
| 18:51 |
sapier |
ohhhhhh .... ok you got me |
| 18:54 |
sapier |
who did add those vbo things? |
| 18:54 |
VanessaE |
pilzadam |
| 18:55 |
sapier |
is there a way to restore old behavior? 0.4 crashes in st_draw_vbo (inside of 3d driver) on my (outdated) ati while 0.3 didn't |
| 18:58 |
PilzAdam |
are you using my vbo branch? |
| 18:59 |
sapier |
no thought those things have already been merged? |
| 19:00 |
PilzAdam |
there are memory leaks, and we havent found a way to fix them |
| 19:01 |
VanessaE |
PilzAdam: Taoki would tell you those alleged memory leaks aren't as feared. |
| 19:01 |
Taoki |
Actually I thought they're fixed |
| 19:01 |
VanessaE |
however there is a performance drop over time as old data stacks up instead of being discarded, but that's not exactly a memory leak. |
| 19:02 |
Taoki |
If the memory isn't completely abandoned and forgotten there, it's likely not a memory leak per say. Still not desired of course... though IMO not as drastic either |
| 19:02 |
sapier |
hmm I guess there is something else that has changed in 0.4 causing it to crash on not quite fresh amd mobile gpu |
| 19:04 |
sapier |
https://github.com/minetest/minetest/issues/984 the stack of crash it's 100% reproduceable |
| 19:12 |
VanessaE |
sapier: Fisher-Price version: All game content present, only the texture files have been deleted, forcing the engine to render flat, basically-textureless meshes. 28 fps, view range of 129: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011052013%20-%2002:11:09%20PM.png |
| 19:13 |
VanessaE |
and that's after flying up and down a bit to make sure what's under the street is loaded, |
| 19:13 |
VanessaE |
this proves conclusively that my texture pack is NOT the cause of the regression. |
| 19:13 |
VanessaE |
there's just no way in hell that a high end GPU should render that ^^ at anything less than 60 fps and a 300m view range. |
| 19:14 |
sapier |
no I didn't expect the texture pack to be source of slow down imho it's HOW engine renders nodeboxes |
| 19:14 |
VanessaE |
people have claimed to me before that my texture pack is the cause. |
| 19:14 |
VanessaE |
I wanted to prove it was not. |
| 19:14 |
sapier |
I assume if you remove all nodeboxes it's gonna be as performant as 0.3 |
| 19:14 |
VanessaE |
you know that randomly-colored world almost looks "kid friendly" doesn't it? :) |
| 19:15 |
sapier |
textures will only matter if you reach limit of video memory as most people have at least 256mb you need big texture packs |
| 19:15 |
VanessaE |
right |
| 19:16 |
sapier |
yes it's a interesting look without textures :-) |
| 19:16 |
VanessaE |
though without texture compression, it's a lot easier to hit that ceiling that you might think. |
| 19:16 |
sapier |
yes maybe ... yet that's another issue and for sure not a "regression" ;-) |
| 19:16 |
VanessaE |
right |
| 19:17 |
sapier |
a regression is a bug that wasn't there before ... whatever causes that slowdown was there in 0.3 too without nodebox it hasn't been revealed |
| 19:18 |
VanessaE |
well at any rate, I've done about all I can with these screenshots. |
| 19:19 |
sapier |
yes I guess now it's up to the engine guys to find out why our engine can't handle those additional faces added by nodeboxes |
| 19:19 |
sapier |
but I don't exactly know who the "engine guys" are |
| 19:31 |
|
proller joined #minetest-dev |
| 19:42 |
proller |
934 is good |
| 19:43 |
proller |
but need to default alias |
| 19:48 |
VanessaE |
menawhile, will someone PLEASE do something about the G*d-awful-slow texture extrude routine? I've got a few 512px textures that, together, take about 1 full minute to render by themselves |
| 20:02 |
ShadowNinja |
Is there any reason not to add Lua 5.2 support? |
| 20:03 |
VanessaE |
it will break some mods, it's not 100% backward compatible to 5.1 |
| 20:03 |
VanessaE |
other than that, no :P |
| 20:03 |
VanessaE |
of course luajit is basically only 5.1 |
| 20:04 |
PilzAdam |
ShadowNinja, we want to be sure that a mod runs on every Minetest build |
| 20:04 |
PilzAdam |
different Lua versions just make things complicated |
| 20:06 |
ShadowNinja |
Hmmm, LuaJIT compatability may be an issue. But Lua 5.2 is about 99% compatible, and you shouldn't depend on depreciated Lua functions anyway. |
| 20:06 |
sapier |
what are those 1% |
| 20:06 |
sapier |
? |
| 20:07 |
VanessaE |
with my luck, that 1% would include every mod I've written :P |
| 20:11 |
ShadowNinja |
Ah, no, we can use -DLUAJIT_ENABLE_LUA52COMPAT |
| 20:11 |
sapier |
does 5.2 have any benefits to 5.1? |
| 20:11 |
ShadowNinja |
Although we have to check the system library to make sure it is built wit that, or build our own. |
| 20:12 |
ShadowNinja |
sapier: Yes, eg, __len works and other metamethods were added. |
| 20:12 |
sapier |
what does __len do and what metamethods are you talking about |
| 20:13 |
sapier |
reading "meta" I always think "shit yet more things to prohibit when implementing client side lua" |
| 20:13 |
ShadowNinja |
sapier: __len returns a objects length(when using #o) also __lt __le __pairs __ipairs... |
| 20:14 |
sapier |
whats lenght of an arbitrary object? |
| 20:15 |
sapier |
yet those things shouldn't be a cause to not add it yet what are those incompatible differences ppl talk about? |
| 20:15 |
ShadowNinja |
sapier: Whatever you define it as, eg the length of a vector is sqrt(x^2+y^2+z^2). |
| 20:16 |
ShadowNinja |
unpack was moved to table.unpack(we can alias it if it isn't already)... |
| 20:16 |
sapier |
ok so a nice to have ... still I'm more interested in things that don't work |
| 20:16 |
ShadowNinja |
math.mod and string.gfind were removed. |
| 20:18 |
ShadowNinja |
goto isn't a valid variable name anymore(pretty non-important). |
| 20:18 |
|
BlockMen joined #minetest-dev |
| 20:18 |
sapier |
now I'm against 5.2 |
| 20:18 |
ShadowNinja |
http://www.lua.org/work/doc/manual.html#8 |
| 20:18 |
ShadowNinja |
Why so? |
| 20:19 |
sfan5 |
hm |
| 20:19 |
sapier |
if goto is not a valid variable name it's most likely added and I hate languages supporting goto for code style issues |
| 20:20 |
sfan5 |
__lt, __le and __len metamethods allow shit like a < #b < (foo > bar) do things nobody understands, don't they? |
| 20:20 |
sfan5 |
+to |
| 20:20 |
sapier |
most likely |
| 20:21 |
ShadowNinja |
Yes, but that doesn't mean you have to use them. |
| 20:22 |
ShadowNinja |
And that isn't the only feature added. |
| 20:22 |
ShadowNinja |
Lua 5.2's goto if fairly limited to prevent unreadable code. |
| 20:23 |
sapier |
I'm not concerned about things I use but about things other mods do |
| 20:24 |
VanessaE |
GOTO \:D/ |
| 20:24 |
sapier |
goto is for people just starting to learn programming only |
| 20:25 |
sapier |
or hardware developers actually writing nice assembler code with c |
| 20:25 |
|
ImQ009 joined #minetest-dev |
| 20:25 |
ShadowNinja |
goto can be usefull, eg to jump out of nested loops. |
| 20:26 |
proller |
sapier, or for complex algorithms |
| 20:27 |
ShadowNinja |
Although I personall haven't used it yet. |
| 20:27 |
ShadowNinja |
+y |
| 20:27 |
sapier |
actuall NO you don't need goto for complex algorithms unless you actually need it to prevent others from maintaining your code |
| 20:27 |
proller |
no. |
| 20:27 |
proller |
some things is very hard to write without goto |
| 20:27 |
proller |
they very rare, but exist |
| 20:28 |
sapier |
so 99.9% goto makes code worse while it improves in 0.1% ... I'll take that 0.1% |
| 20:29 |
proller |
most peoples do not know how use goto |
| 20:31 |
sapier |
that doesn't stop them from using it |
| 20:31 |
ShadowNinja |
sapier: You assume that because goto is available everyone will use it to write unreadable code. |
| 20:31 |
proller |
lets start party: #983 #980 #956 #895 #892 |
| 20:31 |
sapier |
I learned the hard way if it can be done bad it will be done bad yet I'm still looking for a must have feature in 5.2 justifying to add it |
| 20:32 |
proller |
#983 is simplests |
| 20:33 |
sapier |
wtf they use goto to implement break ... |
| 20:37 |
sapier |
ok I assume most things in 5.2 are acceptable ... I'm a little bit concerned about the bitoperations ... those could result in different calculation results |
| 20:37 |
ShadowNinja |
sapier: Look for one here: http://lua-users.org/wiki/LuaFiveTwo |
| 20:38 |
ShadowNinja |
Not sure what you mean, but LuaJIT has BitOp if you need it. |
| 20:38 |
sapier |
http://www.inf.puc-rio.br/~roberto/talks/novelties-5.2.pdf this is better |
| 20:39 |
* ShadowNinja |
shrugs |
| 20:43 |
sapier |
but shadow don't we have enough bugs to fix do we really need to add a new source of unknown bugs? |
| 20:45 |
sapier |
983 seems to be fine |
| 20:45 |
kahrl |
I don't see any problem with goto used as in "goto fail; ... fail: error handling code" |
| 20:46 |
kahrl |
it's not harder to understand than "break" or exception handling |
| 20:47 |
sapier |
goto this; goto dothat; goto antotherthingbetweenthisandthat |
| 20:48 |
sapier |
it's not the legit cases goto is feared for but all those silly usages |
| 20:48 |
kahrl |
you can write functions with 42 arguments |
| 20:48 |
kahrl |
do we ban functions? |
| 20:48 |
sapier |
yet I'll not veto for goto It's useless to open up that discussion again |
| 20:49 |
kahrl |
well I guess the_game makes it look like we ban functions ;-) |
| 20:50 |
sapier |
true ... we should add a rule "DO NEVER EVER INCREASE LINE NUMBER OF THE_GAME" ... so everyone is forced to create those functions that should be there |
| 20:51 |
sapier |
kahrl do you agree to 983 too? |
| 20:55 |
proller |
next not-very-complex thing: #980 |
| 20:55 |
|
Zeg9 joined #minetest-dev |
| 20:56 |
sapier |
I'm not sure about auto respawn |
| 20:57 |
proller |
bots useless without it |
| 20:57 |
sapier |
yes but bots are a debug feature only |
| 20:58 |
proller |
in my server self killing is fun, and respawn message is annoying |
| 21:01 |
sapier |
we should add n new client side settings page |
| 21:01 |
sapier |
it is client side only isn't it? |
| 21:01 |
proller |
yes |
| 21:01 |
proller |
but setting - its for other pull |
| 21:03 |
sapier |
I still dislike that pull it doesn't stick to the rule "one change one commit" and those changes are neither just a small cleanup/bugfix nor related |
| 21:04 |
proller |
split it 3 pulls? |
| 21:04 |
sapier |
we'd add auto_respawn setting with commit message "null driver fixes" ;-( |
| 21:05 |
sapier |
I think 2 are enough everything else seems to be performance improvement |
| 21:05 |
proller |
autorespawn, /0 fixes, performance |
| 21:06 |
proller |
but no |
| 21:06 |
sapier |
is it correct to use 1 instead? |
| 21:06 |
proller |
yes |
| 21:06 |
proller |
all about make bots possible |
| 21:06 |
sapier |
yes but don't you hide errors by doing it that way? |
| 21:07 |
proller |
doing everything hides errors |
| 21:07 |
proller |
simpler do nothing |
| 21:07 |
sapier |
I'm not talking about fixing but usually a division by zero is a bug |
| 21:08 |
sapier |
in this case you'd just divide by one which hides the actual bug "dividion by zero" |
| 21:08 |
proller |
this bug only for 0-sized display |
| 21:10 |
sapier |
isn't tiledef[j].animation.aspect_w sent by server? |
| 21:11 |
proller |
maybe it calculated |
| 21:14 |
sapier |
line 137 it's from server so yes it shouldn't crash ... if I remember correct 1 is default value on server side too ... you should check this is true and add a comment why it's safe to assume 1 in case of 0 |
| 21:18 |
proller |
137? |
| 21:18 |
proller |
all this checks saves from crash |
| 21:19 |
sapier |
nodedef.cpp there are the de/serialization functions so it's sent |
| 21:19 |
sapier |
yes but you still change a value transmitted by server |
| 21:20 |
proller |
i make /x?x:1 |
| 21:20 |
|
EvergreenTree joined #minetest-dev |
| 21:20 |
proller |
no matter from where x |
| 21:21 |
sapier |
you can only do this if you're sure 0 is not a valid value for x ;-) |
| 21:22 |
proller |
0 always invalid in y/x case, also y%x |
| 21:23 |
sapier |
yes but you need to check if that variable is used ONLY there if you fix it there and other locations use 0 you create a inconsistent state within client |
| 21:24 |
sapier |
so if you're sure 0 is invalid you could fix it at deserialization location to ensure noone ever uses 0 as it's value |
| 21:24 |
proller |
i need join all my pulls in one... |
| 21:25 |
sapier |
why do you always merge things not related to each other in a single commi |
| 21:25 |
sapier |
t |
| 21:25 |
proller |
becausse i trying to make one thing. here was working bot |
| 21:25 |
proller |
in other pulls - liquid-weather stuff |
| 21:26 |
proller |
sometimes i cant change one line in separate pulls |
| 21:26 |
sapier |
I'm not gonna agree to multi commits if those things aren't at least related or bugfixes not changeing behaviour |
| 21:26 |
proller |
also need updating 1-2-3- months every |
| 21:27 |
sapier |
so if you want to get them merged you're free to ask someone else to agree |
| 21:28 |
sapier |
I'm not sure what you name your pulls but I feel the name most time doesn't reflect the actual changes |
| 21:29 |
sapier |
no offence maybe this is due to language missmatch only |
| 21:29 |
proller |
because i usually start from one thing, and add more in next 3 months |
| 21:30 |
sapier |
956 --> no, imho feature enhancement for 0.4.9 |
| 21:31 |
sapier |
I do so too proller but if you do completely different things create a different pull request ... I know it's anoying to work with different minetest trees not containing other fixes |
| 21:32 |
proller |
my all completely different things in different pull requests |
| 21:32 |
sapier |
yes but at lest this one looks like a "collected various fixes" commit ;-) |
| 21:33 |
sapier |
maybe you should call it that way |
| 21:38 |
sapier |
895, there's no need to change default max user value for liquid levels |
| 21:38 |
proller |
every server can work with 50+ clients |
| 21:39 |
proller |
this value was decreased from 100 because current servers unplayable at 10+ players |
| 21:39 |
sapier |
it's not related to the fix don't try to push changes like that as trojan horses |
| 21:39 |
sapier |
I think 15 is to small to yet it's not to be changed in this special commit ;-) |
| 21:39 |
proller |
no problem, i will remove this line |
| 21:40 |
sapier |
#max_simultaneous_block_sends_server_total = 100500 if the comment for this line is right I don't think that number is sane |
| 21:41 |
proller |
i can remove this variable |
| 21:41 |
proller |
its only for lag |
| 21:41 |
sapier |
what is it supposed to do? |
| 21:42 |
proller |
to not send blocks if too many players |
| 21:43 |
sapier |
is it actually possible to send that many blocks? |
| 21:44 |
proller |
it limited by max_players*max_simultaneous_block_sends_per_client |
| 21:45 |
sapier |
it's good style to remove unused variables so yes better remove it |
| 21:56 |
ShadowNinja |
sapier: #971 fixes #910? |
| 21:58 |
sapier |
yes but it needs as much testing as possible |
| 21:59 |
ShadowNinja |
sapier: It works under both Windows and Linux? |
| 21:59 |
sapier |
tested in linux windows mingw build and windows vs2012 build |
| 22:12 |
ShadowNinja |
Ok, then I agree with it. We should be able to relese 0.4.8 soon after that. |
| 22:13 |
sapier |
no we need at least 884 and maybe 977 or the httpfetch variant of fixing that bug |
| 22:18 |
kahrl |
sapier: sorry, I was gone, anyway doesn't matter now does it ;) |
| 22:19 |
kahrl |
I'd have said to split the commit into two but meh |
| 22:19 |
sapier |
which commit? |
| 22:19 |
kahrl |
https://github.com/minetest/minetest/pull/983 |
| 22:20 |
sapier |
yes but those changes are that obvious correct no need to even mention ;-) |
| 22:20 |
|
Gethiox4 joined #minetest-dev |
| 22:20 |
kahrl |
well they might make it so that #862 needs a rebase |
| 22:21 |
kahrl |
no big deal anyway... |
| 22:21 |
kahrl |
I'll have to merge the useragent thing into httpfetch somehow when I have time |
| 22:21 |
kahrl |
aka: in a year :P |
| 22:22 |
sapier |
kahrl we need httpfetch or my async changes for 0.4.8 |
| 22:22 |
kahrl |
yes |
| 22:22 |
kahrl |
I have no idea which one would be preferable |
| 22:22 |
kahrl |
or a preference |
| 22:23 |
sapier |
so either you should complete it or review the async things (which I intend to extend in 0.4.9 for scriptapi usage) |
| 22:23 |
kahrl |
I have no time to do either of those |
| 22:23 |
kahrl |
but there's not much that needs to be done to finish httpfetch, any dev could probably do it |
| 22:23 |
sapier |
ok so someone else needs to check the async things |
| 22:23 |
kahrl |
more testing would probably be nice |
| 22:24 |
sapier |
ok if it's almost done I probably have a look at it |
| 22:24 |
kahrl |
list of what needs to be done in httpfetch: http://irc.minetest.ru/minetest-dev/2013-11-04 at the top |
| 22:24 |
kahrl |
plus the useragent thing |
| 22:24 |
sapier |
yet I guess I'd be a little bit biased ;-) |
| 22:27 |
sapier |
I guess async could use httpfetch too so maybe it's just removing the special serverlist handling from httpfetch |
| 22:27 |
kahrl |
yeah that could work |
| 22:28 |
sapier |
I'd prefere the generic async aproach to special lua api calls done async |
| 22:29 |
sapier |
in best case we can do anythin async after cleaning up minetests internal datastructures |
| 22:29 |
sapier |
yet that's quite a long way to go atm |
| 22:30 |
kahrl |
this probably means some API breakage in the future related to APIs that can be called from async, locking, etc... as long as it's only in the mainmenu, no problem at all |
| 22:31 |
sapier |
I'd prefere without api breakage |
| 22:31 |
kahrl |
if the old api can be supported cleanly, sure |
| 22:32 |
sapier |
yes of course it's to early to tell I'd add the calls one by one |
| 22:32 |
sapier |
as done in mainmenu there are some calls missing there too |
| 22:32 |
sapier |
but I guess calling a fileselect dialog from async never will be possible it'd be insane |
| 22:33 |
kahrl |
it could be done with fork() ;) |
| 22:34 |
sapier |
*g* not exactly usefull ;-) |
| 22:52 |
|
BlockMen5233 joined #minetest-dev |
| 22:55 |
|
mrtux joined #minetest-dev |
| 23:02 |
zat |
ping celeron55 |
| 23:08 |
|
troller joined #minetest-dev |
| 23:15 |
|
BlockMen left #minetest-dev |
