Time |
Nick |
Message |
00:07 |
|
leat3 joined #minetest-dev |
00:17 |
|
leat3 joined #minetest-dev |
00:25 |
|
asl97 joined #minetest-dev |
00:32 |
|
altenus joined #minetest-dev |
00:33 |
|
altenus left #minetest-dev |
01:00 |
|
RealBadAngel joined #minetest-dev |
01:01 |
|
Darcidride joined #minetest-dev |
01:19 |
|
Taoki joined #minetest-dev |
01:46 |
|
stormchaser3000 joined #minetest-dev |
02:43 |
|
leat3 joined #minetest-dev |
03:15 |
|
est31 joined #minetest-dev |
03:16 |
est31 |
btw, for the record, I have not agreed to have a c++ kick all functionality merged without having a new server ping protocol |
03:17 |
est31 |
I have agreed that once we have such a protocol, we can kick all legacy clients |
03:17 |
est31 |
because if you are using legacy you can expect inferior functionality |
03:17 |
est31 |
but not if you are on latest master/release |
03:24 |
|
leat3 joined #minetest-dev |
03:28 |
hmmmm |
i thought kicking all clients was okay |
03:28 |
hmmmm |
it only occurs on unhandled C++ exceptions |
03:29 |
hmmmm |
and only for the serverthread |
03:30 |
hmmmm |
the only way this can really mess up is if the exception originated while sending packets, at which point nothing would be lost since the worst that can happen is that the packets simply won't get sent, which is the status quo |
03:38 |
est31 |
I'm concerned about continuity. If players are conditioned that the server doesn't kick them, a crash without a message won't be a very big deal. If however they are accustomed to getting kicked, they will be suprised when a c++ crash occurs. |
03:39 |
est31 |
either way, I'll make those messages configureable, and cache the wstring, ok? |
04:15 |
est31 |
this is shit |
04:16 |
est31 |
I have asked a question yesterday and NOBODY has replied except calinou |
04:16 |
est31 |
they all just come out of their holes when they think something went wrong |
04:16 |
est31 |
then they rant "how could you do that" |
04:17 |
est31 |
seems there is no other way to do something |
04:17 |
est31 |
than to do it, and check for complaints |
04:17 |
est31 |
and if there are, ignore them, because then its too late |
04:19 |
est31 |
http://irc.minetest.ru/minetest-dev/2015-07-15#i_4324844 |
04:19 |
est31 |
hmmmm, kahrl sfan5 Tesseract |
04:19 |
est31 |
^ |
04:20 |
hmmmm |
honestly i have no idea about git submodules or subtrees |
04:20 |
hmmmm |
\(O_o)/ |
04:20 |
hmmmm |
but #1 sounds the best of those |
04:31 |
est31 |
1. might make it harder for inexperienced people to get translations |
04:31 |
est31 |
e.g. no git knowledge |
04:32 |
est31 |
but otoh, they have enough knowledge to compile... |
04:33 |
|
stormchaser3000_ joined #minetest-dev |
04:33 |
est31 |
hmmmm, what about this: https://github.com/est31/minetest/commit/ac7894eee12ddd11b738d24f725644114c7d9a46 |
04:34 |
est31 |
I want to make it configureable, so that the owners can display custom messages. |
04:34 |
hmmmm |
is a setting really needed for that |
04:34 |
est31 |
e.g. experienced people have auto-restart |
04:34 |
hmmmm |
hm well why not i guess |
04:34 |
est31 |
currently we assume every server has auto restart |
04:35 |
est31 |
https://github.com/minetest/minetest/commit/f9dbec6edf94ce20d52d38569545674cfb742eae#diff-ad60d65b34e16a3319296bb5d683acd6R505 |
04:35 |
hmmmm |
instead of "the server has crashed. disconnecting all players" maybe make it something like "This server has experienced an internal error. You will now be disconnected." |
04:35 |
hmmmm |
sounds more professional imo |
04:36 |
est31 |
yea |
04:37 |
est31 |
https://github.com/est31/minetest/commit/bf7174f3f98f0ac665e093aaa3e332f8bd29b64b |
04:38 |
est31 |
how many +1 does this need in your opinion? |
04:38 |
est31 |
also, do you +1? |
04:38 |
hmmmm |
it's not that controversial |
04:38 |
hmmmm |
sure, why not. |
04:38 |
hmmmm |
it looks fine |
04:39 |
est31 |
pushed |
04:41 |
est31 |
originally, i have wanted to use nrz's new accessdenied packet |
04:42 |
est31 |
which sends an u8 reason |
04:42 |
est31 |
so i'd have added additional reasons |
04:42 |
est31 |
but then i found out its not future proof at all |
04:43 |
est31 |
because if a client encounters an "unknown" access denied packet, it sets the message to "unknown" |
04:43 |
est31 |
thats not nice |
04:44 |
est31 |
instead, the server should pass a "fallback string" to the client, so that it can use that if it can't take the reason string |
04:44 |
hmmmm |
indeed |
04:44 |
hmmmm |
this is why things need lots of review before they get added |
04:44 |
est31 |
turns out the packet itself already has a field with a string |
04:45 |
est31 |
its read by the client if the reason equals SERVER_ACCESSDENIED_CUSTOM_STRING |
04:45 |
hmmmm |
this is really poor design |
04:45 |
hmmmm |
if you say nerzhul added it, then we can still change it |
04:45 |
hmmmm |
it's not written in stone until there's a release |
04:45 |
est31 |
yup |
04:45 |
est31 |
its only used in protocol 25 |
05:01 |
est31 |
https://github.com/est31/minetest/commit/a9213fd12c3325f86ac46b2e94a5da701407edf3 |
05:03 |
est31 |
I will make a pr, so that nrz can comment on it. |
05:05 |
est31 |
#2920 |
05:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/2920 -- Protocol 25: Make access deny packet future proof by est31 |
05:05 |
sfan5 |
est31: >being awake at 05:30 |
05:05 |
sfan5 |
morning |
05:05 |
sfan5 |
git submodules sound like a good idea |
05:05 |
sfan5 |
they are also not that hard to use |
05:06 |
sfan5 |
you either do git submodule init && git submodule update |
05:06 |
sfan5 |
or specificy --recursive when cloning the repo |
05:06 |
sfan5 |
it might break existing scripts that rely on the repo being complete as-is though |
05:06 |
sfan5 |
and we need to push an update commit to master when the translations repo changed |
05:07 |
est31 |
or on a timed basis, every month or so |
05:08 |
est31 |
after all, its to reduce commit noise |
05:08 |
sfan5 |
hm |
05:08 |
sfan5 |
shouldn't the 'accept the noise' solution be pretty ok if you we only merge translations before a release? |
05:13 |
est31 |
I dunno |
05:16 |
est31 |
i dont even know whether you can turn off the "merge upstream into weblate/master" commits |
05:16 |
est31 |
50% of the weblate commits are these things |
05:17 |
est31 |
"Merge remote-tracking branch 'origin/master'" |
05:19 |
est31 |
ah very fine |
05:19 |
est31 |
there is a "rebase" button |
05:21 |
est31 |
to give an image of the "noise": in 10 days we had 7 weblate commits. |
05:21 |
|
stormchaser3000 joined #minetest-dev |
05:23 |
est31 |
I'll make a test-push with 3., and see whether people like it |
05:23 |
|
eeew` joined #minetest-dev |
05:44 |
|
Hunterz joined #minetest-dev |
05:45 |
|
leat3 joined #minetest-dev |
05:55 |
|
leat3 joined #minetest-dev |
05:56 |
|
RealBadAngel joined #minetest-dev |
05:57 |
RealBadAngel |
hi |
05:57 |
RealBadAngel |
whats up? |
06:10 |
|
nore_ joined #minetest-dev |
06:21 |
|
dv-_ joined #minetest-dev |
06:29 |
|
stormchaser3000 joined #minetest-dev |
06:30 |
|
est31 joined #minetest-dev |
06:30 |
est31 |
as an example how noisy it can get: https://github.com/osmandapp/Osmand/commits/master |
06:32 |
|
Guest14580 joined #minetest-dev |
06:39 |
|
nrzkt joined #minetest-dev |
06:44 |
kahrl |
est31: why do we need a new ping protocol? |
06:45 |
nrzkt |
for the future |
06:45 |
nrzkt |
est31 is not here :p |
06:45 |
kahrl |
I assume he reads the logs |
06:45 |
nrzkt |
okay |
06:46 |
|
leat3 joined #minetest-dev |
06:46 |
nrzkt |
i discussed about a ping protocol to use when we will use enet (and also legacy for a time) to disconnect the client in case of server long response time or a server crash |
06:47 |
nrzkt |
i will propose the PR later |
06:48 |
kahrl |
yeah but such a protocol is already in place |
06:48 |
kahrl |
both in our current lower level protocol and (according to its docs) enet |
06:48 |
kahrl |
all that needs to be done is something like https://gist.github.com/kahrl/f58cce9dd468045c8fa4 |
06:49 |
nrzkt |
the patchs looks good to me |
06:49 |
nrzkt |
could you provide a PR ? |
06:49 |
kahrl |
sure |
06:52 |
kahrl |
#2921 |
06:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/2921 -- Display an access denied message when client detects a server timeout by kahrl |
06:59 |
nrzkt |
okay, you can merge in 30mins |
07:00 |
kahrl |
I'd like to hear what est31 says about it first |
07:00 |
nrzkt |
if you can fix the spaces on the message before your commit |
07:00 |
nrzkt |
i'm the network maintainer :) |
07:01 |
kahrl |
yeah but it's exactly the type of stuff he has been doing lately :) |
07:01 |
kahrl |
so I'd like his input |
07:01 |
kahrl |
what do you mean about the spaces? |
07:02 |
nrzkt |
infostream<<"toto" => infostream << "toto" |
07:02 |
nrzkt |
:) |
07:02 |
kahrl |
oh, I see |
07:04 |
kahrl |
pushed |
07:07 |
nrzkt |
thanks |
07:12 |
|
leat3 joined #minetest-dev |
07:15 |
* VanessaE |
peeks in |
07:17 |
|
leat3 joined #minetest-dev |
07:17 |
|
kilbith joined #minetest-dev |
07:24 |
|
est31 joined #minetest-dev |
07:24 |
est31 |
nrzkt, what exactly is your problem with 2920? |
07:25 |
nrzkt |
do it properly |
07:25 |
est31 |
how do you mean it? |
07:25 |
nrzkt |
add two new codes to the enum |
07:25 |
nrzkt |
use it when you send the packet |
07:25 |
est31 |
thats unrelated to the pr! |
07:25 |
nrzkt |
you talked about kicking player with message when server crash |
07:26 |
est31 |
I only said that as you asked me which new reasons we could possibly need |
07:26 |
est31 |
then I brought those as example |
07:26 |
nrzkt |
what is the goal of the PR then ? |
07:26 |
nrzkt |
then i give you the solution |
07:26 |
nrzkt |
your PR is not a solution, it's a unproper protocol solution |
07:26 |
est31 |
removing complexity from code |
07:27 |
|
Amaz joined #minetest-dev |
07:27 |
est31 |
so that we can easily add new access denied reasons |
07:27 |
est31 |
without 3 versions to check against |
07:27 |
nrzkt |
the problem is not to add easily access denied reason |
07:27 |
est31 |
I agree, we perhaps send more content over the network |
07:27 |
nrzkt |
it's to define with reasons should be added to core |
07:27 |
est31 |
but thats a trade to do in my opinion |
07:28 |
nrzkt |
maybe, but the goal is not to simplify the coder life but to have a proper protocol |
07:28 |
|
leat3 joined #minetest-dev |
07:28 |
nrzkt |
kicking players on shutdown / lua crash should be standardized, i missed to think about it yesterday and you pointed it, it's good :) |
07:29 |
nrzkt |
we need to see now all reasons which should be added before release on ACCESS DENIED to handle it now for the protocol bump |
07:29 |
est31 |
we can't just raise the protocol because of every single simple thing |
07:29 |
nrzkt |
we can. A protocol is not stucked |
07:29 |
nrzkt |
we just need to handle it and be retrocompat, like other parts of code |
07:30 |
nrzkt |
and after code maintenance timeout on retrocompat code we remove it |
07:30 |
est31 |
no timeout |
07:30 |
est31 |
we should look at what our users use |
07:30 |
est31 |
and remove retrocompat code based on that |
07:31 |
est31 |
if less than ten percent use it, remove it |
07:31 |
est31 |
not until then |
07:31 |
nrzkt |
i agree with that |
07:31 |
est31 |
good |
07:31 |
nrzkt |
based on public server list call |
07:31 |
est31 |
yea |
07:32 |
nrzkt |
it's okay for me, 1 year check on public server list versions to know which code should be removed |
07:32 |
nrzkt |
then, now proper access denied code :D |
07:32 |
nrzkt |
this is time before release to do this properly, after release this will cause problems |
07:33 |
|
FR^2 joined #minetest-dev |
07:33 |
nrzkt |
it's not a huge modification |
07:33 |
Warr1024 |
it'd be nice to have an indicator in your kick message whether or not rejoining is contraindicated... |
07:33 |
est31 |
thats why i made it configureable |
07:33 |
Warr1024 |
...paving the way for client auto-rejoin in the future... |
07:34 |
est31 |
server owners which establish auto restart can set it up |
07:34 |
nrzkt |
Warr1024: then we could handle directly the code to auto restart connection |
07:34 |
nrzkt |
instead of handling a std::string... |
07:35 |
nrzkt |
if (access_denied_code == ACCESSDENIED_CRASH) { reconnectClient(); } |
07:35 |
est31 |
yeah |
07:36 |
nrzkt |
autorestart is not a bad idea, but we need to send some config to client |
07:36 |
est31 |
? |
07:36 |
nrzkt |
how can the client know he should restart ? |
07:36 |
nrzkt |
if it's a server side config |
07:36 |
Warr1024 |
just send a bool |
07:36 |
nrzkt |
yes, a new packet for client |
07:37 |
nrzkt |
TOCLIENT_SEND_CONFIGS |
07:37 |
est31 |
no |
07:37 |
nrzkt |
this could be useful to send many new config types |
07:37 |
est31 |
i think there are already packets sent where we could add that |
07:37 |
nrzkt |
in the INIT ? |
07:37 |
est31 |
no |
07:37 |
est31 |
after it |
07:38 |
|
leat3 joined #minetest-dev |
07:38 |
est31 |
we should look at which packet suits well |
07:38 |
nrzkt |
okay if you find a good packet, else it's not a huge problem to have a custom packet, it permit to change parameters online |
07:38 |
nrzkt |
if admin set /config clients disable_autoreconnect => SEND_CONFIGS (auto_reconnect => false) |
07:39 |
nrzkt |
this could be interesting and extendable |
07:39 |
nrzkt |
extensible* |
07:39 |
Warr1024 |
wait, you're talking server-wide? |
07:39 |
nrzkt |
i think about an api to send some configs t oclients, but yes this could be client side only |
07:39 |
nrzkt |
with a setting checkbox |
07:40 |
est31 |
what? |
07:41 |
nrzkt |
where do you think autoreconnect does be configured ? |
07:41 |
nrzkt |
client side or server side setting sent to client ? |
07:41 |
|
Gael-de-Sailly joined #minetest-dev |
07:41 |
nrzkt |
i think this could be only a client side setting for this |
07:41 |
Warr1024 |
clients should be able to turn on/off auto reconn themselves, but it'd be nice to have the server have a veto over it to advise the client to turn it off, if the client is being disconnected for a reason that isn't easily retryable |
07:41 |
est31 |
yes |
07:41 |
est31 |
the server should send to clients whether such a mechanism is established |
07:41 |
VanessaE |
outside of minetest, e.g. for an IRC server there's usually some kind of reconnect rate limiting as well. |
07:42 |
est31 |
but I wonder what to do for backups |
07:42 |
Warr1024 |
it could be that the server is shutting down (all clients) or that that one client is unwelcome for whatever reason (specific client only) |
07:42 |
est31 |
usually, if there is a crash, the server comes back up pretty fast |
07:42 |
est31 |
but with backups, it can have some downtime |
07:42 |
Warr1024 |
send an advised wait time? |
07:42 |
est31 |
thats the next question |
07:43 |
nrzkt |
if the server crash he cannot advertise client of restauring backup |
07:43 |
Warr1024 |
or just let the client keep retrying until it either connects or user cancels. |
07:43 |
nrzkt |
if it's a scheduled downtime, a normal downtime, don't reconnect client |
07:43 |
nrzkt |
auto-reconnect only on crash |
07:43 |
|
FR^2 left #minetest-dev |
07:43 |
VanessaE |
If there were some way for an outside process to order Minetest to shutdown AND pass an appropriate message, that would be perfect |
07:43 |
est31 |
thats a good tradeof nrzkt |
07:43 |
VanessaE |
for example kill -SIGUSR1 or something |
07:43 |
Warr1024 |
no, I would want to auto-reconnect after backups too. |
07:44 |
VanessaE |
call it a "special notice" version of the regular shutdown message |
07:44 |
est31 |
Warr1024, some servers have fast backups, some dont |
07:44 |
Warr1024 |
mine very doesn't |
07:44 |
nrzkt |
the backup process with a schedule downtime is not the problem of the cleint, but of the admin communication |
07:44 |
VanessaE |
plug in your "the server is making backups. please check back in 'n' minutes" there |
07:44 |
VanessaE |
nrzkt: no, but it's neither of these |
07:45 |
est31 |
VanessaE, its sorta possible right now |
07:45 |
est31 |
you can use the setting like a variable |
07:45 |
nrzkt |
yes, it's possible atm with a mod |
07:45 |
est31 |
lemme see how its called |
07:45 |
Warr1024 |
I don't necessarily want to have to babysit the thing, though, if I'm trying to maintain an idle connection to watch my crops grow... |
07:45 |
nrzkt |
kick all playyers with a custom message |
07:45 |
est31 |
kick_msg_shutdown |
07:45 |
VanessaE |
how would a mod know that the shutdown request was because of a backup versus say, the admin Ctrl-C'ing it? |
07:45 |
est31 |
set that to "the server is going down for backups" |
07:45 |
nrzkt |
in Lua custom message is used, you can have a mod which kick all players and shutdown th eserver |
07:46 |
VanessaE |
in both cases the server gets a SIGINT |
07:46 |
|
Calinou joined #minetest-dev |
07:46 |
est31 |
VanessaE, after the backup you can reset the message to something generic |
07:46 |
nrzkt |
if you do a SIGINT on server, this is a normal down, there is no reason |
07:46 |
est31 |
this is nothing minetest can know, only the person controlling it |
07:47 |
est31 |
nrzkt, see my commit today earlier |
07:47 |
est31 |
https://github.com/minetest/minetest/commit/bf7174f3f98f0ac665e093aaa3e332f8bd29b64b |
07:47 |
VanessaE |
est31: you're missing my point - how can a mod possibly know which message should be in effect at any one time? |
07:48 |
nrzkt |
est31: when we will use a proper code this commit will be useless |
07:48 |
est31 |
nrzkt, yes |
07:48 |
nrzkt |
VanessaE: create a mod which kick all clients and shutdown server |
07:48 |
est31 |
no |
07:48 |
nrzkt |
this will send the message your want to users |
07:48 |
est31 |
no |
07:48 |
VanessaE |
nrzkt: no. |
07:48 |
est31 |
that will add Reason: Kicked: |
07:49 |
est31 |
because its appended to the access denied reason |
07:49 |
est31 |
thats the only function the lua api can access |
07:49 |
VanessaE |
how does the mod know that the shutdown request was a backup (== 5+ mins downtime) versus an admin-requested shutdown for a quick restart? |
07:49 |
nrzkt |
Because you type /shutdown "restarting server in 5 minutes" |
07:49 |
VanessaE |
type? |
07:50 |
nrzkt |
write |
07:50 |
VanessaE |
on what? |
07:50 |
nrzkt |
on the minetest chat |
07:50 |
VanessaE |
you mean the minetest chat that's not open? |
07:50 |
VanessaE |
I'm talking about headless control |
07:50 |
Warr1024 |
you'd need a command pupe or something to control the server externally |
07:50 |
est31 |
nrzkt means something i have done with the kickall mod |
07:50 |
nrzkt |
we don't have a console on minetest |
07:50 |
VanessaE |
Warr1024: exactly |
07:50 |
est31 |
there you have /kshutdown message to users |
07:50 |
nrzkt |
est31: this is the right way |
07:51 |
VanessaE |
my point is I'd like my backup script, which currently issues `kill -INT <pid>` to shut down, to be able to tell the users via some external hook, or signal, or whatever, that the server's shutting down for backups. |
07:51 |
Warr1024 |
unfortunately, the minetest client doesn't run so great under cron. |
07:51 |
VanessaE |
MANY users seem to be unaware of the concept of a daily shutdown + backup |
07:52 |
nrzkt |
kill -INT doesn't have goal to send a custom message to players |
07:52 |
est31 |
nrzkt, VanessaE you are both right |
07:52 |
VanessaE |
*facepalm* |
07:52 |
est31 |
the right way is to do something over the chat |
07:52 |
nrzkt |
we need a minetestctl shutdown "Reason" |
07:52 |
VanessaE |
(at nrz) |
07:52 |
nrzkt |
if you want this goal |
07:52 |
VanessaE |
nrzkt: yes, exactly |
07:52 |
est31 |
yes |
07:52 |
VanessaE |
but it can be a LOT simpler |
07:52 |
nrzkt |
but atm minetest doesn't have this tool |
07:53 |
nrzkt |
the problem is not to do it simpler, but do it right. |
07:53 |
est31 |
nice bash interface |
07:53 |
VanessaE |
kill -USR1 minetestserver ---> triggers a secondary "special" disconnect message instead of kick_msg_shutdown or kick_msg_crash |
07:53 |
nrzkt |
no |
07:53 |
nrzkt |
SIGUSR1 is handled differently on other UNIX systems and isn't named like this |
07:53 |
VanessaE |
well it doesn't HAVE to be USR1 |
07:53 |
est31 |
what do you mean |
07:54 |
VanessaE |
that was just the first thing that came to mind |
07:54 |
|
Darcidride joined #minetest-dev |
07:54 |
VanessaE |
ANY signal the program can catch that doesn't immediately terminate it |
07:54 |
est31 |
we need some way of ipc which allows it |
07:54 |
est31 |
whether its sigusr |
07:54 |
Warr1024 |
whatb systems don't have a usable USR1? |
07:54 |
est31 |
or we use dbus |
07:54 |
est31 |
or pipes |
07:54 |
est31 |
or a text file |
07:54 |
VanessaE |
Warr1024: none I've ever heard of. |
07:54 |
VanessaE |
dbus, G*d forbid :P |
07:54 |
est31 |
or we just connect to the server at the port, i dont know |
07:55 |
VanessaE |
"The SIGUSR1 and SIGUSR2 signals are set aside for you to use any way you want. They're useful for simple interprocess communication, if you write a signal handler for them in the program that receives the signal." |
07:55 |
est31 |
you know, have it as feature of the protocol, hi server im a client, but i dont want to be spawned into the world, chat and commands only, like irc commands |
07:55 |
VanessaE |
( www.gnu.org/s/libc/manual/html_node/Miscellaneous-Signals.html ) |
07:55 |
est31 |
gnu is not unix |
07:56 |
VanessaE |
you mean "GNU's Not Unix" ;) |
07:56 |
est31 |
yes :p |
07:56 |
Warr1024 |
est31: or maybe an "admin mode" connection that's limited and requires some kind of auth... |
07:56 |
Warr1024 |
est31: could use the same packet structure and port, though |
07:57 |
VanessaE |
but I'm *pretty* sure if they're talking libc signals, they're pretty standard :P |
07:57 |
VanessaE |
Warr1024: too complicated to control from an outside script |
07:57 |
est31 |
Warr1024, whether to limit it to admins or not isnt the important part here, i think |
07:57 |
est31 |
VanessaE, you can provide a nice wrapper for it |
07:57 |
Warr1024 |
if any system doesn't support USR1, then it probably also doesn't support mt already. |
07:58 |
est31 |
minetest --headless server port passwordfile --chat "/shutdown message" |
07:58 |
nrzkt |
BSD is not linux VanessaE |
07:58 |
Warr1024 |
VanessaE: i'm assuming, w/ the proto suggestion, that there'd be a scriptable minetestctl client to interface w/ |
07:58 |
est31 |
^ |
07:58 |
VanessaE |
I try not to assume :P |
07:59 |
nrzkt |
okay for a minetestctl but not for this release, it's too short |
07:59 |
Warr1024 |
also, I run BSD myself, and don't see USR1 as being unusable for this...? |
07:59 |
est31 |
yes |
07:59 |
nrzkt |
okay for adding it to next roadmap for me if other devs are okay |
07:59 |
nrzkt |
BSD is a bad example, we should look at other unixes supported |
07:59 |
est31 |
I'd like to not call it minetestctl |
07:59 |
est31 |
reminds me of systemd |
07:59 |
nrzkt |
minetestctl is UNIX |
08:00 |
nrzkt |
it's not from systemd but UNIX |
08:00 |
nrzkt |
look at every BSD |
08:00 |
nrzkt |
smtpctl, ospfctl, bgpctl, ripctl, ntpctl |
08:00 |
est31 |
yes, but blablactl is systemd stench |
08:00 |
|
Yepoleb_ joined #minetest-dev |
08:00 |
nrzkt |
no |
08:00 |
est31 |
yes |
08:00 |
nrzkt |
it's UNIX |
08:00 |
nrzkt |
systemd only use UNIX named for this |
08:00 |
nrzkt |
names* |
08:00 |
Warr1024 |
minetestctl is what it should be called. |
08:00 |
est31 |
systemd is unix rape |
08:00 |
VanessaE |
lol |
08:01 |
Warr1024 |
we can't just let systemd ruin *ctl for everyone. |
08:01 |
nrzkt |
but systemd named things correctly, unlike many gnu shits |
08:01 |
VanessaE |
don't sugar-coat it, est31. tell us what you REALLY think. |
08:01 |
est31 |
ntpctl: command not found |
08:01 |
est31 |
lol |
08:01 |
nrzkt |
you are not on a UNIX |
08:01 |
|
nore joined #minetest-dev |
08:01 |
nrzkt |
[1] rootjenkins> ls /usr/bin/*ctl ~ |
08:01 |
Warr1024 |
if minetestctl ends up colliding with a systemctl script name, I'd consider that a plus :-) |
08:02 |
est31 |
lotsa whitespace |
08:02 |
nrzkt |
/usr/bin/iscsictl/usr/bin/rctl/usr/bin/usbhidctl |
08:02 |
nrzkt |
sorry :p |
08:02 |
|
kilbith joined #minetest-dev |
08:02 |
nrzkt |
on a native FreeBSD |
08:02 |
est31 |
akonadictl |
08:02 |
est31 |
balooctl |
08:02 |
nrzkt |
/usr/bin/alsactl /usr/bin/coredumpctl /usr/bin/keyctl /usr/bin/netctl /usr/bin/pccardctl /usr/bin/systemctl /usr/bin/vde_tunctl |
08:02 |
est31 |
^ these things make me hate my distro |
08:02 |
nrzkt |
/usr/bin/apachectl /usr/bin/cupsctl /usr/bin/localectl /usr/bin/networkctl /usr/bin/plugctl /usr/bin/teamdctl /usr/bin/wdctl |
08:03 |
nrzkt |
apachectl !! |
08:03 |
est31 |
akonadi and baloo are search bloat programs whose indexers require 100% CPU and more |
08:03 |
nrzkt |
if you use KDE it's not my problem, i'm only sorry for u :p |
08:04 |
est31 |
well regardless how its named, we need it |
08:04 |
nrzkt |
minetestctl make sense, but we are evading our problem here, the shutdown message :p |
08:04 |
est31 |
as long as its not called minetest-ctl |
08:04 |
nrzkt |
i don't agree with - |
08:05 |
nrzkt |
this is not UNIXlike |
08:05 |
est31 |
just because the arch package is named that way |
08:05 |
nrzkt |
no |
08:05 |
nrzkt |
community/minetest 0.4.12-2 [installed] |
08:05 |
nrzkt |
Multiplayer infinite-world block sandbox game |
08:05 |
nrzkt |
community/minetest-common 0.4.12-2 [installed] |
08:05 |
nrzkt |
Common data files for minetest and minetest-server |
08:05 |
nrzkt |
community/minetest-server 0.4.12-2 [installed] |
08:05 |
nrzkt |
Server of infinite-world block sandbox game |
08:05 |
Warr1024 |
if we use USR1, we can't specify a custom message unless it's pre-set in config, but that wouldn't be a show-stopper, and it'd probably be a good first step to making this usable and seeing how it works in practice. |
08:06 |
VanessaE |
Warr1024: that's exactly what I was proposing. |
08:06 |
nrzkt |
okay then |
08:06 |
nrzkt |
if SIGUSR1 is available on all our supported UNIX systems |
08:06 |
est31 |
and on windows |
08:06 |
nrzkt |
server doesn't run on windows ? |
08:07 |
nrzkt |
there is only the client, no ? |
08:07 |
Calinou |
the dedicated server runs on Windows, and we intend to keep that. |
08:07 |
Warr1024 |
if it's not available on a particular system, we could either use a different signal in porting code, or leave the feature off problematic platforms. |
08:07 |
nrzkt |
okay Calinou |
08:07 |
nrzkt |
Warr1024, porting make sense |
08:07 |
Warr1024 |
windows users are not going to script backups anyway. |
08:07 |
|
leat3 joined #minetest-dev |
08:08 |
Warr1024 |
those platforms must surely offer SOME reasonable IPC we can use, though. |
08:08 |
VanessaE |
default could be, message_on_sigusr1 = "Server shutdown by Admin request." |
08:08 |
nrzkt |
then, here is what to do: first => use a proper ACCESSDENIED code for our current use |
08:09 |
VanessaE |
(vague enough to mean just about anything, but configurable) |
08:09 |
nrzkt |
second handle the signal which a kick all and custom message |
08:09 |
est31 |
no |
08:09 |
est31 |
first we need reconnect |
08:09 |
nrzkt |
then use proper ACCESSDENIED codes before |
08:09 |
est31 |
thats why we need the signal the first place |
08:09 |
nrzkt |
because you will need to handle them |
08:10 |
est31 |
es |
08:10 |
est31 |
yes* |
08:10 |
est31 |
first ACCESSDENIED |
08:10 |
est31 |
then reconnect |
08:10 |
Warr1024 |
VanessaE: yeah, or "Server shutting down for maintenance, please reconnect soon(ish)" or "Server restarting" maybe... |
08:10 |
nrzkt |
and |
08:10 |
est31 |
then signal |
08:10 |
VanessaE |
Warr1024: exactly |
08:10 |
nrzkt |
because we are in a protocol bump est31 i allow a thing on the new ACCESSDENIED_SHUTDOWN : have a suffix with the custom std::string on client |
08:10 |
VanessaE |
whatever the message is, it should be generic but distinct from the current two |
08:10 |
VanessaE |
by default. |
08:11 |
est31 |
we have three accessdenied codes then |
08:11 |
Warr1024 |
or "Planned shutdown, but you idiot admin forgot to edit this message." :-) |
08:11 |
est31 |
heh |
08:11 |
VanessaE |
lol |
08:11 |
VanessaE |
that's perfect ;D |
08:11 |
kahrl |
why bake more behaviour on certain signals into the core? |
08:11 |
kahrl |
I'd prefer an API to hook signals and let mods do whatever with it |
08:11 |
nrzkt |
why 3 ? |
08:11 |
est31 |
becuz lazy |
08:11 |
est31 |
(to kahrl) |
08:12 |
Warr1024 |
kahrl: I think the issue here is that it's not readily apparent how external scripts should be able to communicate with mods... |
08:12 |
est31 |
nrzkt, we need ACCESSDENIED_SHUTDOWN_RECONNECT ACCESSDENIED_CRASH and ACCESSDENIED_SHUTDOWN_NORECONNECT |
08:12 |
est31 |
perhaps even ACCESSDENIED_CRASH_RECONNECT |
08:12 |
est31 |
so 4 |
08:12 |
Warr1024 |
kahrl: are you suggesting maybe minetest.register_on_signal(...)? |
08:12 |
|
H-H-H joined #minetest-dev |
08:12 |
est31 |
then we dont need that config packet |
08:12 |
kahrl |
Warr1024: yeah, something like that |
08:12 |
est31 |
or find another packet |
08:13 |
est31 |
there is an age old pr for that |
08:13 |
est31 |
or is it only issue?? |
08:13 |
Warr1024 |
kahrl: actually, yeah, I'm kinda starting to like that idea :-) |
08:13 |
kahrl |
then we could close #116 too :) |
08:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/116 -- Support signals with Lua API |
08:14 |
est31 |
#116 |
08:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/116 -- Support signals with Lua API |
08:14 |
est31 |
yea |
08:14 |
kahrl |
:P |
08:14 |
est31 |
:D |
08:14 |
nrzkt |
est31 merge ACCESSDENIED_SHUTDOWN_RECONNECT & ACCESSDENIED_SHUTDOWN_RECONNECT in ACCESSDENIED_SHUTDOWN (u8 code, std::string custom, bool reconnect) |
08:15 |
est31 |
nrzkt, perhaps lets make a new packet for this? |
08:15 |
nrzkt |
not needed there |
08:15 |
nrzkt |
just add a flag for reconnect into the ACCESS_DENID packet |
08:16 |
nrzkt |
but just handle it on SHUTDOWN and CRASH |
08:17 |
est31 |
makes sense |
08:17 |
est31 |
ok to that |
08:18 |
est31 |
still i think we should provide a fallback string to make these things possible without raising the protocol version and adding more complexity |
08:18 |
nrzkt |
perfect, i must work on my real work now, i listen to the chan, but be more slow on responses :p |
08:18 |
nrzkt |
handle client protocol version to use custom string for <= 25 |
08:18 |
nrzkt |
(if current version is version, didn't remember) |
08:19 |
est31 |
other's opinion on #2920 ? |
08:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/2920 -- Protocol 25: Make access deny packet future proof by est31 |
08:20 |
est31 |
(i have the nrz opinon already) |
08:20 |
nrzkt |
xD |
08:21 |
Warr1024 |
"future-proof" should almost always be "future-resistant"; there's potentially an awful lot of future, and it can be very persistent. |
08:22 |
nrzkt |
:) |
08:29 |
Calinou |
rebuilding Minetest since Debian stretch's libhiredis went from 0.10 to 0.13... |
08:32 |
|
Gael-de-Sailly joined #minetest-dev |
08:36 |
est31 |
nrzkt, so your argument against 2920 was that the overhead created by the server which sends the fallback if not needed is too much? |
08:36 |
est31 |
well I think the opposite, but i will close the pr for the sake of agreement |
08:38 |
est31 |
one idea though, to make us not regret this descision: what about adding the client side part of the pr, then we can always decide otherwise in the future |
08:38 |
nrzkt |
it's not only the overhead, it's a clean protocol use |
08:38 |
est31 |
? |
08:38 |
nrzkt |
can you explain what do you mean with cleint side part ? |
08:39 |
est31 |
https://github.com/minetest/minetest/pull/2920/files?diff=unified#diff-80833cc92bd95c628787db9b919fe87cR220 |
08:40 |
nrzkt |
i don't think it's useful on core side |
08:40 |
nrzkt |
but i agree for shutdown new codes it could be good |
08:40 |
nrzkt |
shutdown message is new, we can design it properly then :) |
08:41 |
nrzkt |
other core messages are fixed and can be translated, this is good for users |
08:42 |
nrzkt |
then i don't think this PR is useful sorry, the idea is good, but the design doesn't match the packet design |
08:44 |
est31 |
what about a less intrusive version |
08:44 |
est31 |
you said the idea is good |
08:44 |
est31 |
what does that mean? |
08:44 |
est31 |
I am changeing packet design here yes |
08:45 |
est31 |
also without providing compatability with older versions in one case yes |
08:45 |
est31 |
but protocol 25 isn't used that often yet |
08:45 |
est31 |
its not officially released |
08:45 |
nrzkt |
yes but it's used :s |
08:45 |
est31 |
only in git |
08:45 |
est31 |
also its not a major feature |
08:45 |
|
Krock joined #minetest-dev |
08:45 |
nrzkt |
you are right, this is a real problem that clients use our development clients |
08:46 |
nrzkt |
we could add the feature to protocol v 25 and say to clients in protocol v25 on git, upgrade instead of whine |
08:46 |
* H-H-H |
waits patiently for the irrlicht sf page to come back online |
08:46 |
est31 |
so i think its consensus that if the change doesnt destroy important things like chat or ability to craft, it can be done without raising protocol verison# |
08:47 |
est31 |
thats what i think too nrzkt |
08:47 |
nrzkt |
then it's okay for me |
08:47 |
nrzkt |
protocol v25 will be stopped at feature freeze |
08:47 |
nrzkt |
deve* |
08:48 |
est31 |
so i can push 2920 now? I will make additional PR with the shutdown messages. |
08:48 |
nrzkt |
no |
08:49 |
nrzkt |
i'm against it sorry |
08:49 |
est31 |
so what did you say ok to before? |
08:49 |
est31 |
please state yourself more clearly |
08:50 |
est31 |
or did you say ok to the less intrusive client side only verison |
08:50 |
nrzkt |
i think we should focus on shutdown message handling first |
08:50 |
nrzkt |
and reconnect |
08:50 |
nrzkt |
this is the most important feature to add for release |
08:51 |
est31 |
this should be done before release too |
08:51 |
est31 |
to allow us not regret it |
08:51 |
est31 |
to* |
08:51 |
nrzkt |
later we will re-talk about it |
08:56 |
|
rubenwardy joined #minetest-dev |
09:09 |
rubenwardy |
https://github.com/minetest/master-server/pull/6 |
09:09 |
rubenwardy |
server#6 |
09:09 |
rubenwardy |
master-server#6 |
09:09 |
rubenwardy |
nope :P |
09:10 |
|
proller joined #minetest-dev |
09:10 |
kilbith |
rubenwardy: you should penalize the old versions as well |
09:10 |
rubenwardy |
separate issue |
09:11 |
rubenwardy |
the problem is that we support multiple versions, and the list is sorted globally |
09:11 |
rubenwardy |
should old clients not see old servers penalised? |
09:11 |
|
jin_xi joined #minetest-dev |
09:11 |
kilbith |
yes because they don't give the best image of MT |
09:12 |
kilbith |
and likely no longer maintained |
09:12 |
est31 |
we support them, but we dont endorse them |
09:12 |
rubenwardy |
With that logic, penalise Just Test |
09:12 |
kilbith |
exactly |
09:12 |
est31 |
no |
09:12 |
rubenwardy |
It doesn't give the best image of MT# |
09:12 |
kilbith |
quality servers should be enthroned on top of the list |
09:12 |
rubenwardy |
I see what you mean though |
09:12 |
est31 |
we shouldnt penalize servers based on how often their admin logs in |
09:13 |
est31 |
the admin's goal with the server is apparently to have it moderator-less |
09:13 |
rubenwardy |
That's not what I'm saying, Just Test is all stone |
09:13 |
est31 |
and to have democracy |
09:13 |
kilbith |
that doesn't mean that the admins are competent if they log often |
09:13 |
est31 |
there people can vote for kicks |
09:13 |
est31 |
are you against democracy rubenwardy ? |
09:13 |
rubenwardy |
<rubenwardy> That's not what I'm saying, Just Test is all stone |
09:13 |
est31 |
?? |
09:14 |
rubenwardy |
https://forum.minetest.net/download/file.php?mode=view&id=1512&sid=328c276043563b0052bee789371fc829 |
09:14 |
kilbith |
just test is not worth being under the spotlights at all |
09:14 |
kilbith |
not constantly |
09:14 |
nrzkt |
i agree with the penality for old versioned server, but not a big penality |
09:14 |
VanessaE |
my "Basic" server generally beats out "just test" |
09:14 |
VanessaE |
so maybe the list is working as intended anyway? |
09:15 |
est31 |
yes i think |
09:15 |
kilbith |
VanessaE: your servers would be more favorized with penalization of old clients |
09:15 |
VanessaE |
case in point, just now it moved to the #1 spot again (it bounces among the top 3 or so, at this time of night) |
09:15 |
est31 |
perhaps people dont care about the mapgen |
09:15 |
VanessaE |
kilbith: penalize old *clients*??? |
09:15 |
kilbith |
oops |
09:15 |
kilbith |
i meant "old versions" sorry |
09:16 |
VanessaE |
penalizing old server versions I can see an argument for, but that won't affect e.g. just test, it's 0.4.12-dev |
09:16 |
kilbith |
it is already penalized with guest detection |
09:16 |
kilbith |
but not enough |
09:16 |
VanessaE |
*nod* |
09:16 |
est31 |
we shouldnt penalize 0.4.12 stable, nobody should be blamed for using a stable version |
09:17 |
kilbith |
sure |
09:17 |
rubenwardy |
I was going to say that est31, but I thought it was obvious |
09:17 |
rubenwardy |
* latest stable version |
09:17 |
est31 |
it is sorta |
09:17 |
VanessaE |
well right now I count about 5 "gbibberish" names and two guests there |
09:17 |
kilbith |
but penalizing < 0.4.11 is okay |
09:17 |
est31 |
yea |
09:17 |
VanessaE |
-b |
09:17 |
rubenwardy |
aksi > 0.5-dev |
09:17 |
rubenwardy |
*also |
09:17 |
VanessaE |
yeah I guess I could agree with that |
09:18 |
VanessaE |
and ruben's suggestion too |
09:18 |
est31 |
there is no 0.5-dev |
09:18 |
VanessaE |
penalize that which strays too far from "normal" |
09:18 |
rubenwardy |
http://servers.minetest.net/ |
09:18 |
rubenwardy |
4.firc.de:300011/25 1/130.5.0-dev, minetest, v6Free mining [EU]Mine here for free |
09:18 |
est31 |
no |
09:18 |
VanessaE |
4.firc.de:300011/25 1/130.5.0-dev, minetest, v6Free mining [EU]Mine here for freeDed Dmg Pwd Rol Far10.0m, 160.1d15, 100 |
09:18 |
kilbith |
show up more quality and less quantitative servers |
09:18 |
VanessaE |
damn, ninja |
09:18 |
VanessaE |
'd |
09:18 |
rubenwardy |
:P |
09:18 |
est31 |
we should endorse diversity not ban it |
09:19 |
VanessaE |
that's the only one in the list though, and it's already near the bottom anyways |
09:19 |
rubenwardy |
Yeah, diversity should be rewarded |
09:19 |
est31 |
well the firc.de admin did something weird here |
09:19 |
est31 |
we dont have 0.5.0-dev |
09:19 |
VanessaE |
est31: I assumed he pulled from the 0.5-dev branch when it was still being considered. |
09:19 |
rubenwardy |
He maybe using the 0.5-dev branch |
09:19 |
kilbith |
pure chaos can be considered as part of diversity ? |
09:19 |
VanessaE |
and I still see users asking once in a while when 0.5 comes out |
09:19 |
rubenwardy |
now you ninja'd me |
09:20 |
est31 |
VanessaE, idk, perhaps we release 0.5 after 0.4.13 perhaps its 1.0.0 or something else |
09:20 |
est31 |
i have no idea |
09:21 |
|
RealBadAngel joined #minetest-dev |
09:34 |
nrzkt |
-stable and -dev and -wtf shouldn't be a criteria |
09:35 |
rubenwardy |
actually, the bonus for game_time is limited at 8 months, so there's probably no need to penalise for unrealistic servers |
09:35 |
nrzkt |
est31, why 0.4.12 and not 0.5.0 ? we have a huge amount of features on this release which can justify 0.5.0 |
09:36 |
est31 |
nrzkt, please dont discuss this with me, i give a shit about which version comes next |
09:36 |
est31 |
I just want **some** release |
09:36 |
est31 |
at august 10 |
09:36 |
est31 |
or whenever we have fixed all blocker bugs |
09:37 |
VanessaE |
0.5.0 doesn't follow the new versioning scheme we wanted to use |
09:37 |
VanessaE |
semver or whatever it's called |
09:37 |
est31 |
but not in two months |
09:37 |
est31 |
also not in three months |
09:37 |
VanessaE |
no |
09:37 |
VanessaE |
0.4.13 for that one. |
09:37 |
nrzkt |
est31 okay for a release but it's not a minor release |
09:37 |
kilbith |
+1 with VE |
09:38 |
nrzkt |
what is the new versionning scheme ? |
09:38 |
VanessaE |
but when the time comes to seriously say "it's time for 0.5.0", that's when we go with 1.0.0 instead. |
09:38 |
VanessaE |
nrzkt: Semantic Versioning |
09:38 |
nrzkt |
can you be more precise ? |
09:38 |
Calinou |
semver.org |
09:38 |
VanessaE |
major.minor.patchlevel |
09:38 |
VanessaE |
http://semver.org/ |
09:38 |
nrzkt |
okay |
09:38 |
VanessaE |
bah, ninja'd |
09:39 |
nrzkt |
i agree with this schem |
09:39 |
nrzkt |
but here we are in 0.major.minor |
09:39 |
VanessaE |
more or less |
09:39 |
nrzkt |
and 13 is not minor on this release |
09:39 |
VanessaE |
and treating minor as if it's patchlevel |
09:39 |
nrzkt |
it's major for me |
09:39 |
Calinou |
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0. |
09:40 |
nrzkt |
and for using semver we need to have two branches, because we need to have minor modifications in one branch and patch to another and merge everything to minor |
09:40 |
kilbith |
does we can afford frequent releases with minor patches ? |
09:40 |
VanessaE |
I suggested started at 5.0.0 a while back because a lot of users are stupid and think 0.y.z = y.z.0 |
09:40 |
nrzkt |
no |
09:40 |
VanessaE |
but others here prefer 1.0.0 instead |
09:40 |
nrzkt |
yes |
09:41 |
est31 |
ahhh this code si so ugly!!!! |
09:41 |
nrzkt |
? |
09:41 |
est31 |
you know we have Player |
09:41 |
est31 |
and we have RemotePlayer |
09:41 |
est31 |
so where do you think do we store peer_id?? |
09:41 |
est31 |
in the remote player you guess |
09:41 |
est31 |
but no we store it in player |
09:41 |
nrzkt |
yes |
09:42 |
est31 |
now, how do we set it= |
09:42 |
est31 |
? |
09:42 |
est31 |
in the constructor? |
09:42 |
nrzkt |
xD |
09:42 |
est31 |
nooo that would be too simple |
09:42 |
est31 |
no, we first pass the peer id to the playersao |
09:42 |
est31 |
to its constructor to be precise |
09:42 |
est31 |
then the playersao stores the peer id |
09:43 |
est31 |
in its constructor |
09:43 |
est31 |
and it also gets the player object in its constructor |
09:43 |
est31 |
(i mean a pointer to it) |
09:43 |
est31 |
so does it set the peer id of the player in its constructor, where it has both values?? |
09:43 |
est31 |
no |
09:44 |
est31 |
it waits till the addedToEnvironment call |
09:44 |
est31 |
out of which reason, i dont know |
09:44 |
est31 |
so, when i now try to add a protocol version field to the player |
09:44 |
est31 |
i either have to replicate this horrible structure |
09:45 |
est31 |
or i have to write other horrible code |
09:45 |
est31 |
which makes a lookup based on the peer id |
09:45 |
est31 |
i hate this |
09:46 |
jin_xi |
https://www.youtube.com/watch?v=2Oy6DwHAi70 |
09:48 |
nrzkt |
in fact est31 our session system is a little bit shit |
09:48 |
nrzkt |
i will work on it when enet will be finished because i will need it |
09:48 |
est31 |
about enet |
09:49 |
est31 |
perhaps you should fix some regressions first |
09:49 |
est31 |
VanessaE has a list of them |
09:49 |
est31 |
flat player, and so on |
09:49 |
nrzkt |
i don't know about flat player, i haven't seen this anywhere |
09:49 |
est31 |
people are angra at you because of those regressions |
09:50 |
nrzkt |
and i cannot reproduce it |
09:50 |
VanessaE |
https://github.com/minetest/minetest/issues/2524 |
09:50 |
nrzkt |
i don't say i haven't see the PR |
09:51 |
nrzkt |
i say i haven't see it in action |
09:51 |
rubenwardy |
I prefer 5.0.0 |
09:51 |
rubenwardy |
before we were 0.major.minor, now we would be major.minor.patch |
09:51 |
est31 |
VanessaE, other regressions? this ghost entity thing is it one too? |
09:51 |
rubenwardy |
anyway: how would you detect diversity for the serverlist? |
09:51 |
VanessaE |
est31: yes, but that's not caused by any of nrz's code. |
09:52 |
est31 |
how do you know |
09:52 |
kilbith |
ghost entities are one the oldest bugs |
09:52 |
est31 |
ah its no regression since 0.4.12 then |
09:52 |
est31 |
ok |
09:52 |
kilbith |
i always saw it (ie. since 0.4.6) |
09:52 |
rubenwardy |
~title https://gist.github.com/rubenwardy/6d6882db0cbe1b5b24be |
09:52 |
ShadowBot |
rubenwardy: Server list point checker |
09:52 |
VanessaE |
because I'm pretty sure it was ShadowNinja's SAO rewrite that started the MAIN problem (the player-ref delete bug) |
09:53 |
VanessaE |
some of the regressions (like flat player and 0,0,0) just become more visible because you're forced to sign on multiple times. |
09:53 |
est31 |
our client is shit, our server is shit, what isn't shit. |
09:54 |
nrzkt |
you forget your pseudo in the list xD |
09:54 |
kilbith |
but it's free shit |
09:54 |
est31 |
pseudo? |
09:54 |
nrzkt |
nickname :p |
09:54 |
VanessaE |
pseudo? |
09:54 |
VanessaE |
pseudonym |
09:55 |
est31 |
ive meant that seriously btw. |
09:55 |
nrzkt |
i laugh :p |
09:55 |
VanessaE |
I don't want to necessarily agree with it being "shit" given how capable it is, despite, |
09:56 |
VanessaE |
but yeah there's a need for improvement in many places. |
09:56 |
nrzkt |
it's not completely this, it's hard to maintain, that's different |
09:56 |
nrzkt |
s/this/shit |
09:56 |
est31 |
ok next idea |
09:56 |
est31 |
we dont have the kick all method in the environment |
09:56 |
est31 |
but iterate over the clients instead |
09:56 |
est31 |
that should work |
09:57 |
est31 |
andr |
09:57 |
est31 |
|
09:57 |
est31 |
and require less overhead |
09:57 |
nrzkt |
can you provide me a patch ? |
09:57 |
nrzkt |
i keep the same usage as saveAllPlayers i nfact |
09:58 |
VanessaE |
so long as new connections are no longer possible before the first client is kicked, I don't see a problem with that |
10:05 |
kahrl |
merging #2921 now since it has 2 agreements, thanks for the tests est31 :) |
10:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/2921 -- Display an access denied message when client detects a server timeout by kahrl |
10:15 |
est31 |
btw, why do we have peer ids? |
10:16 |
est31 |
why not just use pointers? |
10:18 |
|
leat3 joined #minetest-dev |
10:19 |
|
RealBadAngel joined #minetest-dev |
10:20 |
nrzkt |
you are right |
10:20 |
nrzkt |
we should have a std::map<u64 peer_id, Player* player> |
10:20 |
nrzkt |
but it's too late for this release to do this |
10:21 |
nrzkt |
and we should have a SessionManager, not have this in server or Environment |
10:21 |
VanessaE |
greetz, RBA |
10:21 |
est31 |
whatever that makes dealing with it fun |
10:21 |
est31 |
dealing with this is no fun |
10:22 |
est31 |
also, i think more important than enet is that we can get multiple servers to cluster together |
10:22 |
est31 |
then we can do enet |
10:22 |
est31 |
perhaps both together |
10:22 |
nrzkt |
cluster ? |
10:22 |
VanessaE |
est31: oh G*D yes |
10:22 |
nrzkt |
calm :p we are not at this point :p |
10:23 |
VanessaE |
clustering ftw |
10:23 |
nrzkt |
there is many things to do, clustering is useless if minetest design is fixed |
10:23 |
est31 |
wtf |
10:23 |
VanessaE |
est31: it's my understanding that Minecraft clients form nodes on some kind of rudimentary cluster also. |
10:23 |
est31 |
do they |
10:23 |
VanessaE |
we should look at doing the same if there's any hope of that |
10:23 |
est31 |
didnt know that |
10:23 |
est31 |
eiither way, clients must not be trusted |
10:23 |
nrzkt |
+1 |
10:23 |
VanessaE |
well I can't confirm it of course, but that's what I've heard - supposedly it helps spread the load around |
10:24 |
RealBadAngel |
hi all |
10:24 |
est31 |
if, the server owner has to provide the cluster nodes |
10:24 |
est31 |
call it multithreading, call it clustering, in my opinion clustering is better because it can run on different hosts |
10:25 |
est31 |
multithreading can be done too, but not too intensely |
10:25 |
|
FR^2 joined #minetest-dev |
10:26 |
nrzkt |
don't be too ambitious |
10:26 |
nrzkt |
there are others things to do before, don't add a new system with new problems atm clustering is complex |
10:27 |
VanessaE |
nrzkt: I'm pretty sure that's for the future :P |
10:27 |
nrzkt |
i hope |
10:27 |
kilbith |
RealBadAngel: you have worked on the VBO patch ? |
10:27 |
est31 |
no! lets push this in before 0.4.13! |
10:27 |
est31 |
10 hour code marathon, now! |
10:28 |
RealBadAngel |
kilbith, theyre waiting in line. atm im working on reenabling shaders for wielded and entities |
10:28 |
kilbith |
ah ok |
10:28 |
est31 |
also, who does the minimap fixes? |
10:28 |
est31 |
me, hmmm, rba, nrz? |
10:28 |
est31 |
sfan? |
10:28 |
|
FR^2 left #minetest-dev |
10:28 |
RealBadAngel |
i will code a few things for minimap on weekend |
10:29 |
nrzkt |
not me, i'm not familiar with that code |
10:29 |
nrzkt |
i'm mainly focussed on server design and net proto |
10:29 |
RealBadAngel |
but "better algorithm for scanning" in the issues is quite a joke |
10:29 |
VanessaE |
oh speaking of entities, I noticed an odd lighting glitch yesterday: players are starting to ..blink? that is, vacillate between two brightness steps, even if they're just standing still |
10:29 |
VanessaE |
s/entities/objects/ |
10:30 |
kahrl |
RealBadAngel: btw, I made a small improvement to the wield extrusion code, https://github.com/minetest/minetest/issues/2902#issuecomment-121843662 |
10:30 |
est31 |
wielded ones? or all items? |
10:30 |
VanessaE |
not everyone does it, usually it's just one user who sits there shifting brightnesses |
10:30 |
kilbith |
VanessaE: players are blinking when they lose health normally |
10:30 |
kilbith |
it's intentional |
10:30 |
VanessaE |
kilbith: no, I don't mean that |
10:31 |
RealBadAngel |
kahrl, does it really fix fsaa issue? |
10:31 |
VanessaE |
I mean an occasional small change in brightness, like some precision error happening somewhere. |
10:31 |
kahrl |
it fixes the lines way above the wield hand |
10:31 |
kahrl |
and similar lines for other extruded items |
10:31 |
RealBadAngel |
kahrl, so i will merge that into my fixes, is that okay? |
10:31 |
kahrl |
it doesn't fix the lines on the side |
10:32 |
kahrl |
sure |
10:32 |
RealBadAngel |
i should have shaders for wielded almos ready |
10:33 |
RealBadAngel |
by today i mean |
10:33 |
RealBadAngel |
it will be a separate shader |
10:33 |
RealBadAngel |
theres no need in wielded shader to support parallax, waving etc |
10:34 |
|
proller joined #minetest-dev |
10:35 |
VanessaE |
RealBadAngel: but bumpmap support in the wield would be nice |
10:35 |
VanessaE |
at least so that it matches the world better |
10:35 |
RealBadAngel |
yeah, bumpmapping will work without problems |
10:37 |
RealBadAngel |
https://imgrush.com/lnYUz6-miqqc.png |
10:42 |
|
Player_2 joined #minetest-dev |
10:58 |
|
proller joined #minetest-dev |
11:04 |
|
blais3 joined #minetest-dev |
11:40 |
RealBadAngel |
i wonder what for we do use light source for wielded |
11:41 |
RealBadAngel |
i works just faster to set the mesh color |
11:41 |
VanessaE |
well |
11:41 |
VanessaE |
I don't know WHY, but it reflecting the light in a given spot has one obscure use: |
11:42 |
VanessaE |
to see if you're in an unloaded block up in the air |
11:42 |
VanessaE |
(because the wield turns black then) |
11:46 |
est31 |
~ping |
11:46 |
ShadowBot |
pong |
11:46 |
est31 |
yey |
11:46 |
est31 |
(Just testing timeouts) |
11:46 |
RealBadAngel |
VanessaE, that could mean that lighting never works in fact |
11:46 |
est31 |
so I am planning the following behaviour |
11:46 |
RealBadAngel |
that can be achieved only by setting mesh color |
11:47 |
est31 |
if the server shuts down, and reconnect == false |
11:47 |
est31 |
the normal errormsg is shown |
11:47 |
RealBadAngel |
im trying now to use that non-shaders wielded light source, but it simply doesnt work |
11:47 |
est31 |
if the server shuts down, and reconnect == true, a dialog is shown, with the message, and "main menu", "exit game", and "reconnect" |
11:48 |
est31 |
perhaps without "exit game" |
11:48 |
VanessaE |
est31: I like that |
11:54 |
|
FR^2 joined #minetest-dev |
12:01 |
est31 |
lol like that "No future without mainmenu" |
12:02 |
VanessaE |
hah |
12:11 |
est31 |
wow, this is garbage code |
12:19 |
kilbith |
hell, MT is really too RAM-greedy - never stops to increase when you fly over the map |
12:19 |
kilbith |
in MC it's always stable and limited ~250-300 MB |
12:21 |
est31 |
it is |
12:21 |
kilbith |
returning to the menu does not clear out the RAM |
12:21 |
est31 |
paramat said that sometimes it does, sometimes not |
12:22 |
kilbith |
just flying, go ahead and keep en eye on your task manager |
12:22 |
kilbith |
never stops to increase |
12:22 |
kilbith |
as long you have some RAM free available |
12:23 |
est31 |
all your ram are belong to us! |
12:23 |
kilbith |
in MC i guess it have a managering from fee-ing the RAM dynamically |
12:23 |
kilbith |
*free-ing |
12:24 |
|
twoelk joined #minetest-dev |
12:25 |
est31 |
well RealBadAngel the gfx guy says that stuff is deleted, at shitdown |
12:25 |
est31 |
yes, its shitdown, not shutdown |
12:28 |
kilbith |
i laugh sometimes when i read that FOSS code is better |
12:29 |
kilbith |
MT is quality-demo for the opposite |
12:30 |
kilbith |
same goes for Oad vs Age of Empires |
12:30 |
est31 |
there is very few foss software out there that has a gui and is better than the closed source alternative. |
12:31 |
est31 |
because you cant easily build business models around foss software with a gui. |
12:31 |
est31 |
it works for software without a gui, look at the server market |
12:31 |
kilbith |
yeah |
12:33 |
Calinou |
how 'bout Synergy (lol) |
12:33 |
Calinou |
<kilbith> same goes for Oad vs Age of Empires |
12:33 |
Calinou |
you saw original, non-decompiled Age of Empires source code? |
12:33 |
Calinou |
most proprietary games are very monolithic in their design |
12:34 |
kilbith |
no, i meant AoE III vs Oad |
12:34 |
Calinou |
in contrast, 0 A.D. is much more modulra |
12:34 |
kilbith |
0 A.D. is very CPU/RAM inefficient |
12:34 |
kilbith |
unlike AoE |
12:34 |
Calinou |
there are exceptions, eg. Source engine |
12:34 |
Calinou |
that's because it uses SpiderMonkey for JavaScript |
12:34 |
nrzkt |
kilbith: as i see it's because every mapblock is load in RAM but never unload after a max view range |
12:35 |
nrzkt |
est31: a menu at disconnect seems a good idea :) |
12:35 |
kilbith |
modularity and freedom is good, but i prefer stability and efficience |
12:35 |
kilbith |
that's a recurrent problem in FOSS games |
12:37 |
|
FR^2 joined #minetest-dev |
12:37 |
|
Lunatrius` joined #minetest-dev |
12:40 |
RealBadAngel |
well, i must admit that lightsource in wieldmanager is an ipressive idea |
12:40 |
RealBadAngel |
to change level of the light ambient color is set |
12:40 |
RealBadAngel |
rotfl |
12:41 |
RealBadAngel |
so the lightsource is here for a reason unknown |
12:43 |
RealBadAngel |
trashing that code, its useless and has as much common with proper lighting as cow trying to fly |
12:43 |
nrzkt |
:p |
12:47 |
|
FR^2 joined #minetest-dev |
12:51 |
|
Megaf joined #minetest-dev |
12:51 |
est31 |
nrzkt, in the meantime, do you want to review my chat pr? |
12:52 |
|
Lunatrius` joined #minetest-dev |
12:55 |
kilbith |
will it have a PR-merging session soon ? i see some fixes here and there |
12:55 |
|
FR^2 joined #minetest-dev |
12:55 |
kilbith |
especially TeTpaAka's ones |
12:56 |
nrzkt |
est31: link, i will try to take time |
12:57 |
est31 |
*nrzkt << #2885; |
12:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/2885 -- Utf8 based chat by est31 |
12:58 |
est31 |
the other option is that we don't change protocol, but then we have to provide utf-16 conversion utilities on linux. |
12:59 |
nrzkt |
i like this option to remove wide and have conversion |
12:59 |
nrzkt |
but don't protocol bump |
12:59 |
|
Lunatrius joined #minetest-dev |
12:59 |
nrzkt |
as we said before protocol v25 is for this release |
13:00 |
est31 |
chat is an important feature |
13:00 |
est31 |
we said before that you dont have to additionally bump protocol when the feature isnt important, or not used often |
13:01 |
est31 |
so for access denied strings that only happen when a server restarts ---> no big deal |
13:02 |
est31 |
(old proto 25 clients would have an "unknown" reason for denial) |
13:02 |
est31 |
thats acceptable |
13:02 |
est31 |
but when chat isn't working, people will start to complain, and we should bump. |
13:02 |
est31 |
there is already another feature we can put into protocol 26 |
13:03 |
RealBadAngel |
nrzkt, i also need protocol bump for my code |
13:03 |
RealBadAngel |
code is sleeping waiting for it |
13:03 |
est31 |
thats the one i spoke of :) |
13:05 |
nrzkt |
okay for 26 then |
13:05 |
nrzkt |
but at release 26 will be fixed |
13:05 |
nrzkt |
RealBadAngel what do you need in protocol ? |
13:06 |
est31 |
its all done |
13:06 |
est31 |
he only needs the define |
13:06 |
est31 |
https://github.com/minetest/minetest/commit/655fc6010ffd4be7de315be261df2a61d5d4538a#diff-70868aa6d6b96c0c1623c761500d23c4L123 |
13:07 |
est31 |
the only thing needed is #define LATEST_PROTOCOL_VERSION 26 |
13:08 |
nrzkt |
oh i see |
13:08 |
nrzkt |
okay for me too for this v26 |
13:08 |
est31 |
nrzkt, what do you mean with "at release 26 will be fixed" |
13:08 |
nrzkt |
we couldn't modify the v26 |
13:08 |
est31 |
yes of course |
13:09 |
RealBadAngel |
going, out bbl |
13:09 |
RealBadAngel |
move that comma ;) |
13:09 |
nrzkt |
the protocol version is not a problem, but is this a u8 or a u16 ? :p |
13:09 |
est31 |
u16 i think |
13:10 |
est31 |
yes u16 |
13:11 |
nrzkt |
good new |
13:12 |
nrzkt |
whereas at this speed in 2 or 3 years we will reach max(u8) :p |
13:12 |
est31 |
heh |
13:12 |
est31 |
protocol bump every 2-3 months... |
13:12 |
est31 |
i mean thats only statistics |
13:13 |
est31 |
we dont hold back a pr "because we already had a bump this moth" |
13:13 |
est31 |
month* |
13:13 |
|
Lunatrius` joined #minetest-dev |
13:14 |
nrzkt |
:) |
13:15 |
|
nore joined #minetest-dev |
13:20 |
est31 |
nrzkt, what do you mean with "Can you add an extra empty line for reading ?" |
13:21 |
nrzkt |
just add an empty line after the first if |
13:21 |
est31 |
ok |
13:22 |
|
Taoki joined #minetest-dev |
13:24 |
|
SopaXT joined #minetest-dev |
14:17 |
|
Gael-de-Sailly joined #minetest-dev |
14:30 |
|
hmmmm joined #minetest-dev |
14:41 |
|
nrzkt joined #minetest-dev |
14:53 |
|
Amaz joined #minetest-dev |
15:03 |
|
Hunterz joined #minetest-dev |
15:03 |
est31 |
ok, it works! |
15:06 |
nrzkt |
what ? |
15:09 |
est31 |
yea sorta |
15:09 |
est31 |
will make pr, now coding the /shutdown command |
15:10 |
est31 |
it will be /shutdown request_reconnect reason |
15:10 |
nrzkt |
std::time is great |
15:10 |
nrzkt |
good est31, you are crazy :p |
15:10 |
est31 |
lol |
15:10 |
nrzkt |
you have the reconnect process ready to review ? |
15:11 |
|
stormchaser3000 joined #minetest-dev |
15:11 |
est31 |
no, i will have to polish a bit |
15:14 |
|
RealBadAngel joined #minetest-dev |
15:15 |
est31 |
hmmmm, do you know whether std::string(NULL) is safe? does it produce "", or do i have to check |
15:15 |
hmmmm |
std::string(NULL) produces an exception |
15:15 |
hmmmm |
try it out yourself |
15:15 |
est31 |
ok will make a ternary |
15:20 |
RealBadAngel |
hmmmm, i am fixing now wielded (and CAOs) shader |
15:20 |
RealBadAngel |
it will be ready by today |
15:20 |
hmmmm |
great |
15:20 |
RealBadAngel |
but some decisions were made |
15:21 |
RealBadAngel |
some1 made wielded (in hand) using lightsource |
15:21 |
est31 |
hmmmm, what's better style .empty() or == "" |
15:21 |
RealBadAngel |
but made it totally wrong. |
15:21 |
hmmmm |
it really doesn't matter |
15:21 |
RealBadAngel |
ive switched wield to use our lighting style back |
15:22 |
RealBadAngel |
when we decide to switch to HW lighting system we will have to do it right way |
15:22 |
RealBadAngel |
for all scene nodes |
15:24 |
RealBadAngel |
atm wieldhand having lightsource is comparable to cow trying to fly |
15:26 |
RealBadAngel |
setting light pos is ok (with lotsa facy cos and sin). then fact that lightsource has no light temperature set and using only diffuse color? |
15:27 |
RealBadAngel |
slapstick comedy |
15:31 |
RealBadAngel |
hmmmm, anyway, a screenie: https://imgrush.com/lnYUz6-miqqc.png |
15:32 |
est31 |
looks n1ce |
15:32 |
nrzkt |
hmm... normal maps are not very very stable in render i think |
15:33 |
nrzkt |
RealBadAngel: pass on Apple Tree server and look at the textures :s |
15:34 |
RealBadAngel |
nrzkt, screenie please |
15:34 |
RealBadAngel |
i will tell you then what is the problem |
15:35 |
RealBadAngel |
btw we shall make a thin red line with release |
15:35 |
RealBadAngel |
and forbid olders to connect |
15:36 |
est31 |
no |
15:36 |
nrzkt |
https://lut.im/Rqr4J1Vs/5l7NjjMT & https://lut.im/C29MPb3D/3HiE4w8g |
15:36 |
nrzkt |
simply move the camera change the render :s |
15:36 |
est31 |
RealBadAngel, we should maintain compatibility based on what the users use |
15:36 |
nrzkt |
and some textures which should be flat are.. not flat |
15:37 |
est31 |
if less than 10% use something we still support, we can remove compat |
15:37 |
RealBadAngel |
outaded client, case closed |
15:37 |
RealBadAngel |
next please |
15:37 |
nrzkt |
5% |
15:37 |
nrzkt |
10% is huge |
15:37 |
est31 |
ok with 5% |
15:37 |
RealBadAngel |
display a link with source to get new client just |
15:37 |
nrzkt |
i think we should remove minetest 0.2 compat layer |
15:38 |
nrzkt |
xD |
15:38 |
RealBadAngel |
backwards compability is causing more problems and bugs than anythin else |
15:38 |
nrzkt |
i think in some parts it's a real problem |
15:38 |
RealBadAngel |
got the client outaded? move kindly your ass and get one up to date |
15:38 |
nrzkt |
didn't we have this thing implemented ? |
15:38 |
est31 |
RealBadAngel, look at 2#508 |
15:38 |
nrzkt |
a message sent by servers |
15:39 |
est31 |
err |
15:39 |
est31 |
#2508 |
15:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/2508 -- Pass version information to joinplayer callback by est31 |
15:39 |
RealBadAngel |
we could propably close at least 25-30% of the issues |
15:39 |
est31 |
its even forbidden to check version to display a nice note |
15:39 |
est31 |
even that is hated! |
15:39 |
RealBadAngel |
we have to end that shit |
15:40 |
nrzkt |
RealBadAngel: i agree, we have a rule 1 year without activity and after a question to sender |
15:40 |
est31 |
and #1689 |
15:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/1689 -- Add version API by ShadowNinja |
15:40 |
RealBadAngel |
1 yr? |
15:40 |
|
Taoki[mobile] joined #minetest-dev |
15:40 |
RealBadAngel |
are you a sleeping queen or what? |
15:40 |
nrzkt |
if it was me it will be close after 1 month :p |
15:41 |
RealBadAngel |
during one yr you can develop whole new game from scratch |
15:41 |
nrzkt |
but i can't remember if it was 1 year or 3 month |
15:41 |
RealBadAngel |
its IT |
15:41 |
RealBadAngel |
now technology of producing hammers |
15:41 |
RealBadAngel |
1yr here is ages |
15:41 |
nrzkt |
you are right, but if you look at my current enterprise methods... it's not agile (and i'm not a developper , i'm a UNIX systems production architect) |
15:42 |
nrzkt |
everybody isn't agile but it's the best |
15:42 |
nrzkt |
the problem with MT is distros like Debian which are old |
15:42 |
nrzkt |
we should support squeeze and wheezy |
15:42 |
RealBadAngel |
nrzkt, but im sick of resolving issues caused by outdated clients being able to connect |
15:42 |
|
twoelk joined #minetest-dev |
15:42 |
nrzkt |
i agree with you |
15:42 |
nrzkt |
trash older clients and next :p |
15:43 |
est31 |
RealBadAngel, you are network maintainer lol? |
15:43 |
RealBadAngel |
im forced to use technology that is 9 yrs old, you know? |
15:43 |
RealBadAngel |
im talkin OpenGL now |
15:43 |
nrzkt |
RBA: did you look at my part on network it's a pain... |
15:43 |
nrzkt |
we have retrocompat since the minetest birth xD |
15:43 |
RealBadAngel |
2.1 is almost 10 yrs old |
15:43 |
nrzkt |
sfan5: did you have stats on protocol version ? |
15:43 |
RealBadAngel |
and even a fridge can run it |
15:43 |
nrzkt |
xDD |
15:44 |
nrzkt |
i think we should drop protocol versions under 15 |
15:44 |
RealBadAngel |
is it our fuckin goal to get our project running on every kitchen machine or what? |
15:44 |
est31 |
RealBadAngel, so whats so hard about having simple shaders? |
15:44 |
RealBadAngel |
thats a workaround |
15:44 |
est31 |
also nrzkt removing compat is always a hard job why do it? |
15:44 |
RealBadAngel |
not a real solution |
15:44 |
nrzkt |
RBA: it's not my goal, i agree with retrocompat, but i'm not for twenty years compat. 2 years is sufficient for me |
15:45 |
est31 |
so your "solution" is to tell people to fuck off and use minecraft? |
15:45 |
nrzkt |
est31: in protocol it's easy, we have protocol version tests everywhere :p |
15:45 |
RealBadAngel |
my gf is playing online free game |
15:45 |
RealBadAngel |
HayDay |
15:45 |
RealBadAngel |
each time game is changing, user are asked to update their clients |
15:45 |
RealBadAngel |
one can do? ofc he can |
15:46 |
nrzkt |
the main problem RBA is our protocol is not ready for that... |
15:46 |
RealBadAngel |
protocol is ready |
15:46 |
nrzkt |
no |
15:46 |
nrzkt |
we need to switch to enet before doing that |
15:46 |
RealBadAngel |
just dont let olders to connect |
15:46 |
est31 |
protocol is ready |
15:46 |
nrzkt |
servers owners can do this |
15:46 |
est31 |
its more a choice |
15:46 |
RealBadAngel |
and trash all the backwards code |
15:46 |
hmmmm |
if you want to trash minetest please do it in your own fork, please |
15:46 |
RealBadAngel |
current one or nothing |
15:47 |
RealBadAngel |
simple as that |
15:47 |
est31 |
RealBadAngel, so convince some server owners to do it |
15:47 |
est31 |
just ask them kindly whether they can do it |
15:47 |
nrzkt |
or we can switch refuse backward clients to true by default ? |
15:47 |
est31 |
we can talk again if you have convinced the top 10 from the list |
15:47 |
hmmmm |
frankly the users' demands are more important than your own, RBA |
15:47 |
RealBadAngel |
hmmmm, i dont want to trash anythin. i want it to be reliable |
15:48 |
hmmmm |
sure |
15:48 |
RealBadAngel |
this is not possible to get everything workin if youre workin on pieces out of sync |
15:48 |
RealBadAngel |
client, engine, mods |
15:49 |
RealBadAngel |
each one can have code out of its funny cache |
15:49 |
nrzkt |
i need protocol version stats |
15:49 |
Calinou |
<+nrzkt> we should support squeeze and wheezy |
15:49 |
Calinou |
squeeze? no |
15:49 |
Calinou |
wheezy? perhaps |
15:49 |
RealBadAngel |
im tired of reports hey thats broken, horrible, slow etc |
15:49 |
nrzkt |
squeeze is supported by Debian, yes i know it's old |
15:49 |
Calinou |
in 2017 we'll add C++11 support |
15:50 |
Calinou |
(that is, when Ubuntu 12.04 becomes EOL) |
15:50 |
est31 |
no |
15:50 |
est31 |
we already have c++11 support |
15:50 |
hmmmm |
RealBadAngel, trashing compatibility isn't the solution |
15:50 |
nrzkt |
we can run c++11 |
15:50 |
nrzkt |
but we don't use it |
15:50 |
est31 |
also, we can already use c++11 |
15:50 |
RealBadAngel |
and hmmmm even you claimed to be working in IT business should know that |
15:50 |
est31 |
with ifdefs |
15:50 |
RealBadAngel |
especially you |
15:50 |
est31 |
but we should not drop pre c++11 |
15:50 |
hmmmm |
RealBadAngel, it sounds to me like a horrible excuse for incompetence |
15:51 |
RealBadAngel |
rly? |
15:51 |
hmmmm |
how come *I* can make things stable and reverse compatible? |
15:51 |
nrzkt |
hmmmm: do you agree < 2 years old versions of protocol support if the stats shows nobody is using it ? |
15:51 |
RealBadAngel |
keep the client and server in sync |
15:51 |
est31 |
reverse compatibility and stability are orthogonal imo |
15:51 |
RealBadAngel |
you smart guy |
15:51 |
hmmmm |
nrzkt, I guess that sounds reasonable |
15:52 |
RealBadAngel |
otherwise youre just book learned techican not a real coder |
15:52 |
hmmmm |
if you have a choice between keeping compatibility or not, though, the former should be preferred |
15:52 |
nrzkt |
okay, then sfan5: if you have stats, i'm waiting you to do a PR to drop old protocol versions |
15:52 |
nrzkt |
this will remove spaghettis :p |
15:52 |
est31 |
nrzkt, why not do you a pr? |
15:52 |
RealBadAngel |
learned only to watch the whitespaces and trying to find a use for templates |
15:52 |
est31 |
you want it nrzkt |
15:52 |
est31 |
also where are spaghettis |
15:52 |
nrzkt |
because i need to have stats to do the cleanup and know what i should cleanup :) |
15:53 |
hmmmm |
oh god |
15:53 |
RealBadAngel |
somebody call for a delivery |
15:53 |
hmmmm |
like I said |
15:53 |
hmmmm |
if it presents an actual problem, then sure, remove it |
15:53 |
hmmmm |
if you just decided you don't like old code, maybe that's not such a good idea |
15:53 |
RealBadAngel |
hmmmm, most of us are self learned |
15:53 |
hmmmm |
you shouldn't strive to break things for the purpose of breaking things |
15:53 |
nrzkt |
est31: spaghettis for me are the horrible many conditions for protocol in some packets, if we could remove somes it could be better :) |
15:53 |
RealBadAngel |
after many yrs of coding actual things |
15:54 |
hmmmm |
RealBadAngel, then how come your code is so memory leaky |
15:54 |
hmmmm |
with all that experience |
15:54 |
hmmmm |
pfth |
15:54 |
RealBadAngel |
i should pay more attention to that |
15:54 |
hmmmm |
i think you should pay more attention to everything |
15:54 |
RealBadAngel |
nobodys perfect |
15:54 |
hmmmm |
shit commit in your own project, not minetest, okay? |
15:55 |
hmmmm |
i get you want to develop new features fast but this isn't the appropriate venue |
15:55 |
RealBadAngel |
im not doing them fast |
15:55 |
RealBadAngel |
not since a long time |
15:55 |
Calinou |
we're not at 1.0 yet, remember |
15:55 |
RealBadAngel |
im always leaving prs for a long long time open |
15:55 |
Calinou |
this means we can break compatibility and we have done so successfully in the past, many times |
15:56 |
RealBadAngel |
even when i do have green light already |
15:56 |
est31 |
Calinou, give an example pls |
15:56 |
H-H-H |
is anyone actively working on the android side , i mean as aposed to just doing builds ? |
15:56 |
Calinou |
est31, 0.3 -> 0.4_20111209 -> 0.4_20120320 -> 0.4 |
15:57 |
Calinou |
one added modding, one made modding use digging groups, one changed a lot of other things |
15:57 |
Calinou |
(mod namespace, etc) |
15:57 |
est31 |
sfan5, H-H-H has a sound problem with android, have you talked with each other yet? |
15:57 |
est31 |
Calinou, did that break the network code? |
15:57 |
nrzkt |
est31: he doesn't have problem with our daily build |
15:58 |
nrzkt |
no because old protocol version only add features |
15:58 |
Calinou |
est31, yes |
15:58 |
Calinou |
0.3 servers can't accept 0.4 clients, 0.4 clients can't connect to 0.3 servers |
15:58 |
H-H-H |
if i build master for androd the sound us fubar |
15:58 |
est31 |
Calinou, well, there was actually a reason behing |
15:58 |
est31 |
behind* |
15:58 |
nrzkt |
oh i should look at 0.3 PROTOCOL_VERSIOn to remove it :p |
15:58 |
est31 |
and minetest was much smaller back then |
15:58 |
H-H-H |
but if i build head of stable0.4 itss fine |
15:58 |
H-H-H |
which is last android release |
15:59 |
est31 |
H-H-H, can you perhaps make a git bisect? |
15:59 |
nrzkt |
yes, we have some master backports for android on it, especially from Zeno` |
15:59 |
nrzkt |
and what about the daily build H-H-H ? |
15:59 |
RealBadAngel |
hmmmm, with you i have this usual problem: "hey i think you should use here this and that." for example templates. after some time you admit yourself whenever you spot such place and think the same to yourself, it ends with trashing the idea |
16:00 |
H-H-H |
nrzkt the daily build for android is built from stable-0.4 |
16:00 |
RealBadAngel |
but yet, fact that you commented my code (thrown some shit on it) stays |
16:00 |
H-H-H |
its not built from master |
16:00 |
RealBadAngel |
and you do that all the time |
16:00 |
nrzkt |
oh ? |
16:01 |
RealBadAngel |
if you were my manager i would propably kicked you in the ass |
16:01 |
H-H-H |
est31 i need to do some reading on git bisect |
16:01 |
* H-H-H |
has never used it |
16:01 |
RealBadAngel |
and went lookin for another one |
16:01 |
nrzkt |
you are right H-H-H |
16:01 |
RealBadAngel |
but luckily its our hobby |
16:01 |
est31 |
lol "i would propably kicked you in the ass" |
16:02 |
H-H-H |
:) |
16:03 |
H-H-H |
anyone know if sf is back up yet |
16:03 |
* H-H-H |
is waiting to do a svn-git conversion for irrlicht |
16:04 |
est31 |
H-H-H, it has nothing to do with irrlicht |
16:04 |
H-H-H |
i know |
16:04 |
est31 |
we always take latest irrlicht versino |
16:04 |
est31 |
version* |
16:04 |
est31 |
make a bisect on the minetest repo itself |
16:04 |
H-H-H |
but i want to keep a copy of irrlicht on github so when sf goes down it dont matter |
16:04 |
est31 |
H-H-H, https://github.com/zaki/irrlicht |
16:04 |
H-H-H |
as a new android build allways d/l it from sf |
16:05 |
est31 |
https://github.com/svn2github/irrlicht |
16:05 |
est31 |
meh, you dont need to make new android builds every time |
16:05 |
est31 |
completely |
16:05 |
H-H-H |
i know i dont have to |
16:06 |
RealBadAngel |
hmmmm, btw your code is not that leaky, perfect and all. and we still have floating invisible caves in the air. also to that flying circus lately joined dungeon team. |
16:06 |
est31 |
yes its more proper your way, agreed |
16:06 |
H-H-H |
thanks for those links will try them |
16:06 |
RealBadAngel |
so indeed, youre not leaky. youre from the flying league :P |
16:07 |
est31 |
that last argument by RealBadAngel is the first one i agree to in a long time |
16:07 |
est31 |
(in this discussion) |
16:08 |
nrzkt |
xD |
16:10 |
TBC_x |
It looks like ~intlGUIEditBox never runs |
16:10 |
est31 |
TBC_x, why that |
16:10 |
TBC_x |
the Reference counter is always > 0 |
16:10 |
est31 |
we dont delete it? |
16:10 |
est31 |
shame on us |
16:10 |
est31 |
make a pr which deletes it |
16:11 |
TBC_x |
can't find where it is |
16:11 |
H-H-H |
thanks for your time guys :) |
16:11 |
TBC_x |
I'm also tracking leaking MapBlockMesh |
16:12 |
est31 |
oh yes that has to be fixed |
16:12 |
TBC_x |
i wrapped it in c++11 pointers and it got worse :P |
16:13 |
RealBadAngel |
TBC_x, whats leakin here? |
16:14 |
TBC_x |
MapBlockMesh doesn't get deleted and hangs in memory, but I can't find where |
16:15 |
RealBadAngel |
i can put in the code count of copies being active |
16:15 |
RealBadAngel |
i made so to compare meshes and minimap mapblocks |
16:15 |
RealBadAngel |
havent noticed a leak. but it was a simple comparision of number of loaded ones |
16:16 |
TBC_x |
i don't care how many, I care where |
16:17 |
TBC_x |
IMO it is because a container gets deleted without removing the elements |
16:17 |
TBC_x |
properly |
16:18 |
TBC_x |
maybe missing a virtual desctructor somewhere |
16:19 |
TBC_x |
authentication seems to leak memory also |
16:19 |
nrzkt |
TBC_x the only leak i see it that the player is not unloaded when leaving the player |
16:20 |
nrzkt |
and not loaded at the next reconnection |
16:20 |
nrzkt |
i don't think it's the better thing to do, unloading him and reloading is better |
16:20 |
RealBadAngel |
so, how one can check exact memory usage? |
16:20 |
TBC_x |
to be clear, I'm looking at client leaks atm |
16:21 |
nrzkt |
okay TBC |
16:21 |
RealBadAngel |
i can make a world with just one block that have content and then hunt it down |
16:21 |
RealBadAngel |
but what should i use to check it |
16:22 |
nrzkt |
sfan5: http://meow.minetest.net/tmp/serverlist_stats_2015-03-14.txt march stats , i need more detailed about outdated versions if you can , because we have 0.4.7 and older |
16:23 |
TBC_x |
will be back in an hour or two |
16:23 |
nrzkt |
i need to have all before 0.4.7 per version found |
16:31 |
RealBadAngel |
hmmmm, anyway, i hope you dont mind we are fighting and arguing. im learning from others, from you too. Just dont be so strict and call some1's code a shit. |
16:33 |
nrzkt |
someone know what is the minetest version on iOS ? |
16:34 |
est31 |
we dont have ios version |
16:34 |
est31 |
yes, we have mac version |
16:34 |
est31 |
but no ios |
16:34 |
nrzkt |
http://meow.minetest.net/tmp/serverlist_stats_2015-03-14.txt |
16:34 |
nrzkt |
read that |
16:35 |
est31 |
its an unofficial fork |
16:35 |
nrzkt |
oh... |
16:35 |
est31 |
this is the general problem of minetest |
16:35 |
nrzkt |
then we don't really care about it, he should updaate its app |
16:35 |
est31 |
most people connect through official forks |
16:36 |
est31 |
and we can't force the owners of those forks to update |
16:36 |
nrzkt |
minetest on play store has 2686 current install and 26000 total installations |
16:36 |
nrzkt |
no, but if they fork, it's their problem to permit players to play, not our |
16:36 |
nrzkt |
it's not minetest, it's not us |
16:38 |
nrzkt |
on android official: 97% users are android 4.0+ |
16:38 |
nrzkt |
15% 5.0+ |
16:38 |
est31 |
I guess we are in the current situation because nobody cared about getting us more directly to our users |
16:38 |
est31 |
this is where we are |
16:39 |
nrzkt |
agree |
16:39 |
nrzkt |
we miss some communication |
16:39 |
nrzkt |
we need a community manager |
16:39 |
nrzkt |
and cleanup this fucking code :p |
16:39 |
est31 |
we should get a blog |
16:39 |
est31 |
its read by press people |
16:39 |
est31 |
press people make articles |
16:39 |
est31 |
articles are read |
16:39 |
nrzkt |
USA are our great users (743) followed by german (252) and France (213) |
16:39 |
est31 |
really? |
16:40 |
nrzkt |
it's the yesterday Google play store stats, yes :p |
16:40 |
est31 |
perhaps we should translate the description to russian too |
16:40 |
nrzkt |
the best connectivity: 4% are using Verizon Wireless |
16:40 |
nrzkt |
in play store languages: russian < 1.5% |
16:41 |
nrzkt |
UK 6.6% Brasil 5.4% |
16:41 |
nrzkt |
oh sorry russia 4.1% |
16:41 |
twoelk |
dont forget the emerging asian markets |
16:42 |
est31 |
we should get to the chinese play store alternative |
16:42 |
est31 |
they have alternatives for everything |
16:42 |
nrzkt |
they are not in the top of google play store |
16:43 |
nrzkt |
est31 you published on F-Droid, is there any stats ? |
16:43 |
nrzkt |
Android upgrade for us is not a problem, 99.89% of our users are up to date |
16:43 |
est31 |
nrzkt, no stats for f-droid |
16:43 |
twoelk |
we should get to every store that offers unofficial versions and offer something better (hopefully we have something better) |
16:44 |
est31 |
nrzkt, here it is #2922 |
16:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/2922 -- Optional reconnect functionality by est31 |
16:44 |
est31 |
im gone |
16:49 |
|
FR^2 joined #minetest-dev |
16:50 |
RealBadAngel |
damn i seem to be only one polish, moreover responsible (or to blame just) whatever you can see on the screen ;) |
16:54 |
twoelk |
polished screen ? |
17:04 |
nrzkt |
bdb ++ all |
17:05 |
|
Taoki[mobile]_1 joined #minetest-dev |
17:06 |
|
stormchaser3000 joined #minetest-dev |
17:11 |
|
stormchaser3000 joined #minetest-dev |
17:12 |
|
rubenwardy joined #minetest-dev |
17:29 |
|
rubenwardy joined #minetest-dev |
17:32 |
|
RealBadAngel joined #minetest-dev |
17:40 |
RealBadAngel |
ok, i do have shaders for wielded ready. i will make pr with it later today |
17:40 |
RealBadAngel |
now i do need a nap |
18:07 |
|
est31 joined #minetest-dev |
18:07 |
est31 |
hmmmm, can you take a look at #2922 |
18:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/2922 -- Optional reconnect functionality by est31 |
18:07 |
est31 |
also everybody else who has time |
18:08 |
est31 |
VanessaE, with the pr people can write mods that shut the server down with a custom message |
18:08 |
est31 |
there are multiple ways to send a message to a mod |
18:09 |
est31 |
e.g. you can make a named pipe |
18:09 |
est31 |
like the mtsatellite mod did |
18:09 |
est31 |
lets see what the modding community comes up with |
18:10 |
est31 |
if the pr gets merged at all, seems nrz dislikes a non-functional detail of it |
18:10 |
est31 |
but i wont merge it without it, sorry. |
18:28 |
|
stormchaser3000_ joined #minetest-dev |
18:31 |
|
paramat joined #minetest-dev |
18:35 |
paramat |
nore, i'll push game#576 (fix for stairs) and game#575 soon |
18:35 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/576 -- Grant multiple tiles on stairs model by kilbith |
18:35 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/575 -- Add items table for give_initial_stuff by Rui914 |
18:38 |
|
stormchaser3000_ joined #minetest-dev |
18:45 |
TBC_x |
how do I link against custom built irrlicht? |
18:45 |
|
kilbith joined #minetest-dev |
18:49 |
kilbith |
TBC_x: https://github.com/minetest/minetest/blob/master/README.txt#L194 |
18:49 |
paramat |
kilbith yes i'm waiting for the 2nd +1 |
18:50 |
kilbith |
paramat: already have : https://github.com/minetest/minetest_game/pull/565#issuecomment-122268509 |
18:51 |
rubenwardy |
paramat |
18:52 |
rubenwardy |
don't merge game#575 |
18:52 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/575 -- Add items table for give_initial_stuff by Rui914 |
18:52 |
rubenwardy |
I'm about to submit an improvement |
18:52 |
TBC_x |
thanks |
18:53 |
paramat |
okay |
18:57 |
paramat |
hm okay will push 577 too |
19:02 |
rubenwardy |
game#579 |
19:02 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/579 -- Add items table for give_initial_stuff and Add an API for give_initial_stuff by rubenwardy |
19:03 |
rubenwardy |
actually, it might be a good idea to get stuff from a setting |
19:03 |
paramat |
ah nice an api |
19:05 |
rubenwardy |
1sec, I'm adding a setting |
19:07 |
paramat |
perhaps we can do without a setting if we have an api? |
19:07 |
rubenwardy |
should I submit this: https://gist.github.com/rubenwardy/c811be03d917a6bfdef6 |
19:07 |
rubenwardy |
that way you can also do give_initial_stuff.stuff from a mod |
19:09 |
paramat |
not sure, perhaps start a discussion in the thread for other's input |
19:09 |
rubenwardy |
that doesn't actually work |
19:09 |
TBC_x |
I would suggest to have on_account_creation or on_first_world_enter (if there is a plan for multiple worlds in the future) instead of that |
19:10 |
rubenwardy |
minetest.register_on_new_player |
19:11 |
rubenwardy |
updated to actually work: https://gist.github.com/rubenwardy/c811be03d917a6bfdef6 |
19:11 |
rubenwardy |
missing :trim() |
19:12 |
TBC_x |
don't mind me, I talk first, then read |
19:19 |
rubenwardy |
game#579 done |
19:19 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/579 -- Improve give_initial_stuff by rubenwardy |
19:24 |
|
twoelk|2 joined #minetest-dev |
19:44 |
|
MinetestForFun joined #minetest-dev |
19:49 |
paramat |
now pushing game 576 and game 577 |
19:57 |
paramat |
complete |
20:05 |
|
stormchaser3000_ joined #minetest-dev |
20:07 |
|
paramat left #minetest-dev |
20:09 |
|
stormchaser3000_ joined #minetest-dev |
20:17 |
|
blaise joined #minetest-dev |
20:29 |
|
nore joined #minetest-dev |
20:32 |
|
blaise joined #minetest-dev |
20:33 |
|
selat joined #minetest-dev |
20:47 |
VanessaE |
another backtrace added to #2913 |
20:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/2913 -- Unexplained, random crashes (segfaults, aborts, OOM) |
20:57 |
RealBadAngel |
meanwhile im ready with wielded_shader, preparing pr now |
21:00 |
RealBadAngel |
VanessaE, from the logs it looks like thats something related to latest est31 fixes to threas |
21:00 |
RealBadAngel |
*threads |
21:01 |
RealBadAngel |
but im not sure if he touched emerge threads, if not its hmmm's case |
21:01 |
RealBadAngel |
__PRETTY_FUNCTION__ = "bool JSemaphore::Wait(unsigned int)" |
21:05 |
VanessaE |
*shrug* |
21:05 |
VanessaE |
I figure if I add enough backtraces, a pattern will emerge |
21:22 |
|
stormchaser3000 joined #minetest-dev |
21:45 |
celeron55 |
VanessaE: try this: https://github.com/celeron55/minetest/tree/bdebug |
21:46 |
TBC_x |
hi c55 |
21:47 |
celeron55 |
it's a weird thing that sometimes might make it easier to collect useful information about memory errors in live environments |
21:48 |
RealBadAngel |
celeron55, does it slow down build? (like debug one does) |
21:48 |
VanessaE |
celeron55: ok, added. |
21:48 |
celeron55 |
RealBadAngel: it won't give you proper backtraces if you're not using a debug build |
21:49 |
RealBadAngel |
i see |
21:50 |
celeron55 |
it does two things: it wraps memory allocation in such a way that it is able to always clear out memory both when it is allocated and when it is deallocated (with different patterns), and it will catch segfaults and aborts on its own and print a compact backtrace without a debugger (which is configurable in main.cpp in this case) |
21:51 |
celeron55 |
i mean, it's usually useless but in case of obscure stuff, it sometimes reveals things you wouldn't see otherwise |
21:51 |
celeron55 |
and it only works on x86 and x86_64 linux |
21:52 |
celeron55 |
also this is a cobbled together piece of code from another project so it's exactly that; don't push it upstream |
21:53 |
celeron55 |
it even enables C++11 for the whole project because that's what it's coded in |
21:53 |
|
Taoki[laptop] joined #minetest-dev |
21:55 |
TBC_x |
the minimap code needs some tweaking |
21:55 |
RealBadAngel |
celeron55, rebasing it when needed is a small price when you will nail some bug imho |
21:55 |
RealBadAngel |
TBC_x, what you have in mind? |
21:55 |
celeron55 |
VanessaE: you should probably add an abort() somewhere in the code to test how it behaves |
21:56 |
RealBadAngel |
#2924, some testing welcom |
21:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/2924 -- Add wielded (and CAOs) shader by RealBadAngel |
21:56 |
TBC_x |
it apparently generates minimap even for item meshes, or at least initializes memory for the minimap |
21:56 |
TBC_x |
minimap data to be exact |
21:56 |
RealBadAngel |
TBC_x, you mean when called to get 1x1x1 item mesh? |
21:57 |
TBC_x |
I got leaks at MapBlockMesh::MapBlockMesh(MeshMakeData*, irr::core::vector3d<short>) (mapblock_mesh.cpp:1048) |
21:57 |
TBC_x |
which is m_minimap_mapblock = new MinimapMapblock; |
21:57 |
RealBadAngel |
TBC_x, hold on a second |
21:57 |
TBC_x |
and destructor was not updated |
21:58 |
RealBadAngel |
aw shit |
21:58 |
RealBadAngel |
youre right |
21:59 |
TBC_x |
wanna do the pr yourself? |
21:59 |
RealBadAngel |
we all have forgot that mapblock_mesh is used to get inventory images |
22:00 |
RealBadAngel |
TBC_x, have you wrote already a fix for that? |
22:00 |
TBC_x |
not yet |
22:00 |
TBC_x |
had destroyed the entire code to find that |
22:00 |
TBC_x |
lol |
22:00 |
VanessaE |
celeron55: er, FAIL |
22:00 |
VanessaE |
vanessarainbird:~/Minetest-related/minetest_core$ minetest |
22:00 |
VanessaE |
bdebug/cmem: Ran out of preinit memory pool |
22:00 |
VanessaE |
Aborted (core dumped) |
22:01 |
RealBadAngel |
TBC_x, gimme half an hour, i will fix it then |
22:01 |
celeron55 |
8) |
22:01 |
TBC_x |
because I misinterpreted valgrind logs :P |
22:01 |
* kilbith |
implores the devs on his knees to fix that f-leak : https://lut.im/GJvAiBTc/zuDMcZA1 |
22:01 |
celeron55 |
you'll have to increase a... value |
22:01 |
TBC_x |
could find it in minutes |
22:02 |
celeron55 |
VanessaE: bdebug/linux/cmem.c:127 |
22:02 |
celeron55 |
VanessaE: make that value ten times larger or whatever |
22:02 |
TBC_x |
I was wondering why even stack allocated MapBlockMesh was leaking memory |
22:02 |
celeron55 |
don't ask what it does; it's a weird system |
22:04 |
RealBadAngel |
TBC_x, there are two pieces responsible for that |
22:04 |
RealBadAngel |
itemdef and wieldmesh |
22:04 |
TBC_x |
yes |
22:05 |
TBC_x |
I'd refactor that bit |
22:05 |
TBC_x |
but I think this is not the way things are done here |
22:06 |
RealBadAngel |
getting a single mesh for a node and using for it thingy that generates a mesh for whole mapblock is more than a hack |
22:07 |
RealBadAngel |
i would rather code simpler routine to obtain the mesh |
22:08 |
RealBadAngel |
anyway since im done with wielded shader, i can start coding that right now |
22:08 |
RealBadAngel |
thanks for investigating and pointing out this issue |
22:08 |
VanessaE |
celeron55: I'll pass. |
22:10 |
RealBadAngel |
lol |
22:10 |
RealBadAngel |
travis just failed, irrlicht pages are down |
22:11 |
RealBadAngel |
sf looks to be down |
22:13 |
TBC_x |
I'm not surprised |
22:15 |
TBC_x |
and Why I am leaking now? :P |
22:17 |
RealBadAngel |
well, im a bit stuck |
22:17 |
RealBadAngel |
mapblock_mesh is a kinda swiss army knife |
22:18 |
RealBadAngel |
thats not any good |
22:21 |
|
sloantothebone joined #minetest-dev |
22:23 |
TBC_x |
well, better break it apart |
22:24 |
TBC_x |
will be 'fun' |
22:28 |
RealBadAngel |
TBC_x, i want to get rid of need to get inv images, so calls to mapblock_mesh will become obsolete |
22:28 |
RealBadAngel |
but thats a song of a future |
22:30 |
RealBadAngel |
meanwhile maybe just call to content_mapblock directly, without the need of mapblock mesh would do |
22:32 |
|
paramat joined #minetest-dev |
22:38 |
|
stormchaser3000 joined #minetest-dev |
22:52 |
RealBadAngel |
kahrl, paramat, can you check wielded/CAOs pr? |
22:52 |
RealBadAngel |
kahrl, your FSAA fix is in it |
22:53 |
paramat |
sorry busy at the moment |
23:04 |
TBC_x |
well... SINGLE leak fixed |
23:07 |
RealBadAngel |
TBC_x, which one? |
23:08 |
TBC_x |
missing delete for minimapblock |
23:08 |
RealBadAngel |
where it was missing? |
23:09 |
RealBadAngel |
btw, ive coded fix for wielded and itemdef case |
23:09 |
|
proller joined #minetest-dev |
23:09 |
RealBadAngel |
about to test it |
23:09 |
TBC_x |
http://sprunge.us/VjAS |
23:10 |
RealBadAngel |
im afraid thats wrong |
23:10 |
TBC_x |
hmm? |
23:10 |
RealBadAngel |
you cant do that |
23:10 |
RealBadAngel |
mesh can be deleted if its only air |
23:11 |
RealBadAngel |
and its being deleted then |
23:11 |
RealBadAngel |
but minimap mapblock have to stay here |
23:11 |
RealBadAngel |
and thats not a leak |
23:12 |
RealBadAngel |
otherwise you will get fucked up radar mode for example |
23:13 |
RealBadAngel |
one and only case when you can delete minimap mapblock is the case when block gets unloaded |
23:13 |
RealBadAngel |
or shutdown |
23:13 |
TBC_x |
minimap mapblocks need refcounting then |
23:14 |
TBC_x |
yeah, it segfaults, whoops |
23:14 |
RealBadAngel |
lemme point you the code that takes care of it |
23:15 |
RealBadAngel |
read client.cpp line 520 and on |
23:15 |
TBC_x |
is it thread safe? |
23:16 |
RealBadAngel |
deleting minimap_mapblock? |
23:16 |
RealBadAngel |
no its not |
23:16 |
TBC_x |
ok |
23:16 |
RealBadAngel |
mapper can be running when you are deleting its data |
23:17 |
RealBadAngel |
deletion is allowed only in minimap thread |
23:17 |
RealBadAngel |
and on update |
23:18 |
RealBadAngel |
basically you can easily check if theres a leak. number of loaded blocks have to be the same as minimap mapblocks count |
23:19 |
RealBadAngel |
there can be a slight delay to get them even (its done in threads) |
23:20 |
RealBadAngel |
but after triggering an update they should match |
23:22 |
RealBadAngel |
btw, if you want to delete something you dont have to check if its not null |
23:22 |
TBC_x |
was not sure on the behaviour |
23:22 |
|
zat joined #minetest-dev |
23:23 |
RealBadAngel |
i was thinking the same, but somebody pointed that to me too :) |
23:23 |
TBC_x |
so client.cpp:536 is useless then |
23:24 |
RealBadAngel |
indeed |
23:24 |
RealBadAngel |
also 538 should be not needed |
23:24 |
RealBadAngel |
delete shall set it to NULL |
23:25 |
TBC_x |
its minimap block needs to be deleted also, right? |
23:26 |
RealBadAngel |
line 555? |
23:27 |
RealBadAngel |
this should be the case of !block |
23:27 |
RealBadAngel |
ie block is not here any longer |
23:28 |
RealBadAngel |
and somebody messed it |
23:29 |
TBC_x |
yeah, I don't think that is doing anything |
23:29 |
RealBadAngel |
in this case mapper update should be also triggered |
23:29 |
RealBadAngel |
with empty data |
23:30 |
RealBadAngel |
mapper shall receive pos and empty data in order to remove stored block from cache |
23:35 |
hmmmm |
[07:24 PM] <RealBadAngel> delete shall set it to NULL |
23:35 |
hmmmm |
this is hilariously wrong |
23:38 |
|
stormchaser3000 joined #minetest-dev |
23:41 |
|
H-H-H joined #minetest-dev |
23:41 |
RealBadAngel |
hmmmm, so what it does? |
23:41 |
hmmmm |
why don't you try it before causing double free errors based on completely baseless assumptions |
23:43 |
RealBadAngel |
i havent tried it yet even |
23:43 |
RealBadAngel |
it was just a thought |
23:44 |
hmmmm |
why don't you say "maybe delete sets it to NULL" |
23:44 |
hmmmm |
no, instead you proudly assert that delete shall set it to null |
23:44 |
hmmmm |
it's not even a question |
23:44 |
hmmmm |
you're so cocksure |
23:47 |
TBC_x |
delete r.mesh in else doesn't delete its minimap block |
23:48 |
RealBadAngel |
hmmmm, calm down a bit :P |
23:48 |
hmmmm |
that's because you have me afraid you're going to start adding in subtle, hidden bugs again |
23:48 |
hmmmm |
jesus christ man |
23:49 |
hmmmm |
remember the "if (g_settings->getBool("enable_thing")); {" you tried to slip in with something you wanted to make the default? |
23:49 |
RealBadAngel |
youre starting to code that dont even exists yet :P |
23:49 |
hmmmm |
that is sly, but thankfully i have good eyesight |
23:50 |
RealBadAngel |
oh cmon, we are talking here, lookin what can be improved |
23:50 |
TBC_x |
it looks like sound_enabled = false still initializes audio and stuff |
23:51 |
hmmmm |
RealBadAngel: also could you point me to where a block unload event adds a mesh update to the queue |
23:56 |
RealBadAngel |
hmmmm, whoever added do_mapper_update broke it |
23:56 |
hmmmm |
why's that, RealBadAngel? |
23:57 |
RealBadAngel |
line 554 should be a reason to update too |
23:57 |
hmmmm |
and it is |
23:57 |
RealBadAngel |
no its not |
23:57 |
hmmmm |
why not? |
23:57 |
RealBadAngel |
wait |
23:58 |
hmmmm |
nice try, but i'm not wrong. |
23:58 |
TBC_x |
line 555 doesn't even make sense |
23:58 |
RealBadAngel |
its not my original code, lemme rethink it |
23:59 |
RealBadAngel |
i will put there debug code and will check it just to be sure |
23:59 |
hmmmm |
why not just use some logic |
23:59 |
hmmmm |
use your thinker |