| Time |
Nick |
Message |
| 00:01 |
|
ShadowNinja joined #minetest-dev |
| 00:05 |
sapier |
using a reinterpret cast against adding a transition struct and quite some copy code ... I think I can live with reinterpret in one location |
| 00:22 |
|
EvergreenTree joined #minetest-dev |
| 00:22 |
|
EvergreenTree joined #minetest-dev |
| 00:32 |
Sokomine |
are there any more changes coming today? (just want to know if it's time to undo that one unwanted "bugfix" and compile again :-)) |
| 00:34 |
|
zat joined #minetest-dev |
| 00:36 |
|
sapier joined #minetest-dev |
| 00:36 |
sapier |
sorry got disconnected |
| 00:37 |
sapier |
which bugfix sokomine? |
| 00:38 |
sapier |
well sokomine by now you're the only one (i know) who has really a problem with it. I suggest at least asking in forum and starting a poll. |
| 00:50 |
Sokomine |
hm. that might be an option, yes. else i'll have to change it every time something is changed with game.cpp :-/ |
| 00:51 |
sapier |
well you could write a fix adding a setting ... but I don't know how much work it is to stop player from building to other player/mobs but not to himself |
| 00:57 |
|
Sokomine joined #minetest-dev |
| 01:25 |
|
sapier left #minetest-dev |
| 01:30 |
|
rsiska joined #minetest-dev |
| 01:40 |
|
EvergreenTree joined #minetest-dev |
| 01:40 |
|
EvergreenTree joined #minetest-dev |
| 01:44 |
|
zat joined #minetest-dev |
| 02:10 |
VanessaE |
anyone awake here? |
| 02:11 |
* VanessaE |
pokes ShadowNinja |
| 02:14 |
|
farlepet joined #minetest-dev |
| 02:26 |
|
OldCoder joined #minetest-dev |
| 02:37 |
|
Miner_48er joined #minetest-dev |
| 03:19 |
|
farlepet joined #minetest-dev |
| 05:28 |
|
Selat joined #minetest-dev |
| 05:37 |
|
Guest98666 joined #minetest-dev |
| 05:45 |
|
nore joined #minetest-dev |
| 05:50 |
hmmmm |
hrm sapier you still around? |
| 05:50 |
VanessaE |
long gone, hmmmm |
| 05:50 |
VanessaE |
[02-07 20:25] <-- sapier (~sapier p5498D3D3.dip0.t-ipconnect.de) has left #minetest-dev |
| 05:50 |
hmmmm |
ah |
| 05:51 |
hmmmm |
i just saw that yaeh |
| 05:51 |
hmmmm |
i need to strap down and get some substantial work done on minetest |
| 05:51 |
hmmmm |
so much stuff to do |
| 05:51 |
hmmmm |
i don't ever do any of it though |
| 05:51 |
VanessaE |
want a simple one to look at? :) |
| 05:51 |
hmmmm |
no |
| 05:51 |
VanessaE |
haha |
| 05:51 |
hmmmm |
i have my own things to look at |
| 05:52 |
hmmmm |
gonna fix up the flag string BS first |
| 05:52 |
hmmmm |
then i'm gonna do the ServerMap::emergeBlock() callback |
| 05:52 |
hmmmm |
then i'm gonna fix up findSpawnPos |
| 05:52 |
VanessaE |
well I think I'm gonna crash |
| 05:53 |
hmmmm |
but before i do any of that I'd like to first fix up that horrible NULL dereference that somebody retardedly put in there |
| 05:54 |
hmmmm |
then i have to look into celeron's custom emergequeue_limit_* parameter settings for a quick fix until I can get a real solution to looking up which blocks exist in the db already |
| 05:54 |
hmmmm |
then i need to remove the noiseparam reading from the config file and do that in Lua instead |
| 05:55 |
hmmmm |
then I need to finally commit my biome fixup |
| 05:56 |
Guest98666 |
It sounds like you have quite a lot on your plate. |
| 05:57 |
hmmmm |
i still didn't get around to the *real* unfinished work like finishing mapgen v7 and porting mapgen v5 |
| 06:10 |
hmmmm |
interesting, AsyncWorkerThread_0 gives me a failed to parse json data blah blah blah |
| 06:10 |
hmmmm |
and then it spits out an incredibly huge amount of json |
| 06:10 |
Guest98666 |
That's helpful. |
| 06:16 |
hmmmm |
hmm, i don't notice any significant difference with celeron's custom block sending parameters |
| 06:16 |
hmmmm |
in fact what i have noticed is that it gets stuck every once in a while |
| 06:17 |
hmmmm |
but minetest as-is could benefit from more aggressive block emerge/send settings |
| 06:19 |
|
Zeitgeist_ joined #minetest-dev |
| 06:25 |
|
OldCoder joined #minetest-dev |
| 07:52 |
|
darkrose joined #minetest-dev |
| 08:16 |
|
OldCoder joined #minetest-dev |
| 08:23 |
|
Calinou joined #minetest-dev |
| 08:29 |
|
us_0gb joined #minetest-dev |
| 09:23 |
|
bas080 joined #minetest-dev |
| 09:46 |
|
deltib joined #minetest-dev |
| 10:29 |
|
sapier joined #minetest-dev |
| 10:31 |
|
Jordach joined #minetest-dev |
| 10:47 |
|
rsiska joined #minetest-dev |
| 11:36 |
|
ImQ009 joined #minetest-dev |
| 11:55 |
|
PilzAdam joined #minetest-dev |
| 12:11 |
|
Megaf joined #minetest-dev |
| 12:15 |
sapier |
ShadowNinja: some of your recent changes managed to completely hide lua errors occuring "on_activate" |
| 12:16 |
Megaf |
sapier, I just pulled the latest things to get you fix |
| 12:16 |
Megaf |
now I get this error |
| 12:16 |
Megaf |
10:15:29: ACTION[main]: Server for gameid="minetest" listening on 67.215.65.132:30002. |
| 12:16 |
sapier |
ok completely isn't quite right it will cause very very strange effects |
| 12:16 |
Megaf |
10:15:30: ERROR[main]: ERROR: An unhandled exception occurred: Failed to bind socket (port already in use?) |
| 12:16 |
Megaf |
first, the correct IP would be 0.0.0.0 |
| 12:16 |
Megaf |
as it was before |
| 12:16 |
sapier |
yes did you set bind_addr? |
| 12:17 |
Megaf |
and the port is not in use, I just changed it |
| 12:17 |
Megaf |
hm |
| 12:17 |
Megaf |
hm |
| 12:17 |
Megaf |
let me check |
| 12:19 |
Megaf |
sapier, my minetest.conf doest have that thing |
| 12:19 |
sapier |
that's strange |
| 12:19 |
Megaf |
well, working now |
| 12:20 |
Megaf |
sapier, git pull wont change minetest.conf, and thats good |
| 12:20 |
Megaf |
it will just update minetest.conf.example |
| 12:20 |
sapier |
but not a solution where did it get that address from |
| 12:20 |
Megaf |
no idea |
| 12:21 |
sapier |
I've heared about that issue now and then but can't reproduce it. If you manage to find out how this happens I'd be very thankfull. |
| 12:33 |
sapier |
well ShadowNinja to make it worse it doesn't hide all errors. Seems to be a quite special case |
| 12:48 |
|
jin_xi joined #minetest-dev |
| 13:00 |
|
Gethiox joined #minetest-dev |
| 13:12 |
|
blaise joined #minetest-dev |
| 13:35 |
|
EvergreenTree joined #minetest-dev |
| 13:35 |
|
EvergreenTree joined #minetest-dev |
| 13:41 |
|
Mitroman joined #minetest-dev |
| 13:43 |
|
werwerwer joined #minetest-dev |
| 14:09 |
sapier |
https://github.com/minetest/minetest/pull/1142 should ensure noone uses broken luajit with minetest |
| 14:11 |
PilzAdam |
sapier, https://github.com/minetest/minetest/pull/1142/files#diff-af3b638bc2a3e6c650974192a53c7291R166 |
| 14:11 |
PilzAdam |
its menu_lua_api.txt, not lmenu_lua_api.txt |
| 14:11 |
sapier |
oops |
| 14:11 |
|
EvergreenTree joined #minetest-dev |
| 14:11 |
|
EvergreenTree joined #minetest-dev |
| 14:12 |
sapier |
thanks |
| 14:12 |
PilzAdam |
an option to disable luajit is nice |
| 14:13 |
|
eeew` joined #minetest-dev |
| 14:13 |
sapier |
yes I needed it to be able to use lua debuger ... doesn't work with luajit |
| 14:14 |
sapier |
btw on asigning this one to our buildsystem maintainer I realized this is xyz who recently quit supporting minetest :-( |
| 14:14 |
PilzAdam |
did he? |
| 14:15 |
sapier |
yes he revoked his membership of minetest repository |
| 14:15 |
PilzAdam |
well, there is still the good old "2 core devs have to agree" rule |
| 14:17 |
sapier |
ok do you agree to the fixed version? |
| 14:17 |
PilzAdam |
sapier, s/luajit/LuaJIT/ in lnies 249 & 252 |
| 14:18 |
sapier |
ok something else? |
| 14:18 |
PilzAdam |
I agree to the idea behind it, but Im not familiar with cmake |
| 14:18 |
PilzAdam |
so I cant check if the code is right |
| 14:19 |
sapier |
ok so lets wait a day or two maybe someone voloteers to test it |
| 14:20 |
sapier |
of course I did test it too, but as always different environments may show different issues. I haven't tested windows for example |
| 14:23 |
PilzAdam |
IIRC sfan5's win builds have LuaJIT, he could test it |
| 14:24 |
sfan5 |
I thought yours have LuaJIT too |
| 14:25 |
PilzAdam |
I havent used my scripts for some time now |
| 14:25 |
PilzAdam |
there might be other problems with them already |
| 14:26 |
sapier |
https://github.com/minetest/minetest/issues/1082 what do you think about patch 1 and 3? |
| 14:26 |
sapier |
I'm not sure about the custom thing but I guess switching to bitset and list will improve performance |
| 14:29 |
PilzAdam |
I guess we should think about a release |
| 14:29 |
PilzAdam |
sapier's network fixes lead to a noticeable faster experience |
| 14:30 |
sapier |
there's the one 0.4.9 issue left. VanessaE hasn't approved it by now. And noone else seems to test it |
| 14:30 |
PilzAdam |
do you mean #1132 ? |
| 14:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/1132 -- 0.4.9 (sometimes) failes to connect to old as well as latest server due to missing TOSERVER_RECEIVED_MEDIA |
| 14:32 |
sapier |
yes and #1139 |
| 14:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/1139 -- Workaround for missing initialization of 0.4.9 by sapier |
| 14:32 |
sapier |
last one is fix for 1132 |
| 14:33 |
PilzAdam |
havent we already decided to use alternative 1)? |
| 14:33 |
sapier |
yes and 1139 is a patch doing this but it's not yet proven to work correct |
| 14:34 |
PilzAdam |
ok, so we have to wait for that one |
| 14:34 |
PilzAdam |
anything else that is important before a release? |
| 14:36 |
PilzAdam |
(the milestone isnt really useful, since it seems that are more or less random issues there) |
| 14:38 |
nore |
PilzAdam, I guess this should be fixed: https://github.com/minetest/minetest/issues/944 |
| 14:40 |
sapier |
https://github.com/minetest/minetest/pull/973 ... not important as of features but maybe from legal perspective |
| 14:42 |
sapier |
https://github.com/minetest/minetest/pull/954 |
| 14:43 |
sapier |
https://github.com/minetest/minetest/pull/670 |
| 14:43 |
|
proller joined #minetest-dev |
| 14:43 |
PilzAdam |
nore, the idea to have a special "slot" for stacks that are hold by the cursor comes up once in a while, but there are reasons why it wasnt done yet |
| 14:43 |
nore |
the reasons were something about saving the player IIRC |
| 14:44 |
PilzAdam |
also the Lua callbacks, IIRC |
| 14:44 |
PilzAdam |
the on_take and on_place wouldnt be at the same time anymore |
| 14:44 |
PilzAdam |
(or something like this) |
| 14:45 |
sapier |
I guess that one isn't trivial to fix so nothing to rush in before a upcoming release ... assuming we decided to do a release ... did we? |
| 14:45 |
PilzAdam |
what Sokomine suggests sounds like a better idea: only allow moving when the target slot is empty, or can hold the whole stack |
| 14:46 |
PilzAdam |
nore, what makes it important to be fixed before next release? |
| 14:46 |
nore |
because it should have been fixed far earlier... ;) |
| 14:47 |
nore |
(or else, it will become something like the entity duplication bug that nobody will try to fix for a long time) |
| 14:47 |
sapier |
well if there's noone willing to do it it wont be fixed |
| 14:48 |
|
Yepoleb_ joined #minetest-dev |
| 14:50 |
xyz |
kahrl: can you explain why do you call endScene here: https://github.com/minetest/minetest/blob/master/src/tile.cpp#L886? it seems to cause (little) troubles on android, when endScene() is called everything is redrawn on screen so user sees item texture in lower left corner, a moment after it's replaced with the loading screen |
| 14:50 |
xyz |
so it kinda blinks |
| 14:53 |
PilzAdam |
nore, also, do you know which machines remove the items in their output slots when they "update"? since the default furnace doesnt do that its not a problem there |
| 14:53 |
nore |
PilzAdam, the circular saw from moreblocks does that |
| 14:54 |
|
hmmmm joined #minetest-dev |
| 14:55 |
PilzAdam |
hmmmm, do you have anything to do that is important before a release? |
| 14:55 |
hmmmm |
what do you mean |
| 14:56 |
PilzAdam |
IMO we should release in the near future |
| 14:56 |
hmmmm |
eh |
| 14:56 |
hmmmm |
how about the end of the month |
| 14:56 |
hmmmm |
nothing this soon, we all see what forced releases do |
| 14:58 |
PilzAdam |
the problem of the last one was that there wasnt a long enough feature freeze IIRC |
| 14:58 |
hmmmm |
nonsense, it ended up being a very long feature freeze |
| 14:59 |
hmmmm |
stuff just sat around for an entire week after i wanted to originally release it |
| 14:59 |
hmmmm |
anyway yes, there are a lot of things i'd like to do before any new sort of version |
| 14:59 |
PilzAdam |
I havent even noticed that we wanted to realease last time |
| 15:00 |
PilzAdam |
it was more a communication problem |
| 15:00 |
hmmmm |
it's because we needed to fix a serious deficiency with 0.4.8 quickly and also to coincide with the holidays |
| 15:01 |
hmmmm |
like i was saying with sapier, the REAL problem is that there's no way to give the users of specific versions patches |
| 15:01 |
hmmmm |
so if we were able to patch 0.4.8 and push an update for that, maybe a notifier or whatever "would you like to update" then everything would work out so much better |
| 15:01 |
PilzAdam |
the reason why Id like to release in the near future is that sapier's connection fixes lead to a noticeable faster experience |
| 15:02 |
hmmmm |
oh |
| 15:02 |
hmmmm |
by the way |
| 15:02 |
hmmmm |
about version numbers, i feel that when 0.5.0 rolls around we should make it 5.0.0 instead and actually use minor/patch numbers for minor and patch versions |
| 15:02 |
hmmmm |
this isn't unprecedented, SunOS did it before |
| 15:03 |
PilzAdam |
the number itself doesnt matter |
| 15:12 |
sapier |
and for what I think next version should be 0.4.10 ... but as PilzAdam said number doesn't really matter especially as we don't really use them anywhere |
| 15:13 |
hmmmm |
well why not, we should use them anymore |
| 15:15 |
sapier |
I don't have a problem with using version number but I don't have a problem with not using it too |
| 15:16 |
|
Mitroman joined #minetest-dev |
| 15:16 |
sapier |
I'm gonna finish my detailed client info patch to support reading client version too ... this way we would have chance to notify player about outdated version |
| 15:24 |
|
Exio4 joined #minetest-dev |
| 15:32 |
|
Mitroman_ joined #minetest-dev |
| 15:33 |
|
blaise joined #minetest-dev |
| 15:40 |
|
zat joined #minetest-dev |
| 15:41 |
|
blaise joined #minetest-dev |
| 15:48 |
|
OldCoder joined #minetest-dev |
| 15:51 |
|
Zeitgeist_ joined #minetest-dev |
| 15:51 |
|
Zeitgeist_ joined #minetest-dev |
| 16:12 |
|
Calinou joined #minetest-dev |
| 16:12 |
|
rubenwardy joined #minetest-dev |
| 16:14 |
|
rubenwardy_ joined #minetest-dev |
| 16:32 |
|
mrtux joined #minetest-dev |
| 16:33 |
Megaf |
folks, is there a way to ban an IP range? |
| 16:33 |
Megaf |
Id like to ban or block all Brazilians |
| 16:33 |
sapier |
no |
| 16:34 |
PilzAdam |
Megaf, Peacock has a mod for that |
| 16:34 |
xyz |
use iptables |
| 16:34 |
sapier |
and be sure I will not support adding things with that much collateral damage to core features ;-) |
| 16:35 |
sapier |
and xyz is right too, for blocks beeing that static things like iptables are way more suited |
| 16:39 |
Megaf |
xyz, that may be a good idea |
| 16:41 |
hmmmm |
haha |
| 16:41 |
hmmmm |
so I guess the whole BR thing is true. hue hue hue |
| 16:42 |
sapier |
what's the br thing? |
| 16:42 |
hmmmm |
it was a meme that BRs (brazillians) join game servers in gangs and shit everything up |
| 16:42 |
Megaf |
They are irritating, griefer, boring |
| 16:42 |
hmmmm |
but i guess like all stereotypes it's based in truth |
| 16:43 |
Megaf |
hmmmm, and I am a Brazilian myself, unfortunately |
| 16:43 |
hmmmm |
wow :( |
| 16:43 |
xyz |
oh |
| 16:43 |
Megaf |
and I absolutely hate this shit of country |
| 16:43 |
xyz |
then it'll be fun when you ban all BR ip ranges with iptables and drop out of ssh connection |
| 16:44 |
Megaf |
so please, would you let me move and live with you in another country? |
| 16:44 |
Megaf |
:P |
| 16:44 |
xyz |
sure |
| 16:44 |
xyz |
move to russia |
| 16:44 |
sapier |
well just be sure not to have a bad opinion about putin ;-) |
| 16:45 |
Megaf |
legally, my grandfather is Russian |
| 16:45 |
xyz |
putin is good |
| 16:45 |
Megaf |
I mean, my great-grandfather |
| 16:45 |
xyz |
http://russiannerd.files.wordpress.com/2012/07/2054-145008-d618b27bdae29c37836a9c24d58de821.jpg |
| 16:46 |
xyz |
(should stop the offtopic here) |
| 16:52 |
|
farlepet joined #minetest-dev |
| 17:06 |
|
us_0gb joined #minetest-dev |
| 17:12 |
Megaf |
and there should be something to block everyone whos not playing the actual minetest |
| 17:12 |
|
OldCoder joined #minetest-dev |
| 17:16 |
us_0gb |
What? Block us from the IRC channel? That's not nice, Megaf. Don't you like us any more? |
| 17:17 |
Megaf |
us_0gb, nah, from minetest servers |
| 17:17 |
Megaf |
so people need to use minetest client |
| 17:17 |
us_0gb |
Oh, okay. |
| 17:17 |
us_0gb |
That could be easily bypassed though. |
| 17:20 |
|
Gethiox2 joined #minetest-dev |
| 17:23 |
xyz |
nice |
| 17:23 |
xyz |
let's do vendor lock-in |
| 17:23 |
xyz |
talking about double standards |
| 17:24 |
us_0gb |
Vendor lock in won't even work with the free license anyway. People will read the code and find out what the server is looking for. |
| 17:24 |
VanessaE |
> freeminer author |
| 17:24 |
VanessaE |
> argues against vendor lock-in |
| 17:24 |
sapier |
no there never will be a check for minetest, minetest is open source and will be opensource |
| 17:25 |
VanessaE |
> irony: dripping. |
| 17:25 |
us_0gb |
Or they will just fork, and the server won't know the fork is the not the real deal. |
| 17:25 |
us_0gb |
What is the problem with alloing non-Minetest clients, anyway? |
| 17:25 |
us_0gb |
*allowing |
| 17:26 |
* us_0gb |
is still getting used to this tiny UK keyboard |
| 17:26 |
* us_0gb |
's fingers are too big and the keys aren't where he is used to them |
| 17:27 |
* us_0gb |
shutters to think of how hard it would be to use a cell phone keyboard with his fat fingers |
| 17:29 |
* VanessaE |
pokes kahrl |
| 17:29 |
VanessaE |
you available? we have a problem. |
| 17:31 |
xyz |
VanessaE: who are you quoting? |
| 17:31 |
VanessaE |
xyz: not "quoting" anyone. |
| 17:32 |
VanessaE |
(I'm using it in a different way) |
| 17:32 |
xyz |
ahh |
| 17:32 |
VanessaE |
in other words, to be perfectly honest, you're th last one who should be bringing up "vendor lock-in". |
| 17:33 |
VanessaE |
+e |
| 17:33 |
xyz |
why? |
| 17:34 |
VanessaE |
because of your proposals in the past with freeminer being apt to become incompatible with Minetest. |
| 17:35 |
VanessaE |
vendor lock-in is defined as getting people to use your product, and then making it such that your product isn't compatible with anything else. |
| 17:36 |
xyz |
but it's not because i dislike mt or anything, it's because it's not worth it to keep protocol compatible while switching to enet and msgpack |
| 17:36 |
xyz |
still the same thing as adding a client check? |
| 17:36 |
us_0gb |
Was the goal to create incompatibility, or was that a byproduct of optimisation? There is a difference. |
| 17:36 |
xyz |
well, feel free to believe whatever you want |
| 17:37 |
xyz |
yes, it'll make the network much faster |
| 17:37 |
us_0gb |
It doesn't sound like lock-in to me. |
| 17:37 |
us_0gb |
Someone could fork Freeminer and remerge it with Minetest for compatibility. |
| 17:38 |
sapier |
guys this is minetest-dev can you please stick back to development of minetest? :-) |
| 17:38 |
xyz |
sure ban us |
| 17:38 |
sapier |
noone intends to ban anyone xyz |
| 17:39 |
us_0gb |
Development. Right. sapier, ShadowNinja asked me to tell you about the fact that my 0.4.9 client isn't sending passwords to servers. He said it might be something that got messed up in Minetest's networking. |
| 17:39 |
sapier |
there wont be a vendor lock in core as long as I contribute to minetest, if someone adds it I'm gonna stop working for minetest. I guess lots of other core devs do think same |
| 17:40 |
us_0gb |
I would hope so. |
| 17:40 |
sapier |
what server version us_0gb |
| 17:41 |
us_0gb |
0.4.8, I think. Is there an incompatibility between 0.4.8 and 0.4.9? |
| 17:41 |
sapier |
none I know about but we can't fix any of them |
| 17:42 |
sapier |
0.4.9 stable? |
| 17:42 |
us_0gb |
Yes, the stable one in the PPA. |
| 17:42 |
us_0gb |
But only the 32 bit client. The 64 bit one has no such issue. |
| 17:43 |
sapier |
ok that information is quite relevant. can you verify this happens on latest master too? |
| 17:44 |
sapier |
while we can't fix it for 0.4.9 we can fix it for 0.4.10 ... case this will be the version number :-) |
| 17:44 |
us_0gb |
Okay, but it will take a bit while I install the build tools. |
| 17:44 |
us_0gb |
(I'm on a new machine.) |
| 17:45 |
sapier |
ok, I have to go soon. could you write a issue for this? case it isn't fixed yet this is a issue to be fixed |
| 17:46 |
us_0gb |
sapier: Okay, will do. |
| 17:50 |
* hmmmm |
pulls hair out |
| 17:50 |
hmmmm |
how many wrappers do i have around readFlagString exactly?!? |
| 17:50 |
hmmmm |
this is insane and i should've designed it right from the beginning |
| 18:07 |
sapier |
*g* hmmmm it's never to late to fix a bad decision ;-) |
| 18:07 |
hmmmm |
I am also adding some documentation while i'm at it :D |
| 18:07 |
sapier |
most time it's just a lot of work |
| 18:07 |
hmmmm |
// N.B. if setStruct() is used to write a non-POD aggregate type, |
| 18:07 |
hmmmm |
// the behavior is undefined. |
| 18:08 |
sapier |
I recently realized marking a client as active on got media message is worth nothing as old clients don't use it consistently ... their behaviour did change from time to time .. noone relized this because it didn't have any effect by now |
| 18:09 |
hmmmm |
fantastic |
| 18:09 |
|
salamanderrake joined #minetest-dev |
| 18:09 |
hmmmm |
so whose idea was it to change this behavior!?? |
| 18:09 |
sapier |
I guess I'll add a new message finaly telling server about client beeing ready |
| 18:10 |
sapier |
this is required to fix the issue about players standing at spawn for quite some time till they're really ready |
| 18:10 |
hmmmm |
usually there's a client initialization/login sequence for protocols after a few handshakes but the decision to use MEDIARECEIVED as the initialized marker seems arbitrary and it was clearly not designed for this task |
| 18:10 |
sapier |
I don't know what this is used at all ;-) server doesn't do anything with this information |
| 18:11 |
sapier |
we could also remove it as far as I see now it wouldn't make a difference |
| 18:13 |
xyz |
oh I think I added this! |
| 18:13 |
sapier |
the finished message has another benefit, I can send it AFTER preloading visuals and put all the nice to know but information e.g. client version in this package |
| 18:14 |
sapier |
"non required information" |
| 18:14 |
hmmmm |
well that's good for the per-server statistics I guess but the original idea was to send that to some centralized server like serverlist |
| 18:14 |
xyz |
I mean, I added TOSERVER_RECEIVED_MEDIA but previously it'd just set definitions_sent to true, now it also does some crazy shit I didn't write D: |
| 18:14 |
hmmmm |
the serverlist should tell the client about updated versions |
| 18:15 |
hmmmm |
in addition to collecting how much each version is used |
| 18:15 |
sapier |
what is done there is client stage 2 init the one I intend to move behind finished message |
| 18:15 |
hmmmm |
it'd be nice if we can get an rsa signature to sign like Win32 binaries with so we can push auto-updates when possible |
| 18:16 |
sapier |
I don't think so, e.g. if a server is running a quite old version suggestion to update may be wrong |
| 18:16 |
hmmmm |
hmmm |
| 18:17 |
hmmmm |
for 'controversial' settings like an auto update and so on I think it'd be a good idea to have a dialog box pop up in the GUI on first run asking about these settings |
| 18:17 |
hmmmm |
instead of keeping it disabled and then the user would never know about them unless they look at the config file or settings or whatever |
| 18:17 |
sapier |
we're not talking about autoupdate ... that's way more to do |
| 18:18 |
hmmmm |
autoupdate is something that i'd like to see eventually though |
| 18:18 |
sapier |
there could be a text in mainmenu always shown about a newer version beeing available |
| 18:18 |
hmmmm |
it's a lot of work but then the vast majority of users who are too lazy to get patches |
| 18:19 |
sapier |
and additionally a option to make server owners tell their users what version should be used for a specific server |
| 18:19 |
hmmmm |
they're going to be the ones to complain about bugs |
| 18:19 |
sapier |
how is autoupdate supposed to work on linux? |
| 18:19 |
hmmmm |
it doesn't |
| 18:19 |
hmmmm |
for example autoupdate for firefox works where it can but is disabled for platforms where it's too troublesome to get it right e.g. freebsd |
| 18:19 |
sapier |
it'd be nice to have on windows, but I don't see anyone to do it anytime soon :-( |
| 18:20 |
sapier |
while we can add the server side notification next version without lots of trouble |
| 18:21 |
sapier |
I have to leave now maybe there are others who know additional options? |
| 18:22 |
xyz |
just adding a notification with link to download is fine enough |
| 18:29 |
|
blaise joined #minetest-dev |
| 18:35 |
|
Exio4 joined #minetest-dev |
| 18:41 |
VanessaE |
G*d damn it. internet went down for a while |
| 18:45 |
|
Exio4 joined #minetest-dev |
| 18:45 |
us_0gb |
Autoupdate on systems with package managers should be handled through said package managers. |
| 18:46 |
us_0gb |
We have that for APT-based systems with Minetest, but not for other package managers. |
| 18:48 |
VanessaE |
regarding the client<->server init I'll say it plain: it broke with kahrl's httpfetch. someone fixed it. it broke again recently. Now some older-but-post-0.4.8 clients are not able to receive either player models, or skins, or both, randomly at connect, and people are bitching that players who were already on before they signed on are invisible to them - no player names, no skin, no model. |
| 18:49 |
VanessaE |
and no, telling users to upgrade WILL NOT WORK. |
| 18:49 |
VanessaE |
because many users cannot. |
| 18:50 |
VanessaE |
I verified the no-skins/models myself with 0.4.9-stable |
| 18:50 |
VanessaE |
and the absence of players |
| 18:50 |
VanessaE |
there were 15 or 20 players on the server when I signed in with 0.4.9. I saw only one, and she signed on right after I did. |
| 18:52 |
|
blaise joined #minetest-dev |
| 19:00 |
|
Exio4 joined #minetest-dev |
| 19:05 |
VanessaE |
so can someone please just tell me what I should do here? |
| 19:14 |
proller |
revert some commits? ;) |
| 19:15 |
VanessaE |
way too late for that now |
| 19:15 |
VanessaE |
how about helping fix the problem? |
| 19:15 |
VanessaE |
if I could help more than I do, I of course would |
| 19:27 |
PilzAdam |
VanessaE, tried https://github.com/minetest/minetest/pull/1139 ? |
| 19:38 |
VanessaE |
PilzAdam: indeed I have. |
| 19:39 |
VanessaE |
PilzAdam: older clients can connect with that patch in place, but it makes the previously-discussed no-models-no-names problem quite evident then |
| 19:39 |
VanessaE |
thing is, that problem does not require his patch |
| 19:39 |
VanessaE |
at least not on the client |
| 19:39 |
VanessaE |
I can reproduce the no-models-no-names glitch with an 0.4.9-stable client also. |
| 19:44 |
VanessaE |
if I remove that patch, clients newer than when httpfetch went in, on up through git from about last week (but not newer I guess) will have a high chance if getting nailed by that grey screen/"mainlist == NULL" bug |
| 19:44 |
VanessaE |
and thus will be unable to connect fully sometimes |
| 19:44 |
|
EvergreenTree joined #minetest-dev |
| 19:44 |
|
EvergreenTree joined #minetest-dev |
| 20:17 |
xyz |
they can't update why exactly? |
| 20:19 |
VanessaE |
buildcraft. |
| 20:19 |
VanessaE |
'nuff said? |
| 20:19 |
xyz |
wait weren't you the one who wanted to ban those clients? |
| 20:20 |
VanessaE |
I presume the buildcraft team (well, I guess it's just one guy?) doesn't exactly have a regular update schedule. |
| 20:20 |
VanessaE |
at one time yeah but they make up at least half my userbase now. I'm kinda committed at this point |
| 20:20 |
VanessaE |
(or I should be :P ) |
| 20:20 |
xyz |
because we got them off google play thanks to dmcas lololol |
| 20:21 |
xyz |
I think some APKs of them have update feature |
| 20:27 |
|
PilzAdam joined #minetest-dev |
| 20:36 |
|
mrtux joined #minetest-dev |
| 20:38 |
VanessaE |
screw it. I'll roll back to 458045d49fd96cf19bdd61b2f8dbdbc0fd11b587 ... as I recall it worked fairly reliably there. |
| 20:46 |
VanessaE |
yep, that commit seems fine. |
| 20:46 |
VanessaE |
at least on a first try, with 0.4.9-stable. |
| 20:46 |
VanessaE |
(0.4.9-stable for the client that is) |
| 21:04 |
kahrl |
good morning |
| 21:05 |
kahrl |
xyz: I didn't write that code, but there has to be an endScene to match beginScene |
| 21:05 |
|
EvergreenTree joined #minetest-dev |
| 21:05 |
|
EvergreenTree joined #minetest-dev |
| 21:05 |
kahrl |
(I'm probably in git blame for the code because I moved it around) |
| 21:06 |
xyz |
kahrl: I don't think it has to be there |
| 21:07 |
|
Maxou56800 joined #minetest-dev |
| 21:07 |
Maxou56800 |
Hello |
| 21:07 |
kahrl |
the docs are not completely clear on what beginScene and endScene do |
| 21:07 |
kahrl |
but for beginScene: "Applications must call this method before performing any rendering." |
| 21:07 |
xyz |
yes endScene says "Presents the rendered image to the screen." |
| 21:07 |
kahrl |
for endScene: "Applications must call this method after performing any rendering." |
| 21:08 |
|
farlepet joined #minetest-dev |
| 21:08 |
kahrl |
so it seems pretty clear that they must be called in pairs |
| 21:08 |
xyz |
http://irrlicht.sourceforge.net/docu/example013.html |
| 21:08 |
xyz |
hm, I see, then is there a real need for beginScene? |
| 21:08 |
kahrl |
well that example is structured so the RTT part happens during the on-screen scene |
| 21:09 |
kahrl |
while our RTT code could be called at any time |
| 21:09 |
RealBadAngel |
i have moved normal maps generation from shaders on the fly to engine and on startup, it works pretty nice |
| 21:09 |
kahrl |
so I think beginScene is needed |
| 21:09 |
RealBadAngel |
normals for minetest_game are generated in circa 20s |
| 21:10 |
RealBadAngel |
and are better quality than before |
| 21:10 |
kahrl |
unless we move enough stuff around that generateTextureFromMesh only happens during the on-screen scene |
| 21:13 |
xyz |
hm, so wasn't there a bug before with same thing (blinking black screen) happening? how was it solved? |
| 21:14 |
kahrl |
I'm not aware of that |
| 21:16 |
xyz |
not aware of what? |
| 21:16 |
kahrl |
that bug |
| 21:16 |
|
Gethiox2 joined #minetest-dev |
| 21:16 |
RealBadAngel |
http://i.imgur.com/RxkYJ4e.png http://i.imgur.com/vVkDZGl.png |
| 21:17 |
RealBadAngel |
how do you like the effect? |
| 21:17 |
xyz |
I see, I remember it happening on Windows; maybe it was never fixed, maybe it's not our bug |
| 21:20 |
kahrl |
hmm, it seems the flickering is by design (or a known sideeffect) and we should structure our code like the example you linked |
| 21:20 |
kahrl |
see http://irrlicht.sourceforge.net/forum/viewtopic.php?t=22546 |
| 21:21 |
kahrl |
but I don't see any clean way to get to that structure |
| 21:22 |
xyz |
ah right |
| 21:28 |
xyz |
do we really need to call it at random times? can't those textures be generated once when connecting? |
| 21:28 |
kahrl |
other stuff calls this function too iirc |
| 21:28 |
kahrl |
but it might be possible |
| 21:30 |
xyz |
well |
| 21:30 |
xyz |
queuing is already implemented there |
| 21:31 |
xyz |
so we just need to move 'itemdef->processQueue(gamedef);' right after beginScene and make it queue everything? |
| 21:32 |
kahrl |
then it would deadlock if you tried calling it from the main thread outside beginScene/endScene |
| 21:32 |
xyz |
ah right, I forgot about it |
| 21:34 |
|
nore joined #minetest-dev |
| 21:36 |
xyz |
it actually would deadlock no matter where you call it from (if it's main thread), bleh |
| 21:37 |
kahrl |
right |
| 21:39 |
Jordach |
RealBadAngel, what's worrying is that those nodes have specularity |
| 21:40 |
xyz |
so the only entry point are getInventoryTexture and getWieldMesh and both seem to be quite static since we don't allow to modify/add definitions after the client is connected/initialized |
| 21:41 |
|
us_0gb joined #minetest-dev |
| 21:41 |
xyz |
on the other hand, what if we want to allow this some day |
| 21:41 |
kahrl |
ah, for some reason I thought there were others |
| 21:42 |
xyz |
if we just always queue it (returning dummy image) things will only break for a frame, right? |
| 21:43 |
kahrl |
yeah |
| 21:43 |
kahrl |
seems to be the easiest solution |
| 21:43 |
xyz |
or maybe no |
| 21:43 |
xyz |
ugh |
| 21:43 |
xyz |
i.e. in formspecs |
| 21:44 |
xyz |
it doesn't redraw everything every frame, does it? |
| 21:44 |
xyz |
i.e. in itemimagebutton |
| 21:45 |
kahrl |
yeah that's a problem |
| 21:45 |
xyz |
and who knows where else |
| 21:47 |
xyz |
so we can just allocate ITexture* in getInventoryTexture, initialize it to dummy texture and queue; then in processQueue replace with rendered image |
| 21:47 |
kahrl |
ItemCAO caches the result of getInventoryTexture too |
| 21:47 |
xyz |
that sounds awful |
| 21:47 |
kahrl |
(are those still used if you load an old map?) |
| 21:50 |
kahrl |
overwriting the texture should work, I guess, can't think of a situation where it wouldn't |
| 21:51 |
xyz |
can't say I like it much since it depends on Irrlicht internals |
| 21:51 |
kahrl |
the only exception would be converting the texture to an extruded mesh, but that's only done in createClientCachedDirect anyway |
| 21:54 |
kahrl |
the ^[inventorycube handler calls generateTextureFromMesh too |
| 21:54 |
kahrl |
if you handle that by queuing too, you won't be able to specify any additional modifier such as ^[brighten (not sure if anyone does that) |
| 21:57 |
|
ImQ009 joined #minetest-dev |
| 21:57 |
kahrl |
I guess if optimize_invtex was finished, that could be used for inventorycubes... |
| 21:58 |
xyz |
why won't that be possible? |
| 21:59 |
* VanessaE |
mumbles something about optionally disabling extruded wield meshes :) |
| 21:59 |
kahrl |
oh, I mean queeing it within the inventorycube handler |
| 21:59 |
VanessaE |
(as long as you're fucking around with this stuff) |
| 22:00 |
kahrl |
not queuing all the getTexture calls (which could break a lot of stuff) |
| 22:00 |
xyz |
ah right, got it |
| 22:01 |
xyz |
ugh, for now it'd be easier to queue this task and mark it as low priority, I guess |
| 22:02 |
kahrl |
maybe |
| 22:03 |
kahrl |
could simply comment out (beginScene and) endScene for android if it works |
| 22:04 |
kahrl |
but it's not the correct solution of course |
| 22:04 |
xyz |
yup |
| 22:04 |
xyz |
I wonder what's going to happen if it's called between some other beginScene/endScene pair |
| 22:04 |
xyz |
will it clear everything? |
| 22:04 |
xyz |
will it leak? |
| 22:08 |
kahrl |
they don't seem to actually do much outside of the clearbuffer/swapbuffer equivalent |
| 22:09 |
kahrl |
and clear some random state variables of C{Null,OpenGL,...}Driver |
| 22:17 |
|
Zeitgeist_ joined #minetest-dev |
| 22:17 |
|
Zeitgeist_ joined #minetest-dev |
| 22:30 |
hmmmm |
alright, based on the existing conventions regular mapgen flags should be just fine |
| 22:31 |
hmmmm |
but what I did was remove the v6_* and v7_* prefixes from mapgen-specific flag parameters |
| 22:31 |
hmmmm |
so anymore, specifying "trees, caves" in mg_flags in your config file is redundant |
| 22:31 |
hmmmm |
they're always going to be there as per the default MapgenParams ctor |
| 22:32 |
hmmmm |
to get rid of trees and caves you need to explicitly put "notrees, nocaves" |
| 22:32 |
hmmmm |
so basically anybody who is using jungles in v6 right now, be aware that you're gonna have to change it to mgv6_spflags = jungles |
| 22:33 |
hmmmm |
also same with biome blend, in order to get rid of that you have to specify "nobiomeblend" in mgv6_spflags |
| 22:33 |
hmmmm |
I would make it reverse compatible but that makes things messier than they really need to be |
| 22:34 |
hmmmm |
so I'm just going to add a little release note to people telling them of what they need to change in their config, or something, unless someone has a better idea. |
| 22:34 |
hmmmm |
or maybe a little script to fix their config files and worlds |
| 22:35 |
hmmmm |
if they don't change it, nothing *bad* will happen, it's just that newly generated areas will be missing jungles where they would otherwise be, or they get that ugly biome dithering effect between biome transitions |
| 22:36 |
RealBadAngel |
hmmmm, i tried different way of generating normal maps, i made them generated on startup and it looks like this code will be unusable. |
| 22:36 |
hmmmm |
what way? |
| 22:37 |
RealBadAngel |
instead of shaders calculations per pixel, i coded texture generation in the engine |
| 22:37 |
RealBadAngel |
and i cant connect to vanessa's server which have over 4k textures |
| 22:37 |
RealBadAngel |
4gb of memory is not enough |
| 22:38 |
hmmmm |
you sure it can't just be done algorithmically better |
| 22:38 |
RealBadAngel |
wait, now im talking about memory usage |
| 22:39 |
RealBadAngel |
normal map to be usable has to be at least 256x |
| 22:40 |
RealBadAngel |
anythin less looks like shit |
| 22:42 |
RealBadAngel |
and bout the algorithm it is most common used one in games to generate such effects |
| 22:45 |
RealBadAngel |
this is the method i am using: http://en.wikipedia.org/wiki/Sobel_operator |
| 22:53 |
hmmmm |
https://github.com/kwolekr/minetest/commit/83bafbe08b508266d31a6a76f1ffc2cddc662390 |
| 22:54 |
hmmmm |
RealBadAngel, surely you don't need the entire texture loaded into memory at any given time |
| 22:56 |
RealBadAngel |
currently not displayed textures are dropped? |
| 22:56 |
RealBadAngel |
dont think so |
| 22:57 |
RealBadAngel |
on startup every single texture is loaded into memory |
| 22:58 |
RealBadAngel |
in nodedef.cpp |
| 22:59 |
hmmmm |
yes but the memory that takes up 4gb like you were talking about |
| 22:59 |
RealBadAngel |
huh, i mean amount of textures needed |
| 22:59 |
RealBadAngel |
normal map is a texture 256x |
| 23:00 |
RealBadAngel |
and have to be loaded into memory |
| 23:00 |
RealBadAngel |
having 2*4500 texures is too much for 4gb machine |
| 23:01 |
hmmmm |
oh |
| 23:01 |
hmmmm |
yeah but what does that have to do with your thing not working |
| 23:02 |
hmmmm |
just because it doubles the amount of textures in memory? |
| 23:02 |
RealBadAngel |
both solutions are working |
| 23:02 |
hmmmm |
[05:36 PM] <RealBadAngel> hmmmm, i tried different way of generating normal maps, i made them generated on startup and it looks like this code will be unusable. |
| 23:02 |
hmmmm |
you said it was unusable |
| 23:02 |
VanessaE |
It's been my experience that it takes around 6-7 GB for that, on Survival/30001 + HDX 256 + normalmaps for everything that it supports on that server |
| 23:02 |
RealBadAngel |
but my machine is too weak to use generated on startup one |
| 23:02 |
hmmmm |
yes... so it can be an option, right...? |
| 23:02 |
RealBadAngel |
could be |
| 23:03 |
hmmmm |
so |
| 23:03 |
hmmmm |
any comments/concerns about the mapgen flag fixup? |
| 23:03 |
RealBadAngel |
sadly i wont be able to use that option ;) |
| 23:03 |
hmmmm |
you've all been warned... ... ... ... |
| 23:04 |
hmmmm |
plus it's a development version so it's not like anybody could blame me if stuff breaks |
| 23:04 |
VanessaE |
hmmmm: no comments as long as it doesn't b0rk emergethread agin ;) |
| 23:04 |
VanessaE |
again* |
| 23:04 |
hmmmm |
there's no way that's happening https://github.com/minetest/minetest/commit/7f743178db2a45bd3f68ef2c9c7df6deca1f3ab6#diff-1dc3934293fad6b8769890134ac51c21R116 |
| 23:05 |
VanessaE |
of course I'm rolled back to 458045d49 on my servers, so I won't see the effects right away if something breaks, anyhow. |
| 23:05 |
VanessaE |
oh,well that looks safe enough. |
| 23:08 |
* VanessaE |
waits for the next "oh shiiiiiiiit..... I did THAT?" moment.. ;) |
| 23:14 |
|
Selat_ joined #minetest-dev |
| 23:19 |
|
farlepet joined #minetest-dev |
| 23:20 |
|
farlepet joined #minetest-dev |
| 23:25 |
|
Selat_ left #minetest-dev |
| 23:25 |
|
Selat_ joined #minetest-dev |
| 23:25 |
|
iqualfragile joined #minetest-dev |
| 23:44 |
|
jin_xi joined #minetest-dev |
| 23:58 |
|
farlepet joined #minetest-dev |
