Time Nick Message 00:00 hmmmm then now when i went to go git diff, it showed that all the files were completely different 00:00 hmmmm and they were, because every line had a CR added to the ending 00:00 SpeedProg you can set git to convert line endings 00:00 hmmmm so when i went to commit and push it, it'd commit absolutely everything as new and show no changes 00:00 SpeedProg through I don't actually know the name of the setting 00:00 hmmmm autocrlf 00:01 hmmmm already read about it and all 00:01 Taoki ouch... I see 00:01 SpeedProg it isn't hard to undo a commit :D 00:01 hmmmm i did undo it 00:02 hmmmm for damage control, i'm converting everything back to LF manually 00:02 SpeedProg lol 00:02 SpeedProg good luck and have fun :D 00:02 hmmmm thanks 00:02 Taoki That has to suck :/ Good luck with that 00:02 Taoki Sad some IDE's do that 00:03 SpeedProg can't you text editor search for crlf and replace it with lf? 00:03 hmmmm i'd have to have every single file in the source tree opened 00:03 Taoki hmmmm: You could try that out. There is a high amount of files, but something like notepad++ should be able to handle it 00:04 Taoki Never tried that many files... I assume it could be past 100 00:04 Taoki Yeah, 281 files in source. Dunno if that could crash it or fill up the RAM 00:04 SpeedProg it shouldn't make a difference even if they are a few thousend 00:04 Taoki hmm 00:04 SpeedProg because it does not keep them open 00:11 hmmmm haha, more like 439 according to find . | egrep '.h$|.cpp$' | wc 00:15 Taoki brb 00:35 hmmmm i deserve a raise http://pastebin.com/a2rDu3Xv 00:35 hmmmm on that note, i hate shell scripting with a burning passion 00:41 Taoki Back for a few minutes till heading off to bed 00:41 Taoki hmmmm: Any news? 00:42 hmmmm nah 00:42 hmmmm oh, [19:34] i deserve a raise http://pastebin.com/a2rDu3Xv 00:57 Taoki Late, need to go now. Night everyone 00:58 Taoki Hope you can put the code in Github today or tomorrow, can't wait to see it on some server :) 02:20 hmmmm *phew* 02:20 hmmmm https://github.com/kwolekr/minetest/commit/bd674eea80d89f8cdb25479cb9414d9c4c9fc81e 02:20 hmmmm 22 modified files 02:20 hmmmm 1300 LoC changed 02:20 hmmmm and it doesn't even work yet 02:24 hmmmm actually it's 21 changed files, 1600 additions, 751 deletions 06:07 hmmmm yeah... sorry, i haven't been keeping up with what was said in the channel lately 06:08 VanessaE shit happens. 10:26 thexyz wtf? https://gist.github.com/4147549 13:34 celeron55 thexyz: guess: truncated player file 13:36 celeron55 umm... no 13:36 celeron55 it 13:36 celeron55 it must be a very old version at least 13:36 celeron55 at least since 0.4.3 that error hasn't even existed in the source code 13:38 celeron55 here is some interesting stuff: https://github.com/celeron55/minetest/commits/exp 13:39 celeron55 making things use that for serialization should allow easier compatibility between versions 13:40 celeron55 and way less horrible problems in case somebody messes things up 13:54 celeron55 it does have some storage overhead (when storing many individual bytes), but it can be minimized to be reasonable 13:59 Taoki celeron55: Seen the link hmmmm posted? He managed to get the mapgen stuff on a branch. 13:59 Taoki Now I wonder when and if it will be ready for upstream too 14:01 celeron55 simple answer: not soon 14:01 Taoki ok 14:01 Taoki Was it tested and something known to be wrong? 14:04 celeron55 ... 14:04 celeron55 04:21:54 < hmmmm> and it doesn't even work yet 14:04 celeron55 i suggest reading 14:04 celeron55 it isn't even *supposed* to work yet 14:05 celeron55 22:36:32 < hmmmm> it's in my experience that if something isn't 100% when it's released to the public, people will try to use it and people will complain that it doesn't work 14:05 celeron55 22:36:44 < hmmmm> and i'd get 1000 messages "hey your thing crashed when i did blah blah blah" 14:05 celeron55 8) 14:05 Taoki Sorry, missed some of his lines 14:06 Taoki If it's not intended to work yet then sure, no one can expect it to work. Wasn't sure if it was only... no rush in finishing it then 14:10 Taoki In other news: I'm close to implementing parallax mapping for tiles. Normal maps will be specified as a property of the tile, just like textures and material options are (from mua). Trying to debug why setting the material to EMT_PARALLAX_MAP_SOLID causes eveything to go black, whereas EMT_SOLID works 14:10 Taoki It's not lighting either, I tried enabling ambient light and same story 14:11 Taoki **from lua 14:13 celeron55 probably because here is no lighting 14:14 Taoki Don't see why that should require lighting in a different way. I tried setting ambient lighting to it and same 14:14 Taoki WB hmmmm :) 14:14 hmmmm hi 14:14 Taoki Nice work on that code. Haven't tried it yet but I'm glad it's on GIT, and I see a lot of changes 14:14 hmmmm are you guys talking about shaders 14:14 hmmmm dude 14:14 hmmmm don't try it 14:15 hmmmm it doesn't work 14:15 hmmmm at all 14:15 Taoki hmmmm: ok. And we're talking about me implementing parallax mapping. But for some reason it causes surfaces to go black 14:15 hmmmm is that already a feature in irrlicht? 14:17 Taoki Sure. Found two examples of how to use it and for everyone else it works 14:17 Taoki Here's one: http://irrlicht.sourceforge.net/forum/viewtopic.php?t=42716 See the code sectin at the bottom of the first post 14:17 Taoki I'm adding the same lines where material texture is set 14:18 Taoki And I tried ambient light and diffuse on the material, same story 14:18 Taoki So I don't think it's the lighting either 14:18 hmmmm could it have something to do with the alpha channel? 14:18 hmmmm most likely it's a bug with irrlicht itself 14:19 hmmmm just make sure makeNormalMapTexture isn't being called twice (as the problem is stated in that forum you linked) 14:19 Taoki I'm trying a temporary test that applies it to all textures. Most have no alpha channel 14:20 Taoki hmmmm: Currently I'm trying even without the normal texture. Simply setting the material type to EMT_PARALLAX_MAP_SOLID breaks it 14:22 * Taoki will also want to implement envmap or cubemap reflections... hopefully these go well 14:26 Taoki celeron55: Where exactly is that one line of code that applies the lighting system in MineTest to the material of nodes? Might help to take a look at it 14:29 Taoki http://pastebin.com/raw.php?i=y9UKjFbb And to make sure it's not the lighting, I also smashed in the lines http://pastebin.com/raw.php?i=JpKrJw31 14:30 Taoki (and yes unknown_block.png is used in a temporary test circumstance, it's in the bin folder next to the minetest binary till I get the atlas working with it) 15:12 celeron55 most things that seem like bugs in irrlicht actually aren't so 8) 15:12 celeron55 irrlicht is such a thin wrapper for most parts that many bugs don't fit there 15:15 Taoki Clearly what's happening isn't right. Since like I said I set some Irrlicht lighting too to test and same problem 15:17 celeron55 maybe you have to explicitly enable lighting 15:17 Taoki I set the lighting flag to 1 as well, same thing 15:17 Taoki erm, to true 15:17 Taoki like material.setFlag(video::EMF_LIGHTING, true); 15:18 Taoki But parallax shouldn't use lighting different than existing materials, so it should work with the current light system 15:18 celeron55 maybe mapblock_mesh.cpp:1069 15:24 Taoki doesn't change anything either 15:57 Taoki damn. It seems I have to add an irrlicht light entity before parallax mapping works. It needs new lighting... no idea why 15:58 Taoki Problem is however, that during my test I'm among the first to see a MineTest scene with dynamic lighting :) I got that working without even intending to, and it looks pretty fine 15:58 Taoki Maiybe I can post a screenshot. I'm so tempted to work on implementing this now, but I don't know how sunlight can be kept from shining in caves :( 15:59 Taoki I'm also getting an envmap reflection for an unknown reason 16:02 Taoki I'll try to see if I can somehow get textures to make a screenshot, just so everyone can see the MT world with dynamic Irrlicht lighting 16:06 Taoki Damn this looks good :) 16:07 Taoki OMG, I got it working with good textures! Not parallax (that's still buggy) but dynamic lighting 16:08 Taoki Guess what: It doesn't reduce any performance either 16:09 Taoki http://i46.tinypic.com/j5fd35.png That's with one static light entity added to the world 16:12 celeron55 it looks like generic basic 3d stuff, not interesting at all 16:15 Taoki celeron55: It looks a lot like the current lighting, but it's directional. So eg: surfaces facing the sun will be lit, and everything else only affected by ambiental lighting. 16:15 celeron55 yeah; go in a cave 16:15 celeron55 or under a tree 16:15 Taoki Thing is, the Irrlicht lighting system is needed for many other features to work (in terms of visual improvements). I have toa bandon parallax mapping till then for instance 16:15 Taoki I know, I know 16:16 Taoki That's why I'm pissed this is so hard to implement :P 16:16 Taoki Also note: If this could be used instead, there would no longer be a need to generate lighting with the mapgen. Will be MUCH faster 16:17 celeron55 that is never going to be plausible on old hardware 16:17 Taoki Thing is that in the test I jsut did, tynamic light didn't decrease performance the slightest little bit. 16:17 Taoki **dynamic 16:17 celeron55 i've tested that multiple times myself already 16:18 Taoki So that's another interesting point. Obviously I've no idea how it will be with a lot of torches 16:18 Taoki hmm... ok 16:18 celeron55 the thing is, hardware lighting is horrible without shaders 16:18 Taoki Obviously both the old and new systems will be in place at best. And the client will be able to decide which to use 16:19 Taoki I think I'll make a branch to play with this a little. Just see what I get for now... won't pretend I can suddenly get any of it working properly 16:19 celeron55 yeah, it needs some experimentation 16:19 Taoki Idea: We could use the current lighting system in MineTest, but instead of brightening the area "lit" by this system, use that as a mask for other lights 16:20 Taoki But again, might need a shader 16:20 Taoki I'll see what I can get, at least to get a taste of what it might be like 16:20 Taoki For now I need to go, so BRB 16:20 celeron55 the most interesting outcome would be to feed the voxel lighting data into a shader and use it there 16:20 celeron55 (in addition to other stuff) 18:44 Taoki Back. Going to look into those lights some more 18:56 Calinou Taoki: https://github.com/celeron55/minetest/pull/304 opinions? 18:57 Taoki Calinou: Yes. Make that a server setting in minetest.conf instead if possible. And default it to that then I guess. Might be better to have a way to set it I think 18:57 celeron55 Calinou: have you really tested it to look better or do you just imagine it to do that? 18:58 Calinou yes, i tested it locally 18:58 celeron55 because i don't know 18:58 Calinou it does look better. by far 18:58 Calinou celeron55: maybe host a server with that patch :) and se 18:58 Calinou see* 18:58 Taoki I say default it to that, but please make it a minetest.conf setting. Might be best if it can be tweaked... if other devs agree too 18:58 Calinou serverside minetest.conf setting would be ok too 18:59 celeron55 it shouldn't make much difference unless there is some other problem somewhere 18:59 Calinou people see other people turning more fluidly 18:59 Calinou also, jumping 19:01 Taoki It surely will be a lot better. But again, please do make it a minetest.conf setting 19:01 Calinou Taoki: /msg Taoki 80.118.209.33 port 30000 19:01 Calinou fail 19:01 Calinou I tried to pm... lol 19:01 Taoki hehe, it's ok 19:01 Calinou well then, feel free to connect 19:01 Taoki I'll join 19:01 Calinou (use my patch!!) 19:01 Calinou you have to use my patch and recompile of course 19:01 Taoki Do I need to? I thought the server sends it 19:01 Calinou since the timer is client side 19:01 Calinou nope 19:01 Taoki ahhh, weird. Ok then 19:02 Calinou (also, this is a nice security bug... set it to 100, overflow ;)) 19:02 Taoki It's one line of code so I'll do it manually 19:02 Calinou works too 19:02 Taoki I'm trying toa dd dynamic lighting some, damn hard tho 19:02 darkrose it can have a min/max in client side config 19:03 Taoki Yeah. So trolls won't use it to lag a server 19:03 Calinou making the setting clientside is another option, maybe, force minimum to 5, maximum to 20 19:03 Calinou and default 10 19:03 Calinou (20 would be useful for specific cases, eg. videos) 19:03 Calinou where you need high accuracy :) 19:03 celeron55 Calinou: i ask you to try what changing the value in environment.h:209 to 0.2 does, when the client sends 5 times a second 19:04 Taoki Calinou: Is your server up? Won't connect here 19:04 celeron55 because it could be just a problem of the sends being not in sync, rather than not being frequent enough 19:04 Calinou nope, not frequent enough, definitely. the difference is big between 5 and 10, 10 feels much more smooth 19:05 Calinou i tried changing the amount of smoothing, but it didn't really look good (forgot where) 19:05 celeron55 you didn't try what i asked 19:05 Taoki Server's down, let me know when it will be up 19:05 Calinou celeron55: do i do that while keeping player position frequency to 0.2? or set it to 0.1 like in my patch? 19:06 Calinou Taoki: weird, it is up here.. 19:06 celeron55 Calinou: the smoothing code probably gets screwed up as the server sends two same positions and then two same positions and so; there are two ways to fix that: either raise the client send frequency to 10, or lower the server send frequency to 5 19:06 celeron55 Calinou: both to 0.2 19:06 Taoki You probably mentioned a bad ip or port then\ 19:07 Calinou done, recompiling 19:07 Calinou ERM 19:07 Taoki Calinou: Do I keep the change client-side? 19:07 Calinou the internal IP I forwarded is my printer's O_o 19:07 Taoki lol 19:07 Calinou :p 19:07 Calinou fixing it 19:08 Taoki The first user to run minetest on their printer :3 19:08 Calinou try again Taoki 19:08 Taoki works now 19:08 Calinou celeron55: i bet this won't fully fix the issue (this doesn't fix turning not being smooth enough) 19:08 Taoki someone else join so we can compare 19:08 Calinou if someone spins rapidly in one direction then another, other players might see nothing 19:09 celeron55 if it fixes moving, then the right fix to turning is to smooth turning 19:09 celeron55 it's not like 10 sends per second would fix turning, it just improves it a bit 19:09 celeron55 for smooth turning, smooth turning must be implemented rather than flooding packets 19:10 Calinou it's not really flooding, some games send position 20-30 times a second ;) (like sauerbraten) 19:10 Calinou sends 30fps in best conditions 19:10 Calinou iirc 19:10 Calinou but the more you lag the less you send, of course 19:11 celeron55 well, 10 isn't too much, but i don't want to raise it unnecessarily 19:11 Taoki BTW, a way to reduce bandwidth usage: When a player is staying still and hasn't moved, is its position still being sent? Both by server and clients 19:11 Calinou it is iirc 19:11 Taoki It should't IMO since there's no reason to 19:11 Calinou methinks "turning" and "moving" should be separate packets 19:11 Calinou like in minecraft 19:11 celeron55 it's beneficial to have small bandwidth consumption, because it makes huge servers and crappy connections more viable 19:12 celeron55 Calinou: minecraft does not have packets; it uses tcp which is a stream protocol 19:12 celeron55 Calinou: you can't compare it 19:12 Calinou I spawned a random input player, it doesn't look any better than if I didn't use your change.. 19:13 Calinou it did look better when I used 10fps 19:13 Taoki lol, didn't know about thsse :P Is it a mod 19:13 celeron55 in minetest, sending a packet actually sends a single packet; in minecraft using TCP, sending a virtual packet either sends it or waits for a bit for more data to put into the packet, and then sends it 19:13 celeron55 so it makes sense to put many things in a packet 19:13 Calinou Taoki: random_input = true in minetest.conf 19:14 Taoki fun fun 19:14 Calinou celeron55: well I think it should be set to 10fps, and disable sending positions when you don't move :) would compensate somewhat 19:14 celeron55 that makes sense 19:15 Calinou i suggested this yesterday, since pitch is sent, why not make the player model pitch when looking up/down? not very realistic (since the whole model will pitch) but better than nothing 19:15 Taoki turning should also be transitioned client-side, like movement is 19:15 Calinou probably easy to do 19:16 Taoki So it doesn't snap but turn smoothly 19:16 Calinou yeah 19:16 Calinou i suck at c++ so i didn't tyr 19:16 Calinou try* 19:16 celeron55 i don't want player model pitching, it's not better, just odd 19:16 Taoki it's ok, I do too and not sure how, but someone who knows should be able to do it easily 19:17 Calinou celeron55: when you're looking up/down, mining stuff but looking "normal" to other players, it does feel odd 19:17 Taoki Calinou: Anyway, I don't see a big improvement on your server really. Player seems to be pretty much as smooth 19:17 hmmmm what 19:17 Calinou Taoki: i send 5fps + celeron55's improvement 19:17 Calinou let me come back with 10fps 19:17 Taoki sure, lets try that 19:17 celeron55 by the way, "some players will set it very high (eg. 50 per second), using lots of bandwidth for the server and other clients..." is completely wrong 19:17 Taoki send 10fps from the server so we can see if that makes a difference 19:17 hmmmm even if we used shaders, it turns out to be ~3x slower 19:18 celeron55 the server sends the positions at a static interval, when it sends 19:18 hmmmm which is the reason why it was abandonded in the first place 19:18 Taoki hmmmm: Shaders? Where where where :D 19:18 hmmmm Kahrl's repository 19:18 celeron55 did you try it 19:18 hmmmm i don't have a link handy though 19:18 Calinou Taoki: come back and see 19:18 Taoki Do those still work with latest master? Would be nice if they do 19:18 Taoki Ok, logging back in 19:19 Taoki Ahh yes, now I can feel a difference. It's smoother a bit 19:20 Taoki the 10 fps instead of 5fps on ths server helps. The client update interval, not sure if that too 19:20 Taoki Maybe only when both are done 19:21 Taoki My suggestion is pussing it for both the server and client in minetest.conf 19:21 Taoki *putting 19:21 celeron55 the server already sends 10 19:21 Calinou but it looks like 5 since clients send 5 19:21 celeron55 it sends object messages (position and whatever) in the same packet 19:21 celeron55 (it doesn't send anything if nothing moves) 19:22 celeron55 so... actually it probably sends 5 per second if clients send 5 per second, if there are no other moving entities 19:22 Taoki BTW. At the current moment (with and without the change) how much bandwidth does MineTest use? Both server and client. I'm curious 19:22 Taoki In kbps 19:23 celeron55 in what situation 19:23 Taoki Well, idly for instance. When there are an average number of players on a server, some moving, some standing 19:23 Calinou one player on my server, 1-3kbyte/sec outgoing 19:23 Calinou better than MC which uses 20-40kbyte/sec outgoing 19:23 Calinou -for one player- 19:24 hmmmm oh, on that note, what does everybody say about increasing the server tick default to .25? 19:24 Calinou (with the 10fps patch) 19:24 Calinou default tick is 0.05, no? 19:24 hmmmm it is, but that's really low 19:24 Calinou "0.10 ought to be enough for everybody" --RMS 19:24 Calinou fits 99% of uses 19:24 celeron55 0.10 would be a good default 19:24 Taoki yeah 19:24 celeron55 0.25 is very slow, it already kills gameplay much 19:24 Calinou (like player pos FPS ;)) 19:25 hmmmm I had it up to as high as .35 and it seems fine (for me) 19:25 Taoki Anyway, a more important change about player position sending, if you can add it: Don't send either from client to server or server to clients if the position and rotation of an object haven't changed. There's no need to waste bandwidth for players who are standing and doing nothing 19:25 Taoki And it's easy to check. Just store an old_position and old_rotation vector, and check them if updated 19:26 celeron55 hmmmm: it doesn't matter as long as you don't have moving animals or anything like that, and also it will limit the send interval that we were talking about 19:26 Taoki On both client and server 19:26 Taoki Same for lua entities, not just players. This will be important when mods will add a lot 19:26 celeron55 if clients send position every 0.1s by default, then the server should tick at at least 0.1s as default 19:27 Taoki Agreed 19:27 Taoki Server tick is another thing I'd recomment making a setting in minetest.conf 19:27 celeron55 0.05 is excessive though, this is not an FPS or something... 19:27 celeron55 Taoki: it is 19:28 Taoki ah good 19:28 celeron55 i recommend reading through the example config 19:28 Taoki Ies 0.05 sounds like more than needed to me too 19:28 celeron55 the things aren't there for no reason 19:28 Taoki 0.1 shouldn't make any visible difference compared to that 19:29 hmmmm on my old machine, Minetest took up a consistent 30-50% cpu in system time 19:29 hmmmm which was ridiculous imo 19:29 celeron55 the server? 19:29 hmmmm well, singleplayer 19:29 hmmmm so yes 19:29 celeron55 the client uses practically all of available CPU for rendering 19:29 celeron55 don't blame the server 19:30 hmmmm no, no, i had fps_max set. 19:30 hmmmm to 30 19:30 Taoki Isn't GPU used for rendering, and CPU for calculating other things? 19:30 hmmmm the cpu will spin around and keep rendering 19:30 celeron55 the way minetest draws things makes a lot of CPU usage 19:31 celeron55 (that is, in small pieces) 19:31 Calinou setting FPS to 10 also allows seeing players punching, when they hold mouse for less than 0.2 sec :( 19:31 Taoki ok. That's ok, good CPU here so I don't mind 19:31 Calinou :)* 19:31 Taoki Just wish FPS was higher when "full view range" is enabled 19:31 Taoki BRB 19:31 celeron55 not like "world mesh + players" but like "mapblock + mapblock + mapblock + mapblock + mapblock + mapblock + mapblock with another rendering material + ..." 19:31 Calinou it's impossible unless you have a NASA mainframe, full view range draws a lot of triangles... 19:31 Calinou 1 million+ easily 19:32 hmmmm yeah, but the problem with saying that is you're giving it the "Works on my machine" seal of approval 19:32 celeron55 minetest really struggles on my machine 19:32 celeron55 this is an intel GMA950 with a 1600x1200 display 19:32 hmmmm but you have a stronger cpu, no? 19:32 Calinou my shit connection manages to host 6-8 players with no lag, even with the patch 19:32 celeron55 centrino duo @ 1.6GHz 19:32 celeron55 throttles down due to heat though 19:33 hmmmm ouch 19:33 Calinou how many RAM? 19:33 hmmmm i wonder how it'd stack up against an athlon 64 3500+ 19:33 celeron55 Calinou: 2 19:33 celeron55 hmmmm: that sounds similar to my server, a 3GHz P4 19:33 hmmmm and 1gb ram 19:33 celeron55 it's quite similar 19:33 Calinou a raspi is still slower, wait a few years and they'll be better :P 19:33 celeron55 in performance 19:34 celeron55 well, mobile phones are still a tiny bit slower than this laptop 8) 19:34 hmmmm you see, even though now i have a cpu equivalent to an ivy bridgde i7, i still am going to test my stuff on the athlon 64 19:34 celeron55 except that they have more GPU power 19:34 celeron55 maybe 19:34 celeron55 at least shader power 19:34 hmmmm right 19:35 hmmmm so back on topic, change the default server step to .1 19:35 celeron55 i have a 3.4 or so GHz i3 with 4GB of RAM, but it's boring; i don't generally use it, and also the sandy bridge GPU sucks balls with minecraft and minetest because it is so slow at taking new vertex data into use 19:36 celeron55 works fine for normal games that just load everything and then play, but for these... no way 19:36 hmmmm and i wasn't aware that the position packet send was a separate setting from the server step 19:36 celeron55 that makes the choppy FPS that is known within MC players 8) 19:36 hmmmm what if they were always the same, the clients can negotiate with the server for the interval 19:37 hmmmm and instead of it being the "server step" and the "client step" it can be just the "step" 19:37 celeron55 ehm 19:37 celeron55 are you seriously suggesting running the client at a lower rate than the FPS is? 19:37 celeron55 that'll make some really choppy stuff 19:37 hmmmm no, just the send interval 19:38 hmmmm you don't need to seriously send a packet *every* single frame, do you? 19:38 celeron55 i didn't say that 19:39 celeron55 anyway... 19:39 celeron55 it might be a good idea to make client use the same interval as the server does 19:39 celeron55 based on server configuration 19:39 celeron55 same send interval, that is 19:39 celeron55 ...and that would be the same as the server step interval 19:40 celeron55 hmm, i'll do those now 19:41 Calinou letting clients choose their own rates is bad for fairness (especially for pvp) 19:41 hmmmm yeah, the client will set the interval in TOCLIENT_INIT 19:42 hmmmm when parsing* 19:42 Calinou will the server step/player position rates be changed? 19:43 celeron55 i'll make it stick to the server step interval 19:44 Calinou ah, ok, good then :) 19:44 Calinou gtg 20:55 celeron55 by the way, was this approved by, like, anyone? https://github.com/celeron55/minetest/commit/ffad18e42442fed10c312adc989fc62b74e05896 20:56 celeron55 it has the known issue of being heavy to render for HD texture packs due to the huge per-pixel generated meshes 20:56 celeron55 it's not an issue for me, but surely for HD texture users 20:58 celeron55 oh umm... 20:58 celeron55 what does that even do 20:59 VanessaE celeron55: one thing I've noticed, at least with HD textures, if the image has lots of holes (say, a checkerboard of white-hole/hole-white) it slows the extrude-for-wield down horribly 20:59 celeron55 wtf does that do 20:59 VanessaE like one 512px image takes *minutes* on a fast box. 21:00 celeron55 it forces node items to look like nodes even if they have an inventory image 21:00 celeron55 why was that put in 21:00 VanessaE dunno, I didn't even get a chance to ask pilz about it 21:00 VanessaE maybe related to RBA's new unified inventory mod. 21:01 VanessaE he said he needs a hook to get the wielded appearance of every node/item registered by the game/engine. 21:01 celeron55 i do not approve this 21:02 VanessaE well, the build I have in place now has that commit. 21:02 VanessaE is there something I can look for to say "it's broken"? 21:02 celeron55 it's a change for no reason 21:02 celeron55 that is the problem 21:03 celeron55 the only thing it can do is break things 21:03 celeron55 PilzAdam shall explain it tomorrow 21:03 celeron55 (he should have explained it in the commit message) 21:04 VanessaE RBA says it is *not* related to the inventory mod. 21:22 Taoki back 21:24 VanessaE wb 21:29 Taoki Thanks. Thinking of the next changes to try working on now :) 21:29 Taoki Pretty determined to get a WIP of dynamic lighting working to some extent. Undoubtfully a dead end till someone digufes out good shaders, but I so wanna see that a bit :) 22:16 Taoki WTF? 22:16 Taoki mesh.cpp line 465: smgr->addLightSceneNode(0, light_position, light_color, light_radius); There already is Irrlicht lighting in MineTest? 22:17 Taoki An addLightSceneNode is the correct way to setup Irrlicht lighting, and what I tested with today. But in its case it's not directional. I wonder what use that line has... it exists in upstream, together with an ambient light 22:20 Taoki Well it's part of GenerateTextureFromMesh lol... probably unused in any actual circumstance :P 22:22 celeron55 ehm 22:22 celeron55 it is used for making images from nodes to inventory and so 22:23 Taoki oh, right then :P 23:40 Taoki VanessaE: I got the changes you wanted on a GIT branch. Hats work now. However, I forgot to set some material flags... a code change must also be merged 23:41 VanessaE wonderful! 23:41 Taoki celeron55, thexyz, darkrose: Can any of you please merge those two branches upstream? https://github.com/MirceaKitsune/minetest/tree/models_flags ---- and ---- https://github.com/MirceaKitsune/minetest_game/tree/player_extras 23:41 Taoki The first one is of highest importance since I forgot some material flags for meshes, and they didn't allow transparency and weren't affected by fog 23:42 Taoki The second adds hat support to fix some skins, and also a sit animation to be used by mods (like the carts or chairs) 23:44 Taoki VanessaE: http://i50.tinypic.com/2ynroxs.png With hats working 23:45 VanessaE perfect 23:45 VanessaE you are a goddess, Taoki :-) 23:45 Taoki awww 23:45 Taoki Still around for 15 or so minutes, if anyone with upstream access can check this 23:46 Taoki VanessaE: Don't use the new player update yet however. The code is needed to fix alpha channel, otherwise the head / hat will apperar black 23:46 Taoki Clients need the code patch 23:47 VanessaE I will wait until you and c55 are happy with it and merge it to git master. 23:47 VanessaE make sure it is backwards compatible with the pre-hats code ;-) 23:48 Taoki yes, it will be 23:53 Taoki Just added a fix for the sit animation positioning, please use latest rev 23:57 Taoki Also, to be clear: You can't animate the player sitting and mining at the same time. Please don't ask me to add that, it would be a waste of animation space. I already do a combined walk + mine animation since there's no other choice 23:58 VanessaE oh that's more than fair - who sits and mines at the same time? :-) 23:58 Taoki exactly :) 23:59 Taoki BTW: I made the sit animation so that the player sits on the bottom of his origin / bounding box. This can already be used to sit on the ground even, and it looks great for that 23:59 Taoki Will post a shottie