Time Nick Message 03:46 ShadowNinja sfan5: Pong. 03:51 VanessaE damn, that's one long ping time 03:59 ShadowNinja Yeah... Been busy. 04:00 ShadowNinja sfan5: Just PM me (or message me in-channel) if I'm not around when you come back. 05:31 kahrl has anyone else had trouble editing issue comments lately? 05:31 kahrl guess I'll just post a second comment 05:32 kahrl ShadowNinja: 6bc4cad0ed has been "first bad commit" in a couple recent issues :P 05:36 ShadowNinja kahrl: Yeah... Better than rotting away in the PR list though IMO. 05:37 kahrl yeah 05:37 ShadowNinja kahrl: And comment editing worked fine for me yesterday, haven't tried today. 05:37 kahrl the delete button even results in a 404 05:38 ShadowNinja kahrl: Can you look into 1708 for me? I can't now. 05:38 kahrl yeah, I'm investigating 1708 still 05:40 kahrl ShadowNinja: ah, you moved that error message from infostream to errorstream in 6bc4cad0ed 05:40 kahrl ShadowNinja: any particular reason for that? 05:40 * ShadowNinja checks... 05:41 kahrl it's the first one in ServerMap::loadMapMeta() 05:42 ShadowNinja kahrl: Well, because it's an error. 05:43 kahrl but it always happens when you first start a new world, so not really 05:43 kahrl tbh though, map_meta.txt should really be created on world creation and not on first load 05:43 kahrl but that would be a lot of work 05:44 ShadowNinja Oh, just remove the loadMapMeta call for new worlds then, or something like that. 05:44 kahrl there is no m_new_world flag 05:45 ShadowNinja It really should be created then though, so createworld(mgparams1), createworld(mgparams2), loadworld(1) doesn't use the second params. 05:46 kahrl exactly 05:47 ShadowNinja Well, comment on the issue saying as much and fix it if you can. I'm off to bed. G'Night! 05:47 kahrl gn8 07:03 sfan5 ShadowNinja: why does minetest.compress ignore the method argument? 07:09 hmmmm std::list *> > m_pending_content_vecs; 07:09 hmmmm I got infected by some STDs 07:13 Zeno` kahrl, a possible workaround. Not ideal, but *shrug*. https://gist.github.com/Zeno-/bdc7c26752443e9ef2df 08:29 Hunterz hi, Im trying compile minetest with leveldb, but get this error: http://pastebin.com/Zu2Yt2ay 08:31 Hunterz hmm my fail, use bad path to libleveldb.so 09:22 Megaf Hi everyone 09:22 Megaf is there any thick or cmake flag to make a 100% static binary of minetest? 10:39 sfan5 Megaf: add "-static" to the cmake linker flags 10:41 Megaf ok 10:45 Krock quick question: did the protocol version change in 0.4.10-dev versions? 10:50 Krock nvm. yes it did. 10:50 kilbith sfan5 : https://github.com/minetest/minetest_game/pull/324#issuecomment-57901236 11:37 Krock Thumbs up or down? #1715 11:38 kilbith hi there, devs. could you add the OpenGL ES libs in MT, please ? 11:39 Megaf kilbith: im here since yesterday trying to make that work 11:39 Megaf sfan5: proller: so, I got no luck at all 11:40 Megaf http://paste.debian.net/plain/124457 11:46 kahrl Zeno`: I think if the file is empty, that should be regarded an error as well 11:47 kahrl because it could be a result of the previous save failing 11:48 Zeno` probably, that's why I didn't make a PR 11:52 Zeno` It *would* be possible to pass the gamedef to that init function, but I didn't have a close look 11:55 Zeno` shallow copy, Krock? 11:55 Krock Zeno`, idk how to call it.. maybe you've found the right word 11:55 Zeno` err nvm. what does core.copy_table work? 11:55 Zeno` how does* 11:55 Krock it copies a table.. 11:56 Zeno` oh, it's a deep copy ok 11:56 Zeno` yeah I like it (not a dev though) 11:57 sfan5 Megaf: static linking does not always work how you want it 11:57 Zeno` I suppose recursion related overflows *might* be a worry, but I dunno 11:57 Krock Zeno`, http://pastebin.com/pKiK8XsH 11:57 Megaf sfan5: that was with a normal linking 11:57 Megaf I didnt try static yet 11:58 sfan5 oh 11:58 sfan5 Megaf: use ENABLE_OGLES 11:58 Megaf I did 11:58 sfan5 http://dev.minetest.net/CMake_Options 11:59 sfan5 ENABLE_GLES I mean 11:59 sfan5 and you need to make sure it finds the libs too 12:01 Zeno` I guess it's no more of a "risk" than dump or dump2() 12:02 Zeno` possibly clone_table might be more descriptive 12:41 sfan5 kilbith: is your problem solved? 12:47 Megaf sfan5: 12:47 Megaf cmake ../../ -DVERSION_EXTRA=MinetestPi -DRUN_IN_PLACE=1 -DIRRLICHT_SOURCE_DIR=~/ogl-es/ -DENABLE_SOUND=0 -DENABLE_GLES=1 12:48 Megaf -- Found system opengles2 library /usr/lib/arm-linux-gnueabihf/libGLESv2.so;/usr/lib/arm-linux-gnueabihf/libGLESv2.so;/usr/lib/arm-linux-gnueabihf/libX11.so;/usr/lib/arm-linux-gnueabihf/libXext.so 12:50 kilbith sfan5 : the solution is to enable OpenGL ES on compiling ? the libs are already provided ? 12:50 sfan5 kilbith: you need to ensure the libs are available 12:51 sfan5 kilbith: then just pass -DENABLE_GLES=1 to cmake 12:51 kilbith hmm, i thought these libs was already available on git 12:52 sfan5 why would be provide OpenGL ES libraries? 12:54 kilbith ARM is not that unused for MT I think. 12:54 sfan5 ARM is mostly used by phones 12:54 kilbith should be a good addition 12:54 sfan5 (for mt at least) 12:54 sfan5 the opengl es libraries are highly platform specific anyway 12:55 sfan5 we can't provide them 12:56 kilbith these libs are not heavy... 12:56 sfan5 yes 12:56 sfan5 but 100 different ones of them are heavy 12:56 sfan5 it's not even in the scope of a project to provide libraries 12:56 kilbith we need a serious competitor to the pre-installed "Minecraft-Pi" on Raspbian. 12:57 sfan5 it's not like we'd maintain our own linux distro just for minetest 12:57 kilbith minimalist game for a minimalist OS/computer 12:58 sfan5 you are aware that raspbian has the gles libraries preinstalled? 12:59 kilbith yes 13:00 kilbith sorry for my noobism, i thought that these libs should be installed IN the client -_- 13:01 kilbith s/installed/provided 13:01 sfan5 Megaf: did it find libEGL too? 13:03 kilbith sfan5 : could re-post the link you have posted above plz ? i'm in the console, I lost it. 13:03 sfan5 kilbith: http://dev.minetest.net/CMake_Options this one? 13:03 Megaf sfan5: http://paste.debian.net/plain/124461 13:03 kilbith thanks, will try that 13:04 sfan5 thats a no 13:04 sfan5 Megaf: make it link to libEGL 13:05 kilbith so : cmake --ENABLE_GLES, that's exact ? 13:05 sfan5 nah 13:05 sfan5 cmake -DENABLE_GLES=1 13:06 kilbith noted 13:11 kilbith ok now 5 hours for compiling... 13:16 Megaf [14:04:18] Megaf: make it link to libEGL 13:16 Megaf you mean, the OpenGL thing? 13:16 sfan5 no 13:16 sfan5 libEGL 14:08 kilbith Megaf : if you success with the compiling, you should open a new build for Raspi on the forums. 14:09 Megaf kilbith: I would, but I dont know what Im doing :P 14:10 Megaf I mean, I think it should work using the ogles version of irrlicht and the flag -DENABLE_GLES=1 14:10 Megaf but I now I have to link I dont know what to I dont know what 14:25 sol_invictus is there any way to aligh text hud to a side (considering text length is variable)? 14:32 kaeza sol_invictus, doesnt align = { x=1, y=0 } work? (this is for vertically-centered, right-aligned text) 14:32 kaeza err, alignment = * 14:33 sol_invictus sorry, what does mean 'vertically-centered'? 14:34 sol_invictus vertically relatively to screen? 14:34 kaeza vertically relative to the position on screen 14:34 sol_invictus got it 14:35 sol_invictus but what if I want to position it in the left bottom corner? 14:35 sol_invictus when line gets big whole hud shift outside the screen 14:36 sol_invictus not whole, part of the text 14:36 kaeza isn't it best if you simply left-align in that case? 14:38 sol_invictus umm, how do I do that? 14:38 sol_invictus I have alignment = {x=0.2, y=0.95}, 14:39 kaeza alignment = { x=-1, ...} 14:39 sol_invictus -1? :O 14:39 sol_invictus where is it documented? 14:39 kaeza it was in lua_api 14:40 kaeza here: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L551 14:41 kaeza err, except it's 1, not -1 14:41 kaeza 1 == shift to the right (i.e. left-align), -1 is the opposite 14:42 sol_invictus oh, I was looking inside HUD definition 14:43 sol_invictus is there any appropriate highlighting for lua_api? 14:46 sol_invictus or it's actually freely formatted text? 14:47 kaeza just plain text 17:14 kilbith sfan5 : http://paste.debian.net/124480/ 17:14 kilbith Megaf ^ 17:15 kilbith OpenGL ES has not been added in the settings 17:17 sfan5 kilbith: run rm -Rf CMakeCache.txt CMakeFiles before running cmake agian 17:17 kilbith ok I take note 17:18 Megaf 100%] Built target minetestserver 17:18 Megaf real 67m51.780s 17:18 Megaf thats how long it takes to build minetest server on the raspberry pi 17:19 kilbith 4h for compiling 17:19 kilbith minetest + server 17:21 kilbith perhaps can I run the executable 'minetest' with the OGLES option ? 17:24 sfan5 no 17:25 kilbith I don't see what was wrong with the cmake... 17:25 sfan5 did you try the rm before running cmake again? 17:26 kilbith I'll try now ! 17:27 ShadowNinja sfan5: Because there's only one method currently, easier to ignore it for now. 17:28 kilbith well, same result. 17:28 sfan5 ShadowNinja: modders will abuse everything they can, if minetest.compress("text text text ", "lzma") is valid right now, they'll expect it to be valid later 17:28 kilbith i don't see any trace of the ogles libs 17:31 ShadowNinja sfan5: Go ahead and add a check then. 17:31 sfan5 ShadowNinja: why would I do that, it's your code? 17:32 sfan5 (aka. the arguemnt sapier uses) 17:32 sfan5 argument* 17:33 ShadowNinja sfan5: I can't code right now, maybe in an hour or so. 17:37 hmmmm I found that LZMA is slightly worse than gzip for small file sizes 17:38 hmmmm if you lzma chunks of data that are only 16^3 * 4 bytes long, that's not going to have much of an effect 17:38 hmmmm the larger the file size, the better the compression ratio (generally speaking) 17:46 RealBadAngel lol, further i am into meshes it turns out to be way more easier than expected 17:46 RealBadAngel http://pastebin.com/JcAkPhMd 17:47 RealBadAngel ^^ the current content_mapblock code for meshes 17:48 RealBadAngel have just modified our collector to apply the tranformations on the fly 17:49 RealBadAngel so no need for doubling the collectors methods 17:50 RealBadAngel fun fact. our code (collector) is way faster than original irrlicht one 17:51 Calinou what is the state of meshnodes? 17:51 Calinou are they ready to be merged or still have a bug? 17:51 Calinou hmmmm, gzip is much faster 17:52 RealBadAngel im coding now facedir rotations 17:52 Calinou can meshnodes be animated? 17:52 RealBadAngel not yet 17:52 RealBadAngel collector (compiled one mesh) is a static one 17:52 RealBadAngel for mesh to be animated it has to be scene node 17:53 Calinou can all mesh formats be used? 17:53 Calinou that is, all supported by Irrlicht 17:53 RealBadAngel i think so 17:53 Calinou lastly, can you change selection box? 17:54 RealBadAngel im using wavefronts ones 17:54 Calinou .obj is a good unanimated format, so use it, yes 17:54 Amaz RealBadAngel, is there any chance that we could test the meshnodes code? 17:54 RealBadAngel selection box can be predefined by modder or at last instance a copy of current mesh 17:55 RealBadAngel there are cases that a mesh is a better selection box 17:55 RealBadAngel and in some cases the opposite 17:55 RealBadAngel ie flowers 17:56 Calinou can you use curved selection boxes using that? 17:56 Calinou since meshnodes can be sloped, curved… 17:56 RealBadAngel yes 17:56 Calinou can you define collision box yourself, like you'd do in a nodebox? 17:56 Calinou (I'd really like that for nodeboxes too) 17:56 RealBadAngel erm i mean highlight box 17:56 RealBadAngel selection box is not useable in this case at all 17:57 RealBadAngel highlight is just a copy of selected node 17:57 RealBadAngel so can be exact shape as original 17:58 Calinou does it support old node highlighting too? 17:59 RealBadAngel as a simple plain boxes 17:59 RealBadAngel for example old selection box for a crystal formation will be a box of node size 17:59 RealBadAngel while highlighting will use crystal shape 18:01 RealBadAngel old selection boxes defs are treated as fall back 18:02 RealBadAngel also i think we need some kind of standards here 18:02 RealBadAngel Jordach propably will know how to define them 18:03 RealBadAngel we are having an range -0.5 to 0.5 18:03 RealBadAngel blender units are slightly different 18:04 RealBadAngel its better imho to predefine correct range for the models than apply visual scale factor all the time 18:07 RealBadAngel and one more thing 18:08 Calinou 1 blender unit = 1 game unit? 18:08 RealBadAngel stuff like stairs will have to be converted into meshes 18:09 RealBadAngel see highlight of the stair node to get why 18:09 RealBadAngel Calinou, atm i think that factor is 5.0 18:09 Calinou yes, selection box of stairs renders a bit buggily 18:10 Calinou doesn't make much sense, RealBadAngel 18:10 RealBadAngel jordach said it was 10.0 but i got a model from him and had to use 5.0 to be exact size of a node 18:10 Calinou 16 would as the default grid is 16² 18:10 Calinou so 1 unit = equivalent of 1 pixel 18:10 RealBadAngel Calinou, stairs do have extra surfaces 18:11 RealBadAngel theyre not optimized just 18:11 ShadowNinja 1 blender unit = 1/10 of a game unit would make sense, because of the BS constant. 18:12 ShadowNinja It should be scaled if possible though. 18:12 RealBadAngel collector.append(f.tiles[j], (video::S3DVertex *)buf->getVertices(), vc, 18:12 RealBadAngel buf->getIndices(), ic, pos, f.visual_scale, c); 18:12 RealBadAngel thats not a problem to apply that 18:13 RealBadAngel as you can see in a call 18:13 RealBadAngel but a standard is needed imho anyway 18:13 RealBadAngel so the visual scale of 1.0 will be standard sized node 18:14 RealBadAngel also the orientation of the model has to be defined 18:15 RealBadAngel my crystal model ive found is turned by XY axis by 90 degs ;) 18:15 ShadowNinja 0 rotatoion, X+ facing blender X+, etc. 18:15 RealBadAngel so imho Jordach part starts here 18:16 RealBadAngel hes our blender master 18:17 RealBadAngel better to ask him how to do that than later apply weird black magic factors into cod 18:17 RealBadAngel *code 18:18 RealBadAngel ah, one more thingy 18:19 RealBadAngel i do convert all the nodeboxes into meshes 18:19 RealBadAngel im not sure bout it, but it can be an end to the era 18:20 RealBadAngel meshes are way more flexible than nodeboxes 18:21 RealBadAngel theyre marked as an experimental stuff anyway ;) 18:24 RealBadAngel brb 18:29 VanessaE as long as I don't have to adapt all those 400000000 nodeboxes I have in my mods :P 18:30 kilbith :s 18:31 VanessaE otherwise ^^^^^^ he will kick your ass ;) 18:31 kilbith s/kick/whip 18:38 sol_invictus is it possible to open inventory from lua? I can't find where this formspec is called 18:40 ShadowNinja sol_invictus: player:set_inventory_formspec(formpec). 18:40 ShadowNinja It's static to pervent lag. 18:41 sol_invictus oh, thank you 19:04 RealBadAngel VanessaE, transformation is done in nodedef.cpp at update textures 19:04 VanessaE col 19:04 VanessaE cool 19:05 RealBadAngel after leaving nodedef will have mesh ptr filled in when applicable 19:05 RealBadAngel either being mesh model or nodebox, doesnt matter 19:06 RealBadAngel only stuff that wont have pre made mesh will remain stuff like fences etc 19:06 RealBadAngel at least for now 19:08 RealBadAngel we got used to nodeboxes so change will take some time propably 19:08 RealBadAngel but in the long run it can be only a benefit 19:09 RealBadAngel and hey, i can see at horizon one method i always wanted to use 19:10 RealBadAngel http://irrlicht.sourceforge.net/docu/classirr_1_1scene_1_1_i_mesh_manipulator.html#ab849bd2c83b206de1e5da19ce3481e35 19:11 RealBadAngel yikes :) 19:11 RealBadAngel that gonna mean faster shaders with better visuals 19:12 RealBadAngel also shaded entities 19:13 RealBadAngel not to mention straight way for correct liquids surfaces 19:14 RealBadAngel since more than a year i was fighting to get per surface tangents 19:14 RealBadAngel and now im at the doorstep 19:14 RealBadAngel and will be able to trash all the temporary code 19:48 sol_invictus ShadowNinja: oops, it's definition 19:49 sol_invictus ShadowNinja: I meant actually inventory from lua 20:01 ShadowNinja sol_invictus: You want a callback to be called when a player opens their inventory or you want to open an arbritrary formspec? 20:02 sol_invictus I want to arbitrarily open inventory formspec from lua 20:03 Krock ShadowNinja, I would like to know your opinion to pull #1715 20:03 ShadowNinja sol_invictus: Look up detached inventories then. 20:03 ShadowNinja sol_invictus: You can't forcibly open the inventory or node formspecs though. 20:04 sol_invictus ): 20:05 Calinou i do convert all the nodeboxes into meshes 20:05 Calinou is this better for performance? 20:05 Calinou especially the coordinates-set-every-frame issue 20:07 RealBadAngel Calinou, yes its way faster method 20:08 RealBadAngel nodeboxes do not change during gameplay, yet theyre interpreted all the time 20:08 RealBadAngel at each mapblock mesh refresh 20:09 RealBadAngel thats why areas with more nodeboxes are causing fps drops 20:10 RealBadAngel please do trace how nodeboxes are shown 20:10 RealBadAngel its a diseaster 20:11 RealBadAngel starting here: https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L1642 20:12 ShadowNinja Krock: Commented. 20:12 RealBadAngel then this is called for each box here: https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L45 20:13 Sokomine RealBadAngel: ah. good to see you. i have a slight problem with nodeboxes, although it might not be worth doing much in this regard...problem is: i want to mirror/flip a house (in order to increase diversity). this works fine for normal nodes, but may not be doable for all nodeboxes 20:14 RealBadAngel also: selection boxes and rotations are applied 20:14 Sokomine RealBadAngel: many players have complained about nodeboxes slowing down their clients. having a house with many nodebox-using sloped roof nodes caused trouble to some it seems 20:14 RealBadAngel 200+ lines of code instead of 15 as for meshes 20:15 kaeza ShadowNinja, uh... >local k = { }; local nt = copy({ [k] = 1234 }); print(nt[k]) --> 1234 20:15 RealBadAngel Sokomine, nodeboxes are slowly taking their way into the museum 20:15 Sokomine noooo! 20:15 RealBadAngel yup 20:15 * Sokomine loves nodeboxes 20:15 RealBadAngel you gonna love meshes even more ;) 20:16 Sokomine just make sure the new system can use the old definitions and worlds don't break :-) 20:16 RealBadAngel trust me 20:16 Sokomine it's very likely that i'll do that :-) 20:16 RealBadAngel ofc for the starters we will have both 20:16 Calinou but making meshes is way harder 20:16 RealBadAngel but as soon as meshes are here you will realize you dont want nodeboxes anymore 20:16 Calinou need to do UV mapping and such 20:16 Calinou nodeboxes are a great way to make 3D models 20:17 Calinou something that is more complicated in Blender 20:17 RealBadAngel either you will say that or im a chineese ballet dancer 20:17 Calinou oh, also… it'd be great if you could use texture packs to replace models 20:17 Sokomine with meshes i think those roofs could be done with far less triangles. instead of beeing a staircase with 16 steps, they could be done more directly 20:17 Calinou this way clients can replace meshnodes :P 20:17 kaeza ShadowNinja, you are using assert() wrong 20:18 Sokomine that's a very good idea, calinou. people who prefer boxy appearance could use other shapes than those who don't mind the occasional roundish object 20:19 proller using assert() always wrong 20:19 RealBadAngel Sokomine, exactly thats the point 20:20 Sokomine as for creating new nodebox/meshlike objects - nodeboxes as such are not the most easiest to create either. there are a few editors out there. if one of those could be used to create meshes, that'd be fine i guess. no idea about textures though 20:20 RealBadAngel meshes done properly can have way less triangles 20:20 RealBadAngel stairs here are the flagship 20:20 Krock ShadowNinja, this copy function is not part of the default Lua functions, therefore it should use minetest. instead of extending table. iMO 20:20 RealBadAngel atm theyre two overlaid boxes 20:21 RealBadAngel with too many common vertices 20:21 Sokomine in how far? i don't see much saving potential for stairs as such? the sloped roofs are a diffrent matter 20:21 ShadowNinja Krock: It fits much better there, and Minetest already extends the string lib. 20:21 RealBadAngel see stairs highlighted 20:21 Krock okay. *commits* 20:21 Sokomine ah. ok 20:21 RealBadAngel you will see the problem clearly 20:22 RealBadAngel lines wasnt able to show the problem 20:22 Sokomine how do i enable highlighting? 20:22 RealBadAngel while surfaces can 20:22 RealBadAngel enable_node_highlighting = true 20:22 hmmmm hmmm 20:23 RealBadAngel RealBadAngel 20:23 RealBadAngel lol 20:23 VanessaE heh 20:23 hmmmm if somebody codes a mod that uses nodes from a particular group, but it turns up with no nodes for that group, would you consider that a name resolution error? 20:23 Sokomine i've wished for some time for a less strictly boxy appearance of nodeboxes. there are some situations where slopes are very popular (roofs, hills). the raillike drawtype is not a solution in most cases either 20:24 hmmmm i think nodeboxes are of the devil. horrible dumb and retarded. it should've been meshes all along. 20:24 hmmmm furthermore, nodebox support should be COMPLETELY DROPPED from the engine, and instead a little shim should be added to convert nodeboxes to meshes 20:24 VanessaE hmmmm: NOOOOOOOO 20:24 VanessaE oh wait 20:25 RealBadAngel hmmmm, agree 100% 20:25 kaeza hmmmm, I'd say no. make the relevant functions simply ignore the group, or return an error indicator 20:25 VanessaE actually, RBA aren't you doing just about the same thing? 20:25 kaeza (re: groups) 20:25 RealBadAngel but with given a bit time to do so 20:25 hmmmm kaeza, that's what I was thinking 20:25 RealBadAngel folks will just realize that nodeboxes are not worth the time 20:25 hmmmm kaeza, this is printing out to errorstream about nodes that couldn't get resolved 20:26 Calinou Sokomine, ideally we'd have full resource packs, to replace textures, models and sounds 20:26 Calinou like Minecraft 20:26 VanessaE hmmmm: c55 wanted to keep the cubical style, that's why he went with nodeboxes. he even threatened to remove them if they were to be too heavily abused into making non-cubic things 20:26 hmmmm I'm thinking of situations where somebody registers a node to get matched up with something else 20:26 Sokomine hmmmm: the way you describe the mod, it might as well be a tool/machine/whatever which can do something with nodes from a special group but does not ship with any such nodes? it would then pretty useless if no other mod is installed that supplies suitable nodes, but apart from that, there's not much harm done. or did i misundersand? 20:26 Calinou Sokomine, the upside of using models is that you use triangles, not cuboids 20:26 Calinou higher performance even for simple stuff 20:26 Calinou no useless faces or duplicate vertices 20:26 hmmmm bit of a political statement here, but I think the game should be defined by the game creator 20:26 hmmmm not celeron 8) 20:27 Calinou VanessaE, there's way too much abuse of them too 20:27 Calinou meshnodes are a potential fix 20:27 RealBadAngel Calinou, everything on the GPU side is a triangle 20:27 Calinou RealBadAngel, I know 20:27 kaeza VanessaE, I think the thing here is again, letting the subgame dev having the option to use non-voxels 20:27 VanessaE oh don't get me wrong, meshes are absolutely a good idea 20:27 kaeza key word: option 20:27 Calinou nodeboxes will be available for some time anyway 20:27 RealBadAngel kaeza, freedom to own the gun does not mean you have to shoot down everybody out there 20:27 VanessaE but we can't remove nodebox support. WAY too late now 20:28 kaeza RealBadAngel, exactly 20:28 Calinou VanessaE, it may go away after a year or so 20:28 Calinou I wouldn't be surprised 20:28 hmmmm Sokomine: what I'm doing is unifying the node resolving code for all my mapgen-related things that take a node name from lua on mod load, and then uses it to either place or search for 20:28 Sokomine calinou: that's a very big upside 20:28 hmmmm so there are 5 different categories of such things 20:28 VanessaE Calinou: then a tool is needed to convert existing nodebox models into mesh models. 20:28 RealBadAngel no need to 20:28 Calinou or considered depreciated (like minetest.env) 20:28 RealBadAngel code will do that 20:28 Calinou can animated textures be used on meshnodes? 20:29 hmmmm internal mapgen, biomes, decorations, ores, and schematics 20:29 Calinou I don't think you can use animated textures on entity meshes currently 20:29 Calinou VanessaE, NBE export to .obj? :P 20:29 RealBadAngel Calinou, no 20:29 Calinou or .x 20:29 VanessaE minetest.env is just a sed/// operation away from translating. nodeboxes need a dedicated tool to convert them to meshes if they were to be dropped. 20:29 VanessaE Calinou: NBE can't import a nodebox :P 20:29 Calinou minetest.env still works today 20:29 Calinou when was it deprecated? 20:29 RealBadAngel animated ones will have to be treated in a very special way 20:29 RealBadAngel separated from static mapblock mesh node 20:30 Calinou I said textures 20:30 RealBadAngel gathered in a list propably and added to the scene on refresh 20:30 RealBadAngel that means the same 20:30 Sokomine hmmmm: i don't yet understand entirely what you're after, but you're generally doing a very good job 20:30 RealBadAngel model textures are quite different 20:30 hmmmm erm 20:30 RealBadAngel you could propably switch them 20:31 RealBadAngel but uv definition will remain there 20:32 Sokomine hmmmm: place or search for...don't think you mean get_content_id/get_name_by_content_id? that has turned up to be required pretty often when i was adjusting the landscape for the villages. those are probably relatively fast functions not to worry about too much? 20:32 hmmmm I mean when you're registering an ore for example 20:32 hmmmm there's place_in 20:32 hmmmm right now place_in just takes a specific node name 20:33 Calinou RealBadAngel, have you tried adding yaw interpolation to entities/players? 20:33 Sokomine hmmmm: what could need improvement is vanessae's plantslib. it is so universal that i have no idea how it could be optimized - except by making parts less universal and thus much faster 20:33 hmmmm what this would do is add the ability to make it either a single string, or a table containing multiple strings 20:33 Calinou currently we only interpolate position, not angles 20:33 hmmmm and the strings may be groups now 20:33 hmmmm so you could have like 20:33 Calinou celeron said it would be very easy 20:33 Calinou just a class edit 20:33 hmmmm place_in = "group:soil" 20:33 Calinou in content_cao.cpp IIRC 20:33 hmmmm or maybe place_in = {"default:stone", "default:desert_stone", "group:sand"} 20:33 hmmmm or something like that 20:35 RealBadAngel Calinou, i havent touched entities so far, but i have adapted some code used by them for nodes 20:35 Sokomine hmmmm: ah! that sounds well 20:35 hmmmm so if you register an ore that has place_in = "group:soil", for example, but group:soil turns up 0 results, would that not be a resolution error? 20:35 Sokomine hmmmm: you might print an error in that case. but i'd say the conditions the mod requires are just not met - thus no nodes placed 20:36 hmmmm where on the other hand if you have 20:36 hmmmm place_in = {"default:water_source", "group:soil"} for example 20:36 RealBadAngel Calinou, and one more thing, all the falling nodes/waving things gonna be made software side, without shaders or entities 20:36 hmmmm if it can't resolve default:water_source, that would be an error 20:36 RealBadAngel just by playing with vertices 20:37 kaeza hmmmm, oh, I thought you meant "error" more like "raise an exception" 20:37 Sokomine hmmmm: and if you ignore nodes that don't exist? if there's nothing left where that ore wants to be placed, then it can't get placed. an error message might be helpful, but only if it doesn't cost too much to implement. most people won't find it in their debug.txt anyway 20:38 kaeza then yes, issuing an error message would be best I think 20:40 hmmmm hmm 20:42 Calinou RealBadAngel, hmm, currently we're using shaders for waves? can you use waves without shaders? 20:42 RealBadAngel yes i can now 20:42 RealBadAngel same for falling sand or waving plants 20:43 RealBadAngel they turned out to be simple playing with vertices 20:44 RealBadAngel no need to bother GPU with such irrevelant shit 20:45 Sokomine regarding nodeboxes/meshes: somebody mentioned that the collusion box is also an issue. for nodes, a simplified and independent collusion box might be sufficient 20:46 RealBadAngel Sokomine, that is not a problem 20:46 RealBadAngel irrlicht have methods to get proper bounding box 20:46 RealBadAngel have you thought we are pioneers or what? 20:46 RealBadAngel just rtfm ;) 20:48 Sokomine no :-) just not much experience with graphic engines. good to hear that that's also been taken into consideration :-) 20:49 RealBadAngel http://irrlicht.sourceforge.net/docu/structirr_1_1scene_1_1_s_mesh.html#a7a16bc83094ab242ae779baf817dc7f9 20:49 RealBadAngel that will calculate bounding box for your mesh 20:53 ShadowNinja hmmmm: I don't think it should be an error. You may have, eg, an ABM that works on nodes from another mod to better integrate the functions of the two mods if the other mod is installed. On the other hand you could just wrap in in a `if minetest.get_modpath("othermod") then ... end`. 21:20 kahrl so meshes can be redefined by texture packs and collision boxes are calculated from meshes? 21:21 kahrl oh, also: how do you calculate the collision on an irrlicht-free server? (for entity physics) 21:21 kahrl collision box* 21:23 iqualfragile how do you even calculate collision at all? if you are not using the exact edges of the model this is a hard thing to do automatically iirc 21:24 kahrl iqualfragile: well the method that RBA linked to calculates the smallest axis-aligned box that contains all vertices of the mesh 21:24 iqualfragile oh, well, that is a way 21:25 kahrl it would be if the server was running irrlicht 21:25 iqualfragile not good for general meshes, but as minetest is blockbased anyways it should be sufficient 21:25 kahrl so I'd say the collision box should be simply read from the nodedef in nodebox format like it is now 21:26 kahrl (in particular the default collision box would be a full node) 21:28 iqualfragile why does that depend on irrlicht? 21:29 kahrl you can't even read a mesh file without irrlicht 21:29 kahrl well, unless you reimplement the whole parser 21:54 RealBadAngel kahrl, collision boxes are recalculated on the meshes 21:54 RealBadAngel exact bounding box is get 21:55 RealBadAngel for highlighting i choose the model itself, a bit bigger to create halo effect 21:57 RealBadAngel iqualfragile, you seem to forget whats native here 21:57 RealBadAngel meshes are 21:57 RealBadAngel nodeboxes are alien body 21:58 RealBadAngel mt is built on top of irrlicht 21:58 iqualfragile RealBadAngel: for irrlicht and rendering: yes 21:58 iqualfragile for collision: boxes are easier then meshes 21:58 RealBadAngel no 21:58 RealBadAngel you are wrong to the bone 21:59 RealBadAngel nodeboxes are weird implementation of meshes 22:00 RealBadAngel that what you think is natural there is just a side effect 22:01 hmmmm wondering if I should make NodeResolver part of INodeDefManager or put it in IGameDef on its own 22:01 RealBadAngel for me as a modder took quite a while to understand the nodeboxes, how they work 22:02 RealBadAngel and at the very end it turned out to be a complete weird 22:02 RealBadAngel idk what c55 thought while creating the system 22:02 RealBadAngel but definitely he was on high 22:02 jin_xi i think its nice to be able to make boxy models 22:03 RealBadAngel you can do the same with meshes 22:03 RealBadAngel more easily 22:03 jin_xi but you need an editor and all. for me its more easy to do simple nodebox by hand 22:03 RealBadAngel you think its easy? 22:04 VanessaE it is. 22:04 jin_xi its not too bad 22:04 RealBadAngel its a piece of bloody shit 22:04 VanessaE I can code a nodebox by hand in less time than it takes to even launch blender. 22:05 RealBadAngel yes yes 22:05 RealBadAngel and you remember the times? 22:05 RealBadAngel we were sitting there for weeks trying to get easier shapes working 22:06 jin_xi i'm all for converting nodeboxes to meshes for internal use but i think the format has its place. its boxes, plain and simple. 22:06 RealBadAngel and i dont know even english translation for words i used 22:07 RealBadAngel its not plain, its not simple, its not fast 22:07 RealBadAngel its a cancer 22:07 iqualfragile RealBadAngel: not fast to render, but relatively fast to write 22:07 RealBadAngel faster is to learn blender than nb 22:08 iqualfragile i don't think so, additonally with blender you have to make sure that the scale is right 22:08 iqualfragile but thats just a secondary concern 22:08 RealBadAngel or use visual_scale factor 22:08 RealBadAngel yes it is 22:08 RealBadAngel but its not blender just 22:09 RealBadAngel irrlicht does support most of them 22:09 RealBadAngel name the one 22:09 iqualfragile model formats? 22:10 RealBadAngel mesh drawtype means you can use all of them 22:10 iqualfragile yes, obviously 22:11 iqualfragile we could ask rubenwardy to update his nodebox editor to output some simple model format 22:11 kahrl RealBadAngel: did you read what I wrote? 22:11 RealBadAngel kahrl, about collision boxes? 22:11 kahrl kahrl, collision boxes are recalculated on the meshes <-- no, they are not, because the server does not read the meshes 22:12 RealBadAngel hmmm 22:12 RealBadAngel thats an issue then 22:12 iqualfragile does the server even need to know? 22:13 RealBadAngel should have 22:13 RealBadAngel for the boxes 22:13 iqualfragile at least for projectiles 22:13 RealBadAngel ok, mesh is loaded while in nodedef.cpp 22:14 RealBadAngel i will just update defs with proper collison boxes there 22:14 kahrl if it didn't, we'd have items sitting 0.5 nodes above slabs again (like a bug in the early days of nodeboxes) 22:14 kahrl I mean if the server simply used the full node as collision box 22:15 RealBadAngel if not given then yes 22:15 RealBadAngel fallback 22:15 RealBadAngel but should be defined or got from mesh itself 22:15 RealBadAngel note that mesh can be way bigger than regular node 22:16 kahrl I think the collision box should just be read from node_box and not calculated 22:17 RealBadAngel it will fail with flowers etc 22:17 kahrl how? 22:17 RealBadAngel since when a flower is a box? 22:17 RealBadAngel you want to collide with two planes? 22:17 kahrl flowers aren't even walkable so it doesn't matter 22:18 kahrl also when did I say it should use the rendered geometry as collision boxes? 22:18 RealBadAngel imho modders supplied collison box in the first place, then mesh, then default 22:19 kahrl I'd say the same thing except "then mesh" 22:19 RealBadAngel no you wouldnt 22:19 kahrl force the modder to supply proper collision information so it will work on server and client 22:20 RealBadAngel you have seen models with visual factor 15.0 22:20 RealBadAngel for that bounding boxes would be overkill 22:20 kahrl well that's just dumb abuse anyway 22:20 RealBadAngel abuse but showing the problem 22:20 kahrl nodes are 1x1x1 large and not 15x15x15 22:22 RealBadAngel http://i.imgur.com/eKgfuns.png 22:22 kahrl also in that case the modder could just supply a 15x15x15 bounding box (even though I assume there will be glitches with that) 22:22 RealBadAngel think about collision boxes for those blue crystals 22:23 RealBadAngel models are the same for all 22:23 RealBadAngel just textures and visual size is different 22:23 kahrl boxes are not the proper way to do collision for those things 22:23 ShadowNinja kahrl: The server already depends on Irrlicht. 22:23 kahrl huh, since when? 22:24 ShadowNinja At least for types, eg v3s32. 22:24 ShadowNinja Since forever AFAIK. 22:24 kahrl ok, but not the library 22:25 ShadowNinja I don't know how heavily it depends on it, but we already depend on it so depending on it for a feature isn't such a big issue. 22:25 kahrl the server doesn't create an irrlicht device 22:25 kahrl (which would be required to load meshes) 22:28 kahrl also the server is kinda lightweight right now (at least compared to the client and to minecraftserver.jar) 22:29 kahrl it wouldn't be anymore if it created an irrlicht device and loaded all the meshes to memory 22:29 RealBadAngel yeah, especially with smooth lighting ;) 22:30 RealBadAngel thats a specialized killer stuff 22:30 RealBadAngel server calculating lights for each client out there 22:30 kahrl RealBadAngel: getSmoothLight is a client function. 22:31 RealBadAngel smooth yes 22:31 kahrl if you work on mapblock_mesh a lot you should know that :P 22:32 RealBadAngel but all the other light code is a mess 22:33 RealBadAngel what i say, ALL the lights are a mess 22:33 kahrl tbh you can take any minetest part X and say X is a mess 22:33 kahrl :P 22:34 RealBadAngel the code is so spreaded around that it is almost impossible to find out what its doing 22:35 RealBadAngel see the attempts to properly smooth light the nodeboxes 22:35 RealBadAngel darkrose tried to do that 22:36 kahrl should be mostly a matter of calling getSmoothLight in the drawtype code in content_mapblock 22:36 ShadowNinja I'll push this in a minute: http://sprunge.us/Ydgd?diff 22:36 RealBadAngel no 22:36 kahrl the tough part is what to do with vertices in the middle 22:37 ShadowNinja (Some functions push to the main thread rather than the current thread) 22:37 RealBadAngel calling that wouldnt help at all 22:37 ShadowNinja kahrl: Can you check that? 22:37 RealBadAngel i had to get all the nodes around to get proper light level at node for highlighting 22:38 RealBadAngel that gone just too far, its messy, not easy to modify 22:38 ShadowNinja kahrl: Fixes https://github.com/minetest/minetest/issues/1709 22:39 RealBadAngel and primarily hard to understand why not hardware lights were not used 22:39 RealBadAngel propably just to make things harder 22:40 RealBadAngel if getting proper and coloured lightigting to the scene is as hard as 2 lines of code 22:40 RealBadAngel the approach we are using cannot be called another way as masochism 22:40 kahrl ShadowNinja: what about other functions that use getStack()? 22:41 kahrl RealBadAngel: what are those 2 lines? 22:41 ShadowNinja kahrl: Do you know of any others that use it and are called from Lua functions? 22:41 RealBadAngel http://i.imgur.com/wHjL1dJ.png 22:42 RealBadAngel kahrl, here i added just 3 lights, of different colours 22:42 kahrl ShadowNinja: every function with SCRIPTAPI_PRECHECKHEADER uses it 22:43 kahrl that's 58, I don't know them all 22:43 RealBadAngel no modifications to our code, expect of enabling the lights 22:43 kahrl s/58/60 22:44 kahrl RealBadAngel: I mean without cheating 22:44 RealBadAngel cheating? i just used add light scene node 22:44 kahrl show me code that displays light_sources nodes with hardware lights 22:45 kahrl RealBadAngel: yeah, too bad we can't just hardcode the location of 3 lights and be done... people will place torches and want them to create light 22:46 RealBadAngel http://irrlicht3d.org/wiki/index.php?n=Main.HowToUseLightsAndMaterials 22:46 RealBadAngel thats general 22:46 RealBadAngel and here you go for the torches: http://irrlicht.sourceforge.net/docu/example020.html 22:47 kahrl still a limit of 8 lights per scene node 22:47 kahrl that's not enough 22:48 RealBadAngel read the second 22:48 kahrl I did 22:48 RealBadAngel it the solution to that 22:48 kahrl I mean even if we make each mapblock a different scene node, 8 is not enough 22:48 RealBadAngel Written by Colin MacDonald. This tutorial explains the use of the Light Manager of Irrlicht. It enables the use of more dynamic light sources than the actual hardware supports. Further applications of the Light Manager, such as per scene node callbacks, are left out for simplicity of the example. 22:48 jin_xi ...You are still limited to 8 lights, but the limit is per scene node. 22:49 RealBadAngel It enables the use of more dynamic light sources than the actual hardware supports 22:49 kahrl what jin_xi said 22:49 RealBadAngel theres no limit 22:50 kahrl can you read? the tutorial clearly says there is a limit 22:50 RealBadAngel http://irrlicht.sourceforge.net/docu/020shot.jpg 22:50 RealBadAngel cant you read? 22:50 RealBadAngel the tutorial is about how to get more than a limit 22:51 kahrl ok, I will repeat it again 22:51 kahrl "You are still limited to 8 lights, but the limit is per scene node." 22:51 jin_xi so im guessing we only have one scene node atm? 22:51 kahrl yes 22:52 kahrl for the map, anyway (objects have their own scene nodes) 22:53 kahrl it could be split so that each mapblock is a scene node; anything finer would be a performance killer 22:54 RealBadAngel i think you shoul read the text bout lights 22:54 RealBadAngel 8 lights yes, but the code can find 8 nearest ones 22:55 kahrl a typical mapblock with buildings in it contains a lot more than 8 lights 22:55 RealBadAngel ofc 22:56 RealBadAngel but you seems to forget bout one thing 22:56 jin_xi idk how its gonna look but 8 lights per block sounds like a limit you're gonna hit. maybe it still looks good with enough light around 22:56 RealBadAngel this is per point 22:56 RealBadAngel so each point being rendered will get 8 lights 22:56 kahrl wut 22:57 kahrl the tutorial clearly says it is per scene node 22:57 kahrl also I've read the code and it says the same thing 22:57 RealBadAngel either you or i cant read english ;) 22:57 RealBadAngel The 8 lights nearest to the camera will be turned on, and other lights will be turned off. 22:58 kahrl that's NO_MANAGEMENT mode and it uses the same set of lights for everything in the whole scene 22:58 kahrl not something you'd want to use 22:58 RealBadAngel ok 22:58 RealBadAngel then lets go another way 22:59 RealBadAngel single hardware light 22:59 RealBadAngel the sun/moon 22:59 kahrl yeah, that'd work, but you can't get rid of the ugly code :P 22:59 RealBadAngel we can 23:00 RealBadAngel we can remove smooth shading code 23:00 kahrl how? 23:00 RealBadAngel the directional light will do that for us 23:00 kahrl then smooth lighting will only work above ground 23:00 RealBadAngel since when sun shines underground irl? 23:01 RealBadAngel :) 23:01 kahrl exactly; it doesn't 23:01 kahrl so there will be no smooth lighting in caves 23:01 RealBadAngel but we do have a flag 23:01 RealBadAngel we can pretend its here 23:01 kahrl ? 23:02 RealBadAngel we can easily determine if sun is present on the scene 23:02 RealBadAngel right? 23:02 kahrl and then? 23:02 RealBadAngel if it isnt we can use another lighting model 23:03 kahrl so you'd like to rebuild all meshes when the sun toggles in and out of view? 23:03 RealBadAngel noooo 23:03 RealBadAngel why to do so? 23:03 kahrl I thought that's what you meant 23:04 RealBadAngel i mean turn off directional light source (the sun) 23:04 RealBadAngel and operate just on vertices colours as till now 23:04 kahrl how do you operate on them without rebuilding the meshes? 23:05 RealBadAngel we dont care bout meshes 23:05 RealBadAngel we care bout vertices 23:06 kahrl explain 23:06 RealBadAngel even our system doesnt need rebuilding for the lights to work 23:06 kahrl you mean the daylight cycle? 23:07 kahrl yeah but we don't switch lighting models suddenly 23:07 RealBadAngel http://i.imgur.com/b3usu4B.png 23:08 RealBadAngel this is achieved with placing single light node with radius 100.0 23:08 RealBadAngel in the middle of the scene 23:08 kahrl I think the lighting we have looks a lot more natural than that screenshot 23:08 RealBadAngel this was a mini sun ;) 23:08 kahrl the nodes in the screenshot are kinda glossy, too 23:08 kahrl ok 23:08 RealBadAngel http://i.imgur.com/T8wf2tp.png 23:09 RealBadAngel this one is a bit bigger 23:09 kahrl again the same thing; the whole scene looks slightly metallic 23:09 RealBadAngel because of shadows 23:09 kahrl or s/slightly// in the desert region 23:09 VanessaE kahrl: I think that's just because of where the light is placed 23:10 RealBadAngel you can clearly see where the light source is 23:10 RealBadAngel theres distance to it shown on the screen 23:11 RealBadAngel raise it, move, and you will get perfect daylight 23:11 RealBadAngel change its colour to get moonlight 23:11 VanessaE RealBadAngel: I still wanna know how you will handle e.g a field with dozens of visible torches 23:12 RealBadAngel the torches can be handled in two ways 23:12 RealBadAngel one could be vertex lighting the same code as we are using now 23:13 RealBadAngel or limiting the visible sources at the vertex to 8 nearest ones 23:13 RealBadAngel as in the example 23:13 kahrl the first one would work 23:14 RealBadAngel the second too 23:14 kahrl the second one not, because you can't make each vertex its own scene node 23:14 RealBadAngel i can limit them by vertex 23:14 RealBadAngel think of node, our node 23:14 kahrl I will only believe you if you upload that code 23:15 RealBadAngel 8 sources is almost all around covered with lightsources 23:16 kahrl every mapnode a scene node? uh... nope 23:16 RealBadAngel and a vertex is just 1/24th of a node 23:16 RealBadAngel its way more than needed 23:16 jin_xi and one scenenode per 8 torches? not possible? 23:17 RealBadAngel well 23:17 RealBadAngel animated mesh nodes will become individual scene nodes on the other hand 23:17 RealBadAngel so why not the lights as well? 23:18 RealBadAngel but still i think that hybrid approach will be the best 23:19 kahrl animated mesh nodes will become individual scene nodes on the other hand <-- which is why you don't want too many of them visible at once 23:20 kahrl if lights are the same, navigating caves with large deep lava lakes will be fun 23:20 RealBadAngel animated ones cannot be combined 23:20 RealBadAngel thats why 23:20 RealBadAngel so have to be separate nodes 23:21 RealBadAngel kahrl i see such nodes treated in a very special way 23:22 RealBadAngel added and removed from scene together with whole mapblock mesh 23:22 RealBadAngel just based on a separate list 23:22 RealBadAngel that shouldnt be much of a problem 23:24 kahrl might be ok (but I haven't benchmarked how well irrlicht copes with a large number of scene nodes; one might have to use octrees or something like that) 23:25 kahrl btw, something else about lava (not performance related for once) 23:25 kahrl look at this screenshot: http://i1139.photobucket.com/albums/n542/x_death1/lava.jpg 23:25 kahrl how would the lava light the top face of the nodes above it? 23:26 RealBadAngel idk 23:26 RealBadAngel ask the allmighty c55 ;) 23:26 kahrl yeah, hardware lights are very poor at global illumination 23:27 shadowzone He is AFK all the time it seems. 23:27 kahrl the voxel based light isn't great at it but it's at least decent 23:28 RealBadAngel voxel based one should be a node property just 23:28 RealBadAngel and i will make the engine lit it all properly 23:28 proller irrlicht octree too slow 23:28 shadowzone Why isn't celeron55_ not voiced? 23:29 kahrl shadowzone: every dev is voiced 23:29 shadowzone Oh. 23:30 kahrl oh, you mean why he isn't voiced? 23:30 kahrl idk 23:30 RealBadAngel propably wrong nick 23:31 kahrl yeah sounds right 23:31 RealBadAngel the clients choose fallback nicks on reconnect 23:31 RealBadAngel not the registered ones propably 23:31 kahrl isn't it based on registrations? 23:32 kahrl not that it really matters though 23:32 RealBadAngel in my case i do have one nick registered 23:33 RealBadAngel if it fails to rejoin (old one is still here due to lag) client choose another 23:33 RealBadAngel which is not registered 23:33 RealBadAngel so i wont be voiced then 23:34 RealBadAngel so c55 should just awake and go back for original nick 23:44 kahrl RealBadAngel: I think I misunderstood you. Did you mean the top faces shouldn't be lit at all? (assuming the torch wasn't there) 23:46 RealBadAngel im not sure, maybe light level for the node should be a light on top of it? 23:46 RealBadAngel and same for interior 23:48 RealBadAngel thats the problem with current lighting 23:49 RealBadAngel damn slow, faulty and looking bad 23:50 RealBadAngel why the heck we are staying with it? 23:52 kahrl sorry you lost me 23:52 kahrl what thing were you talking about right now that looks bad 23:55 kahrl in fact I feel we've been talking at cross purposes so often that we should quit this conversation