Time Nick Message 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 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 10:30 jin_xi and here is said 'explanation'... http://irc.minetest.ru/minetest-dev/2012-10-27#i_2592006 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: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: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 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. 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 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 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: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: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 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: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. 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 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)