| Time |
Nick |
Message |
| 00:02 |
sapier |
but I don't actually care about that feature very much iqualfragile_, just write an issue for animals_modpack and find some supporters, I'm gonna change it as soon as ... lets say 3 ppl request it |
| 00:02 |
iqualfragile_ |
k |
| 00:02 |
iqualfragile_ |
sapier: but you should be able to fight |
| 00:02 |
iqualfragile_ |
it allso jumps waay to high |
| 00:03 |
sapier |
:-) its supposed to jump high it's intended to make you faster ;-) |
| 00:04 |
sapier |
fighting? a ostrich isn't riding military ;-) |
| 00:04 |
sapier |
but write a feature request for this too |
| 00:05 |
iqualfragile_ |
but ust look at it when somebody rides it, it jumps like 10 times its height |
| 00:06 |
sapier |
10 times? hmm it's only supposed to jump about 2 nodes |
| 00:06 |
iqualfragile_ |
it realy looks like 10 times |
| 00:22 |
kahrl |
any idea about #944? |
| 00:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/944 |
| 00:22 |
kahrl |
when I try it I observe something different |
| 00:22 |
kahrl |
no item is lost, but some items are put into the furnace's output slots which the callback is supposed to prevent |
| 00:23 |
kahrl |
some items = the stack I swapped the furnace output with |
| 00:23 |
ShadowNinja |
Would it be possible to add a "holding" stack? |
| 00:24 |
kahrl |
I was wondering that a while ago but for some reason decided against it |
| 00:24 |
kahrl |
I don't remember why, maybe compat? |
| 00:24 |
sapier |
kahrl seems to be no compat month so maybe rething about it ;-) |
| 00:25 |
VanessaE |
kahrl: try it with the circular saw some time. |
| 00:25 |
VanessaE |
you'll see the effect much more readily. take any item from the circular saw's output slots, drop it on any item in your inventory, and that item in your inventory is deleted. |
| 00:26 |
ShadowNinja |
After 0.4.9 I'd like to get the protocol fixed, and while we're at it we may as well break everything (Except the map format) |
| 00:26 |
VanessaE |
ShadowNinja: I believe I put it more succinctly: "just blow it all to hell" :) |
| 00:26 |
kahrl |
if the reason was compat it was map compat and not protocol compat, I'm pretty sure |
| 00:26 |
VanessaE |
(may have been in private) |
| 00:27 |
sapier |
if we wanna do all those changes maybe we should setup a 0.5 experimental branch? |
| 00:27 |
sapier |
network lib as well as protocol change ... i guess core wont be playable for quite some time |
| 00:28 |
ShadowNinja |
kahrl: The holding slot wouldn't be saved to the map. It wouldn't be saved at all. (Or maybe to the playerfile) |
| 00:28 |
sapier |
or at least suffer of major regressions |
| 00:28 |
kahrl |
ShadowNinja: it must be saved |
| 00:28 |
kahrl |
what if the server goes down while you hold some precious item? |
| 00:28 |
sapier |
wow ... I just joined a server transferring 158mb textures in a single shot |
| 00:29 |
ShadowNinja |
Alright, playerfile then. But you can keep it compatible by making the field optional. |
| 00:29 |
ShadowNinja |
sapier: With your tweaks, enet, or remote_media? |
| 00:30 |
sapier |
mine ... and it's compatible to 0.4.8 |
| 00:31 |
ShadowNinja |
sapier: What was the transfer speed? |
| 00:31 |
sapier |
no idea let me check again |
| 00:32 |
kahrl |
yeah, so a holding slot can be added in a way that is compatible with old maps |
| 00:32 |
kahrl |
it would temporarily break mods such as bones |
| 00:35 |
kahrl |
there should really be a method InvRef:get_lists that mods like bones could use |
| 00:36 |
ShadowNinja |
^ I proposed that a while ago. |
| 00:36 |
kahrl |
what happened to it? |
| 00:37 |
sapier |
ShadowNinja: do you have any idea how to measure this within minetest? |
| 00:37 |
PilzAdam |
kahrl, IIRC you said it doesnt fit the callbacks structure we have currently (re: "holding stack") |
| 00:37 |
Exio4 |
can't you use iftop? |
| 00:37 |
ShadowNinja |
I didn't have the skill to code it, so I was ignored. I might be able to code it now. |
| 00:37 |
Exio4 |
implement it in x86 ASM |
| 00:37 |
ShadowNinja |
sapier: Nope, media_size / time? |
| 00:38 |
sapier |
not verry accurate but might work |
| 00:38 |
kahrl |
PilzAdam: it's honestly been a while since I worked with those callbacks so that could be true |
| 00:41 |
kahrl |
btw, challenge: find a way to keep a small amount of items on death with minetest_game (bones) in survival mode |
| 00:41 |
kahrl |
not counting the items stored in the bones chest |
| 00:42 |
sapier |
raw about 2 - 2.5Mb with spiles up to 16Mb and down to 1Mb (starting server) |
| 00:42 |
sapier |
I'll try from separate instance too |
| 00:44 |
|
Miner_48er joined #minetest-dev |
| 00:46 |
|
bas080 joined #minetest-dev |
| 00:48 |
sapier |
rough calculations from start to enter game results in about 0.8MB actual media transfere |
| 00:48 |
sapier |
per second of cours |
| 00:53 |
|
us{0gb joined #minetest-dev |
| 00:54 |
|
us{0gb left #minetest-dev |
| 00:55 |
|
smoke_fumus joined #minetest-dev |
| 01:08 |
|
smoke_fumus joined #minetest-dev |
| 01:13 |
ShadowNinja |
Hmmm, not bad, but if that's on a local server it could certainly be a lot faster. |
| 01:17 |
sapier |
of course, 16 bit sequence numbers are a major problem |
| 01:18 |
sapier |
I can't use the whole 16 bit (32mb) in order to be able to detect stall packets, but this way I get major slowdowns on packet loss |
| 01:18 |
sapier |
and lack of cumulative ack is another issue |
| 01:19 |
sapier |
both can't be added in compatible way |
| 01:27 |
ShadowNinja |
Is it possible to add these tweaks AND enet/TCP? The legacy code would be removed after one stable release, so dev servers wouldn't suddenly lose most of their users and we would have a very fast connection. |
| 01:28 |
sapier |
some of them yes others ... no way, at least enet doesn't have the 16 bit limitation ... no idea if they have cummulative acks |
| 01:29 |
sapier |
ShadowNinja switching to enet is a hard cut, no chance to support both same time |
| 01:29 |
sapier |
synchronizing enet peers and original peers is a no-go |
| 01:30 |
ShadowNinja |
:-| |
| 01:30 |
VanessaE |
then it's a hard cut, as you put it, that has to be done at the 0.5.0 release |
| 01:30 |
VanessaE |
imho |
| 01:30 |
sapier |
both have their own peer handling a well as brodcast support, we'd need to sync it |
| 01:31 |
VanessaE |
that was supposed to be the "this breaks everything" release |
| 01:31 |
sapier |
yes imho there's no chance to do a enet enabled 0.4 version |
| 01:37 |
ShadowNinja |
Well, if it's a "this breaks everything" we should really do a major version increment. |
| 01:37 |
VanessaE |
yeas |
| 01:37 |
VanessaE |
-a |
| 01:37 |
sapier |
you really want to use 1.0.0 for a all unstable version? ;-) |
| 01:38 |
VanessaE |
wait, a MAJOR version increment? |
| 01:38 |
|
smoke_fumus joined #minetest-dev |
| 01:38 |
VanessaE |
O_O |
| 01:38 |
VanessaE |
I read that as "major" (lower case m) |
| 01:38 |
ShadowNinja |
Yep. And .0 releases are expected to be unstable, .1 is the fixer release. |
| 01:38 |
VanessaE |
not Major (capital M) |
| 01:39 |
sapier |
first shot with enet and new packet format most likely will have some regressions |
| 01:39 |
* VanessaE |
gulps |
| 01:39 |
sapier |
and I still don't think it's worth it |
| 02:59 |
|
sapier left #minetest-dev |
| 03:15 |
ShadowNinja |
While implementing get/set_lists I noticed that read_items is wrong. lua_next does not necessarily return the next integer key, the items are unsorted. And do you think git/set_list(s) should push and accept arrays with entries missing? (empty stacks) |
| 03:23 |
|
Megaf_ joined #minetest-dev |
| 04:11 |
|
us{0gb joined #minetest-dev |
| 04:11 |
|
us{0gb joined #minetest-dev |
| 04:34 |
|
zat1 joined #minetest-dev |
| 04:34 |
|
hmmmm joined #minetest-dev |
| 05:06 |
|
KingsleyT joined #minetest-dev |
| 05:43 |
|
OldCoder joined #minetest-dev |
| 06:26 |
|
Weedy joined #minetest-dev |
| 06:56 |
|
darkrose joined #minetest-dev |
| 06:56 |
|
darkrose joined #minetest-dev |
| 06:59 |
|
Zeitgeist_ joined #minetest-dev |
| 07:10 |
|
mrtux joined #minetest-dev |
| 07:30 |
|
mrtux joined #minetest-dev |
| 08:25 |
|
blaaaaargh joined #minetest-dev |
| 09:27 |
|
darkrose joined #minetest-dev |
| 10:06 |
|
john_minetest joined #minetest-dev |
| 10:14 |
|
Weedy joined #minetest-dev |
| 10:29 |
|
EvergreenTree joined #minetest-dev |
| 10:45 |
|
proller joined #minetest-dev |
| 10:54 |
VanessaE |
I've gotten an email from someone using Windows 8.1 and Minetest "0.4.8" (presumable stable) who is getting bad allocation errors when he uses current git HEAD of my HDX texture pack. All the images seem fine here and they work fine for me in Linux. Opinions? |
| 10:55 |
specing |
Tell him to use Linux |
| 10:55 |
VanessaE |
heh |
| 10:55 |
specing |
No, seriously. |
| 10:56 |
VanessaE |
well I already told him that as best as I can figure, it's something in his PNG library, and that the imagery works fine for me. |
| 10:56 |
VanessaE |
he says it started after I ran everything through optipng recently. |
| 10:56 |
VanessaE |
says some stuff fails to be recognized as PNG at all now |
| 10:57 |
VanessaE |
or MT crashes with bad alloc. |
| 11:04 |
|
Jordach joined #minetest-dev |
| 11:04 |
|
Akien joined #minetest-dev |
| 11:05 |
VanessaE |
if someone wants to take a look, the above is all of the data I got from the guy who reported it. |
| 11:37 |
|
jin_xi joined #minetest-dev |
| 12:17 |
|
PilzAdam joined #minetest-dev |
| 12:57 |
|
iqualfragile joined #minetest-dev |
| 13:36 |
thexyz |
your Daily Dose of WAT |
| 13:36 |
thexyz |
goes here |
| 13:36 |
thexyz |
https://github.com/minetest/minetest/blob/master/src/particles.cpp#L224 |
| 13:39 |
|
Gethiox joined #minetest-dev |
| 13:51 |
|
PilzAdam joined #minetest-dev |
| 13:56 |
|
zat joined #minetest-dev |
| 13:58 |
kahrl |
line 378 too |
| 13:59 |
kahrl |
and 430 and 465 |
| 14:01 |
|
PilzAdam joined #minetest-dev |
| 14:01 |
kahrl |
err, not 430 |
| 14:05 |
kahrl |
https://gist.github.com/kahrl/8097603 |
| 14:05 |
|
Megaf joined #minetest-dev |
| 14:08 |
thexyz |
I can confirm, this solves the issue |
| 14:10 |
kahrl |
I'll push it then |
| 14:12 |
|
Taoki[laptop] joined #minetest-dev |
| 14:13 |
|
Taoki[laptop] joined #minetest-dev |
| 14:14 |
iqualfragile |
i think finite liquid needs to be removed, as it does not work at all |
| 14:14 |
kahrl |
apparently the glibc/libstdc++ vector::erase always just returns the argument, so it never caused any trouble for me |
| 14:14 |
|
proller joined #minetest-dev |
| 14:14 |
kahrl |
iqualfragile: even if you define the needed settings? |
| 14:16 |
iqualfragile |
iqualfragile: needed settings? |
| 14:16 |
iqualfragile |
oh, sorry i should have been more specific |
| 14:16 |
kahrl |
liquid_update = 0.2 |
| 14:17 |
kahrl |
maybe some others |
| 14:17 |
iqualfragile |
it does do something and beeing slow does not matter to me, but it does not make the water finite at all, in fact it even makes it a lot easier to produce a lot of water |
| 14:24 |
|
hmmmm joined #minetest-dev |
| 14:26 |
|
proller joined #minetest-dev |
| 14:32 |
|
troller joined #minetest-dev |
| 14:58 |
|
proller joined #minetest-dev |
| 15:07 |
|
john_minetest joined #minetest-dev |
| 15:09 |
|
Zeitgeist_ joined #minetest-dev |
| 15:09 |
|
Zeitgeist_ joined #minetest-dev |
| 15:23 |
|
john_minetest joined #minetest-dev |
| 15:47 |
|
VargaD joined #minetest-dev |
| 15:48 |
VargaD |
Hi |
| 15:48 |
VargaD |
minetest server (current dev, probably older releases also affected) use a lot of CPU even in idle, I think I have found the problem |
| 15:55 |
ShadowNinja |
The server list announcing has to be fixed. We can't release 0.4.9 with it broken. |
| 15:55 |
ShadowNinja |
proller: ^ |
| 15:56 |
proller |
broken what ? |
| 15:56 |
proller |
http threads ? |
| 15:57 |
VargaD |
MutexedQueue::pop_front shouldn't throw exception when the timeout reached, as m_event_queue calls it many times a second. Throwing exception in mass make the server use a lot of CPU. |
| 16:00 |
VanessaE |
ShadowNinja: regarding the server list, I'm at a58b47d0 and it works fine for me. |
| 16:00 |
thexyz |
so you broke it with httpfetch or some other commit and want proller to fix it? |
| 16:01 |
VanessaE |
of course I've got a patch by kahrl in there for denying connections to non-cURL clients: http://pastebin.ubuntu.com/6623924/ |
| 16:02 |
VanessaE |
but I don't think that's affecting the server list any |
| 16:07 |
VargaD |
it would be nice to use condition variables in mutexed queue, but jthead does not supoort it |
| 16:12 |
ShadowNinja |
VanessaE: I'm aware, but that didn't fix it for me. |
| 16:12 |
VanessaE |
huh. |
| 16:13 |
ShadowNinja |
proller mentioned knowing what was causing the issue. |
| 16:13 |
VanessaE |
ShadowNinja: maybe there's some leftover cruft from when shit went all weird before? |
| 16:13 |
VanessaE |
when you were trying to patch around it I mean |
| 16:13 |
ShadowNinja |
Well I recompiled it. |
| 16:13 |
VanessaE |
hrm |
| 16:14 |
ShadowNinja |
I didn't patch around it, I just waited, and when the solution didn't work I downgraded to before HTTPFetch. |
| 16:14 |
VanessaE |
oh ok |
| 16:15 |
VanessaE |
I wonder why it's working for me *confused* |
| 16:16 |
proller |
also threads still broken in freebsd |
| 16:16 |
ShadowNinja |
CURL's compiled in according to CMakeCache.txt. |
| 16:17 |
proller |
and i think windows will have lot of threads crashes |
| 16:19 |
|
Calinou joined #minetest-dev |
| 16:30 |
kahrl |
VargaD: sapier added semaphores a while ago, and we have events too |
| 16:30 |
kahrl |
condition vars could be implemented using those |
| 16:30 |
|
sapier joined #minetest-dev |
| 16:31 |
VargaD |
thanks, I try to solve that also after getting rid of exceptions |
| 16:31 |
kahrl |
have you seen https://github.com/minetest/minetest/pull/1054? |
| 16:32 |
|
proller joined #minetest-dev |
| 16:33 |
VargaD |
oh it is already solved, but still throw exception |
| 16:33 |
sapier |
1054 isn't merged as far as I remember |
| 16:34 |
sapier |
and I have to make a update for it push_front is usefull for some things too |
| 16:35 |
sapier |
btw don't even think about using a sharedbuffer from different threads |
| 16:36 |
sapier |
can someone tell me why it always has to be hard to reproduce a bug once you have proper instrumentalization in place to find it? |
| 16:38 |
kahrl |
that's a simple application of the Heisenberg principle |
| 16:38 |
VargaD |
:) |
| 16:40 |
sapier |
that bug is to obvious to be limited by plank quantum |
| 16:40 |
sapier |
I already know what is wrong just not how it becomes wrong |
| 16:40 |
VargaD |
which bug you are talking about sapier? |
| 16:41 |
sapier |
none within current minetest |
| 16:42 |
sapier |
I did some research about compatible fixing minetest network code and I have a nasty bug left where a incoming packet is queued that isn't even part of receive window ... thus it should cause an assert on inserting |
| 16:45 |
|
Gethiox joined #minetest-dev |
| 16:47 |
VargaD |
sapier: this pull request (https://github.com/minetest/minetest/pull/1054), shoudl solve my problem as the pop_front without arguments does not throw exception, and minetest use that most of the time |
| 16:49 |
sapier |
I intend to rename those functions to match the current minetest naming. I recently discovered NoEx suffix is used for those functions. I think I'll fix it this year |
| 16:50 |
sapier |
those meaning "functions not throwing exceptions" |
| 16:56 |
|
kaeza joined #minetest-dev |
| 16:58 |
sapier |
thexyz can you tell me where to get the bots you use for enet testing? |
| 17:00 |
thexyz |
sapier: proller has a neat script which spawns them, and a config file |
| 17:00 |
sapier |
is it available to public somewhere? |
| 17:00 |
thexyz |
http://pastebin.com/42EpMmjq http://pastebin.com/1fquswVv |
| 17:00 |
thexyz |
I'm not sure if it'll work with Minetest |
| 17:00 |
thexyz |
last time I tried it there were some division by zero errors |
| 17:01 |
thexyz |
but those are easy to fix, there was a pull by proller |
| 17:01 |
sapier |
lets have a try |
| 17:01 |
thexyz |
john_minetest: what do you mean by "chat size"? |
| 17:02 |
VargaD |
sapier: what it the problem with that patch? Can I help to solve it, it would be nice to see it merged. |
| 17:02 |
thexyz |
ah, font |
| 17:03 |
VargaD |
I made a few line hack that also solved the problem |
| 17:03 |
thexyz |
there's a problem with the font |
| 17:03 |
sapier |
john_minetest checkout all variants and platforms and make a suggestion valid for all of them ;-) |
| 17:03 |
* VanessaE |
mumbles... https://forum.minetest.net/viewtopic.php?id=4436 |
| 17:03 |
thexyz |
lol |
| 17:03 |
thexyz |
also non-freetype builds should just be set up to fail when compiling |
| 17:03 |
thexyz |
with an error message |
| 17:03 |
thexyz |
now that we've got readable fonts |
| 17:03 |
VanessaE |
...my build has freetype. |
| 17:04 |
thexyz |
so that no crazy package maintainers ever try to package the game without freetype |
| 17:04 |
VanessaE |
I just don't use that feature because ^^^^ is still more readable to me. |
| 17:05 |
|
NakedFury joined #minetest-dev |
| 17:06 |
sapier |
VargaD https://github.com/sapier/minetest/commit/1d73e545a70885cdab6e70a27ab014828ddf2afd these fixes plus renaming NE to NoEx |
| 17:06 |
sapier |
wait there's an additional fix to it |
| 17:08 |
sapier |
I'll fix it right now, looking for the changes is more time then fixing |
| 17:08 |
thexyz |
john_minetest: font with freetype? wat? |
| 17:08 |
VargaD |
oh nice and it also has the conditional variable |
| 17:09 |
VargaD |
thanks sapier |
| 17:10 |
sapier |
if you meak font bigger you need to check if foreign language texts mess up menu |
| 17:17 |
thexyz |
you can edit minetest.conf |
| 17:17 |
thexyz |
and make the font bigger for you |
| 17:22 |
VanessaE |
it only has two 'bulk' font sizes (the monospace and the proportional spaced setting) that work only with freetype |
| 17:23 |
VanessaE |
they DO work, but like my font, if made too large they tend to screw up the formatting of some menu elements. |
| 17:24 |
thexyz |
true |
| 17:25 |
thexyz |
if you only experience problems with the chat then we can have a separate font for chat? |
| 17:28 |
thexyz |
what's your screen DPI? |
| 17:30 |
sapier |
VargaD pushed the fixes have a try |
| 17:31 |
thexyz |
player names? |
| 17:31 |
thexyz |
they use irrlicht builtin font iirc |
| 17:31 |
thexyz |
not ttf one |
| 17:37 |
VanessaE |
some months ago someone gave me a patch to swap that out for a proper ttf font |
| 17:37 |
VanessaE |
lost it ages ago |
| 17:38 |
* VanessaE |
pokes kahrl ... wasn't it one of yours? |
| 17:38 |
thexyz |
ah, I had it somewhere |
| 17:38 |
thexyz |
but they were buggy |
| 17:50 |
|
Miner_48er joined #minetest-dev |
| 17:51 |
VanessaE |
didn't I say that when what we have now was still being coded? |
| 17:51 |
VanessaE |
but....as usual.... my concerns were ignored. |
| 17:51 |
thexyz |
why the hell isn't kahrl's formspec table merged? |
| 17:52 |
thexyz |
it's an awesome addition to the sucky ui we have |
| 17:52 |
VanessaE |
thexyz: because you didn't merge it? |
| 17:52 |
thexyz |
VanessaE: I can merge it to FM but that'd be a bit unfair |
| 17:52 |
jin_xi |
do eet |
| 17:52 |
VanessaE |
thexyz: you don't have merge access to upstream? |
| 17:52 |
thexyz |
VanessaE: I do but perhaps you should consult our wiki and development guidelines we have |
| 17:53 |
VanessaE |
I am well aware of the guidelines. |
| 17:53 |
thexyz |
I think they suck |
| 17:53 |
VanessaE |
and if you were aware of them then you'd know that, by virtue of him having coded it and you wanting it, it can be merged. |
| 17:53 |
thexyz |
we waste too much time finding more and more devs to agree on code and review |
| 17:53 |
VanessaE |
because you are bothj core devs. |
| 17:53 |
VanessaE |
-j |
| 17:53 |
thexyz |
I didn't review it though |
| 17:53 |
VanessaE |
that's not to say if the code is any good, I didn't review it either, |
| 17:53 |
thexyz |
and in the end the bugs like the one kahrl has fixed still get into the repo |
| 17:54 |
VanessaE |
bugs happen, it's a fact of coding,. |
| 17:54 |
VanessaE |
nothing can be done but fix them when they happen. *shrug* |
| 17:54 |
VanessaE |
(or ideally try to prevent them of course) |
| 17:54 |
VanessaE |
anyways |
| 17:56 |
VanessaE |
hah |
| 17:56 |
iqualfragile |
sapier: status of network fixing? |
| 17:59 |
thexyz |
john_minetest: http://i.imgur.com/9jl6j30.jpg please for casual discussion go to #minetest |
| 18:13 |
sapier |
iqualfragile a small bug is left that I'm tracking down right now (occurs about each 10-100th downloading of 170mb texture data) |
| 18:14 |
sapier |
I guess it's testable (not for benchmarking, there's code in there right now for detecting that bug causing some slowdown ... yet it's still ages faster then original code) |
| 18:16 |
sapier |
thexyz formspec table isn't merged because of you guys alwas starting json formspec discussion once formspec is mentioned ;-) this way we always forget about merging it ;-) |
| 18:18 |
VanessaE |
john_minetest: stress testing. |
| 18:19 |
sapier |
john_minetest I guess you got something wrong my comment for iqualfragile was about some educational just for fun work I'm doing right now |
| 18:21 |
sapier |
thexyz if everyone can merge everything and there are 10 ppl allowed to merge (and actively merging) you end up in pure chaos. I'll not tell this another 100 times but please try to imagine that a project like minetest needs some rules to exist... even if they're not as comfortable to each individual as his own one man show |
| 18:22 |
sapier |
no I'm waiting for iqualfragile to provide modstore texture pack api ... not sure if he has completed it yet |
| 18:22 |
proller |
do not give privs to peoples who can make chaos |
| 18:23 |
sapier |
proller so you're out? *just kidding* |
| 18:24 |
sapier |
but not joking, everyone can make chaos, each of us has a different way of thinking and different coding style (not talking about formating) ... without coordinated merging this will result in chaos no matter what you do |
| 18:25 |
thexyz |
sapier: what's the branch again? |
| 18:26 |
sapier |
https://github.com/sapier/minetest/tree/server_improvement |
| 18:27 |
sapier |
as I said if you're downloading a lot of data there's a corner case where a incoming packet is missqueued triggering a safety assertin |
| 18:27 |
proller |
coding style -> astyle |
| 18:27 |
sapier |
astyle is formating |
| 18:29 |
VanessaE |
proller: he means more like, do I name this function FooBar or foo_bar or fooBar, do I put all this stuff here in this file, or do I put them over here in this, this and this other file instead, blah blha |
| 18:29 |
VanessaE |
blah* |
| 18:29 |
sapier |
I was talking about the way of structuring your code e.g. if else cascades switches function usage instead of copy&paste ... |
| 18:29 |
VanessaE |
exactly |
| 18:30 |
proller |
WE NEED MORE MUTEXes! |
| 18:30 |
sapier |
there are myriards of different (correct) ways to do someting ... even more wrong ways of course |
| 18:30 |
VanessaE |
formatting goes hand-in-hand with one's coding style but is not, by itself, the definition of that style. |
| 18:30 |
VanessaE |
sapier: aw, you mean I can't cram it all onto one unreadable line or delete all my tabs???? sure, spoil my fun. |
| 18:31 |
sapier |
true minetest datastructures need to be reworked for thread safety just avoid locking everything as this will result in exactly oposit effect ;) |
| 18:32 |
proller |
old client still can connect to your new server ? |
| 18:32 |
sapier |
no formating is important too, but you can specify formating by defining a "coding style" document (the one noone wants to do) ... the other part of style can't be defined |
| 18:32 |
sapier |
yes proller |
| 18:33 |
sapier |
and will gain speed benefit too |
| 18:34 |
sapier |
case someone sees the bug in incoming reliable queue insertion prior me, please tell me ;-) |
| 18:34 |
proller |
bad idea split server.cpp and remake connection in one branch |
| 18:34 |
sapier |
it's not in same branch |
| 18:34 |
sapier |
my branch is just based upon that one |
| 18:35 |
sapier |
if I remember correct my server split patch is submitted as pull request too |
| 18:36 |
sapier |
https://github.com/minetest/minetest/pull/1056 that one proller |
| 18:39 |
|
proller joined #minetest-dev |
| 18:50 |
|
rsiska joined #minetest-dev |
| 18:54 |
|
NakedFury joined #minetest-dev |
| 19:12 |
hmmmm |
hrmmmmm |
| 19:13 |
hmmmm |
I dunno if we're really going to release on christmas |
| 19:13 |
hmmmm |
do you guys still want to? the commits since friday have all been bugfixes |
| 19:14 |
hmmmm |
what's wrong with the windows version..? |
| 19:17 |
|
thk joined #minetest-dev |
| 19:19 |
ShadowNinja |
The only serious bug that I can think of now is the broken serverlist announcing. |
| 19:19 |
|
deltib1 joined #minetest-dev |
| 19:20 |
ShadowNinja |
We CAN release be Christmas, but we should include that special thing... |
| 19:20 |
|
EvergreenTree joined #minetest-dev |
| 19:22 |
|
harrison___ joined #minetest-dev |
| 19:26 |
sapier |
hmmmm we don't even have an official freeze yet |
| 19:27 |
sapier |
but if current is stable this may not be an issue of course |
| 19:27 |
sapier |
proller where to find the changes for novideo output? |
| 19:28 |
sapier |
then there's no chance to do a release |
| 19:28 |
proller |
https://github.com/freeminer/freeminer |
| 19:28 |
sapier |
sorry wasn't specific about it where exatly(more or less) find the changes required? |
| 19:29 |
sapier |
something like a commit number or at least which files to look for it |
| 19:29 |
hmmmm |
john_minetest doesn't actually know if it's stable or not on windows |
| 19:29 |
hmmmm |
he's using an old build |
| 19:30 |
|
Taoki[laptop] joined #minetest-dev |
| 19:30 |
hmmmm |
it's helpful that you're testing and everything, but it'd be really nice if we could get reports or some information on these "crashes" |
| 19:30 |
hmmmm |
otherwise it's pretty useless |
| 19:31 |
sapier |
maybe just build a fresh clone |
| 19:31 |
sapier |
ok then maybe even telling about those crashes isn't usefull? ;-) |
| 19:32 |
|
Zeitgeist_ joined #minetest-dev |
| 19:32 |
hmmmm |
i think he's just trying to get it through to us that minetest has problems because we suck |
| 19:32 |
sapier |
proller I guess "silence" means you can't be more precise as "see your self in the mountains of code I touched"? |
| 19:32 |
hmmmm |
the next thing I'd expect john_minetest to say is "It doesn't matter, it's all broken anyway" |
| 19:33 |
hmmmm |
and I just said that information is completely and utterly useless |
| 19:33 |
thexyz |
sapier: do you expect him to go through all the commits because you're too lazy to? |
| 19:34 |
hmmmm |
it's even worse than useless, it's annoying because you talking about how everything is crashing drowns out the rest of the useful conversation |
| 19:34 |
proller |
sapier, it was in pull maybe month, and now it already outdate and broken |
| 19:34 |
sapier |
thexyz: I guess due to prollers commit messages I wont be capable of realizing which one contains those things |
| 19:34 |
hmmmm |
so please stop talking about issues here unless you're actually using the latest version and you have specific helpful information about the crashes |
| 19:34 |
hmmmm |
good day |
| 19:34 |
thexyz |
sapier: that's sad |
| 19:35 |
thexyz |
btw, I was working on colored chat a bit http://i.imgur.com/MHreKYc.png |
| 19:35 |
sapier |
that's why I keep telling "please work with community" not against it |
| 19:35 |
thexyz |
we're trying |
| 19:35 |
thexyz |
yet you always complain |
| 19:36 |
hmmmm |
minetest used to have colored chat |
| 19:36 |
hmmmm |
I don't know what happened to it though |
| 19:36 |
hmmmm |
there was a reason why it's not around now and you should ask celeron about that |
| 19:36 |
thexyz |
well, I'm fine with it not being in Minetest |
| 19:36 |
sapier |
ok to be fair the commit messages of freeminer aren't as bad as they used to be |
| 19:36 |
sapier |
but there's still some room for improvement |
| 19:36 |
thexyz |
just maybe someone is interesting in working on it? |
| 19:36 |
thexyz |
*interested |
| 19:37 |
thexyz |
for now it's really hacky and messy |
| 19:38 |
sapier |
hacky and messy is fine for private branches thexyz but once you push it upstream it needs to be clean, I know work to clean something isn't satisfying, a lot of work with no visible effect ... but it has to be done, and expecting others to do this isn't fair either |
| 19:39 |
celeron55 |
<+hmmmm> minetest used to have colored chat |
| 19:39 |
hmmmm |
john_minetest: again, see above. |
| 19:39 |
sapier |
singleplayer or server john? |
| 19:39 |
celeron55 |
what |
| 19:39 |
sapier |
can you create an issue posting the error log john_minetest? |
| 19:39 |
|
Akien joined #minetest-dev |
| 19:39 |
thexyz |
sapier: 'kay |
| 19:39 |
hmmmm |
john_minetest: an error log, a backtrace, etc.... |
| 19:40 |
proller |
hmmmm, i already post here gdb bt 2 or 4 times |
| 19:40 |
hmmmm |
celeron55: it didn't? |
| 19:40 |
celeron55 |
hmmmm: i'm pretty sure minetest has never had colored chat |
| 19:40 |
hmmmm |
celeron55: I distinctly remember you saying that there was colored chat which was removed |
| 19:41 |
ShadowNinja |
kahrl worked on colored chat, which wasn't pull-requested or merged. |
| 19:41 |
hmmmm |
I remember because I also remember making a comment that a lot of games have colored chat which eventually gets removed (e.g. starcraft, warcraft, so on) |
| 19:42 |
sapier |
hmmmm maybe you can see more from prollers backtraces I can only tell something bad is happening on thread kill. the strange thing is there shouldn't happen a thread kill at that very special action because all threads should've been stopped before |
| 19:42 |
sapier |
so thread kill is almost a nop |
| 19:42 |
celeron55 |
hmmmm: you've probably been dreaming or something |
| 19:42 |
sapier |
at least it's supposed to be |
| 19:42 |
hmmmm |
sapier, I haven't seen any of the backtraces |
| 19:42 |
hmmmm |
anyway |
| 19:42 |
kahrl |
ShadowNinja: iirc PilzAdam and I had a little "competition" one day when we both coded that feature |
| 19:42 |
hmmmm |
I recommend against making colored chat specifically |
| 19:42 |
thexyz |
why? |
| 19:42 |
sapier |
it's on freebsd I can't reproduce it |
| 19:42 |
kahrl |
only for the console though |
| 19:43 |
hmmmm |
because then you're going to make colored text specific stuff and not a more generalized text formatting spec |
| 19:43 |
ShadowNinja |
kahrl: Yes, I remember. |
| 19:44 |
hmmmm |
I personally recommend making TTF the default and then designing format specifiers that also include other things like foreground color, font name, font weight, italics, underline, and so on |
| 19:44 |
ShadowNinja |
This wouldn't be available in formspecs. |
| 19:44 |
hmmmm |
right so we need to find a way to fit it into formspec |
| 19:44 |
hmmmm |
if only we were using something like Lua tables we'd be able to shove it in a new field |
| 19:44 |
sapier |
thexyz the novideo feature for example would be nice to have in minetest too ... it's just not as nice as justifying to merge everything at once ;-) |
| 19:44 |
celeron55 |
so what about not pulling the spec out of our asses but using something known, like bbcode |
| 19:44 |
kahrl |
webkit[This is a field with <b>bold</b> text] |
| 19:44 |
ShadowNinja |
A new format is needed to do it nicely. |
| 19:45 |
thexyz |
sapier: I guess |
| 19:45 |
hmmmm |
if you'd like to do bbcode then sure, I guess that's fine |
| 19:45 |
celeron55 |
well anything will do that exists in this world |
| 19:45 |
hmmmm |
it's all up to you |
| 19:45 |
ShadowNinja |
hmmmm: We can use lua tables, and JSON for sending it. |
| 19:45 |
sapier |
And I'm almost sure (through I haven't looked at it) there's aren't millions of depencencys |
| 19:46 |
hmmmm |
sapier hates that idea for some reason |
| 19:46 |
hmmmm |
well the JSON implementation we use is really crappy |
| 19:46 |
hmmmm |
if we had a better JSON implementation then that would be great |
| 19:46 |
hmmmm |
this is something that's pretty far off |
| 19:47 |
hmmmm |
I'm just saying, the formspec revamp is still on the table |
| 19:48 |
sapier |
I'd have to look back for half a year but proller told to rewrite it by that time |
| 19:49 |
sapier |
and no json formspec is not on list, if ever we need to switch to a full blown gui description language and not do our own crap again in just another format |
| 19:49 |
hmmmm |
I don't see what's horrible about it |
| 19:49 |
hmmmm |
I mean you want to use some existing XML GUI description language |
| 19:50 |
hmmmm |
but do WE really need that |
| 19:50 |
sapier |
someone told me about the not invented her syndrom yesterday is there any real benefit of using json to formspec format? |
| 19:50 |
hmmmm |
yes... |
| 19:50 |
hmmmm |
formspec is inflexible |
| 19:50 |
sapier |
don't tell me about "readable" thats pure subjective interpretation |
| 19:50 |
hmmmm |
you can insert arbitrarily named fields |
| 19:50 |
hmmmm |
you have a single, consistent key value format |
| 19:51 |
hmmmm |
and yes it is more readable |
| 19:51 |
sapier |
you can't do this to json too if you don't modify the formspec parser too |
| 19:51 |
|
ImQ009 joined #minetest-dev |
| 19:51 |
hmmmm |
what I'd like to do is have the new formspec things alongside the old |
| 19:51 |
sapier |
what's use for a field not beeing translatable to a gui element? |
| 19:51 |
hmmmm |
huh? |
| 19:52 |
hmmmm |
look |
| 19:52 |
hmmmm |
JSON is just a means to an end |
| 19:52 |
sapier |
you said you can add a field to json easyly so what for do you want to add a new field? |
| 19:52 |
hmmmm |
because maybe we want to add font weight |
| 19:52 |
sapier |
json is just a format not more not less |
| 19:52 |
hmmmm |
or color |
| 19:52 |
hmmmm |
the thing is |
| 19:53 |
hmmmm |
JSON is just some way to represent objects |
| 19:53 |
sapier |
it's capable of storing arbitrary data that's a big benefit to current formspec (in general) ... but what benefit for gui will result from this ability? |
| 19:53 |
hmmmm |
we'll use that for serialization of formspecs over the network |
| 19:53 |
hmmmm |
in LUA we'd define the same objects using tables |
| 19:53 |
hmmmm |
the idea is not that we write a formspec in json |
| 19:53 |
hmmmm |
it's that the formspec 2.0 is an object that has properties and whatever |
| 19:53 |
sapier |
actually that's what people suggest here |
| 19:54 |
sapier |
write formspecs in pure json |
| 19:54 |
hmmmm |
well |
| 19:54 |
hmmmm |
that's not what I think is a very smart idea |
| 19:54 |
hmmmm |
there are a few key points I'd like to repeat: |
| 19:55 |
hmmmm |
1). this is not REPLACING formspec, we need the old formspec for compatibility |
| 19:55 |
hmmmm |
this is something NEW that we encourage people to use instead |
| 19:55 |
sapier |
we don't need anything for compatibility |
| 19:55 |
hmmmm |
2). the entire thing is not going to use JSON |
| 19:55 |
hmmmm |
only the serialization for network transmission |
| 19:55 |
ShadowNinja |
Me and proller suggested using Lua tables and either write_json or have the engine auto-convert them. |
| 19:56 |
hmmmm |
I don't understand why the user should ever do anything with JSON |
| 19:56 |
sapier |
my suggestion is either not change anything or really use a full featured gui description language ... any other case will hit limits again |
| 19:56 |
hmmmm |
a formspec element is an object |
| 19:56 |
hmmmm |
the formspec itself is an object |
| 19:56 |
hmmmm |
sapier, explain how this would fail |
| 19:57 |
ShadowNinja |
Well, the fornspec would be a array and the entries would be objects strictly speaking. |
| 19:57 |
sapier |
if I undestand correct you want to do the parsing on server transfer json to client and parse again there. Am I right about that? |
| 19:58 |
hmmmm |
yes you're right |
| 19:58 |
hmmmm |
and the actual formspec is just some object |
| 19:58 |
hmmmm |
not a string |
| 19:58 |
hmmmm |
json is nothing but merely a tool to serialize arrays and objects |
| 19:58 |
sapier |
and what exactly is better on parsing on server then on client? |
| 19:59 |
sapier |
btw current master really is broken, locks up on downloading textures ... this does not happen on 0.4.8 |
| 20:00 |
khonkhortisan |
For me it's broken with "no future with broken builtin async environment scripts" |
| 20:00 |
sapier |
async env is already shut down on downloading textures |
| 20:00 |
sapier |
no chance to do bad there |
| 20:04 |
iqualfragile |
sapier: you need to remind me from time to time, or write a bugtracker entery |
| 20:04 |
sapier |
and removing parallelity improvement isn't an option if minetest ever wants to achieve reasonable performance gain from multicore cpus ... so I guess we need to fix it ... instead of doing so we discuss about json formspec json maps json whatever |
| 20:06 |
kahrl |
sapier: do you know what state it locks up in? |
| 20:06 |
kahrl |
e.g. how many and which httpfetch requests are active |
| 20:06 |
sapier |
ni I'm investigating right now |
| 20:15 |
|
Gethiox joined #minetest-dev |
| 20:19 |
|
Calinou joined #minetest-dev |
| 20:21 |
|
proller joined #minetest-dev |
| 20:41 |
|
sapier1 joined #minetest-dev |
| 20:54 |
sapier1 |
ok that lockup is there in 0.4.8 too it occurs just less often ... seems to be a client side network protocol glitch |
| 21:02 |
|
Calinou joined #minetest-dev |
| 21:09 |
sapier1 |
can you please collect the crash logs, post it somewhere and collect links in a issue? especialy for multithreaded issues a single log often doesn't give a picture of the full issue |
| 21:12 |
proller |
try number 5: http://paste.org.ru/?77d33x |
| 21:13 |
sapier1 |
proller can you reproduce that one reliably? |
| 21:14 |
proller |
every run |
| 21:14 |
proller |
i can start game only with --disable-unittests |
| 21:14 |
sapier1 |
wait this is unit testing |
| 21:15 |
proller |
its everywhere |
| 21:15 |
proller |
in game |
| 21:15 |
proller |
in menu |
| 21:15 |
proller |
in disconnect |
| 21:15 |
proller |
in server shutdown |
| 21:16 |
sapier1 |
yes but that one is unit test |
| 21:16 |
sapier1 |
one by one proller |
| 21:16 |
proller |
okay, fix please this first |
| 21:17 |
kahrl |
http://curl.haxx.se/mail/lib-2006-10/0100.html |
| 21:17 |
sapier1 |
is this freeminer or minetest stable? |
| 21:18 |
kahrl |
apparently the curl multi example (which I based httpfetch on) does not account for a windows select() particularity |
| 21:18 |
proller |
minetest last commit |
| 21:18 |
kahrl |
which is that it returns error WSAEINVAL (10022) if all file descriptor sets are NULL |
| 21:19 |
sapier1 |
ugly ... bug may be within connection handling which I just (almost) fixed |
| 21:20 |
sapier1 |
interesting about this one is what is first, TestConnection::Run (this=0x7fffffffa1ef) at /usr/home/proller/minetest_test/src/test.cpp:1963 |
| 21:20 |
sapier1 |
seems to be a failing connection test |
| 21:21 |
sapier1 |
if that one deletese server and client Thread 2 and 1 those are follow up issues of broken shutdown |
| 21:23 |
|
harrison joined #minetest-dev |
| 21:27 |
sapier1 |
there are plenty of tools you just need to set them up |
| 21:27 |
sapier1 |
gdb and eclipse work (somehow) and of course visual studio works too |
| 21:27 |
sapier1 |
well I have issues with gdb too |
| 21:28 |
sapier1 |
be sure to use kepler ... or prior juno ... juno is just crap |
| 21:29 |
sapier1 |
and don't expect to instantly know what to do for eclipse it's like blender without consistent command design ... lots of features ... most of them not usefull for your current task |
| 21:30 |
ShadowNinja |
Comments? This includes a minor bugfix (modifying inventory lists could scramble them). http://ix.io/9uv |
| 21:31 |
sapier1 |
seems more like a feature enhancement it even adds new lua api (not documented either) |
| 21:31 |
|
proller joined #minetest-dev |
| 21:32 |
ShadowNinja |
Oh, oops. Yes, it's a feature with a bugfix that I notied along the way. kahrl: ^ |
| 21:34 |
sapier1 |
not sure if we really are in feature freeze right now if we are skip the feature for next version and merge the fix only |
| 21:36 |
sapier1 |
it's in different files so don't complain about too much splitting work ;-) |
| 21:37 |
|
AllegedlyDead joined #minetest-dev |
| 21:40 |
ShadowNinja |
<3 git-cola. But I'd like to get the whole thing in, I've been asking for this for a while, and kahrl wanted it. |
| 21:41 |
sapier1 |
I thought more about doing git add for the one file only but there are more ways to do this ... as usual |
| 21:41 |
sapier1 |
as I said in feature freeze adding a feature isn't a good idea ... but as usual noone made a clear decision if or if not |
| 21:41 |
ShadowNinja |
git-cola lets you select individual lines to stage and commit. IDK how actively developed it is. |
| 21:42 |
ShadowNinja |
We don't have a feature freeze yet. :-) |
| 21:43 |
sapier1 |
is httpfetch a config or compile time setting? |
| 21:43 |
ShadowNinja |
john_minetest: Stable doesn't have HTTPFetch. |
| 21:43 |
ShadowNinja |
(It does have a CURL remote_media system though, is that what you're talking about?) |
| 21:43 |
sapier1 |
dev has some rework of threads too so this is an additional possible source of error |
| 21:44 |
sapier1 |
and of course threading could trigger old bugs that haven't had a bad effect too |
| 21:45 |
|
diemartin joined #minetest-dev |
| 21:45 |
sapier1 |
networking code is heavyly broken especialy on large amounts of data to transfer |
| 21:46 |
kahrl |
well guys |
| 21:46 |
kahrl |
I explained above what my idea is where this message might come from |
| 21:47 |
sapier1 |
:-) true |
| 21:47 |
sapier1 |
I hate bugs only occuring in release build |
| 21:48 |
kahrl |
it should happen on any kind of build, if it happens |
| 21:49 |
kahrl |
maybe it depends on the winsock implementation, I heard there's a proliferation of those on win32 |
| 22:00 |
hmmmm |
<sapier> and what exactly is better on parsing on server then on client? consistency, although I suppose if you really wanted to, you could add a raw json formspec definition thing |
| 22:00 |
hmmmm |
the thing is that you're treating formspec as if it were just some format |
| 22:00 |
iqualfragile |
about those shaders: i think it would be smarter to overlay multiple sine waves for the waterwaves efect |
| 22:00 |
hmmmm |
whereas it should be ideally a set of API to get something accomplished |
| 22:01 |
hmmmm |
and it just so happens that the API defined for formspec maps nicely over to JSON because you have a table array full of tables with certain elements and whatever |
| 22:01 |
hmmmm |
it's really not too much of a problem, parsing formspec needs to be done by the client anyway, so the code STILL has to be there |
| 22:04 |
hmmmm |
a benefit to server-side parsing of formspecs could be validation. the mod that's registering a formspec could get an error on inititalization that it's wrong for some reason |
| 22:05 |
hmmmm |
what i envision is formspec as a set of API that takes a description of a GUI in whatever form you'd like, as long as there are keys and values |
| 22:05 |
|
kaeza joined #minetest-dev |
| 22:06 |
hmmmm |
in the original formspec string thing, you have keys that are implicit based on position and context and all this other stuff |
| 22:06 |
hmmmm |
but in formspec 2.0, there will be better ways to define these formspecs |
| 22:07 |
PilzAdam |
whos going to rewrite the mainmenu? |
| 22:07 |
hmmmm |
you'll be able to do it in raw JSON if you'd like, or what's preferred is that you define it programatically by making a set of objects in the script language |
| 22:07 |
hmmmm |
PilzAdam, nobody |
| 22:08 |
hmmmm |
so my point is |
| 22:08 |
hmmmm |
formspec will be abstracted away to a set of API that performs operations based on some definition of a GUI, and how it gets that definition is arbitrary |
| 22:08 |
hmmmm |
hell, if you want to make it XML you can do that too |
| 22:09 |
hmmmm |
it's just that it gets serialized into JSON for the trip between the server and the client |
| 22:10 |
hmmmm |
I am pretty much repeating myself by now.... |
| 22:26 |
kahrl |
just rebased: formspec_table (#920) |
| 22:33 |
ShadowNinja |
kahrl: So, does that patch look good? ^ |
| 22:36 |
kahrl |
which one? |
| 22:38 |
kahrl |
ShadowNinja: I can't find it |
| 22:38 |
kahrl |
ah there it is, you mean http://ix.io/9uv? |
| 22:38 |
ShadowNinja |
Yep. |
| 22:39 |
kahrl |
ah, the idea in my head was a method that returned just the inventory list names |
| 22:39 |
kahrl |
but either way should be fine |
| 22:39 |
kahrl |
unless there is some pressing need for a method that returns just the names (for some performance reason or something) |
| 22:41 |
|
Miner_48er joined #minetest-dev |
| 22:43 |
ShadowNinja |
Well if you look at the code it could be improved, but that would require bigger to InventoryLists and the way are pushed. |
| 22:43 |
kahrl |
ShadowNinja: how does the read_items fix work? wouldn't that just abort at the first "hole" in the table? |
| 22:43 |
ShadowNinja |
+changes |
| 22:44 |
ShadowNinja |
kahrl: Yes, but it will go through it in order. (like ipairs instead of pairs) |
| 22:44 |
kahrl |
oh, okay |
| 22:46 |
kahrl |
I thought lua_next moved through the array part of a table in numeric order |
| 22:49 |
ShadowNinja |
If you add them in numeric order it probably does, but that's not guaranteed and modification will mess it up. |
| 22:57 |
kahrl |
ok, so lua_next won't work, but it also feels wrong to me to silently ignore part of a table |
| 22:57 |
kahrl |
ShadowNinja: |
| 22:58 |
|
iqualfragile_ joined #minetest-dev |
| 23:15 |
kahrl |
john_minetest: can you check if this fixes your issue? https://gist.github.com/kahrl/8106473 |
| 23:16 |
kahrl |
good luck ;) |
| 23:17 |
|
Miner_48er joined #minetest-dev |
| 23:48 |
ShadowNinja |
kahrl: Do you have a better idea? IMO it should allow arrays with missing items, but how can that be done? |
| 23:49 |
ShadowNinja |
Using lua_next would work if you can set indexes of a vector in any order. |
| 23:50 |
ShadowNinja |
But that will probably result in some double initialization. |
| 23:51 |
|
john_minetest left #minetest-dev |
