Time Nick Message 01:29 hmmmm https://github.com/kwolekr/minetest/commit/527ddd6d0677e7c2c61ee7daaea46af31d951294 PTAL 03:52 paramat from the code looks like a much improved sheet ore, i'd like to see a screenshot 04:00 paramat perhaps it would be better to add nmin.Y to mapseed instead of randomising seed per chunk, so that the sheets are not chopped at mapchunk borders 04:04 paramat afaik sheet ore is chopped at borders because of that, that looks bad to me 04:05 paramat lol that email c55 posted 04:23 paramat perhaps we can deprecate sheet ore now 04:46 * paramat eats a bowl of ore puffs 04:50 hmmmm nah they're different uses 04:50 hmmmm you can't avoid the discontinuity without defining clear altitudes at which this kind of ore generates 04:50 hmmmm unfortunately 04:56 paramat ah i see i misunderstood 04:58 hmmmm sheet ore is supposed to replicate this stratus ore i saw in a mod that looked cool 04:59 hmmmm it had the same jaggy edges and everything 04:59 hmmmm then my thought process was like 04:59 hmmmm well what if, instead of modulating the height of these columns by uniform randomness, i use noise instead 04:59 hmmmm so i'd just add another noise + this noise 05:00 hmmmm but that always created concave shapes because of noise_threshhold being positive 05:00 hmmmm so i separated the threshhold noise which defines the size/shape from the displacement noises 05:00 hmmmm one for the top and one for the bototm 05:00 hmmmm here's the result: http://i.imgur.com/T6a4JGd.png 05:02 * paramat looks 13:49 VanessaE that last commit kinda went bonkers: http://pastebin.com/qPbDyraL and http://pastebin.com/qMRHne0q 13:50 est31 VanessaE, do you know the player name? 13:50 VanessaE one sec. 13:51 VanessaE ... 13:51 VanessaE 2015-09-16 08:01:13: ACTION[Server]: nomohakon digs default:dirt at (-2634,-697,263) 13:51 VanessaE 2015-09-16 08:01:17: ERROR[Server]: ServerEnvironment::addActiveObjectRaw(): object position outside maximum range 13:51 VanessaE minetestserver: /home/minetest/minetest_core/src/server.cpp:1865: void Server::SendMovePlayer(irr::u16): Assertion `player' failed. 13:51 VanessaE ... 13:51 est31 but we have a stack trace 13:51 est31 lemme see whats causing it 14:02 est31 VanessaE, whats the playerfile spawnpos for player Winslow? 14:02 VanessaE position = (-36254.6,295,-41411.7) 14:03 VanessaE (divide by 10 on those I think) 14:03 est31 is it indeed 10 times as large... 14:03 est31 or ten times as small 14:05 est31 ahh 14:05 est31 well, then that's the problem 14:08 VanessaE meanwhile, I'm gonna head off to bed. 14:08 VanessaE been up all night getting dac.com restored. 14:08 est31 night 14:08 VanessaE night 14:08 est31 thx for the stacktrace 14:09 VanessaE yw 14:19 est31 gonna push in 10 mins https://github.com/est31/minetest/commit/7614259178a1c0c9e3981d4159d28903d1733f98 14:20 est31 dangit 14:20 est31 it has to be multiplied 15:36 est31 hmmmm, can't really judge your mapgen patch 15:36 est31 idk mapgen :) 15:37 est31 okay, now this patch should fix VE's crash: https://github.com/est31/minetest/commit/7220b1a11fddf5a6c125f64fc4f35854abcdeac8 15:37 est31 pushing in 10 minutes 15:39 hmmmm you should make map_gen_limit_bs into a float 15:39 hmmmm in theory it should save a few comparisons 15:39 est31 ok 15:39 hmmmm err i mean conversions 15:39 hmmmm anyway optimizers are really not as smart as you probably think they are :-) 15:40 est31 they do optimize i++ for iterators 15:40 est31 okay can I push https://github.com/est31/minetest/commit/6c81be51ffd26ec7dee1ecb887a8743a8b6a6ce4 15:44 hmmmm sure. 19:41 est31 about translating nodedefs into different languages for different users 19:41 est31 the protocol already supports it, we just need to send the language, and expose the feature somehow over the lua API 19:41 est31 what would be a good way to do that? 19:42 est31 formspecs and other metadata can come later 19:42 VanessaE you mean translating the descriptions? 19:42 est31 descriptions, item names yes 19:43 VanessaE hm. that could get....messy 19:47 est31 the harder problem is really metadata 19:47 est31 because its stored in the map 19:47 est31 we can't just send different versions of the map to different clients 19:48 VanessaE it'll have to be translated in realtime then 19:48 est31 I mean we can, but this would overthrow MANY assumptions in the engine 19:49 est31 and doing that in a backwards compatible way... had. 19:49 est31 hard* 19:50 est31 (regarding realtime translations) 19:51 est31 if we did that we could let server owners decide whether to turn on that feature 19:51 est31 and lose backwards compat 19:52 est31 ah 19:52 est31 it is possible to do in a backwards compatible way 19:52 VanessaE well what mods do is use intllib, but you knew that 19:52 VanessaE (I think that's the name of it) 19:53 est31 yea 19:53 est31 I mean the actual feature we are talking about is that different clients can have different languages 19:53 est31 everything else mods can do 19:53 kahrl The cleanest solution is to get rid of formspec-in-metadata when client side scripting is added 19:53 est31 they already can do one language per server start 19:53 est31 nobody stops them 19:54 VanessaE I can't help wondering if'n that's the best way; when client-side modding is done, update intllib to do it 19:54 VanessaE ^ kahrl :) 19:55 est31 yea I guess that is an option 19:55 est31 a good idea 19:55 kahrl the downside is of course that client side scripting is vaporware for now :) 19:56 VanessaE heh 19:56 est31 and some people will want to overthrow formspecs altogether 19:56 est31 which will spawn lots of discussions of how to do them right 19:56 VanessaE formspecs as a client-side function is a nice idea though 19:56 VanessaE having that crap stored in metadata just plain sucks at times 20:07 est31 yea and it takes away storage 20:08 est31 you just store the same thing over and over again 20:08 est31 pretty bad 20:09 est31 (but in differing mapblocks, which means differing compression contexts) 20:09 est31 which gets us to the next topic 20:10 est31 I think that if we increased the number of mapblocks compressed at a time we would get better compression ratios 20:10 est31 I have done some tests that point towards that direction 20:10 est31 but nothing actually reliable 20:11 VanessaE I'm not even concerned about storage per se - I just hate users having to dig/re-place nodee just to update the stored formspec. 20:11 VanessaE nodes* 20:11 est31 thats not required 20:11 VanessaE it is, for some things. 20:11 est31 they should just interact with the node 20:11 est31 eg put into inventory 20:12 VanessaE I agree, it should just update when the user opens the formspec 20:13 est31 clientside scripting... right now there even isnt a consensus about which thread to run the script in 20:14 VanessaE by all means, a separate dedicated thread. 20:18 VanessaE the server should be able to tell the client to launch a chunk of lua code in a thread so that it can, for example, distort the screen or something but without interfering with the player's ability to do stuff normally 20:18 VanessaE (where that thread is of course shared by all other client-side Lua on that client) 20:19 est31 the problem of a thread approach is that it isn't immediate 20:19 VanessaE but there REALLY needs to be some kind of C or C++ interface on the client-side 20:19 est31 there is always a small lag 20:19 est31 just look at the lag in singleplayer 20:19 VanessaE (something the client will compile on receipt) 20:19 VanessaE true enough 20:19 est31 between client and server 20:20 VanessaE but think of some effect like an earthquake or tornado. the server needs to be able to control that 20:20 VanessaE (while the client executes it) 20:21 est31 so? 20:21 VanessaE so? 20:21 est31 the advantage of doing these things in the main thread would be the reduced lag 20:21 est31 but lets try hmmmm's approach of a separate thread first 20:21 VanessaE this is the same main thread that also controls player movement/actions, no? 20:21 est31 yea 20:21 hmmmm are you kidding 20:21 hmmmm it NEEDS to be in a separate thread 20:22 hmmmm we're not making the same mistake twice, and especially in a place where any lag is extremely noticable 20:22 est31 if you want to do things like custom player physics 20:22 est31 you cant wait for the thread to work down the queue 20:22 est31 you need the result of the movement computation NOW. 20:23 hmmmm celeron and I were actually talking about custom physics 20:23 hmmmm that could be a custom case 20:23 hmmmm the physics handlers would need to be extremely lightweight though 20:23 est31 yea ofc 20:23 est31 its the server's fault in that case 20:25 est31 of course, things like formspecs can run in a separate thread 20:25 est31 or on dig actions 20:25 est31 things like that 20:30 est31 but dont make a ONMOUSEMOVE callback to that thread, otherwise some oversmart mod creator tries to program camera movement with the mouse themselves 20:30 est31 in that separate thread ofc 20:31 VanessaE haha 20:31 VanessaE I could see someone actually trying to do that. 20:31 est31 I guess there will be a legitimate reason for them to do it 20:31 est31 e.g. forbid to look into a direction 20:32 est31 or that you can rotate into every direction indefinitely 20:32 est31 but instead of waiting for the engine to support it they will just abuse our API 20:32 est31 and then the players say its laggy 20:32 est31 and the mod creator says yeah thats because minetest is shit 20:32 VanessaE well, treat it like any other mod - if it's a shitty implementation of something, people won't use it anyway 20:33 est31 our active object implementation is shit at many places 20:33 est31 people still use it because there is no alternative 20:33 VanessaE true. 20:34 est31 well gonna go 20:34 est31 bye 20:34 VanessaE I hate when he does that :P 20:40 Sokomine those seem to be quite diffrent issues. rotation handled clientside would be good - for mobs. larger beasts turning on the spot looks extremly odd. what we currently have works fine for small animals like chicken and rats. but once they get bigger (cows, for example; or even those dionsaurs someone planned to implement), and still rotate on the spot, immersion is uttlerly ruined 20:43 est31 one thing came to my mind 20:43 est31 hmmmm, we do agree that the thread should have no real lock to the clientenv or anything else "vital"? 20:44 est31 e.g. you do minetest.set_node(...) on the client lua, and then it puts a SETNODE_ETCETC into a queue 20:44 est31 and that queue is emptied by the main client thread every render or so 20:44 hmmmm yeah basically 20:44 hmmmm the whole thing is event-based 20:44 hmmmm asynchronous is the future~ 20:45 est31 great 20:45 hmmmm I have not forgotten about client side lua, btw, just been busy with work 20:45 hmmmm we're getting close to release time and there's never been more reported BSoDs than ever 20:45 hmmmm ugh 20:45 est31 no complaint from me 20:46 est31 this is a free time project :) 20:46 est31 just client side scripting became topic as kahrl mentioned it :) 22:45 Soni let's talk about mods 22:46 VanessaE that's for #minetest 22:46 Soni hmm ok wait 22:46 Soni let's talk about the mod system 22:46 Soni yeah that sounds better :> 22:47 Soni so currently all we have are "plugins". 22:48 Soni can we add "softmods" and "hardmods"? 22:48 VanessaE soft? 22:48 Soni (well technically just "hardmods" because "softmods" would be provided by a "hardmod" known as "Lua") 22:48 VanessaE so you mean programming language plugins 22:48 Soni nope! 22:49 Soni not at all! 22:49 Soni ok so what's currently called "mods" would be "plugins" under my proposed system 22:51 Soni now, before I talk about "softmods" I need to talk about "hardmods" 22:55 Soni so "hardmods" can do everything "plugins" can do but also a lot more, like dynamic renderers, add new GUI elements, etc; basically they run both on the server and on the client (altho they may declare themselves optional on either side - more on that later) 22:56 VanessaE well if and when client-side modding happens, well, we'll see :) 22:56 Soni now, "softmods" are a very limited subset of "hardmods". like with hardmods, they support custom packet handling, but unlike hardmods they have no file I/O, FFI, dynamic code loading, etc 22:57 VanessaE hmmmm: *poke* 22:58 Soni "softmods" run on both the client and the server, but, and here's what's important: they're allowed the exact same things on both sides. 22:58 Soni so if a softmod tries to do file I/O on the server it won't work. 22:59 Soni "hardmods" can declare themselves either client-side-required or server-side-required, or both. and they can do anything and everything 23:00 Soni the caveat with hardmods is that they rely on the user to manually install them 23:00 Soni so, back to softmods... 23:01 Soni softmods can register packet handling 23:01 Soni plugins can use softmods' registered packet handling features if they want to, and then they depend on the softmod 23:01 Soni but the plugin doesn't need to be synced over 23:02 Soni (well, both softmods and hardmods would be able to register packet handling, but all 3 kinds of mods would be able to use registered custom packets) 23:05 Soni altho softmods can't directly use file I/O they can register a server-side-only hardmod (or a plugin) to handle their client->server packets and server-side stuff 23:05 Soni and now comes the subject of submods 23:06 Soni "submods" would be nice to group a set of plugins, softmods and hardmods together 23:10 Soni so instead of having 1 folder for each plugin, softmod and hardmod, you'd have 1 folder for the "main mod", and some subfolders for each submodule of the mod. e.g. the plugin part and the softmod part (ps: if you're using/making a hardmod you don't need any of the other 2 kinds of mods, altho it might still be nice to split your mod into various "feature sets": e.g. "ores", "decoration", "machines", etc) 23:10 Soni VanessaE, what do you think? 23:10 Soni (also did that last message go thru ok? or did it cut off?) 23:11 VanessaE the whole message came through 23:11 VanessaE but seems a little complicated 23:14 Soni only a little 23:15 Soni "softmods" are sandboxed & synced "hardmods" (and the files must be plain old .lua not .luac or w/e) 23:16 Soni so it's basically just adding some features and debug hooks 23:16 Soni bbiab 23:22 Soni (actually softmods and plugins wouldn't really exist, they'd be more like abstraction layers on top of hardmods) 23:45 Soni (I mean, hardmods can do anything, including send code over the internet) 23:54 Soni VanessaE, also did I mention no bytecode?