Minetest logo

IRC log for #minetest-dev, 2014-02-08

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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/minete​st/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/2​054-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.sourceforg​e.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.ne​t/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/commi​t/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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext