| Time |
Nick |
Message |
| 00:47 |
|
Robby joined #minetest-dev |
| 01:02 |
|
EvergreenTree joined #minetest-dev |
| 01:22 |
|
EvergreenTree joined #minetest-dev |
| 01:25 |
|
Megaf joined #minetest-dev |
| 01:28 |
|
Megaf left #minetest-dev |
| 01:42 |
|
Robby joined #minetest-dev |
| 03:10 |
|
us_0gb joined #minetest-dev |
| 06:11 |
|
ImQ009 joined #minetest-dev |
| 06:26 |
|
OldCoder joined #minetest-dev |
| 06:27 |
|
damiel joined #minetest-dev |
| 06:27 |
|
damiel joined #minetest-dev |
| 06:56 |
|
ImQ009 joined #minetest-dev |
| 07:00 |
|
NakedFury joined #minetest-dev |
| 07:06 |
keesj |
VanessaE: I modified the minetestmapper to export (red stones) for 3D printing (using openscad) |
| 07:09 |
VanessaE |
nice |
| 07:14 |
VanessaE |
might be a good idea to make a command line option + pull request if possible. others may find that useful. |
| 07:16 |
keesj |
I might indeed. |
| 07:18 |
keesj |
I will need some more work because I need to parse the whole map while the mapper can stop at the upper layers(hence my stuff is slower) |
| 07:53 |
proller |
.py or .c ? |
| 07:56 |
keesj |
it is python |
| 07:58 |
keesj |
or "python" as my skilzz in that area are not great (I am more of a c developer) |
| 08:08 |
|
werwerwer_ joined #minetest-dev |
| 08:51 |
|
celeron55 joined #minetest-dev |
| 08:55 |
VanessaE |
celeron55: not to bother you, but about the texture atlas thing we discussed some time ago... will that be some time soon? |
| 08:56 |
|
IceCraft joined #minetest-dev |
| 08:56 |
|
IceCraft joined #minetest-dev |
| 09:58 |
|
Gethiox3 joined #minetest-dev |
| 10:06 |
|
BrandonReese joined #minetest-dev |
| 10:33 |
celeron55 |
VanessaE: ehm... don't ask me; i'm not going to do it |
| 10:34 |
VanessaE |
ok. |
| 10:42 |
|
proller joined #minetest-dev |
| 11:16 |
|
iqualfragile joined #minetest-dev |
| 11:34 |
|
PilzAdam joined #minetest-dev |
| 12:07 |
|
ImQ009 joined #minetest-dev |
| 12:47 |
|
EvergreenTree joined #minetest-dev |
| 12:47 |
|
EvergreenTree joined #minetest-dev |
| 13:17 |
|
nore joined #minetest-dev |
| 13:18 |
|
zat joined #minetest-dev |
| 13:48 |
nore |
ShadowNinja, do you think param2 getters/setters for Lua VM should be added? |
| 13:52 |
|
smoke_fumus joined #minetest-dev |
| 13:52 |
nore |
And from what I read, client-side Lua is to be added soon? |
| 13:53 |
|
hmmmm joined #minetest-dev |
| 13:55 |
nore |
hmmmm, do you think param2 getters and setters should be added to LuaVL |
| 13:55 |
nore |
-L+M |
| 14:09 |
|
rsiska joined #minetest-dev |
| 14:43 |
|
ImQ009 joined #minetest-dev |
| 14:51 |
|
BlockMen joined #minetest-dev |
| 15:00 |
xyz |
kahrl: tooltips work really weird in formspec table (not updating when moving mouse), can this be fixed? |
| 15:01 |
kahrl |
not that easily |
| 15:02 |
xyz |
maybe just use our own ones? |
| 15:02 |
kahrl |
yeah, that would be a solution |
| 15:03 |
xyz |
I've looked into Irrlicht a bit and there seems to be no way to force-redraw a tooltip |
| 15:03 |
xyz |
other than sending fake mouse events to it |
| 15:04 |
kahrl |
the inventory list display in formspecs has custom tooltips, that code could be copied (or otherwise reused) |
| 15:09 |
|
nore joined #minetest-dev |
| 15:13 |
|
Zeitgeist_ joined #minetest-dev |
| 15:14 |
|
Yepoleb joined #minetest-dev |
| 15:18 |
|
Taoki joined #minetest-dev |
| 15:24 |
BlockMen |
any comments on #1103 (except those on github) and what submodule is it/ or who wants to decide about that? |
| 15:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/1103 -- Page is too big. |
| 15:27 |
xyz |
+1 |
| 15:28 |
PilzAdam |
who marked it as enhancement? |
| 15:28 |
xyz |
just merge it in |
| 15:29 |
BlockMen |
PilzAdam, me, why? |
| 15:29 |
PilzAdam |
isnt it a bugfix? |
| 15:30 |
PilzAdam |
anyway, Im fine with it too |
| 15:30 |
BlockMen |
PilzAdam, hmm...true |
| 15:30 |
BlockMen |
ok, gonna push it now |
| 15:34 |
|
specing joined #minetest-dev |
| 15:36 |
|
Taoki joined #minetest-dev |
| 15:42 |
|
BlockMen left #minetest-dev |
| 15:50 |
|
Amaz joined #minetest-dev |
| 16:03 |
celeron55 |
ehm |
| 16:03 |
celeron55 |
that is going to make jumping up 3-node-high fullnode stairs completely impossible |
| 16:04 |
celeron55 |
(not completely, but even more fucking awful than now) |
| 16:05 |
celeron55 |
there is code to move the camera down if the camera goes inside a node, or was it removed? |
| 16:06 |
celeron55 |
or is the new collision code unable to actually do precise collisions? |
| 16:06 |
xyz |
wat is "3-node-high fullnode stairs"? |
| 16:07 |
celeron55 |
dig two nodes in front of you so that you can walk into there and one down, walk into there (dropping one down), then do the same continuously until bored; then try to get up from there |
| 16:08 |
celeron55 |
once upon time jumping up from there was a matter of hitting down space and forward, and it just went up without missing a step |
| 16:08 |
celeron55 |
upon a time* |
| 16:09 |
|
Jordach joined #minetest-dev |
| 16:09 |
|
nore joined #minetest-dev |
| 16:09 |
xyz |
well, this is how it works now |
| 16:09 |
xyz |
with the patch applied |
| 16:10 |
celeron55 |
i will test |
| 16:12 |
celeron55 |
lol wat |
| 16:12 |
PilzAdam |
xyz, no, its messed up since Taoki's phyiscs "improvements" |
| 16:12 |
celeron55 |
apparently it works better by pure chance |
| 16:12 |
PilzAdam |
walking down sucks too |
| 16:13 |
celeron55 |
walking down is as bad as before, probably worse |
| 16:13 |
|
Calinou joined #minetest-dev |
| 16:16 |
celeron55 |
it depends on the game though; nowadays games already do set their own player physics |
| 16:18 |
kahrl |
is 1b4908bf56 supposed to prevent me from placing nodes at my feet and around my head? |
| 16:18 |
kahrl |
because I can do those things as I always could |
| 16:19 |
PilzAdam |
kahrl, disable noclip? |
| 16:20 |
kahrl |
without noclip |
| 16:20 |
celeron55 |
wait what |
| 16:20 |
celeron55 |
it's disabled if you have the noclip privilege |
| 16:20 |
celeron55 |
no matter if you're actually using it |
| 16:21 |
celeron55 |
it doesn't understand that noclip is actually disabled if noclip is enabled but free move is disabled |
| 16:23 |
PilzAdam |
I can place a node inside the camera if I already stay inside of another node |
| 16:23 |
|
EvergreenTree joined #minetest-dev |
| 16:23 |
PilzAdam |
and its easy to glitch into a node by placing it near you |
| 16:24 |
|
EvergreenTree joined #minetest-dev |
| 16:24 |
xyz |
well if you want to break stuff |
| 16:27 |
|
tomasbrod joined #minetest-dev |
| 16:33 |
|
rsiska joined #minetest-dev |
| 16:55 |
|
sapier joined #minetest-dev |
| 17:00 |
|
tomasbrod left #minetest-dev |
| 17:03 |
sapier |
core devs what do you think about adding subfolders ? e.g. server, client |
| 17:05 |
|
damiel joined #minetest-dev |
| 17:05 |
VanessaE |
purpose of same? |
| 17:06 |
sapier |
clarifying organization, by now only scriptapi can be 1:1 matched to a maintainer |
| 17:06 |
VanessaE |
mm |
| 17:06 |
sapier |
and utils |
| 17:07 |
|
Calinou joined #minetest-dev |
| 17:07 |
|
damiel joined #minetest-dev |
| 17:09 |
|
Zeitgeist_ joined #minetest-dev |
| 17:09 |
|
Zeitgeist_ joined #minetest-dev |
| 17:09 |
sapier |
VanessaE are you fine with closing #522? |
| 17:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/522 -- Allegedly Invalid map data causes server crash |
| 17:09 |
|
Zeitgeist_ joined #minetest-dev |
| 17:11 |
VanessaE |
yeah but check with ShadowNinja, he's been seeing bad mapblocks in one of his maps lately too |
| 17:13 |
sapier |
considering age of that issue I'm almost sure shadow has a diffferent one :-) |
| 17:16 |
VanessaE |
maybe but I've experienced the same issue as he's got, and "invalid" map data happening in a map ...well... just should not happen unless there's imminent hardware failure |
| 17:16 |
VanessaE |
so 522 can be closed I guess but the problem needs to be addressed anyway |
| 17:16 |
sapier |
yes but memory corruption could cause map corruption too and we wouldn't have any chance to find it without additional information. |
| 17:17 |
sapier |
I'm closing issues without any chance to be found right now. It's useless to have them sitting around for years |
| 17:30 |
sapier |
hmm VanessaE #533 is as old the pastebin numbers have been reused for something completely different ;-) |
| 17:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/533 -- An unhandled exception occurred: too many items |
| 17:30 |
kahrl |
is ShadowBot using minecraft mods as exceptions now? |
| 17:31 |
sapier |
sorry don't understand? |
| 17:31 |
kahrl |
sorry just a lame joke :P |
| 17:32 |
kahrl |
http://www.minecraftforum.net/topic/140684-17413w48b-toomanyitems-in-game-invedit-jan-13-172-forge-is-up/ |
| 17:32 |
VanessaE |
oh my |
| 17:32 |
VanessaE |
no idea what the original text was then |
| 17:32 |
VanessaE |
but it doesn't matter |
| 17:32 |
sapier |
doesn't matter, I'm sorry but continuing on corrupt data isn't an option |
| 17:33 |
sapier |
chances to cause even more damage are way to big |
| 17:33 |
xyz |
oh why the hell was this bug not closed |
| 17:33 |
sapier |
now it is closed |
| 17:33 |
VanessaE |
xyz: because someone only got to it just now? |
| 17:33 |
xyz |
it's because VanessaE had broken ram IIRC |
| 17:34 |
xyz |
so should be closed as invalid |
| 17:34 |
xyz |
*should've been |
| 17:34 |
sapier |
the final request was continuing on bad data which isn't a good idea |
| 17:34 |
VanessaE |
it was probably left open because the core issue remained - how minetest handled a corrupt player file |
| 17:35 |
xyz |
yup, I agree |
| 17:35 |
VanessaE |
imho the correct action would have been to either start the player with an empty inventory, or to delete the affected inventory slots in the player file. |
| 17:35 |
VanessaE |
and issue a big, fat warning in the log. |
| 17:36 |
VanessaE |
doesn't matter, the issue's closed now. |
| 17:37 |
kahrl |
should #534 be closed too? |
| 17:38 |
sapier |
there shouldn't be corrupt player files? |
| 17:38 |
sapier |
something musthave caused corruption |
| 17:38 |
kahrl |
brb |
| 17:39 |
sapier |
shwdowbot? |
| 17:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/534 -- Crash at start |
| 17:41 |
sapier |
yes kahrl I think it's done too |
| 17:45 |
ShadowNinja |
Does anyonw know who has controll over this? https://plus.google.com/116830764303517937720 |
| 17:46 |
|
e1z0 joined #minetest-dev |
| 17:46 |
ShadowNinja |
My error was with deserializing the NodeDef data IIRC. |
| 17:47 |
ShadowNinja |
I'll look up the block hash and delete it if it befomes an issue. |
| 17:48 |
sapier |
NodeDef data? is there any reason why those could be corrupted? |
| 17:49 |
ShadowNinja |
Random disc error? |
| 17:49 |
sapier |
discs should be quite reliable |
| 17:50 |
VargaD |
I have made some changes to builtin/mainmenu.lua bugfix: https://github.com/minetest/minetest/pull/1105 |
| 17:50 |
|
ShadowBot joined #minetest-dev |
| 17:50 |
VargaD |
it is now only single commit and I also fixed other get_textlist_index problems |
| 17:51 |
VargaD |
please reviw my changes |
| 17:51 |
VargaD |
*review |
| 17:51 |
sapier |
be carefull gameindex == 0 is invalid |
| 17:52 |
sapier |
you can't replace the "> 0" check by "~= nil" check as nil != 0 |
| 17:53 |
sapier |
didn't get_textlist_index return 0 before ... hmm maybe your fix just adapts to new behaviour |
| 17:54 |
sapier |
wait ... that's a problem get_textlist_index shouldn't behave different to version from 0.4.9 |
| 17:54 |
VargaD |
return value can't be 0 anymore |
| 17:54 |
VargaD |
it returns nil not 0 |
| 17:55 |
VargaD |
get_textlist_index only used there, so we either fix get_textlist_index or builtin/mainmenu.lua |
| 17:56 |
VargaD |
*it seems the problem it does not affect builtin/gamemgr.lua where it is also used |
| 17:56 |
sapier |
we should fix get_textlist_index, in generall It doesn't matter if it returns nil or 0. But as we already have a stable version returning 0 we should keep that behaviour |
| 17:57 |
VargaD |
ok, then I change that |
| 18:01 |
|
Amaz joined #minetest-dev |
| 18:07 |
VargaD |
ShadowNinja made that change 3 days ago |
| 18:07 |
VargaD |
<+ShadowNinja> [2014. 01. 15 22:04:42] VargaD: "engine.get_textlist_index returns nil instead of 0 when nothing is selected. (Also, added: engine.get_table_index)" -- formspec_table description. You can remove the > 0 check. |
| 18:08 |
sapier |
yes but that's wrong |
| 18:08 |
sapier |
changing behaviour without need isn't something we should do |
| 18:08 |
sapier |
I'm almost sure table addon didn't change this on purpose |
| 18:09 |
|
kaeza joined #minetest-dev |
| 18:09 |
sapier |
both options 0 and nil are equaly fine as long as you don't have a history |
| 18:10 |
sapier |
and why fix 20 locations if you can fix it at a single one |
| 18:17 |
VargaD |
I'm not familiar with minetest's lua api, maybe similar functions return nil somewhere else |
| 18:18 |
kahrl |
sapier: I originally fixed all locations where it was used, guess that was broken by rebasing |
| 18:19 |
sapier |
If there isn't a very good reason to break compatibility why should we do it for changing 0 to nil? |
| 18:20 |
sapier |
mainmenu api isn't internal only |
| 18:20 |
kahrl |
I haven't seen any alternative main menus so it's not a matter of compatibility really |
| 18:21 |
sapier |
It's not that critical as there most likely aren't alternative menus ... still some more reason then "because I like nil more then 0" would be fine ;) |
| 18:21 |
kahrl |
well I don't really care about it, so change it back to 0 |
| 18:22 |
sapier |
actully I don't care if 0 or nil to it just shouldn't change backand forward without reason ;) |
| 18:23 |
kahrl |
I think we shouldn't be that concerned with breaking mainmenu api compatibility |
| 18:23 |
kahrl |
with not* |
| 18:23 |
kahrl |
as no one else seems to be using it |
| 18:23 |
sapier |
it's a minor reason of course but even minor is better then none ;) |
| 18:24 |
sapier |
so if you have any reason for changing it most likely will beat compatibility ;-) |
| 18:24 |
kahrl |
well, I don't |
| 18:29 |
kahrl |
I think my original reasoning was to make it more obvious when some code fails to check for the nil/0 case |
| 18:29 |
kahrl |
so you get errors like "attempt to compare nil with number" |
| 18:31 |
sapier |
hmm ok that could be reason enough ... we'd have to note on release |
| 18:33 |
celeron55 |
the main menu simply isn't officially a public interface; just change whatever needs changing |
| 18:33 |
sapier |
actually it is as public as modapi |
| 18:34 |
celeron55 |
no it isn't; there is no way to plug code into it without modifiying existing code |
| 18:34 |
sapier |
it is |
| 18:34 |
sapier |
you can just set it in config |
| 18:34 |
kaeza |
it would be easier to make alternative main menus if the UI was based on some template system, like checking for `$path_user/mainmenu/theme.fs' and load that file as a formspec string |
| 18:35 |
sapier |
yes but that template would limit degrees of freedom too |
| 18:35 |
sapier |
it's like most things easy == limited |
| 18:36 |
sapier |
but feel free to write templated mainmenu ;-) |
| 18:40 |
sapier |
main_menu_script is parameter to specify your own mainmenu in config |
| 18:42 |
kaeza |
would be useful too to list those options in menu_lua_api.txt ... |
| 18:42 |
sapier |
you're right about that |
| 18:57 |
sapier |
kahrl/VargaD guess we all agree to use nil as nothing selected, I just request to add some obvious notice this is changing behaviour of api at leas by an obvious commit message better as point in release notes |
| 18:57 |
sapier |
do we have release notes? |
| 18:58 |
xyz |
http://dev.minetest.net/Changelog |
| 19:01 |
sapier |
ok guess that's good enough |
| 19:03 |
|
damiel joined #minetest-dev |
| 19:03 |
|
damiel joined #minetest-dev |
| 19:10 |
|
EvergreenTree joined #minetest-dev |
| 19:10 |
|
grrk-bzzt joined #minetest-dev |
| 19:11 |
|
EvergreenTree joined #minetest-dev |
| 19:12 |
|
nore joined #minetest-dev |
| 19:16 |
nore |
"<sapier> Binary mods could solve this issue," <-- does this mean it is planned to do that? |
| 19:17 |
sapier |
not that I know about but it's an idea beeing mentioned every now and then |
| 19:17 |
sapier |
there are a lot of issues with binary mod |
| 19:17 |
sapier |
s |
| 19:17 |
nore |
sapier, what are those? |
| 19:17 |
sapier |
first of all portability |
| 19:17 |
sapier |
second, you need a stable interface |
| 19:18 |
sapier |
another one is how to check a binary mod for harmfull code |
| 19:18 |
nore |
ok... and I also read that client-side Lua is to be added soon? |
| 19:19 |
sapier |
I guess I'll do client side lua this year but don't ask me if it's june or oktober |
| 19:19 |
nore |
^ well, there are already problems with that now... it is possible to make a mod that will delete all files... |
| 19:19 |
|
proller joined #minetest-dev |
| 19:19 |
xyz |
if you want portability you'll have to write C api |
| 19:20 |
sapier |
as I said there are lot of issues with binary mods |
| 19:20 |
xyz |
indeed |
| 19:20 |
xyz |
maybe it'll be easier to just say that we don't need portability |
| 19:20 |
sapier |
I've written in that comment that improving lua modapi is way more promising |
| 19:23 |
|
VanessaE joined #minetest-dev |
| 19:24 |
|
VanessaE joined #minetest-dev |
| 19:25 |
VargaD |
sapier: shall I change something in the pull request? |
| 19:27 |
sapier |
if you checked that those values not resulting from direct reading can't be 0 it's fine |
| 19:28 |
nore |
^ sapier: perhaps voxelmanip param2 getters/setters would be the first thing to do regarding that... |
| 19:28 |
sapier |
regarding what? |
| 19:29 |
|
VanessaE joined #minetest-dev |
| 19:31 |
nore |
regarding your comment (about improving lua API) |
| 19:31 |
nore |
and another idea: negative values in voxelmanip would mean swap_node... not sure if that is a really good one though... perhaps another way would be needed |
| 19:32 |
sapier |
I more thought about improving api to get those circuits done in a usefull way in lua instead of c++ |
| 19:33 |
sapier |
but of course if you have ideas how to improve lua api they're always welcome ... at least I guess ShadowNinja is same opinion as he's in charge about lua api |
| 19:34 |
|
VanessaE joined #minetest-dev |
| 19:34 |
sapier |
I'm repeating but what to other core devs think about adding subfolders for server/client? |
| 19:34 |
nore |
yes... better voxelmanips could help that |
| 19:34 |
sapier |
containing files only used at server or client |
| 19:37 |
xyz |
what's the point? |
| 19:37 |
|
Miner_48er joined #minetest-dev |
| 19:38 |
sapier |
xyz are you talking about subdirectorys or voxelmanip suggestions? |
| 19:38 |
xyz |
subdirectories |
| 19:39 |
sapier |
it'd match the new organization and in mid to long term improve development of "stable" interfaces between subsystems |
| 19:39 |
sapier |
and interfaces could reduce side effects of changes |
| 19:41 |
xyz |
how would it "improve development of "stable" interfaces between subsystems"? |
| 19:42 |
sapier |
if organization separates that code from other code this separation will help separating interfaces too |
| 19:42 |
proller |
add 5000 lines of useless code will mprove interfaces! |
| 19:42 |
sapier |
we don't add a single code line by splitting |
| 19:42 |
proller |
you can dont add lines??? |
| 19:44 |
sapier |
proller if you want to complain about random things please do this somewhere else |
| 19:46 |
proller |
add new organizations to github: minetest-client, minetest-server, minetest-connection, minetest-menu ....... |
| 19:46 |
proller |
ant slpit code to repos |
| 19:46 |
sapier |
proller I can't help if you want to extend things way beyond any sane suggestion |
| 19:46 |
PilzAdam |
proller, that would mean youd have to create multiple pull requests for almost all new features |
| 19:46 |
xyz |
what happened to RBA btw? did he quit? |
| 19:46 |
proller |
cool! 20 pulls to one feature |
| 19:46 |
xyz |
sapier: dunno, I don't see any reason to do that |
| 19:46 |
sapier |
It's organizational change only imho it'd be better but I wont push that topic against majority of course |
| 19:47 |
proller |
instead of fixing tons ow wtf code we will mix sources without changes, or add useless lines |
| 19:47 |
proller |
sapier, you must be head of minetest |
| 19:47 |
xyz |
making organizational changes while there are almost no people actually developing stuff? I don't see any reason to do that |
| 19:48 |
sapier |
I'm gonna split server file to sane parts this will add additional files to a folder already way to crowded to find the file you see |
| 19:48 |
sapier |
k |
| 19:48 |
xyz |
well if you say it like this then probably add a directory for those files you split server.cpp into |
| 19:49 |
proller |
src/s/se/ser/server.cpp |
| 19:49 |
sapier |
would be an option to but why handle those file different to other files beeing server only? |
| 19:49 |
sapier |
proller if you don't want to participate at a constructive discussion BE QUIET |
| 19:50 |
proller |
you can handle mote than million files in this way ^ - i think it very constructive |
| 19:51 |
sapier |
ok proller if you manage to find the file you are looking for manually in folder structure like that I agree to you |
| 19:53 |
sapier |
any other suggestions/opinions? |
| 19:54 |
proller |
do not touch anything |
| 19:55 |
sapier |
anyone not beeing picky about fixes not matching his own half way fixes? |
| 19:58 |
VargaD |
files shouldn't be longer than few thousand lines of code, but many small files hurt development |
| 19:58 |
sapier |
yes but right now we have more issues with files beeing 5k+ lines than with small files ;-) |
| 20:00 |
sapier |
server.cpp is something to be cleaned up, I'll do this anyway |
| 20:01 |
sapier |
first thing is fixing client handling as it's broken right now |
| 20:02 |
proller |
add tcp now! |
| 20:02 |
sapier |
why? we still don't have reliable comparison to enet? |
| 20:04 |
proller |
enet suck |
| 20:04 |
sapier |
what made you change your opinion? |
| 20:05 |
proller |
i test it |
| 20:05 |
proller |
it use all cpu |
| 20:06 |
sapier |
this can be fixed at cost of jitter |
| 20:06 |
sapier |
at least I don't see that issue in my enet implementation ... but according to thexyz mine seems to be slower then his suggestion |
| 20:08 |
sapier |
but as I said I don't have reliable tests right now |
| 20:11 |
|
troller joined #minetest-dev |
| 20:12 |
khonkhortisan |
As of irrlicht r4669, the numpad is fixed on linux. |
| 20:40 |
VargaD |
sapier: I checked them again one-by-one and fixed some more index problem, I think I covered all the cases now |
| 20:45 |
|
sapier1 joined #minetest-dev |
| 20:46 |
|
mrtux joined #minetest-dev |
| 20:54 |
sapier1 |
VargaD L509-L515 leading indention is supposed to be tabs not spaces |
| 20:56 |
sapier1 |
other things seem to be fine |
| 20:58 |
|
NakedFury joined #minetest-dev |
| 21:03 |
VargaD |
sorry I haven't noticed that vim messed up whitespace... :( |
| 21:03 |
sapier1 |
no problem |
| 21:13 |
ShadowNinja |
I'm in favor of more subfolders. src/ is getting really big... |
| 21:18 |
VargaD |
I have changed space to tab, it should be fine now |
| 21:21 |
|
damiel joined #minetest-dev |
| 21:21 |
|
rsiska joined #minetest-dev |
| 21:26 |
celeron55 |
i don't think there is actual need for subfolders |
| 21:26 |
celeron55 |
the subsystems are meant to be purely people-organizational |
| 21:27 |
celeron55 |
i already think the scriptapi directories are hard to navigate |
| 21:28 |
troller |
+1 |
| 21:28 |
sapier1 |
*g* how do you navigate celeron? maybe I could learn something from you because I usually don't find the files I need quick |
| 21:29 |
celeron55 |
i navigate by typing the start of a filename and pressing tab |
| 21:29 |
ShadowNinja |
I like the script API organization actually. I can figure out where something should be easily. |
| 21:29 |
celeron55 |
if i don't know the file i want, i use some kind of haphazard ctags-vim integration |
| 21:29 |
celeron55 |
or grep |
| 21:30 |
xyz |
that's what you need IDEs for |
| 21:30 |
sapier1 |
ok :-) command line ... guess folders don't help in this case |
| 21:30 |
sapier1 |
ide won't help if you have that much files you have to scroll in project explorer |
| 21:30 |
xyz |
no, IDEs help you to navigate the code |
| 21:31 |
celeron55 |
what does xyz think then? |
| 21:31 |
celeron55 |
are you with sapier or with proller? |
| 21:31 |
sapier1 |
they don't help in seeing what file is good for what |
| 21:31 |
ShadowNinja |
grep -r is helpfull. :-) It's also easy to search for something only in the lua_api if the files are organized in subfolders. |
| 21:31 |
xyz |
celeron55: dunno, I'm fine with what we have |
| 21:32 |
sapier1 |
but I see there's to much disagreement to this change and I don't want to spend that much time on this discussion |
| 21:32 |
sapier1 |
I'll keep it the way it is until others are as anoyed as I am about searching in that much files :-) |
| 21:33 |
celeron55 |
i'm fine with anything really because i can just code whatever features i happen to need into my development environment, and every existing developer already knows where everything is |
| 21:35 |
sapier1 |
really? |
| 21:38 |
celeron55 |
so it's probably a matter of making things easier to find for new contributors vs. letting old devs not need to re-learn things |
| 21:39 |
sapier1 |
maybe ... true ... but considering duplicated code within minetest I don't agree all developers know where things are |
| 21:39 |
kaeza |
duplicated code? |
| 21:39 |
celeron55 |
could be just laziness |
| 21:39 |
celeron55 |
to which splitting things into subdirectories doesn't help at all |
| 21:39 |
celeron55 |
only makes it worse |
| 21:39 |
sapier1 |
request queue for example ... kahrl as well as I implemented a own version instead of fixing/improoving the existing one ... I can't speak for kahrl but I just didn't know it existed |
| 21:39 |
sapier1 |
all three have different features and it's quite some work to merge now |
| 21:39 |
sapier1 |
and by the time we implemented our versions the original one didn't work completely |
| 21:39 |
celeron55 |
subdirectories wouldn't have helped at all in that |
| 21:39 |
|
NakedFury joined #minetest-dev |
| 21:39 |
celeron55 |
really nothing would have |
| 21:39 |
celeron55 |
except communicating and reading code so much that nothing wouldn't have gotten done in the first place |
| 21:39 |
celeron55 |
would* |
| 21:39 |
sapier1 |
subdirectories with good speaking names might have helped ... but of course I can't proove this assumption |
| 21:39 |
sapier1 |
I fully agree to the communication point |
| 21:39 |
celeron55 |
that would have been simply in an utility directory (probably is already) |
| 21:39 |
xyz |
minetest/server/classes/containers/queues/request_queue/request_queue.cpp |
| 21:39 |
sapier1 |
yes in best case in a file called requestqueue.cpp/h |
| 21:40 |
sapier1 |
didn't know proller is using xyz as name now ;-) |
| 21:40 |
VanessaE |
he's channeling ;) |
| 21:40 |
sapier1 |
ok lets forget the subdirectorys |
| 21:41 |
sapier1 |
what about the client thing, I plan to take client list from server class and make it a separate class. I need this to make sure clients get initialized prior others are able to send data to them |
| 21:42 |
|
NakedFury joined #minetest-dev |
| 21:42 |
celeron55 |
sounds sane-ish |
| 21:44 |
sapier1 |
yes but it add's another layer in som places ... on the other hands I can remove a lot of duplicated looping code from server |
| 21:46 |
celeron55 |
isn't it obvious: add it if it's needed, don't add it if it isn't needed and it can be done by fixing existing things |
| 21:47 |
celeron55 |
i don't remember what kinds of issues there are |
| 21:47 |
celeron55 |
and i don't know what issues you aim to fix with that |
| 21:47 |
sapier1 |
on vanessae's server we get hud as well as detached inventories sent prior TOCLIENT_INIT |
| 21:48 |
VanessaE |
because my server is fast as hell :) |
| 21:48 |
celeron55 |
can't it be fixed without some huge additional structure? |
| 21:48 |
sapier1 |
I can't stop it as those messages are sent by scriptapi accessing clientlist ... and that client list is updated on new peer |
| 21:49 |
sapier1 |
of course I can add same code to server class ... but that class is already huge |
| 21:49 |
celeron55 |
oh it's the issue of joinplayer being called before the client is actually initialized? |
| 21:49 |
sapier1 |
I'm not absolutely sure but could be yes |
| 21:49 |
celeron55 |
can't you simply move the call to joinplayer to after the initialization |
| 21:50 |
sapier1 |
those calls don't seem to be related |
| 21:50 |
sapier1 |
peer is added by add peer event which is handled async |
| 21:50 |
sapier1 |
as of this time scriptapi may send data to peer |
| 21:51 |
celeron55 |
well in any case KISS |
| 21:51 |
celeron55 |
i don't want to see overengineered solutions to almost non-existent problems |
| 21:51 |
sapier1 |
so even if I'm able to fix the joinplayer thing I can't stop ocassional random send to all packages beeing sent to peer |
| 21:51 |
celeron55 |
nobody wants |
| 21:52 |
sapier1 |
I have a workaround too ... queuing packages on client side until init is received ... but I don't like hacky solutions like that |
| 21:54 |
celeron55 |
if you do something considerable, you should do it so that it allows somehow not showing the player in the world until the client is fully initialized |
| 21:54 |
sapier1 |
I think this could be done |
| 21:55 |
celeron55 |
i think nobody likes the current behavior of frozen players hanging in mid-air while the client initializes and downloads things 8) |
| 21:56 |
sapier1 |
ok I guess fixing this issue won't be a big deal on fixing the client init |
| 21:57 |
sapier1 |
and I can split the "conlock" which is actually a clientlistlock |
| 22:00 |
ShadowNinja |
kahrl: s/httpfetch_async/httpfetch_sync/ does nothing. |
| 22:00 |
kahrl |
as in, it still doesn't even try to connect? |
| 22:00 |
ShadowNinja |
kahrl: Yep. |
| 22:00 |
kahrl |
ok |
| 22:01 |
ShadowNinja |
No noticable wait either. |
| 22:01 |
kahrl |
well the good thing is that it should be way more debuggable now |
| 22:01 |
ShadowNinja |
This is what I changed: http://ix.io/9UD |
| 22:02 |
kahrl |
yeah, that's right |
| 22:02 |
ShadowNinja |
What should I try now? |
| 22:02 |
kahrl |
let me see |
| 22:04 |
kahrl |
first off, set a breakpoint on serverlist.cpp:243 and see if it gets there at all |
| 22:05 |
|
Amaz joined #minetest-dev |
| 22:07 |
|
cheapie joined #minetest-dev |
| 22:08 |
ShadowNinja |
Yep, it runs. |
| 22:08 |
kahrl |
can you dump the fetchrequest? |
| 22:10 |
* ShadowNinja |
switches to a debug build |
| 22:11 |
ShadowNinja |
(gdb) dump value fetchrequest --> No value to dump. |
| 22:12 |
kahrl |
great ;) |
| 22:12 |
kahrl |
is this with the debug build already? |
| 22:13 |
ShadowNinja |
Got it: http://pastebin.ubuntu.com/6764491/ |
| 22:13 |
ShadowNinja |
(bt full works) |
| 22:15 |
kahrl |
timeout = true <-- that's interesting |
| 22:15 |
kahrl |
you said it returns immediately? |
| 22:15 |
ShadowNinja |
Yes, or very quickly at least. |
| 22:16 |
kahrl |
oh! the timeout is 5ms |
| 22:16 |
kahrl |
I guess the server doesn't respond that quickly |
| 22:17 |
ShadowNinja |
64 bytes from minetest.ru (176.9.122.10): icmp_seq=1 ttl=42 time=119 ms |
| 22:17 |
sapier1 |
hmm 5ms? |
| 22:17 |
sapier1 |
:-) |
| 22:18 |
VanessaE |
haha |
| 22:18 |
sapier1 |
who sets this value? |
| 22:18 |
ShadowNinja |
Hmmm, so was curl_timeout changed from s to ms? |
| 22:18 |
kahrl |
I dunno, was it s before? |
| 22:19 |
ShadowNinja |
I had curl_timeout set to 5 in my conf. It worked before. |
| 22:19 |
sapier1 |
as far as I know it's always been ms? |
| 22:20 |
sapier1 |
at least the default value is still 5000 |
| 22:20 |
ShadowNinja |
It's also multiplied by 5... |
| 22:20 |
sapier1 |
what's set in your minetest.conf? |
| 22:21 |
ShadowNinja |
curl_timeout = 5 *Was* in there. |
| 22:21 |
kahrl |
I only know that before b03135548b sendAnnounce ignored curl_timeout and used a fixed value of 1000ms |
| 22:21 |
ShadowNinja |
Ah, OK, so it was always ms. |
| 22:22 |
ShadowNinja |
Well, thanks. :-) |
| 22:22 |
sapier1 |
ok that could explain it ... but you should have had other issues before with curl timeout 5ms |
| 22:23 |
sapier1 |
e.g. not loading modstore |
| 22:23 |
sapier1 |
textures never beeing loaded by curl |
| 22:23 |
sapier1 |
things like that |
| 22:23 |
ShadowNinja |
I have a seperate build for my server. I think the anouncement is the only CURL thing it uses. |
| 22:23 |
sapier1 |
oh ok that's an explanation |
| 22:25 |
sapier1 |
kahrl can we add a warning message to be written to debug log on timeout? |
| 22:26 |
ShadowNinja |
I beleive it did report timeouts before... |
| 22:27 |
kahrl |
yeah, it should print something |
| 22:29 |
sapier1 |
ok :-) I gues curl timeouts could be worth mentioning on curl not working as expected ;-) *just kidding* |
| 22:29 |
kahrl |
but isn't httpfetch.cpp:316 enough? |
| 22:30 |
sapier1 |
we don't have a warningstream? |
| 22:30 |
kahrl |
errorstream, actionstream, infostream, verbosestream, dstream |
| 22:30 |
sapier1 |
maybe it's worth an error but I'm not sure about that |
| 22:31 |
sapier1 |
I always wonder what actionstream is exactly meant for |
| 22:31 |
|
zat joined #minetest-dev |
| 22:32 |
kahrl |
"Admin2005 digs bedrock:bedrock at (42,23,9001)" |
| 22:32 |
sapier1 |
ok so user actions only |
| 22:34 |
troller |
celeron55, connection.cpp now one big overengineered solution to non-existent problem |
| 23:37 |
ShadowNinja |
Screwdriver unknown node fix and extra indent removal incomming... |
| 23:48 |
ShadowNinja |
Suggestion: Disable unit tests in release builds. |
