| Time |
Nick |
Message |
| 00:00 |
|
EvergreenTree joined #minetest-dev |
| 00:14 |
|
blaaaaargh joined #minetest-dev |
| 00:14 |
|
Miner_48er joined #minetest-dev |
| 00:18 |
|
blaaaaargh joined #minetest-dev |
| 00:25 |
|
Miner_48er joined #minetest-dev |
| 00:35 |
|
john_minetest left #minetest-dev |
| 00:51 |
|
Miner_48er joined #minetest-dev |
| 02:03 |
|
sapier left #minetest-dev |
| 02:40 |
|
OWNSyouAll joined #minetest-dev |
| 03:03 |
|
kaeza joined #minetest-dev |
| 03:03 |
VanessaE |
fwiw: kizeren and I are now using sapier's fork, server_improvement branch for testing. Thus far, the on-join lag with non-cURL clients seems to have been fixed, and server CPU load during the initial non-cURL media fetch is much improved. |
| 03:04 |
VanessaE |
( https://github.com/sapier/minetest/tree/server_improvement ) |
| 03:04 |
VanessaE |
this makes a total of 6 servers that are using this branch. only been testing for a couple of hours yet, so too early to say if it's good enough for general audiences. Just a heads-up. |
| 03:23 |
|
us_0gb joined #minetest-dev |
| 04:06 |
|
VanessaE joined #minetest-dev |
| 04:06 |
|
OldCoder joined #minetest-dev |
| 04:08 |
ShadowNinja |
kahrl: Does this look good? http://ix.io/9zo |
| 05:38 |
|
NakedFury joined #minetest-dev |
| 05:44 |
|
smoke_fumus joined #minetest-dev |
| 06:59 |
|
mrtux joined #minetest-dev |
| 07:13 |
|
darkrose joined #minetest-dev |
| 07:13 |
|
darkrose joined #minetest-dev |
| 07:13 |
kahrl |
ShadowNinja: I think key should be a signed integer type |
| 07:14 |
kahrl |
how (in)efficient is repeatedly calling std::vector::reisze? |
| 07:14 |
kahrl |
resize* |
| 07:14 |
kahrl |
other than that it looks good to me |
| 07:15 |
kahrl |
maybe for consistency change the Server* srv to Server *srv while you're at it :) |
| 07:16 |
kahrl |
sapier: #1070 seems good, you can merge it if you want |
| 07:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/1070 |
| 07:17 |
* kahrl |
brbs |
| 08:46 |
|
VanessaE joined #minetest-dev |
| 10:13 |
|
proller joined #minetest-dev |
| 10:46 |
|
blaaaaargh joined #minetest-dev |
| 10:53 |
|
NakedFury joined #minetest-dev |
| 10:54 |
|
iqualfragile joined #minetest-dev |
| 11:12 |
|
Evolykane joined #minetest-dev |
| 11:41 |
|
VargaD_ joined #minetest-dev |
| 12:00 |
|
werwerwer joined #minetest-dev |
| 12:03 |
|
robmyers__ joined #minetest-dev |
| 12:05 |
|
mrtux joined #minetest-dev |
| 12:06 |
|
us{0gb joined #minetest-dev |
| 12:07 |
VanessaE |
Is there some logical reason why there is no simple, basic /kick command? |
| 12:07 |
VanessaE |
for minetest servers I mean |
| 12:08 |
VanessaE |
it seems like the equivalent of killing a fly with a bazooka to have to /ban and then immediately /unban just to boot someone from the server |
| 12:08 |
|
us{0gb joined #minetest-dev |
| 12:14 |
|
ImQ009 joined #minetest-dev |
| 12:32 |
|
blaaaaargh joined #minetest-dev |
| 12:35 |
|
elmux joined #minetest-dev |
| 12:37 |
elmux |
Is there any possibility for entitys to have a inventory ? |
| 12:41 |
celeron55 |
they do |
| 12:43 |
celeron55 |
umm wait... do they |
| 12:43 |
celeron55 |
yes they do |
| 12:43 |
celeron55 |
ObjectRef:get_inventory() |
| 12:46 |
celeron55 |
IIRC there could be some issues in getting those to be shown in inventory views; feel free to report bugs |
| 12:50 |
elmux |
thx |
| 13:00 |
|
Jordach joined #minetest-dev |
| 13:44 |
|
Evolykane joined #minetest-dev |
| 13:45 |
|
Jordach joined #minetest-dev |
| 14:07 |
|
werwerwer_ joined #minetest-dev |
| 14:50 |
|
daswort joined #minetest-dev |
| 15:03 |
|
zat joined #minetest-dev |
| 15:04 |
|
Zeitgeist_ joined #minetest-dev |
| 15:04 |
|
Zeitgeist_ joined #minetest-dev |
| 15:22 |
|
Weedy_lappy joined #minetest-dev |
| 15:30 |
|
proller joined #minetest-dev |
| 15:32 |
|
kaeza joined #minetest-dev |
| 15:35 |
|
Jordach joined #minetest-dev |
| 15:38 |
ShadowNinja |
std::vector::resize should be pretty fast, unfortunately this will cause double-initializations, with the advantage that it will assume empty slots are empty itemstacks. I thought about using a signed type, must have not done that. |
| 15:43 |
|
nore joined #minetest-dev |
| 15:47 |
|
Weedy joined #minetest-dev |
| 15:56 |
|
jojoa1997 joined #minetest-dev |
| 16:03 |
|
PilzAdam joined #minetest-dev |
| 16:14 |
|
EvergreenTree joined #minetest-dev |
| 16:14 |
|
EvergreenTree joined #minetest-dev |
| 16:16 |
|
EvergreenTree joined #minetest-dev |
| 16:32 |
|
Calinou joined #minetest-dev |
| 16:59 |
|
hmmmm joined #minetest-dev |
| 17:11 |
ShadowNinja |
Should be ready now: http://ix.io/9A6 I'll push it soon if nobody objects. |
| 17:12 |
ShadowNinja |
And I guess we're not in a feature freeze now, so http://ix.io/9A7 can be considered. (I'll make it into a PR soon) |
| 17:23 |
ShadowNinja |
And http://ix.io/9A9 is an alternative to #1074 that has the server create the world directory rather than having the RollbackManager handle that. |
| 17:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/1074 |
| 17:25 |
ShadowNinja |
(Which begs the question, where was it ceated before?) |
| 17:31 |
ShadowNinja |
Hmmm, maybe just move createRollbackManager after initializeWorld. (Both of which are global and should probably be renamed) |
| 17:37 |
|
artur99 joined #minetest-dev |
| 17:37 |
artur99 |
,,(seen OldCoder) |
| 17:37 |
ShadowBot |
artur99: I haven't seen OldCoder. |
| 17:39 |
ShadowNinja |
I moved the RollbackManager and BanManager after initializeWorld: http://ix.io/9Ac |
| 17:40 |
|
werwerwer joined #minetest-dev |
| 17:42 |
nore |
https://github.com/minetest/minetest/commit/4e5760a5416cbca6945b1b4484cbd96bea7b250c <-- oops, that shouldn't have been done |
| 17:42 |
nore |
I should fix it again |
| 17:42 |
|
robmyers__ joined #minetest-dev |
| 17:43 |
nore |
ShadowNinja, okay for reverting it? (I tested again really this time, and it is incorrect) |
| 17:46 |
|
AllegedlyDead joined #minetest-dev |
| 17:47 |
ShadowNinja |
nore: So the first way was correct? |
| 17:47 |
nore |
yep... I must have made wrong tests the first time |
| 17:48 |
nore |
this time, I made a little script (you click on colored faces of a node...) |
| 17:48 |
|
Evolykane joined #minetest-dev |
| 17:48 |
nore |
maybe I should add that script somewhere, and let it be used to generate those tables |
| 17:51 |
VanessaE |
suddenly, a week later: <nore> Um, ShadowNinja I need to revert that revert. the original patch was right after all.... |
| 17:51 |
nore |
... I can give you the script if you want |
| 17:51 |
VanessaE |
;) |
| 17:55 |
ShadowNinja |
Seems OK to me then, although I haven't noticed any issues either way... |
| 18:02 |
|
rubenwardy joined #minetest-dev |
| 18:09 |
|
ImQ009 joined #minetest-dev |
| 18:10 |
|
IceCraft joined #minetest-dev |
| 18:15 |
ShadowNinja |
Does this seem good? https://github.com/freeminer/freeminer/commit/75e5895afaec95c530d68847a058aac5338e3c81 |
| 18:16 |
|
Evolykane joined #minetest-dev |
| 18:17 |
PilzAdam |
ShadowNinja, if it does what I think then its good, I dont know cmake very well, though |
| 18:17 |
|
EvergreenTree joined #minetest-dev |
| 18:17 |
ShadowNinja |
It seems OGLES got linked into the Arch build, which broke it. ^ should fix that. |
| 18:18 |
ShadowNinja |
PilzAdam: Can you check my other changes? |
| 18:19 |
PilzAdam |
what does the first one (http://ix.io/9A6) do? |
| 18:21 |
ShadowNinja |
PilzAdam: Tables in Lua are not necessarily in order, so that could load a table in the order [2] = ItemStack("air"), [1] = ItemStack("ignore") and resilt in InveltoryList("air", "ignore") rather than "ignore", "air". |
| 18:22 |
ShadowNinja |
result* InventoryList* |
| 18:23 |
PilzAdam |
did that happen in the past? |
| 18:23 |
ShadowNinja |
So meta:set_list("main", meta:get_list("main")) could shuffle the inventory, though in practice it usually doesn't. |
| 18:24 |
ShadowNinja |
I heven't heard of that, but Lua doesn't guarantee the order. It's basically the C++ equivilant of s/pairs/ipairs/ |
| 18:25 |
PilzAdam |
what happens if I pass a table that has strings as keys to it? |
| 18:27 |
ShadowNinja |
luaL_checkinteger will throw a Lua error. (Something like "Invalid string argument for set_list, expected integer") |
| 18:28 |
|
diemartin joined #minetest-dev |
| 18:28 |
PilzAdam |
has it thrown errors previously, too? |
| 18:31 |
ShadowNinja |
It ignored the keys previously. ({["test"]=ItemStack(), [minetest.register_node]=ItemStack()} was vaild) |
| 18:31 |
ShadowNinja |
read_item handles bad ItemStacks in both cases. |
| 18:32 |
PilzAdam |
well, you shouldnt change that behaviour |
| 18:33 |
ShadowNinja |
What? We should support string keys in InventoryLists? Should strings be randomly inserted in the list? |
| 18:33 |
PilzAdam |
no, it should just ignore it |
| 18:34 |
ShadowNinja |
It's obviously an error, it shouldn't be simply ignored. |
| 18:41 |
celeron55 |
it should throw an error |
| 18:41 |
celeron55 |
i don't understand PilzAdam at all in this |
| 18:42 |
celeron55 |
it was obviously not designed to not throw an error |
| 18:42 |
ShadowNinja |
Alright, push it? |
| 18:43 |
PilzAdam |
dont be suprised if mods will stop working suddenly |
| 18:44 |
ShadowNinja |
If they do then they were very glitchy before due to random inventories. |
| 18:50 |
ShadowNinja |
So, I guess I'll push it soon... Unless someone has something more to say. |
| 18:54 |
|
AllegedlyDead joined #minetest-dev |
| 19:03 |
ShadowNinja |
Next: http://ix.io/9Ac PilzAdam, celeron55: ^ |
| 19:03 |
ShadowNinja |
s/^/</ |
| 19:04 |
|
sapier joined #minetest-dev |
| 19:10 |
ShadowNinja |
I only found that one commit from Freeminer that looked good in the first few pages. |
| 19:10 |
ShadowNinja |
sapier: What do you think about ^? (See logs) |
| 19:14 |
sapier |
the opengles commit? |
| 19:19 |
VargaD |
hi sapier |
| 19:25 |
|
Evolykane joined #minetest-dev |
| 19:28 |
PilzAdam |
ShadowNinja, its good if it works |
| 19:28 |
sapier |
SUCCESS ... tcp client joining for the first time :-) |
| 19:31 |
thexyz |
sapier: is the source available anywhere? |
| 19:32 |
sapier |
I'm about to push it ... expect it to crash not work for everything be unpolished, print a lots of error/debug messages ;-) |
| 19:33 |
sapier |
it's bleading edge ... really bleading, it's crashing 100% reproducable on disconnect right now :-= |
| 19:34 |
sapier |
https://github.com/sapier/minetest/tree/tcp_connection_support |
| 19:34 |
sapier |
I guess I should push the wireshark file too wait a moment |
| 19:35 |
sapier |
don't expect the wireshark support to be perfect too, I don't have any idea how to write those addons it's just doing something that did help me ;-) |
| 19:36 |
sapier |
ok all pushed |
| 19:38 |
sapier |
wow downloading media is way better then even my fixed udp protocol and that was way better then last core implementation |
| 19:41 |
proller |
and better than enet? |
| 19:42 |
PilzAdam |
sapier, downloading from the Minetest server, I assume? |
| 19:42 |
sapier |
non curl yes |
| 19:42 |
proller |
and better than http? |
| 19:43 |
sapier |
no idea you can have try if your interested |
| 19:43 |
proller |
why not embed small http server into MT? |
| 19:43 |
proller |
except NIH |
| 19:44 |
ShadowNinja |
Because we don't need a HTTP server. |
| 19:44 |
proller |
but neex complex buggy BLOAT protocol? |
| 19:44 |
proller |
need |
| 19:44 |
sapier |
why do you always want to embedd thousands of non required features and think this is more efficient? |
| 19:45 |
|
Miner_48er joined #minetest-dev |
| 19:45 |
proller |
tcp also not required here |
| 19:45 |
sapier |
even minetest protocol itself is neither broken nor complex nore buggy only thing beeing broken WAS implementation |
| 19:45 |
proller |
you can get 6mbps only by tuning current connection |
| 19:45 |
sapier |
and the most critical bug was even simple just noone even dared to check |
| 19:46 |
VargaD |
but HTTP is faster than TCP :D (one of my coworker said that) |
| 19:46 |
thexyz |
yeeah, not broken, just slow as hell |
| 19:46 |
proller |
facepalm.jpg |
| 19:46 |
sapier |
lots of slowness wasn't result of protocol but implementation too |
| 19:47 |
proller |
and stupid defaults |
| 19:47 |
sapier |
does anyone want to to tell risk of enet becomming orphaned is anywhere near risk of tcp getting orphaned? :-) |
| 19:48 |
sapier |
tcp is os part, no need for additional libs, no bugfixing nothing |
| 19:48 |
VargaD |
embedding a http server isn't that bad idea |
| 19:48 |
sapier |
embedding a http server is useless as hell |
| 19:48 |
proller |
if you cant fix current, why you think you can make good tcp? |
| 19:49 |
proller |
tcp more useless useless |
| 19:49 |
sapier |
you're wrong about it I fixed current ;-P |
| 19:49 |
thexyz |
does it work? |
| 19:49 |
thexyz |
last time I tried it enet still was faster |
| 19:49 |
thexyz |
so let's just add TCP on top! because TCP is reliability (what we need), it can't be bad! |
| 19:49 |
sapier |
yes most likely enet will ever be as it doesn't have to stick to some limitations of old protocol |
| 19:50 |
thexyz |
even though we have TCP-over-UDP implementation which sucks we'll just add TCP and everything will be better! |
| 19:50 |
thexyz |
also we get compatibility no one actually cares about but we love compatibility, right? |
| 19:50 |
sapier |
no I didn't implement tcp on udp |
| 19:50 |
thexyz |
I mean, what could go wrong |
| 19:50 |
sapier |
don't mix up things |
| 19:51 |
thexyz |
and then if it still is not fast enough let's just add more stuff to it |
| 19:51 |
thexyz |
I mean, stuff that can't be bad |
| 19:51 |
thexyz |
whoa, do you mean we don't have tcp-over-udp here? |
| 19:51 |
thexyz |
how should I call it then? |
| 19:52 |
sapier |
we have as much tcp-over-udp as enet has |
| 19:52 |
thexyz |
indeed |
| 19:52 |
thexyz |
there's one difference |
| 19:52 |
proller |
maybe implenent SMB for sharing files and map parts? |
| 19:52 |
VargaD |
some things won't need resend -> udp, some things need to be reliable but we don't carfe about latency -> tcp |
| 19:52 |
thexyz |
our implementation sucks, enet doesn't |
| 19:52 |
thexyz |
anyway, it'll be fun to compare so keep working on it |
| 19:52 |
sapier |
yes but WHY the hell use ANY tcp-over-udp variant if we don't have to do crap like that ? ;-P |
| 19:53 |
thexyz |
sure just use both |
| 19:53 |
proller |
sapier, kahrl fix better crashes |
| 19:53 |
thexyz |
udp for non-reliable and tcp for reliable |
| 19:53 |
thexyz |
such design |
| 19:53 |
sapier |
use right tool for right thing design |
| 19:53 |
proller |
linux sometimes crashes too on shutdown |
| 19:54 |
sapier |
do you really believe enet can compete to tcp as of reliability/support/proofensess ? |
| 19:54 |
thexyz |
meanwhile, wtf |
| 19:54 |
proller |
use two tools where one is enough - bad design |
| 19:54 |
thexyz |
cyrillic input doesn't work for me anymore |
| 19:54 |
sapier |
of course, you use a butcher knife for your steak because you don't want to make your steak knife dirty :-) |
| 19:55 |
sapier |
because using two tools is inefficient ;-) |
| 19:55 |
thexyz |
to me it looks like you're doing this stuff because you find it fun |
| 19:55 |
celeron55 |
just make something that works perfectly and nobody will have anything to complain about |
| 19:55 |
celeron55 |
simple 8) |
| 19:55 |
sapier |
there's nothing that will ever work perfect celeron55 ;-) |
| 19:55 |
thexyz |
and it's fun to you right now, you don't care much about whether it'll be fun for you to support, say, the next year |
| 19:55 |
thexyz |
(that's how I see it, at least) |
| 19:56 |
celeron55 |
(enet has it's issues including lack of ipv6 so nothing is perfect to begin with; this is an open-ended issue as long as nothing is in the upstream repo) |
| 19:56 |
sapier |
and you don't care about beeing fun to replace orphaned enet in a year or so |
| 19:56 |
thexyz |
sure |
| 19:56 |
thexyz |
a library which is 9 years old |
| 19:56 |
celeron55 |
its* |
| 19:56 |
thexyz |
will be deprecated the next year |
| 19:56 |
|
khonkhortisan joined #minetest-dev |
| 19:56 |
sapier |
as tcp will be deprecated next year ;-) |
| 19:56 |
thexyz |
adding ipv6 to it for sure is a harder task that implementing another protocol support |
| 19:56 |
thexyz |
I really don't understand it |
| 19:57 |
thexyz |
if that's your only argument |
| 19:57 |
sapier |
there is NO OTHER PROTOCOL |
| 19:57 |
sapier |
protocol is TCP |
| 19:57 |
celeron55 |
this is really pretty stupid; making all these solutions work simultaneously is a lot of effort for the sake of being able to compare them (nothing but one of them will be used in the end anyway) |
| 19:57 |
thexyz |
well, there's UDP and you're adding TCP so you're adding a protocol, no? |
| 19:57 |
sapier |
yes celeron |
| 19:58 |
thexyz |
stupid indeed |
| 19:58 |
proller |
sapier, use 2 ports for one application - BAD |
| 19:58 |
celeron55 |
but i don't want to dictate; i want to believe that people will make sane choices themselves |
| 19:58 |
sapier |
an enet isn't adding 2 new protocolsß |
| 19:58 |
celeron55 |
so please do sane choices, ok? |
| 19:58 |
thexyz |
anyway, it seems that MT is going with UDP/TCP and FM with enet |
| 19:58 |
VargaD |
one port just use both TCP and UDP |
| 19:58 |
thexyz |
also by not just dropping the compatibility you won't be able to do fun things like key-value protocol |
| 19:58 |
proller |
enet+messagepack |
| 19:58 |
sapier |
this discussion is far from technical celeron there most likely wont be a sane choice |
| 19:58 |
proller |
VargaD, it 2 rules in firewall |
| 19:58 |
celeron55 |
if FM goes with enet, then MT using something else is probably not a good idea because the projects can't support each other |
| 19:58 |
sapier |
so 2 new protocols + 1 new packet format |
| 19:59 |
proller |
you must forwart 2 ports via router, etc |
| 19:59 |
thexyz |
brb, bisecting |
| 19:59 |
celeron55 |
altough people like to hate the other project, in the long run nothing is worse than having two implementation of the same thing |
| 19:59 |
VargaD |
you can do hole punching with UDP, and not with TCP |
| 20:00 |
VargaD |
it would be nice to merge the two project, or at least maintain compatibility |
| 20:00 |
sapier |
both protocols have pro and cons ... depends on situation of usage |
| 20:00 |
proller |
supporting 2 protocols harder in 2 times for admins |
| 20:00 |
sapier |
none of you even dared to read enet code so don't tell me about supporting |
| 20:01 |
proller |
also ipv6 - it not stopper, who use ipv6 for MT (except one my server?) |
| 20:01 |
sapier |
lack of ipv6 support is a show stopper in long run |
| 20:01 |
thexyz |
I didn't read Linux kernel source code either yet I use it |
| 20:01 |
celeron55 |
proller: there have been people making issues about ipv6-related things, so those i guess |
| 20:01 |
thexyz |
I didn't read Irrlicht code |
| 20:01 |
thexyz |
I don't think there's a problem |
| 20:02 |
sapier |
so you compare reading 10 pages to reading 10million pages ? :-) |
| 20:02 |
thexyz |
and yeah, I'm not saying that enet is as solid as Linux kernel; just that it's probably better than what you can come up with |
| 20:03 |
proller |
celeron55, ipv6 is must-to-have thing, but actually NOW it only for geeks and 1-3% lucky users with good providers |
| 20:03 |
sapier |
I don't want to tell all the issues about enet again, it's not the proofen project you try to make it |
| 20:03 |
sapier |
and no comparison to tcp |
| 20:03 |
sapier |
it's not bad either I don't wanna tell that |
| 20:04 |
thexyz |
sure thing |
| 20:04 |
thexyz |
you're not willing to break protocol (for messagepack) |
| 20:04 |
thexyz |
got it |
| 20:05 |
sapier |
but yet you're breaking compatibility for what? for slightly better performance? for having right and adding something new? for having chance to breake protocol format too? |
| 20:06 |
sapier |
I don't see a pressing need for doing all those things, tell me where you see it |
| 20:07 |
thexyz |
for messagepack |
| 20:08 |
thexyz |
for the ability to extend the protocol |
| 20:08 |
thexyz |
in a sane way |
| 20:10 |
sapier |
and messagepack is the one and only sane way? |
| 20:11 |
sapier |
guess we need to add a messagepack lib too? |
| 20:11 |
VargaD |
bson? |
| 20:11 |
thexyz |
proller told me it was the fastest one |
| 20:11 |
sapier |
so another piece of code we don't know how to maintain? |
| 20:12 |
thexyz |
wow! it really is pointless to talk to you; do you think it's better to reimplement everything than to depend on external libraries? |
| 20:12 |
thexyz |
this is really a weird case of NIH |
| 20:12 |
proller |
sapier, why your bots.. not working? |
| 20:13 |
sapier |
no it isn't there's no need to use external libraries for most simple things |
| 20:13 |
thexyz |
ah sure thing |
| 20:13 |
thexyz |
let's write our own serializer then |
| 20:13 |
thexyz |
anyway, since it's not going to happen why talk about it? it really is pointless |
| 20:13 |
sapier |
why don't you replace main server loop by external lib? there are gamelibs out there too |
| 20:13 |
VargaD |
sapier: do we really need an own serializer? |
| 20:14 |
thexyz |
sapier: can you point me at some? |
| 20:14 |
proller |
main server loop is terrible singleplayer thing. |
| 20:14 |
sapier |
varga we already have 3 serializers last one was added by ShadowNinja |
| 20:14 |
VargaD |
wow |
| 20:14 |
VargaD |
thats a lot, we should use only one :) |
| 20:15 |
proller |
json! |
| 20:15 |
sapier |
yes that's why I was against adding the last one |
| 20:15 |
VargaD |
what is the last one? |
| 20:16 |
sapier |
the first two are at least functional different the last one is a 1:1 feature identical replacement ... exept for proller he get's shiny eyes on seeing it as it's serializing to his beloved json format ;-P |
| 20:16 |
thexyz |
22a59b3912ff5e7bb1516faa06f1841545a8117c is the first bad commit |
| 20:16 |
thexyz |
commit 22a59b3912ff5e7bb1516faa06f1841545a8117c |
| 20:16 |
thexyz |
Author: sapier <Sapier at GMX dot net> |
| 20:16 |
sapier |
what's that commit about? |
| 20:16 |
|
Evolykane joined #minetest-dev |
| 20:16 |
sapier |
and what's the bug |
| 20:16 |
thexyz |
fix windows i18n blah blah ugly blah microsoft? |
| 20:17 |
thexyz |
can't input cyrillic on linux |
| 20:17 |
sapier |
broken cyrillic? fix your os |
| 20:17 |
sapier |
set language correctly |
| 20:17 |
sapier |
set correct codepage |
| 20:17 |
thexyz |
how? |
| 20:17 |
proller |
wat& |
| 20:17 |
sapier |
what's your LANG and LANGUAGE? |
| 20:18 |
sapier |
btw that was added ages ago why do discover it now? |
| 20:18 |
thexyz |
https://gist.github.com/xyzz/895b992c8d640bb00b5c/raw/ba4095fee5b90a0a7d6eada413e82f4098866c34/gistfile1.txt |
| 20:18 |
thexyz |
well because I discovered it now |
| 20:18 |
sapier |
of course you can't enter cyrilic with setting to US ;-) |
| 20:19 |
thexyz |
reaaaally? |
| 20:19 |
thexyz |
why does every other app work then? |
| 20:19 |
sapier |
maybe because of more sane in app code not doing conversion hundreds of times? |
| 20:19 |
VargaD |
hungarian characters also don't work |
| 20:19 |
sapier |
if you don't convert noone will realize broken charset |
| 20:20 |
thexyz |
maybe because it's UTF-8 and it shouldn't matter? |
| 20:20 |
thexyz |
anyway |
| 20:20 |
thexyz |
what should I set it to for it to work? |
| 20:20 |
sapier |
check if input really is utf8 |
| 20:20 |
sapier |
I assume ru_RU.UTF-8 should work |
| 20:20 |
VargaD |
probably it is my fault... |
| 20:21 |
thexyz |
sapier: I set export LANG=ru_RU.UTF-8; export LANGUAGE=ru; export LC_ALL=ru_RU.UTF-8 |
| 20:21 |
thexyz |
sapier: still doesn't work |
| 20:21 |
thexyz |
plz fix |
| 20:22 |
|
Calinou joined #minetest-dev |
| 20:24 |
sapier |
no I won't touch that i18n thing anymore I'm done with it whenever you fix something you break something else |
| 20:25 |
sapier |
the one beeing in there is best I can do, guess that one needs a more i18n skilled person |
| 20:25 |
thexyz |
fine |
| 20:25 |
sapier |
but I know for sure cyrillic is working as I did test it |
| 20:25 |
thexyz |
break everything, don't care to fix it |
| 20:26 |
thexyz |
adding setlocale(LC_ALL, "") to main.cpp apparently fixes it |
| 20:26 |
sapier |
do you have gettext enabled? |
| 20:26 |
thexyz |
hm, no |
| 20:26 |
sapier |
for you ... but most likely will break on windows |
| 20:26 |
VargaD |
I got _ characters instead of öüóúőűáé |
| 20:27 |
VargaD |
LC_ALL=hu_HU.UTF-8 |
| 20:27 |
sapier |
there are about 100 combinations to check if you change anything in locales and charset |
| 20:27 |
thexyz |
okay, building it with gettext apparently fixes it; still strange |
| 20:27 |
thexyz |
since gettext isn't enabled by default |
| 20:27 |
VargaD |
building with gettext wupport isn't default? |
| 20:27 |
sapier |
not strange I did do the localization fixes with gettext enabled so I may have missed that one |
| 20:28 |
thexyz |
anyway, it's fine this way then |
| 20:29 |
sapier |
it's almost impossible to test any i18n build variant thexyz if you found a bug in non gettext variant check the other variants and merge it |
| 20:29 |
VargaD |
oh it isn't :( |
| 20:29 |
thexyz |
don't care anymore since it works |
| 20:29 |
sapier |
especially windows build variants are ugly |
| 20:30 |
VargaD |
thanks thexyz that solved to problem, it was my fault after all... |
| 20:34 |
celeron55 |
well shit |
| 20:34 |
VanessaE |
not here. |
| 20:34 |
VanessaE |
it stinks and draws flies. |
| 20:34 |
celeron55 |
but shit is here |
| 20:35 |
sapier |
can't we dropp i18n support and stick to english with utf8? ;-) |
| 20:35 |
sapier |
gettext is our own best example for something we should've invented ourselfs ;-) |
| 20:35 |
thexyz |
yeah sure |
| 20:36 |
celeron55 |
how the fuck can all these things be so difficult to handle and choose |
| 20:36 |
VanessaE |
celeron55: because NIH |
| 20:36 |
VargaD |
shouldn't gettext and freetype used by default? |
| 20:36 |
VargaD |
as least we should mention them in build docs... |
| 20:36 |
celeron55 |
what i |
| 20:36 |
sapier |
both are quite tricky on windows |
| 20:37 |
celeron55 |
what i'm seeing now is that sapier is pretty much alone with his stuff |
| 20:37 |
thexyz |
VargaD: yeah they should |
| 20:37 |
VanessaE |
celeron55: not entirely. |
| 20:37 |
VargaD |
how many people build minetest on windows? |
| 20:37 |
celeron55 |
is this what others are seeing? |
| 20:37 |
VanessaE |
kizeren and I have been testing his fork on our servers. |
| 20:37 |
thexyz |
VargaD: we usually don't care about it |
| 20:37 |
VargaD |
the windows build on forums has freetype and gettext support |
| 20:37 |
sapier |
seems everytime I improve something I get responsible for the remaining bugs too ;-) |
| 20:38 |
thexyz |
well I said this didn't matter since there's a way to make it work |
| 20:38 |
VanessaE |
(at least for his work on the UDP/TCP stuff aka media_FUBAR) |
| 20:38 |
thexyz |
so I'm not blaming anyone |
| 20:38 |
nore |
about those locales things, btw: was the "Local install" button fixed? |
| 20:38 |
thexyz |
and I'm sure others don't either |
| 20:39 |
VanessaE |
VargaD: I've taken something of an odd liking to the new shadowed text even over my own font, though I think I'd prefer it to be double-shadowed, so maybe even I could suggest freetype enabled by default. gettext, I have no opinion on. |
| 20:39 |
ShadowNinja |
nore: Nope, it's been ignored so far. |
| 20:40 |
thexyz |
there's no reason not to enable gettext |
| 20:40 |
VargaD |
nearly all the linux distributions has gettext by default and you can't even remove it |
| 20:41 |
celeron55 |
is there nobody else in here who thinks separating freeminer and minetest even on the network level is probably a really bad idea and should be avoided? |
| 20:41 |
celeron55 |
seriously; this will affect so many things in the future that nobody should be even thinking anything else until there is a proper plan |
| 20:41 |
VanessaE |
celeron55: it is a bad idea, absolutely. the two projects need to remain cross-compatible imho. |
| 20:41 |
thexyz |
that's only bad for FM |
| 20:41 |
celeron55 |
i don |
| 20:42 |
celeron55 |
i don't really care for any particular project as i can't foresee which (or whether both) will ultimately succeed |
| 20:42 |
VanessaE |
at least to the point where one can connect to the other, even if one can't necessarily run code meant for the other. |
| 20:43 |
VargaD |
thexyz: it is bad for both projects |
| 20:43 |
celeron55 |
client compatibility is quite a large goal if actual development is going to be made and things aren't just left to rot |
| 20:43 |
celeron55 |
so we either choose to have it or not |
| 20:43 |
|
sapier1 joined #minetest-dev |
| 20:44 |
celeron55 |
thexyz: will FM use sapier's implementation if it goes into minetest? |
| 20:45 |
celeron55 |
(of course assuming it actually works well) |
| 20:45 |
thexyz |
we plan to switch to key-value protocol, so no |
| 20:45 |
thexyz |
I mean, it'll be incompatible anyway |
| 20:45 |
celeron55 |
so FM isn't going to be client-compatible in any case? |
| 20:45 |
celeron55 |
what if i want that same key-value protocol in minetest? |
| 20:46 |
thexyz |
well if you're breaking compatibility anyway then why not add enet? |
| 20:46 |
sapier1 |
we'd have to either merge all of freeminer (including the broken history) or extract the necessary fixes on our own |
| 20:46 |
celeron55 |
i'm not the one yearning for backwards compatibility |
| 20:46 |
celeron55 |
it seems to be sapier's personal thing |
| 20:47 |
sapier1 |
thexyz already told he's not gonna provide pulls for minetest |
| 20:47 |
sapier1 |
And don't expect me to do it ;-P |
| 20:47 |
thexyz |
yeah and since adding KV would take a lot of time then we'll be in sync for quite some time |
| 20:48 |
VargaD |
hey we need to work together |
| 20:48 |
celeron55 |
it would be insane to leave such positive development out of minetest (as compared to proller's weather stuff and whatever that was *actually* controversial) |
| 20:48 |
thexyz |
well that's only how you're seeing it |
| 20:48 |
celeron55 |
i know i'm biased |
| 20:49 |
thexyz |
I'm sure sapier1, for example, sees both weather and kv protocol as ugly useless things or something |
| 20:49 |
sapier1 |
I think the way the weather improvements have been done are controversial too ... not talking about the feature itself |
| 20:49 |
celeron55 |
thexyz: and is there anyone else? |
| 20:50 |
sapier1 |
If I didn start a new project kv would be my choice too but this isn't situation |
| 20:50 |
VanessaE |
we have a new problem with backward compatibility though |
| 20:50 |
VanessaE |
this damn buildcraft is exploding |
| 20:50 |
VanessaE |
users are coming out of the woodwork |
| 20:51 |
thexyz |
no worries we've already submitted a few dmca requests |
| 20:51 |
VanessaE |
I don't mean like that |
| 20:51 |
celeron55 |
i think the only real way to combat it is to build a competing program |
| 20:51 |
VanessaE |
I mean,m do we break compatibility with it, which is basically 0.4.8-stable? |
| 20:51 |
celeron55 |
and if nobody does it, then whatever; fail for that part |
| 20:51 |
celeron55 |
VanessaE: of course |
| 20:52 |
VanessaE |
mmmh |
| 20:52 |
celeron55 |
they'll update to the new one in no time anyway; why wouldn't they |
| 20:52 |
thexyz |
true |
| 20:52 |
sapier1 |
celeron55 for what reason? I'm all in if someone manages to persuade me with some real benefits |
| 20:52 |
thexyz |
they're illegal though |
| 20:53 |
sapier1 |
to me all of this seems like the other "json is better then xml" thingy |
| 20:53 |
celeron55 |
sapier1: there are no real benefits other than short-sighted compatiiblity in your way, so you can't demand much of those |
| 20:53 |
VanessaE |
celeron55: for the same reason that their current source release is already 2 months old - some combination of lack of time, stubbornness, and perhaps a bit of laziness |
| 20:54 |
thexyz |
anyway, my point is: if we decide to break compatibility then we should go with enet; if we go with sapier's solution then we shouldn't break compatibility in some other way |
| 20:54 |
thexyz |
*any other way |
| 20:54 |
sapier |
so why the hell have I been punched that often to keep compatibility at each single lua fix? |
| 20:54 |
sapier |
no matter how insane that was |
| 20:54 |
thexyz |
because his tcp/udp stuff is good for exactly that reason — compatibility with current clients |
| 20:54 |
celeron55 |
i'm with thexyz; it just makes sense to break compatibility now that not much else is happening so that there is a good base for new stuff in the future |
| 20:55 |
thexyz |
sapier: I don't know, was that me who punched you? |
| 20:55 |
sapier |
so we switch to a protocol not beeing evaluated not beeing any standard not beeing driven by any community? |
| 20:56 |
thexyz |
the only problem is that we probably won't find anyone willing to do kv |
| 20:56 |
proller |
but kv transfer needed for future evolution.. |
| 20:56 |
sapier |
you want it thexyz you do i |
| 20:56 |
sapier |
t |
| 20:56 |
celeron55 |
but really, this is partly an organizational solution too; if minetest and freeminer have dual efforts here, the community overally loses |
| 20:56 |
thexyz |
sapier: sure thing |
| 20:56 |
sapier |
the community already lost due to lack of decision |
| 20:56 |
sapier |
face it |
| 20:56 |
thexyz |
sapier: and how exactly your stuff is better in that way? |
| 20:56 |
celeron55 |
sapier: why are you developing then? |
| 20:57 |
thexyz |
not beeing evaluated not beeing any standard not beeing driven by any community? |
| 20:57 |
sapier |
because tcp/udp was yesterdays decison to do it |
| 20:57 |
thexyz |
I'm talking about UDP part |
| 20:57 |
sapier |
I will not do a third implementation for sure |
| 20:57 |
celeron55 |
this project exists for the community, and if it fails in something, it doesn't mean it couldn't find a way to recover |
| 20:57 |
proller |
but i think keep kv and old format possible, in cost of ugly dual code |
| 20:57 |
VanessaE |
sapier: didn't you tell them? |
| 20:58 |
sapier |
you can do what you want kv or not that's not related to protocol at all |
| 20:59 |
celeron55 |
sapier: it's not my fault that it's so hard to see where the progress is going as everyone is just ignoring everyone else |
| 20:59 |
thexyz |
but it is |
| 20:59 |
thexyz |
if we break compatibility anyway then why not add enet? since it's better |
| 20:59 |
celeron55 |
sapier: (and you don't have to do a third implementation) |
| 20:59 |
sapier |
it's hard to see celeron55???? you're kidding, I told multiple times I'm working on tcp support he last days |
| 20:59 |
sapier |
it's been even thexyz who made me realize decision was to do tcp/udp .... |
| 21:00 |
sapier |
guess he did say that expecting not getting any working tcp implementation at all |
| 21:00 |
celeron55 |
sapier: i know what you're doing, but i didn't hear about these further protocol rework plans of thexyz & co |
| 21:00 |
sapier |
packet format != protocol |
| 21:00 |
thexyz |
sapier: I said that because you asked what the decision was |
| 21:00 |
celeron55 |
same thing, different level |
| 21:01 |
sapier |
no if you don't mess up layers you can transfere any packet format with a protocol |
| 21:01 |
sapier |
-e |
| 21:01 |
thexyz |
celeron55: those are just plans that could be delayed for undefined amount of time due to no free time |
| 21:02 |
|
djdduty joined #minetest-dev |
| 21:02 |
thexyz |
sapier: yeah but if you do kv protocol then you don't want to support the old one too |
| 21:02 |
celeron55 |
thexyz: in that case there isn't really any basis for any decision |
| 21:03 |
sapier |
guys I want a decision NOW udp fixes lack final polishing (which requires quite some time) and tcp lacks final stage of development I will not spend any additional time if decision to use enet no matter how much issues are left is already done |
| 21:04 |
sapier |
and no i wont do kv that's your whish if you want it do it yourself |
| 21:06 |
celeron55 |
so how are we supposed to make any decisions when we don't know when anyone is going to code anything |
| 21:06 |
celeron55 |
i guess we could just write a roadmap and expect people to follow it slowly but surely |
| 21:06 |
sapier |
I said what I'm doing |
| 21:06 |
sapier |
and I said what I'm not gonna do |
| 21:07 |
sapier |
I don't blame anyone for the time I spent on udp fixes as I did those for educational purposes |
| 21:07 |
celeron55 |
can you say why you would rather spend your time effectively re-implementing enet but not in making a key-value packet format? |
| 21:07 |
celeron55 |
that seems insane to me |
| 21:07 |
sapier |
because I see no actual benefit in switching the packet format |
| 21:07 |
sapier |
explain it to me |
| 21:08 |
celeron55 |
but it has obvious benefits; currently the packet formats are very messy to keep backwards-compatible and newbie developers break them all the time and everyone has to stress that |
| 21:08 |
sapier |
it's basicaly reqriting server and client ... much more effort then udp and tcp together |
| 21:08 |
celeron55 |
i don't believe so |
| 21:08 |
sapier |
have a look at it |
| 21:09 |
celeron55 |
it should be pretty straight-forward once the basic things are set up |
| 21:09 |
sapier |
it's a lot of typwrtiting testing fixing |
| 21:09 |
sapier |
for what? |
| 21:09 |
celeron55 |
thexyz: your words? |
| 21:11 |
celeron55 |
i don't want to force this with my personal opinions and hate it if no other sane person describe their view |
| 21:11 |
celeron55 |
proller? |
| 21:11 |
celeron55 |
kahrl? hmmmm? whoever; don't hide now |
| 21:12 |
celeron55 |
there obviously are alternative things to do too |
| 21:12 |
celeron55 |
like some more feature-like things |
| 21:13 |
celeron55 |
and whatever rework (locking?, whatever else) |
| 21:13 |
sapier |
of course comparing mt packet format to kv on green meadow I'd choose kv too ... but right now it's just a lot of work for some diffuse possible benefit in some distant future I'm not even sure it's gonna be real |
| 21:14 |
celeron55 |
it of course goes deeper than that; the same format would be used for the deeper data structures that are included in the packets, and maybe something on disk too |
| 21:15 |
sapier |
I don't even know what needs to be touched, usually I see a lot of things and I'm called to be pessimistic for this .... but most time it's even more then I see |
| 21:15 |
|
Gethiox joined #minetest-dev |
| 21:16 |
sapier |
and btw I'm for dropping UDP support in mid to long range too |
| 21:16 |
celeron55 |
all this could of course be just a big bad idea, which is why i really would appreciate input of others than us few who are already pissed off by this being so undecidable |
| 21:16 |
sapier |
UDP reliable |
| 21:20 |
sapier |
https://github.com/minetest/minetest/pull/1054 |
| 21:20 |
sapier |
hmmmm do you want to do a release the next days? |
| 21:22 |
celeron55 |
minetest seriously lacks developer time at the moment; it's kind of impossible to avoid the problems caused by that |
| 21:22 |
celeron55 |
this is a large project and getting a lot of "bang for the buck" for the time of a single developer is practically impossible |
| 21:22 |
sapier |
minetest lacks of management time not developer time that's what drove proller away and causes the current issues too |
| 21:23 |
sapier |
or management structure |
| 21:23 |
celeron55 |
it may be the deeper problem |
| 21:23 |
celeron55 |
the immediate problem is that though |
| 21:23 |
celeron55 |
you're free to suggest management structure |
| 21:24 |
sapier |
I tried this as much as others did without noticable effect |
| 21:24 |
VargaD |
sapier: move updates don't need to be teransmitted on package lost |
| 21:25 |
celeron55 |
proller had some "drive" to his doings, but his ways of doing things weren't approved by many, so proller was lost |
| 21:25 |
sapier |
by now we haven't found any way to decide on a common path if different parts of community drive minetest to different directions |
| 21:25 |
|
person22 joined #minetest-dev |
| 21:25 |
sapier |
and proller did join at a time where amost nothing was decided |
| 21:25 |
|
jin_xi joined #minetest-dev |
| 21:26 |
sapier |
move updates are transmitted unreliable |
| 21:26 |
|
person22 left #minetest-dev |
| 21:26 |
celeron55 |
i think we ultimately lack people who simultaneously have understanding of development and either play the game or know about game development |
| 21:26 |
VargaD |
you said you would like to drop UDP |
| 21:27 |
sapier |
I corrected this to UDP reliable vargaD ;-) |
| 21:27 |
VargaD |
oh sorry, I understand |
| 21:27 |
|
person22 joined #minetest-dev |
| 21:27 |
VargaD |
you are right (again) |
| 21:27 |
celeron55 |
we or i could search the community for people that are potentially like that and try to "recruit" them for the reward of getting minetest to progress |
| 21:27 |
sapier |
that'd be the perfect person celeron55 but I don't thing we'll find someone doing it this way |
| 21:28 |
celeron55 |
i don't think we have a chance of getting people from outside of the community to do things like that |
| 21:28 |
sapier |
maybe we could try something like linux kernel is doing subsystem responsibilities |
| 21:28 |
|
person22 left #minetest-dev |
| 21:28 |
VargaD |
that is a good idea |
| 21:28 |
celeron55 |
that has been suggested by me many times before, but i have no clue how to start it |
| 21:29 |
celeron55 |
hmmmm agreed to it too |
| 21:29 |
sapier |
I assume defining subsystems would be first step ;-) |
| 21:29 |
sapier |
e.g. script api, mapgen, server, networking, client |
| 21:29 |
sapier |
graphics |
| 21:30 |
sapier |
maybe split script api to ingame/menu |
| 21:30 |
celeron55 |
could work |
| 21:30 |
VargaD |
and we also need someone like Linus |
| 21:30 |
VargaD |
do the decision when the maintainers have conflict |
| 21:30 |
sapier |
that one would've to be celeron55 but I assume we don't get fsf to pay him anytime soon ;-) |
| 21:31 |
VargaD |
:) |
| 21:31 |
VargaD |
Can have have a better release schedule also? |
| 21:31 |
sapier |
and another thing, reliable strict merge rules |
| 21:31 |
sapier |
e.g. you need two agreements to merge a pull |
| 21:31 |
VargaD |
with this management it is totally easier to do proper release management |
| 21:32 |
celeron55 |
well i could try, but i don't have a lot of time so i would just be a way to connect the trust of people; i want to use time to progress my other projects |
| 21:32 |
sapier |
and those agreements have to be done as github comments |
| 21:32 |
sapier |
this way you don't have to interpret if some saying is a agreement or not |
| 21:32 |
VanessaE |
bbl |
| 21:33 |
VargaD |
celeron55: it is OK as long as minetest subsystem maintainers accepts your decisions |
| 21:33 |
celeron55 |
but frankly there aren't really alternatives to me, because hmmmm and kahrl are just as busy too |
| 21:34 |
celeron55 |
and thexyz and whoever other long-timer like that |
| 21:36 |
sapier |
I'd like to use the key value things too celeron55, at least if they're provided in a way we don't have as much work as doing it by our own ... last time I was told "merge freeminer" |
| 21:36 |
celeron55 |
well i'll say i'm ready to try; how do we choose subsystem maintainers? |
| 21:37 |
sapier |
I'd first try volonteers? |
| 21:37 |
sapier |
rba might be interested in graphics |
| 21:38 |
sapier |
maybe shadow is interested in scriptapi? |
| 21:38 |
sapier |
formspecs may be as big as beeing a own subsystem |
| 21:38 |
celeron55 |
i will direct my decisions based on the idea written by me in "the" blog post, unless the community clearly points out a problem in it - this is what the supposed-to-be maintainers can expect |
| 21:39 |
PilzAdam |
will we have 1 maintainer per subsystem, or more? |
| 21:39 |
celeron55 |
one that i trust; it's how it works |
| 21:40 |
celeron55 |
i also will have to trust the one to choose a second one wisely if needed |
| 21:40 |
celeron55 |
this brings up a problem in graphics, because i don't trust rba to make good graphical design decisions (coding-wise it's fine) |
| 21:41 |
sapier |
make visible changes to be agreeable by at least two core maintainers? |
| 21:41 |
sapier |
this would affect formspec and menu changes too |
| 21:43 |
sapier |
we don't need that rule as there still need to agree two core devs ... guess that's gonna be equivalent |
| 21:43 |
celeron55 |
i see an issue in this actually |
| 21:44 |
celeron55 |
sapier: i think if there is a division of responsibility, then the one responsible is free to choose how many agreements he wants |
| 21:44 |
sapier |
someone (guess you) needs to define some basic development directions ... e.g. keep compatibility, enforce usage of external libs, keep windows build ... in best case those directions don't request opposit things :-) |
| 21:44 |
|
Miner_48er joined #minetest-dev |
| 21:45 |
sapier |
(s)he's still free to want more |
| 21:45 |
celeron55 |
of course it's probably reasonable to ask someone other too usually, but there is no need for strict rules |
| 21:45 |
sapier |
demanding to at least two agreements is just a minimum requirement |
| 21:45 |
celeron55 |
why would you demand that? |
| 21:46 |
celeron55 |
currently that is in place mostly to make sure that someone who actually knows about the thing in question sees it |
| 21:46 |
sapier |
yes, it's gonna make work for maintainers more easy too |
| 21:47 |
celeron55 |
in a subsystem responsibility scheme, the one who sees it is the one who knows it, and thus is the one who can decide |
| 21:47 |
sapier |
he's the one who can decide not to merge it of course |
| 21:48 |
sapier |
100 agreements without maintainer agreement are worth nothing |
| 21:49 |
VargaD |
can we define precisly the subsystems? |
| 21:49 |
sapier |
I'd see dual agreement a minimum standard but if you want to do it in another way I'll accept it too. I just tell my opinion |
| 21:50 |
sapier |
right now the only real subsystem is scriptapo |
| 21:50 |
sapier |
-o+i |
| 21:50 |
|
Evolykane joined #minetest-dev |
| 21:51 |
sapier |
connection.cpp/.h have a quite defined interface too so this could be done without major changes too |
| 21:51 |
celeron55 |
so.... server, networking, scriptapi, mapgen, client, graphics |
| 21:51 |
celeron55 |
do we even have enough volunteers for these? |
| 21:51 |
sapier |
I'd give it a try |
| 21:52 |
celeron55 |
sapier: i'd leave it fuzzy for now; the precise limits will take shape as actual work is done |
| 21:52 |
PilzAdam |
https://github.com/minetest/minetest/blob/master/src/porting.cpp#L344 the function in this assert() is not called in release builds, which leads to broken paths in osx builds (http://irc.minetest.ru/minetest/2013-12-30#i_3522670) |
| 21:52 |
sapier |
thinking about server/client this may be even better to be a single subsys |
| 21:52 |
sapier |
but that's what a discussion is for |
| 21:53 |
sapier |
PilzAdam: I know I made this mistake too :-) but that one isn't mine |
| 21:53 |
VargaD |
proller, thexyz what do you think? |
| 21:56 |
celeron55 |
so... what will immediately happen if this organization takes place is that basically a single person will have the authority to decide the networking thing |
| 21:56 |
celeron55 |
(oh, and of course a single person can be responsible for multiple subsystems, if that person has more time than others) |
| 21:58 |
sapier |
of course, but that means that one is repsonsible for those decisions too |
| 21:58 |
celeron55 |
yes |
| 21:59 |
ShadowNinja |
Me, kahr|, and sapi3r probably knw most about ScriptApi; hmmm -> mapgen; hmmm, sapi3r, xyz -> protocol... |
| 21:59 |
celeron55 |
no, not many people for a single thing; there needs to be a main person always |
| 22:00 |
celeron55 |
that is the basis of straightforward decision making |
| 22:00 |
sapier |
but you know key value and networking would be in different subsystems on proposed subsystem structure? |
| 22:00 |
celeron55 |
yes, i just was thinking about that |
| 22:00 |
sapier |
as packet format is primary server/client thingy |
| 22:00 |
celeron55 |
it's not really an issue; those two responsibles will have to decide how to do it |
| 22:01 |
thexyz |
ShadowNinja: why would you think I know anything about the protocol? I'd say proller does |
| 22:01 |
celeron55 |
and they will then ejoy the results of whatever they decided 8) |
| 22:01 |
celeron55 |
enjoy* |
| 22:01 |
ShadowNinja |
thexyz: Because you wrote a enet patch. |
| 22:01 |
sapier |
do we need any rules about commit quality? |
| 22:02 |
ShadowNinja |
Yes, of course. |
| 22:02 |
sapier |
e.g. a commit comment telling what the commit is supposed to do? |
| 22:02 |
celeron55 |
we don't change commit quality rules |
| 22:02 |
celeron55 |
but they won't be checked by everybody |
| 22:03 |
sapier |
ok so it's up to you to clap those maintainers fingers not keeping the rules |
| 22:05 |
celeron55 |
(obviously anyone can) |
| 22:05 |
celeron55 |
(informally) |
| 22:06 |
celeron55 |
hmm, we should assign a documentation responsible too |
| 22:06 |
sapier |
*smile* guess that one will be very hard to find |
| 22:06 |
celeron55 |
well 8) there are that kinds of people around sometimes |
| 22:07 |
celeron55 |
it's not a full-time task anyway |
| 22:07 |
celeron55 |
(as if anything is) |
| 22:07 |
|
Miner_48er joined #minetest-dev |
| 22:10 |
celeron55 |
how about on-disk formats? |
| 22:11 |
celeron55 |
if one responsibilty is server/client, then that doesn't go there |
| 22:11 |
celeron55 |
let's say server-other is for stuff like that |
| 22:12 |
celeron55 |
(includes configuration and whatever) |
| 22:14 |
celeron55 |
hmm, this is a tad too vague |
| 22:16 |
sapier |
isn't on disk format part of map/mapgen? |
| 22:16 |
celeron55 |
imo not at all |
| 22:17 |
sapier |
I don't know much about it that subsys is one of those things I haven't done anything by now |
| 22:17 |
celeron55 |
i'll try to make a sane proposal of subsystems |
| 22:18 |
celeron55 |
PilzAdam: are you able to point out a part in minetest the development of which you would like to be responsible of? |
| 22:18 |
celeron55 |
same goes for others; sapier? |
| 22:20 |
celeron55 |
of course responsibility doesn't mean at all that you need to code that thing; but you need to be ready to at least accept/decline stuff related to it |
| 22:20 |
sapier |
right now I know most about networking. Scriptapi is kind of completed right now and shadows knowledge is more fresh than mine. I guess I could do most usefull work on server/client right now (fixing the environmental locks). |
| 22:21 |
sapier |
but I guess I'll open up some conflicts on server rework too :-) |
| 22:23 |
celeron55 |
hmm, we need to get used to switching these sometimes tooo i guess |
| 22:23 |
PilzAdam |
hmmmmmm |
| 22:23 |
sapier |
right now I don't think you have a way to make everyone happy |
| 22:24 |
PilzAdam |
Im mostly interested in "game logic"; i.e. node/time properties and behaviour, player movement, and other stuff that is directly visible to the players |
| 22:25 |
PilzAdam |
s/time/item/ |
| 22:25 |
sapier |
e.g. if thexyz is responsible for networking and I am for server I guess enet will be added (by some time) but kv wont be added soon |
| 22:25 |
sapier |
as my primary focus would be removing as much locking as possible and packet format isn't an issue for this |
| 22:27 |
celeron55 |
i'm going to put thexyz on build system |
| 22:27 |
PilzAdam |
my "goal" with it would be to make it as generic as possible, to give the Lua games more possibilities |
| 22:27 |
sapier |
I fully support that goal |
| 22:28 |
sapier |
btw I might even switch to enet instead of tcp ... but not in that incompatible way proller and thexyz suggested |
| 22:29 |
PilzAdam |
and Id like to help whoever gets the API |
| 22:30 |
sapier |
guess I'm gonna have some improvements for lua too ;-) |
| 22:30 |
celeron55 |
is there anyone in here who would like to work on *sound*? i think someone was talking about it |
| 22:31 |
celeron55 |
(of course wish to work on something isn't equal to ability to judge it, but it's a starting point) |
| 22:31 |
ShadowNinja |
These assignments should be noted on the dev wiki. |
| 22:31 |
celeron55 |
hmm, taoki |
| 22:32 |
PilzAdam |
eh, dont mix minetest_game with engine now |
| 22:32 |
sapier |
as well as the files that make that subsystem :) |
| 22:33 |
celeron55 |
PilzAdam: yeah, it isn't worth a subsystem; just trying to figure out what things i bundle together |
| 22:33 |
PilzAdam |
I would count the sound triggers in the engine to "game logic" |
| 22:34 |
celeron55 |
https://gist.github.com/celeron55/8189279 |
| 22:34 |
celeron55 |
current draft |
| 22:35 |
sapier |
what's meant with dedicated? |
| 22:36 |
celeron55 |
the dedicated way of running the server (as opposed to with the client) |
| 22:37 |
sapier |
isn't that hard to split? |
| 22:37 |
celeron55 |
it's currently quite tightly squeezed together with the client startup though |
| 22:37 |
celeron55 |
hmm let's see |
| 22:37 |
celeron55 |
server/config/dedicated -> startup/config? |
| 22:37 |
sapier |
guess we need to do some adjustments once we got some experience with it |
| 22:38 |
celeron55 |
i'm going with startup/config for that |
| 22:39 |
celeron55 |
PilzAdam's thing doesn't really fit in any of this stuff; it's more like a theme than a certain part of minetest |
| 22:40 |
celeron55 |
and this has to be done with physical parts |
| 22:40 |
sapier |
if this is anything at all it's server |
| 22:40 |
sapier |
but builtin and scriptapi match equaly |
| 22:45 |
|
testman42 joined #minetest-dev |
| 22:46 |
celeron55 |
a vast majority of the startup/config code seems to be still directly from my hands |
| 22:47 |
sapier |
yes i guess last one to touch this was me on adding the lua startmenu |
| 22:47 |
sapier |
at least client part |
| 22:47 |
celeron55 |
i guess i can take the responsibility of that for now |
| 22:47 |
|
NakedFury joined #minetest-dev |
| 22:47 |
celeron55 |
so wtf about client/audiovisuals |
| 22:49 |
celeron55 |
i think rba's work there is too controversial |
| 22:50 |
celeron55 |
and i don't think he'd care about that responsibility anyway |
| 22:50 |
sapier |
I'm not sure about it most time ppl just don't want to try it ;-) or don't really care about it |
| 22:51 |
celeron55 |
i can assign it to myself and try to get rid of it as soon as someone suitable can take it |
| 22:52 |
celeron55 |
by doing that this kind of reflects the current development situation i guess |
| 22:53 |
sapier |
true |
| 22:53 |
celeron55 |
as these are supposed to subsystems, a good reality test should be that whether they could possibly be eventually located in their own subdirectories |
| 22:54 |
sapier |
but it's a starting point if we keep on pushing this direction we may succeed |
| 22:54 |
celeron55 |
and indeed these could |
| 22:55 |
sapier |
but for now it doesn't seem a common accepted direction PilzAdam seems to be at least not against it thexyz and proller don't say anything bout it ... sfan5 ShadowNinja and hmmmm don't tell anything (by now) too |
| 22:57 |
celeron55 |
yeah, let's let people comment on it (https://gist.github.com/celeron55/8189279) |
| 22:58 |
|
iqualfragile_ joined #minetest-dev |
| 22:58 |
celeron55 |
the way this would (should, could) work in practice is that the person marked for the subsystem is allowed to push/merge stuff related to that subsystem into upstream |
| 22:59 |
celeron55 |
and... not really other rules |
| 22:59 |
celeron55 |
usage of common sense should make the rest of it |
| 23:00 |
celeron55 |
(including following the applicable rules/practices we have now) |
| 23:01 |
celeron55 |
the way this changes the decision making is that there is almost always a person to blame for a hanging pull request, unlike now when it's everyone's = nobody's responsibility |
| 23:01 |
celeron55 |
(the most radical thing in it, i mean) |
| 23:02 |
sapier |
we all know you never can see every sideeffect |
| 23:04 |
sapier |
and if some maintainer requests another core dev to agree to a commit I'd assume it to be rude if all others refuse to check fixes (at least if they are checkable) |
| 23:04 |
PilzAdam |
many pull requests touch multiple subsystems |
| 23:04 |
sapier |
PilzAdam: this will improve by time |
| 23:05 |
celeron55 |
PilzAdam: in those cases it's simple (altough not as efficient): each of the maintainers must agree on it (and sort it out between themselves) |
| 23:05 |
PilzAdam |
sapier, "improve"? |
| 23:05 |
sapier |
in best case subsystems have defined interfaces ... of course this ain't possible everywhere but for most things it is |
| 23:05 |
PilzAdam |
celeron55, in this case there is not a single person to blame if the pull request hangs forever |
| 23:06 |
celeron55 |
PilzAdam: yeah, but there's 2 or 3 instead of the full core team |
| 23:06 |
sapier |
if someone is responsible the one might be more motivated to do it too ;-) |
| 23:06 |
PilzAdam |
sapier, if I want to add a new node property, it will touch api, server (for sending it), client (for handling it) and maybe graphics too |
| 23:07 |
sapier |
yes but I guess in practice noone will refuse changes like that ... at least if you don't add a 100mb property ;-) |
| 23:08 |
celeron55 |
we'll see if that works or not; if not, i guess we can figure out something |
| 23:08 |
sapier |
I guess if not it's just gonna be same as now ;-) |
| 23:08 |
thexyz |
okay, I'm fine with doing buildcrap |
| 23:09 |
thexyz |
this involves stuff like enabling freetype by default or so, right? |
| 23:09 |
thexyz |
and making sure this shit builds where it should |
| 23:09 |
celeron55 |
yes |
| 23:10 |
celeron55 |
all the cmake files are yours |
| 23:10 |
celeron55 |
i put you there because you do some windows builds sometimes 8) |
| 23:10 |
thexyz |
alright |
| 23:13 |
celeron55 |
aand then the one part of this idea is that there is a... ehm, let's call it Linus; so there is a Linus (lol) who comes officially into play only if two subsystem maintainers can't make a decision on something that affects both of them (of course there are "unofficial" discussions all the time between any people, eg. this channel just like now) |
| 23:16 |
celeron55 |
we could have a free vote of who people would trust in that position |
| 23:16 |
celeron55 |
because there could very well be someone else than me |
| 23:19 |
celeron55 |
what if we had a subsystem maintainer for democracy? 8) |
| 23:20 |
celeron55 |
duties would involve knowing what the actual players and modders want |
| 23:21 |
celeron55 |
and being able to get that information when any core dev asks for it |
| 23:21 |
celeron55 |
or, well, subsystem maintainer, or really any contributor |
| 23:22 |
sapier |
subsystem decision_making? ;-) |
| 23:23 |
celeron55 |
no; decision making is distributed |
| 23:24 |
celeron55 |
or not really, but as far as the organization would go, it is |
| 23:29 |
VargaD |
can we have a defined relase schedule/plan also? |
| 23:30 |
sapier |
I assume that'd be best to be in build subsystem? |
| 23:34 |
sapier |
#1067 |
| 23:34 |
sapier |
#1068 |
| 23:34 |
sapier |
#1054 |
| 23:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1067 |
| 23:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1068 |
| 23:34 |
sapier |
#1076 |
| 23:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1054 |
| 23:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1076 |
| 23:34 |
VargaD |
so thexyz: what do you think about a defined release schedule? |
| 23:34 |
sapier |
plz review and comment those (maybe start with first 3 ones) ;-) |
| 23:42 |
celeron55 |
no, that's not thexyz's problem |
| 23:43 |
sapier |
guess we need to have someone to decide uppon that too |
| 23:43 |
celeron55 |
it could be it's own thing with a responsible person |
| 23:43 |
celeron55 |
...if somebody is willing to |
| 23:44 |
celeron55 |
it practically has been hmmmm for a long time, and before that it was me for forever |
| 23:44 |
sapier |
that one needs to have the authority to make maintainers merge bugfixes only during feature freeze phase |
| 23:45 |
sapier |
hmm maybe that issue might settle on its own once a maintainer got clapped for merging a broken feature within feature freeze |
| 23:50 |
|
Zeitgeist_ joined #minetest-dev |
| 23:57 |
celeron55 |
everyone knows each other; it's not like we suddenly became some kind of wild animals |
| 23:58 |
celeron55 |
as long as people know it's a feature freeze, that's what they do |
| 23:59 |
|
sapier left #minetest-dev |
| 23:59 |
|
sapier joined #minetest-dev |
