Time  Nick      Message
20:02 MrDJK     #minetest
20:03 MrDJK     Oops. >_<
20:12 Taoki     Latest updates on the models code: http://minetest.net/forum/viewtopic.php?pid=51559#p51559 The code is nearly ready, and there's just two more issues which need to be fixed first (related to an Irrlicht problem it appears)
20:29 MrDJK     May I ask an advice question in here? It's relating to Minetest mods.
20:30 PilzAdam  #minetest-mods
20:30 MrDJK     Oh okay, thank you much appreciated.
20:44 Taoki     BTW: If anyone knows Irrlicht and is interested in seeing the models code finished and working well, please see those two threads: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=1&t=47579 and http://irrlicht.sourceforge.net/forum/viewtopic.php?f=1&t=47580 It would help if someone could poke around the code and see what's causing that... I personally have no idea.
20:45 PilzAdam  Taoki, this might interest you: https://github.com/PilzAdam/carts/tree/attachment
20:46 Taoki     PilzAdam: Nice. Thanks... glad to see people are using it already. Yes, that's onevery useful case for it
20:46 PilzAdam  it works pretty good
20:47 Taoki     Nice. Using my latest GIT code?
20:47 PilzAdam  yep
20:47 Taoki     I tried player to player attachments, but not player to lua ent
20:47 Taoki     Awesome
20:48 Taoki     Yes it took quite a bit of work... was about to give up and remove attachable players altogether. Since it was tricky to find how to update local position and block movement
20:48 PilzAdam  but you should cahnge set_detachment() into detach() or something like this
20:48 PilzAdam  and extend the lua-api.txt
20:48 Taoki     Yeah, will think about that. I used that (ugly) name so it would be easy to find with set_attachment
20:48 Taoki     I might rename those however
20:49 Taoki     PilzAdam: If you're on my GIT branch though, feel free to try more test cases. Testing will be needed soon, to see if there are any other bugs. Only ones I'm aware of are issues with mone animations and attachments
20:50 Taoki     **bone animations and attachments
20:56 celeron55 i'd imagine those should be called .attach() and .detach(), or if it has to be more specific, then .attach_object() and .detach_object()
20:57 celeron55 or maybe no .detach() at all, just .attach(nil)
20:57 celeron55 dunno 8)
20:58 celeron55 great work anyways
20:59 PilzAdam  Taoki, what does the second param of set_attachment() mean?
20:59 Taoki     celeron55: Thanks. I'll think on how to rename these tomorrow
21:00 Taoki     PilzAdam: The string? It's the skeletal bone / joint to attach to, if the parent is an animated mesh
21:00 Taoki     Does not work yet... I'm waiting for input from the Irrlicht people
21:00 PilzAdam  ah, ok
21:03 Taoki     setBonePosRot also. Which should allow manually rotating a bone, for the head to look up / down and that sort of thing
21:05 celeron55 oh lol, started browsing a full diff of taoki/models
21:06 celeron55 you changed the loggings of everything in Client::loadMedia to say "loading into irrlicht" while the only one that loads anything into irrlicht is the one you added there 8)
21:07 celeron55 http://pastebin.com/V6QXy7Mf
21:07 celeron55 "loading sound into irrlicht" *proceeds stuffing it into the custom sound manager*
21:09 celeron55 oh well, i might just as well browse through all of this
21:09 Taoki     Ah yes, I remember I did that to match the rest. Hope that's fine, if not I'll ut it back
21:09 Taoki     **put
21:09 celeron55 "std::vector<core::vector2d<int> > attachment_list;" in content_cao.cpp should probably be stored as a member variable of ClientEnvironment
21:10 Taoki     celeron55: If you're looking at the diff, let me know if you find anything that could be considered "bad coding". This is my first big try at C++ after all
21:10 celeron55 Taoki: it should log what it does
21:10 Taoki     Thought that's accurate for the other media types too
21:11 Taoki     And yes, that list is just a client-side global. I'll move it if that's better
21:13 celeron55 well, in practice it doesn't matter, but making globals is quite selfish because you can only make a certain amount of them until everything becomes very unreadable
21:13 Taoki     I see
21:14 Taoki     And yeah. If it works well it's good, though clean and correct code matters too. Did my best to keep it as consistent as possible to my knowledge
21:14 celeron55 also, technically you *can* make two Clients and ClientEnvironments, but not if that is a global
21:18 Taoki     I have a TODO list so if there's something else that's bad and not too difficult to change I can look into it tomorrow
21:19 celeron55 the bad line ratio of this is surprisingly low 8)
21:22 Taoki     That's good :)
21:23 Taoki     Most things to do from this point are tweaks, so it will likely stay that way too
21:24 celeron55 most of this seem to be just changing "doStuff();" to "if(attached) doSomethingElse(); else doStuff();"
21:24 celeron55 this is kind of obvious
21:24 celeron55 which*
21:25 Taoki     yeah. Part of attachments filters other events. Such as setting position in other places, or sending position to clients and wasting bandwidth (since if it's attached to an object that's aready sent the client will know where to see it)
21:29 celeron55 the addition of irrlichttypes_bloated.h to other headers should be avoided like plague; you should rather include only the precise thing you need
21:29 celeron55 because it will bloat up compile time by the enormous amount of useless stuff it contains, and headers spread it to many .cpp files
21:31 celeron55 umm... actually it doesn't seem to include "enormous amounts"... well, but many useless things anyway
21:31 Taoki     ok. A lot of files seem to have that already. Not sure if that can be avoided in some parts
21:31 celeron55 that was pretty much all
21:31 Taoki     ok
21:32 Taoki     Will get to those things tomorrow :) Then the code can go on servers for testing.\
21:33 Taoki     Hope the Irrlicht people will help find out why bone attachments and animations break though
21:33 celeron55 do you know any software based on irrlicht that does use them?
21:35 Taoki     None where I seen it working. But the functions are there and should work
21:35 Taoki     It's probably a bug or another flag I should be setting
21:35 celeron55 supertuxcart is the "known" game based on irrlicht
21:35 Taoki     For bone attachments sure, many games were attempted in Irrlicht with people holding a sword in hand
21:37 Taoki     Seen some on Youtube myself IIRC. For manual joint rotations no, but the function for that is there and people have mentioned using them IIRC.
21:37 Taoki     Might be an issue with the x format. Which would be bad, since it's the only skeletal format that seems to work and can be exported from Blender (natively even). So I'm sticking to it
21:37 Taoki     But we'll see
21:39 celeron55 i know roughly nothing of this subject, so you are on your own
21:40 celeron55 or, well, with the irrlicht people
21:40 Taoki     yeah
21:40 Taoki     it's ok, a solution has to be found eventually
21:41 celeron55 http://www.irrlicht3d.org/wiki/index.php?n=Main.IrrlichtPoweredGames
21:42 celeron55 lol why is minetest in the "free" section, not "open source"
21:42 celeron55 well whatever...
21:44 Taoki     That's a sad mistake
21:46 celeron55 http://www.google.com/trends/explore#q=minetest%2C%20Star%20Sonata%202%2C%20SpaceWork%2C%20SuperTuxKart%2C%20Bolzplatz%202006&cmpt=q
21:46 celeron55 some other somewhat known irrlicht games versus minetest 8)
21:47 Taoki     oh my, nice :D
21:47 celeron55 it's funny how popular it is
21:47 celeron55 it's like the only thing irrlicht is used for these days, in addition to STK
21:47 Taoki     Indeed. Still can't believe so many people are liking it. Didn't expect we'd be this lucky
21:48 Taoki     It's also in the Linux game repos... for my distro at least. So it's surely something
21:48 Taoki     Likely thaks to he lua API, and that MT can be used as an engine and it's so easy to create stuff. If everything stayed hard-coded it probably wouldn't have gotten very far, and be close to where it was 3 years ago
21:49 Taoki     **thanks to the lua API
21:49 celeron55 minetest could catch openttd in popularity at the end of next year
21:49 celeron55 http://www.google.com/trends/explore#q=minetest%2C%20openttd&cmpt=q
21:49 celeron55 it's a funny comparison
21:49 celeron55 dunno; of course it could just drop like dead too
21:50 Taoki     Likely not. Especially since new features are being added
21:50 celeron55 3 years ago? minetest did barely exist 2 years ago :P
21:50 Taoki     After the models patch I think people will like it even more
21:50 Taoki     True
21:51 Taoki     I think I'm among those who found it 3 or so years back. But I liked it since, sticked around but wasn't very active
21:51 celeron55 there didn't exist even a line of minetest code 25 or 26 months ago
21:51 celeron55 i don't know where you get that 3 years figure from :-D
21:52 Taoki     Menas time passed faster than I thought
21:52 Taoki     Erm, or slower
21:52 Taoki     Actually yes. It was around the beginning of 2011. That's when I remember I was on a public server for the first time and made a house
21:52 Taoki     http://www.youtube.com/watch?v=coI1rX6gclI&feature=related
21:54 celeron55 the early times of 0.2, that i
21:54 celeron55 is*
21:56 celeron55 http://www.google.com/trends/explore#q=minetest%2C%20minecraft&cmpt=q
21:56 Taoki     Yeah. Quality improved quite a bit too. I remember those static torches and water, the old texture... and when the only tol was the mese rockpick. And obviously there was no sound. Flat clouds and... a very ugly day / night cycle (instant snapping to three phases of the day)
21:56 Taoki     Playing minetest_game now surely feels a lot more improved
21:56 Taoki     **old textures
21:57 celeron55 hmm, the minecraft graph is interesting
21:57 celeron55 i wonder if it's starting to decline
21:58 celeron55 http://www.google.com/trends/explore#q=terraria&cmpt=q
21:58 celeron55 these really do vary a lot
21:58 Taoki     It eventually will. Since most poeple who like MC probably got it by now
21:59 celeron55 and it's interesting how large scale even terraria is; if you make it compare it to minetest, it's 19:1 currently
22:00 Taoki     yeah. It is a nice project too
22:01 celeron55 http://www.google.com/trends/explore#q=braid%20game%2C%20minetest&cmpt=q
22:01 Taoki     What makes it special are the graphics. But I plan to optionally allow for graphics like that in MT too, with shaders and post-processing effects. Later on, not sure how hard those will be to add
22:01 celeron55 from the indie scene, braid seems to be equally popular at the present moment
22:01 Taoki     nice
22:05 celeron55 i guess you know of kahrl's shader branch
22:06 Taoki     I heard about it, didn't try it yet. Wonder if there's a video or images of it
22:06 Taoki     Also if it has bugs given it wasn't merged yet
22:06 celeron55 it adds some management stuff for shaders; you should be able to get going with some post processing stuff very fast with it
22:06 celeron55 it has no real use
22:06 celeron55 nobody implemented any useful shaders on it
22:07 celeron55 it just inverts colors 8)
22:07 celeron55 (the test shader that it has)
22:08 Taoki     ok. Hope its still updated and compatible with latest master. Need to find some shaders for it online perhaps
22:08 Taoki     If it's common GLSL ones
22:08 Taoki     If the code is good though, it could be added. Might encourage people to make new shaders more quickly
22:09 celeron55 i won't do that until somebody makes at least something useful
22:10 Taoki     Fair enough. Will try to keep it on my list, maybe Irrlicht users have some good ones
22:11 celeron55 we need to keep around a working shader-free implementation of rendering too though; lowest end cards can't cope with the polygon count even with the tiniest bit of a shader
22:12 Taoki     Shaders would be optional of course. And yeah, the polygon count is an issue. I have a high-end card and normally it works well. But if I enable full view range, it's very slow. I wonder why
22:12 Taoki     Mc renders the same amount of cubes times faster, and it's java rather than C++ even :P
22:12 celeron55 well, high-end cards don't work optiomally with the small batch sizes minetest uses
22:13 Taoki     Plus that I tested, and blocks do culling (hiding other things behind themselves if no important part shows). Backfaces should also be hidden (like the opposite side of blocks too) so I wonder why
22:13 celeron55 on the other hand, they can't be enlarged at all for crappiest cards
22:13 Taoki     hmm
22:14 Taoki     What does the batch size do exactly? Perhaps it can be turned into a client setting, if it's about rendering
22:14 celeron55 minecraft takes the route of just not supporting crappiest stuff, but i don't think we really can
22:14 celeron55 Taoki: well, minetest renders the bulk node stuff as MapBlocks
22:14 celeron55 that is the unit of rendering
22:14 celeron55 and culling
22:15 celeron55 and everything
22:15 Taoki     Well, there are some users who play MT on very old machines. Wouldn't wand them left out either. But it won't help if the performance isn't somehow optimized
22:15 Taoki     I see
22:15 Taoki     Can't MT add some way to improve rendering without breaking old cards? By using client settings if needed, to disable unsupported techniques
22:16 celeron55 for higher-end cards, the meshes of for example 2x2x2 or 3x3x3 MapBlocks could be combined to one and rendered as such
22:17 celeron55 it's not entirely trivial though
22:17 Taoki     That sounds nice. A client setting could allow adjusting a size for that too, and disabling if unsupported
22:17 Taoki     yeah. Will still be needed eventually so players on normal machines can have a reasonable draw distance
22:18 celeron55 the meshes of single mapblocks need to be stored too because regenerating the mesh of a mapblock when a node updates is already slow enough; making it any larger would be just not viable; combining meshes should be fast though
22:18 celeron55 i've thinked through this quite many times 8)
22:20 Taoki     Hope it does happen :) It is one thing that's a bit complex to do though... doubt I know how. Surprised I knew to add the models so well... mostly thanks to them using Irrlicht functions
22:30 Taoki     I think things are advancing fast, and that's important. The way I see things personally, MT will have to advance with a lot of new features and more stability. Otherwise people will eventually get bored, once the current lua API has reached its limits and most interesting mods have been made.
22:30 Taoki     Many who use it likely have the hope this is just the beginning... I do to personally :)
22:33 Taoki     Right now, it's still pretty simple and basic. Not because of limits in the lua api... just that there are mechanics missing from the code. Like better physics, detail, and a lot more. Obviously no one can do it all at once, coding is really hard. But I think it's important that in 1-2 years at most it will have the same solid feel MC has. Plus new features that being C++ and using Irrlicht will
22:33 Taoki     ... allow for