Minetest logo

IRC log for #minetest-dev, 2015-10-16

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

All times shown according to UTC.

Time Nick Message
00:02 jin_xi_ joined #minetest-dev
00:02 sfan5 joined #minetest-dev
00:02 celeron55 joined #minetest-dev
00:06 crazyR_ joined #minetest-dev
00:06 waressearcher2 joined #minetest-dev
00:06 sofar joined #minetest-dev
00:06 VanessaE joined #minetest-dev
00:06 book` joined #minetest-dev
00:06 kahrl joined #minetest-dev
00:07 Kray joined #minetest-dev
00:07 Ritchie joined #minetest-dev
00:07 Robby joined #minetest-dev
00:08 Fritigern joined #minetest-dev
00:08 Puma_rc joined #minetest-dev
00:08 Icedream joined #minetest-dev
00:09 Warr1024 joined #minetest-dev
00:12 Garth joined #minetest-dev
00:12 proller joined #minetest-dev
00:12 DFeniks joined #minetest-dev
00:12 ekem joined #minetest-dev
00:12 Eivel joined #minetest-dev
00:12 neti_netwalker joined #minetest-dev
00:13 Miner_48er joined #minetest-dev
00:13 zat joined #minetest-dev
00:13 Brains joined #minetest-dev
00:13 Anchakor joined #minetest-dev
00:13 janakas joined #minetest-dev
00:13 enesbil joined #minetest-dev
00:13 Ardonel joined #minetest-dev
00:13 hmmmm joined #minetest-dev
00:13 Soni joined #minetest-dev
00:13 gentoobro joined #minetest-dev
00:13 younishd joined #minetest-dev
00:13 Guest61682 joined #minetest-dev
00:13 nanepiwo joined #minetest-dev
00:13 Hijiri joined #minetest-dev
00:13 eeew joined #minetest-dev
00:13 johnnyjoy joined #minetest-dev
00:13 pozzoni joined #minetest-dev
00:14 Megaf_ joined #minetest-dev
00:14 VargaD joined #minetest-dev
00:14 JohannesG joined #minetest-dev
00:14 thatgraemeguy joined #minetest-dev
00:14 leat joined #minetest-dev
00:14 misprint joined #minetest-dev
00:14 exio4 joined #minetest-dev
00:14 _tutima joined #minetest-dev
00:14 Danek joined #minetest-dev
00:17 dzho joined #minetest-dev
00:17 rom1504 joined #minetest-dev
00:17 Lunatrius joined #minetest-dev
00:17 AnotherBrick joined #minetest-dev
00:17 Wayward_One joined #minetest-dev
00:18 cheapie joined #minetest-dev
00:18 exoplanet joined #minetest-dev
00:18 ShadowBot joined #minetest-dev
00:18 Taoki joined #minetest-dev
00:18 VirusJones joined #minetest-dev
00:18 ShadowNinja joined #minetest-dev
00:25 GreenDimond joined #minetest-dev
00:25 GreenDimond joined #minetest-dev
00:31 OldCoder joined #minetest-dev
03:51 ShadowBot joined #minetest-dev
03:51 ShadowBot joined #minetest-dev
04:20 Player2 joined #minetest-dev
05:30 Player2 joined #minetest-dev
05:39 Hunterz joined #minetest-dev
06:51 kaeza joined #minetest-dev
06:58 diemartin joined #minetest-dev
07:03 Darcidride joined #minetest-dev
07:18 OldCoder hmmmm, just FYI; heart patient reports message stream is 0.4.13 only. We will debug.
07:19 hmmmm just disable the message for now
07:19 hmmmm I'm kind of busy at the moment
07:19 OldCoder hmmmm, see above. You are asked for zero. This is FYI.
07:19 OldCoder We will debug and report additional clues for such time as this issue may be in the queue.
07:19 hmmmm I sort of doubt you're going to get anywhere to be 100% honest
07:19 hmmmm I'll give you a hint though
07:20 OldCoder Go on
07:20 OldCoder I estimate odds at 20% myself
07:20 OldCoder So what?
07:20 * OldCoder awaits hint
07:20 hmmmm take a look at server.cpp:835-850
07:20 hmmmm that's where AOMs are composed
07:20 OldCoder I have an adult player who loves the game and needs it. He will help. We will see what goes through that block.
07:21 OldCoder For tonight, this is all: He only sees the problem with a 0.4.13 client
07:21 OldCoder That is clearly a clue. You mentioned 0.4.10; so this may be multiple issues.
07:21 hmmmm the issue is pretty clear
07:21 OldCoder Oh?
07:22 hmmmm minetest clients are sometimes being sent bogus packets from the server that are active object messages
07:22 * OldCoder listens
07:22 OldCoder And the cause of an endless stream of these?
07:22 OldCoder Not known, right?
07:22 hmmmm it wasn't an endless stream when I was looking into it
07:22 hmmmm it was like one brief instance and never again for a while
07:22 OldCoder It is now for me. This is therefore useful and interesting. We will report back.
07:23 hmmmm anyway
07:23 OldCoder Endless means interesting, no? Thank you. All for now.
07:23 hmmmm active object messages have a 2 byte length prefix and then the message payload
07:23 * OldCoder listens
07:23 hmmmm this is the thing that's a bogus value, and then of course there is like 1 more byte after that corrupted length prefix
07:24 hmmmm compare active object message length while being sent to what's being received
07:24 hmmmm that way you can narrow down where the problem begins
07:24 hmmmm good luck
07:24 OldCoder I seem to have nodes that trigger this continuously. If I identify them and do that, possibly progress.
07:24 OldCoder If not, no harm done. All right; that is all.
07:24 OldCoder
07:33 nrzkt joined #minetest-dev
07:33 hmmmm why do you keep sending blank lines
07:41 OldCoder hmmmm, Hi. I explained this 2 years ago. There are 3 logical purposes: #1 paragraph breaks #2 polite acknowledgments #3 announcement of presence. It is odd that everybody does not do this.
07:41 ShadowBot https://github.com/minetest/minetest/issues/1 -- GlowStone code by anonymousAwesome
07:41 ShadowBot https://github.com/minetest/minetest/issues/2 -- Burned wood
07:41 ShadowBot https://github.com/minetest/minetest/issues/3 -- Furnace segfault
07:42 hmmmm that's because people don't usually write a novel on irc
07:43 OldCoder hmmmm, point is irrelevant. Paragraph breaks are readable regardless of novel. Plus there are 2 other reasons, aren't there? And this is not really core dev discussion.
07:43 OldCoder Speaking of which, answer to error message issue...
07:44 OldCoder Seems to be that player had too many cobble nodes right on top of light sources. So we don't know the root fix needed but vaporizing cobble seems to have ended the messages.
07:44 OldCoder
07:46 Amaz joined #minetest-dev
08:37 jin_xi joined #minetest-dev
08:52 julienrat joined #minetest-dev
08:52 julienrat left #minetest-dev
09:07 H-H-H joined #minetest-dev
09:23 Megaf joined #minetest-dev
10:23 deltib joined #minetest-dev
10:30 jin_xi and here is said 'explanation'... http://irc.minetest.ru/minet​est-dev/2012-10-27#i_2592006
10:55 Calinou joined #minetest-dev
11:24 Brains joined #minetest-dev
11:27 nrzkt jin_xi, good memory :D
11:32 jin_xi i know and its a pain. i'd love a way to learn to forget :)
11:32 proller joined #minetest-dev
11:36 crazyR_ I cant beleive how people can get so easily annoyed or disturbed by what is such a trivial matter. it a blank line really going to cause anyone any harm?
11:43 thatgraemeguy joined #minetest-dev
11:43 thatgraemeguy joined #minetest-dev
11:55 OldCoder What I said in that link stands. jin_xi has left. If somebody sees him or her later, tell him/her to shove off.
11:55 OldCoder In a channel like this, civility is recommended
11:55 technics joined #minetest-dev
11:55 OldCoder No irony there; I give what I get
11:55 OldCoder
11:56 OldCoder Thanks loads for dumping on a contributor. Makes lots of sense to p*ss upon people who invest days or weeks trying to help.
11:56 OldCoder
11:58 VanessaE this isn't the place to be discussing this.
12:06 nrzkt OldCoder, mister OldCoder :)
12:06 nrzkt But OldCoder i agree that empty lines should be avoided
12:07 OldCoder VanessaE is correct
12:07 OldCoder nrzkt, you got something to say, PM me
12:07 OldCoder jin_xi's use of single quotes around explanation was insulting
12:07 OldCoder I damn well deserve better and you know it
12:07 OldCoder F*ck
12:07 VanessaE guys, just DROP IT
12:07 OldCoder Chase away *everybody* will you?
12:08 OldCoder I said he/she could PM me
12:13 celeron55 lol
12:13 celeron55 this is clearly an important development subject
12:14 OldCoder Communication about communication happens, celeron55; people here seem to like to bash others about it quite a bit. I've done nothing but explain and respond.
12:14 OldCoder In a text world, subtleties matter a lot. Civility rules are recommended.
12:14 OldCoder
12:16 OldCoder celeron55, add up the people who have been chased away by incivility, it's not a large number. It does however have an impact. I respectfully submit that the project is moving towards potential Mozilla.com level. Civility rules will be needed for the next stage. They are not optional.
12:16 OldCoder
12:17 celeron55 ehm
12:17 OldCoder Am I incorrect? Take it under advisement.
12:17 OldCoder The project will rise or fall on whether or not the old ways continue.
12:18 celeron55 yeah but it's now you who i am criticizing; more jin_xi
12:18 celeron55 not*
12:18 OldCoder We should seek to avoid issues to begin with. Simple civility rules and expectations will help.
12:18 celeron55 but your IRC novels are kind of riciulous though, but you already know it so whatever
12:18 celeron55 ridiculous (what's wrong with my hands)
12:18 * OldCoder refrains from jokes
12:19 OldCoder There are *3* reasons for blank lines, celeron55. *3*. However, that is not the point. Criticism should be civil.
12:20 OldCoder You are unlikely to dispute this. You know that your team has a reputation for being (obscenity redacted)s. Only a few but this is enough.
12:20 OldCoder Professional behavior is advised.
12:21 celeron55 yes, i can agree that people should act professionally
12:21 OldCoder Add to this one point: In a world of text there is no body language. Subtleties matter.
12:22 OldCoder It is not best to mock somebody by wording explanation as 'explanation'
12:22 OldCoder Little things matter in IRC
12:22 OldCoder Hm. I've had my say. Thank you.
12:24 celeron55 then again, why should you care about what jin_xi said; he's not an important person here and nobody else really cares what he said, and he didn't prevent some other more important discussion
12:25 OldCoder celeron55, I think I'd respond in PM if you wished to hear more. The parts about civility are appropriate for the channel. My own feelings are not.
12:25 OldCoder I'll say that nrzkt and jin_xi together... having two people come after me... was not pleasant
12:25 OldCoder
12:25 celeron55 yes but you are telling the things about civility to people who don't need to hear about them
12:25 OldCoder Hm? You will decide the rules, right?
12:26 OldCoder It is ultimately your decision. I did not suggest that you yourself were incivil.
12:26 celeron55 anyway, i'll just drop this, getting into any details is useless
12:26 OldCoder If you wish responses on such subjects, PM me. But civility rules are not useless.
12:27 celeron55 (we have civility rules; the fact that somebody is not civil does not mean that we don't have them)
12:27 OldCoder Ah
12:27 OldCoder Let's call them guidelines. Are they posted somewhere?
12:28 OldCoder Enough for now. I stand by the point; the core devs are viewed as unpleasant by more than a few people...
12:28 celeron55 http://dev.minetest.net/How_to_communicate
12:28 OldCoder Rules or not, this could be improved. Thank you.
12:38 proller joined #minetest-dev
12:38 zat joined #minetest-dev
12:46 julienrat joined #minetest-dev
12:46 julienrat left #minetest-dev
13:38 RealBadAngel joined #minetest-dev
13:49 luizrpgluiz joined #minetest-dev
13:56 luizrpgluiz left #minetest-dev
14:19 Hunterz joined #minetest-dev
14:33 CraigyDavi joined #minetest-dev
15:07 VanessaE ok, question...
15:07 VanessaE why is it that when I redefine some old default node (tree trunks in this case) to use something other than the "normal" drawtype, that they turn solid black in the world?
15:07 VanessaE (and yes, paramtype="light" is already in the new def)
15:08 VanessaE morning, RealBadAngel.
15:08 kahrl VanessaE: because the light level is still 0 in those already placed nodes
15:08 VanessaE so why aren't they black *before* the redef?
15:09 kahrl because the normal drawtype cares about the light level in the adjacent nodes, not in the node itself
15:09 VanessaE I see
15:09 VanessaE in this case I'm writing yet-another-round-treetrunks mod.  was hoping by now this had already been fixed :-/
15:10 kahrl I'm not sure there is anything to fix
15:12 crazyR_ hey VanessaE, just to let you know on starting a minetest server up with homedecor enabled. this error is being produced for a handfull of nodes:
15:12 crazyR_ WARNING[Main]: Not registering alias, item with same name is already defined: homedecor:table_lamp_max -> homedecor:table_lamp_white_max
15:12 VanessaE the engine can't default to some "sane" value if the drawtype is inconsistent with the way light is handled?
15:12 kahrl crazyR_: --> #minetest
15:13 crazyR_ Ive not had chance to report it yet but i will do later, and sorry kahrl i forgot what channel i was in
15:13 kahrl VanessaE: the engine can't really detect that case
15:14 kahrl VanessaE: 0 is a valid light level in mesh/nodebox nodes
15:14 VanessaE hrm
15:14 VanessaE I guess I could add an ABM to recalc the light or something
15:15 VanessaE it's too bad I can't just "preset" a param1 value :)
15:15 VanessaE (yeah I know that wouldn't work)
15:20 kahrl looks like the ABM is what hungry_games_plus does (in a separate mod so you can activate it once and then disable)
15:20 kahrl err no hungry_games_plus
15:20 kahrl 3dfurniture
15:21 VanessaE yeah
15:21 VanessaE 3dforniture had something like that
15:25 VanessaE it just feels dirty to have to use such a thing
15:26 VanessaE given that an ABM has a limited action range and doesn't have any kind of "auto-deactivate"
15:28 crazyR_ could an ABM not be put in a while statement and once it has acheived its objective setting the while statement to false. thus disabling it... not tested it just an idea
15:28 VanessaE nope.
15:29 PilzAdam joined #minetest-dev
15:29 kahrl est31's idea of having ABMs that only run on block load (or activation) could come into play here
15:29 crazyR_ maybe we need a "de_register_abm" api function??
15:30 PilzAdam o/
15:30 kahrl moin PilzAdam
15:31 VanessaE hey PilzAdam.
15:31 VanessaE kahrl: yeah, that might do the trick.
15:31 PilzAdam #3258 should be merged soon, since it will break with each commit that adds a new setting
15:31 ShadowBot https://github.com/minetest/minetest/issues/3258 -- New Lua main menu settings by PilzAdam
15:32 PilzAdam the stuff in the todo list can be added later; it's already functional enough
15:46 VanessaE kahrl: this seems to work:  http://pastebin.com/MVxjKYQJ
16:33 Krock joined #minetest-dev
17:04 celeron55 maybe there should be a callback for when a bunch of map is loaded from disk (in practice a mapblock, but mods don't have to know about those)
17:04 celeron55 it's still messy because it would be re-done every time the block is loaded
17:04 celeron55 but really there is no way around it; the node data and definitions have been optimized in such a way that relies on the fact that definitions will not suddenly change in an incompatible way
17:04 celeron55 to do it in a way that is actually supported, you should define them as a new node type and explicitly convert the old ones to the new ones that use a different way of handling light
17:04 hmmmm joined #minetest-dev
17:05 celeron55 but you still end up with many of the same issues because there is no existing systems for handling a case like this done this way either 8)
17:06 VanessaE celeron55: I was hoping to avoid doing that..
17:07 celeron55 the way to make this automatically handled would be to include each definition field that affects how the node data is interpreted of each node type used in a mapblock to the mapblock data, and then convert appropriately at load-time when comparing that data to the data that is actually defined by the current game content
17:08 celeron55 but that's very complex and wasteful in 99.99% of cases where those data interpretations don't ever change
17:08 VanessaE plus, ironically, this is not a problem for newly-generated mapblocks so that would be moot anyway
17:08 celeron55 so, tough luck; there is no proper solution :P
17:08 celeron55 yes it would not work for your world specifically
17:10 VanessaE seems to me, the most proper solution is to treat "light=0, drawtype != normal" as a special case and re-calc the light or something.
17:10 celeron55 one other way would be to allow mods to version their data manually and allow them to run migration steps a bit like automatically migrating a database format
17:10 celeron55 but there would be like one mod that would be using it so... eh
17:10 celeron55 VanessaE: but that happens all the time
17:10 celeron55 it's a completely valid case for all furniture in an unlighted cave for example
17:11 celeron55 no way around it
17:11 VanessaE hm
17:12 VanessaE well the ABM I put in my code at least sort it out gradually.
17:13 VanessaE sorts*
17:15 VanessaE now as for register_on_mapload or whatever you wanna call it, seems to me the engine could retain a table of mapblocks that have recently been loaded, something it could pass to the mod
17:16 VanessaE (well, table of mapblock coords)
17:17 VanessaE something that would persist until restart, and which would contain a list of ALL blocks that have ever been loaded since startup.
17:17 VanessaE I dunno..
17:22 nrzkt joined #minetest-dev
17:25 Gael-de-Sailly joined #minetest-dev
17:31 hmmmm 4 celeron55 maybe there should be a callback for when a bunch of map is loaded from disk (in practice a mapblock, but mods don't have to know about those)
17:31 hmmmm that exists ^ hah
17:31 hmmmm just no lua interface to it at the moment
17:33 celeron55 it's kind of funny how minetest is actually quite purely just a complicated visualization software for 4-byte voxel data
17:33 celeron55 you see it when this kind of situations occur
17:34 hmmmm yeah this is ridiculous
17:34 hmmmm minetest is the best OS
17:36 hmmmm erm anyway, instead of adding a lua callback for loaded blocks, maybe it'd be a better idea to have a single callback that copies m_added_blocks in the environment step to a lua table and calls a single callback
17:36 celeron55 if there's buffering like that already, then probably yes
17:36 hmmmm ?? yes
17:37 hmmmm you don't remember the chunk of code in ServerEnvironment::step() that goes through the list of recently loaded blocks to activate them?
17:37 celeron55 i'm not questioning whether that exists, i'm just not even trying to remember anything
17:38 hmmmm hmmmm
17:38 hmmmm hrmmm...
17:39 hmmmm alright, so Emerge Completion Callbacks have a use; for notification when an asynchronous load/generate block command has finished
17:39 hmmmm it's not exactly the best thing to write a Lua interface for
17:39 proller joined #minetest-dev
17:39 hmmmm because it wouldn't capture any of the instances where blocks were synchronously loaded from the db
17:40 hmmmm mods who want to know about loaded blocks probably want to know about *all* loaded blocks
17:43 PilzAdam joined #minetest-dev
17:44 hmmmm mm okay i just looked, it turns out that added_blocks list is for blocks that became active within that step
17:45 hmmmm in other words, not all of the recently loaded blocks.  i can't help but think that it would be sufficient enough to have the recently activated block list, however.
18:03 proller joined #minetest-dev
18:17 proller joined #minetest-dev
18:20 Soni joined #minetest-dev
18:24 Gael-de-Sailly joined #minetest-dev
18:34 jin_xi joined #minetest-dev
19:17 proller joined #minetest-dev
19:23 rickmcfarley joined #minetest-dev
19:28 est31 joined #minetest-dev
19:32 blaze joined #minetest-dev
19:33 est31 we do have a mechanism to tell old blocks apart from new ones
19:33 est31 the timestamp
19:39 est31 so you could do minetest.register_on_old_block​_load("default:stairs_update", function() ... end)
19:40 est31 and in the world dir, there would be a file "block_load_times.txt" which contains a list of game times together with the names, e.g. default:stairs_update
19:40 est31 so one line could be default:stairs_update 466832 501340
19:41 est31 denoting that the "block replacer" default:stairs_update ran between game times 466832 to 501340.
19:41 est31 so blocks loaded with that timestams don't get affected by the function
19:41 est31 but all blocks before or after do.
19:42 est31 (you see I dont really have a name for it, perhaps we can just realize it with special params for the ABMs)
19:45 est31 I don't think we should pass the list over registered_on_globalstep functions
19:46 est31 we can pass the block coords in "bulk" if we want, so that it's faster
19:49 est31 but globalstep is the wrong place to do it
19:49 est31 a trivial optimisation would be to not call the step function if no blocks have been loaded
19:49 est31 and then we enter the ABM domain
19:51 est31 idc perhaps the stuff can even be stored in the envargs file
19:56 est31 issue #3198 has some discussion about bulk passing of data
19:56 ShadowBot https://github.com/minetest/minetest/issues/3198 -- Batching APIs
19:57 est31 tldr: it is indeed faster, but only a tiny bit
20:12 Darcidride joined #minetest-dev
20:44 rickmcfarley joined #minetest-dev
20:58 DFeniks joined #minetest-dev
22:33 kaeza joined #minetest-dev
22:51 proller joined #minetest-dev
22:56 proller joined #minetest-dev
23:08 Miner_48er joined #minetest-dev
23:15 est31 oh, super nice
23:15 est31 thanks to a "refactor" we crash now when we get a formspec with invsize
23:16 est31 I'll push a commit that reverts parts of that refactor
23:16 hmmmm oopsies
23:16 hmmmm which one
23:16 est31 #3260
23:16 ShadowBot https://github.com/minetest/minetest/issues/3260 -- Crash regression when displaying deprecated formspecs
23:17 hmmmm oh no dammit
23:17 hmmmm I'm guessing this is because L is in fact == NULL
23:17 est31 yes
23:17 hmmmm how the hell does that happen
23:17 est31 scripting_game.cpp
23:17 est31 look at the commit that added the methods b5acec0a3c5701c53854ff7afdf4008863e6e8df
23:18 hmmmm hrmm
23:19 hmmmm ahhhhh
23:19 hmmmm sorry est that one's my fault, I was the one who removed the NULL check there because I didn't think there was any circumstances where it'd be NULL
23:20 hmmmm I mean L parameters literally everywhere else are assumed to be non-null, so why the difference here?
23:20 est31 yup
23:20 est31 will add a comment
23:20 hmmmm and the answer to that is because of guiFormSpecMenu.cpp
23:20 est31 it is weird indeed
23:20 hmmmm the crummy design that parses the formspec string inside of the formspec engine
23:21 hmmmm and not as part of the interface to lua
23:21 est31 well it makes total sense
23:21 hmmmm god I can't wait to blow up formspec
23:21 est31 lua runs on the server
23:21 est31 formspec gets parsed by the client
23:22 est31 if you have lua on the client its wrong, yes
23:22 hmmmm well I mean there still should be a difference between serialized form and the internal form
23:22 hmmmm bbl
23:22 est31 the weird thing is that we call a method from src/script from the client
23:22 est31 the only place where we have lua on the client is mainmenu
23:22 hmmmm I know this is all poorly thought out and it does not need to be like that
23:22 hmmmm :)
23:22 hmmmm we can fix it
23:22 hmmmm I'm taking a week off from work so I can really do some damage perhaps
23:23 est31 wow thats great
23:23 hmmmm okay be back later
23:30 est31 hmmmm, PTAL https://github.com/est31/minetest/commit/​836486a98e7b09e25b97c9d989301ed9eb365b3b
23:30 est31 (if you are there)
23:48 luizrpgluiz joined #minetest-dev

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