Minetest logo

IRC log for #minetest-dev, 2014-10-03

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
01:27 shadowzone joined #minetest-dev
01:32 GrimKriegor joined #minetest-dev
02:03 Zeno` joined #minetest-dev
02:58 hmmmm jjeez
02:59 hmmmm I'm just making braindead simple style changes in nodedef.cpp and all of a sudden those 100+ column lines are fixing themselves
03:00 hmmmm I mean stuff like TileSpec *stile = &f->special_tiles[tile_index]; and then s/f->special_tiles[j]./stile->/
03:02 rickmcfarley joined #minetest-dev
03:06 hmmmm this is a lot more time intensive than i thought it was
03:07 hmmmm and all this is just so i can start work on the resolveNodeNames() improvement in a state of sanity
03:40 Miner_48er joined #minetest-dev
03:45 Hunterz joined #minetest-dev
03:46 chchjesus__ joined #minetest-dev
03:47 Hunterz1 joined #minetest-dev
05:27 mos_basik joined #minetest-dev
05:46 proller joined #minetest-dev
05:49 Hunterz joined #minetest-dev
05:53 NakedFury joined #minetest-dev
06:08 hmmmm guys
06:08 hmmmm when you're doing switch fallthrough, could you ACTUALLY FUCKING COMMENT THE SWITCH FALLTHROUGH
06:09 hmmmm look, i do it
06:09 hmmmm /* FALLTHROUGH */
06:09 hmmmm https://github.com/minetest/minetes​t/blob/master/src/nodedef.cpp#L705
06:10 hmmmm oh, git blame says TriBlade did that... I guess it's understandable because he's new, but come on guys, isn't it common sense?
06:12 Zeno` I would say it's common sense
06:12 Zeno` unless it's like lines 706-710 of course
06:14 Zeno` I may not have even used fallthrough there though
06:14 Zeno` I don't think repeating f->solidness = 0; break; would have been that much of an issue heh
06:15 hmmmm I am pretty sure that's intended but I wouldn't know for certain unless I actually loaded minetest up and verified that it doesn't work if I were to add a break
06:15 hmmmm https://github.com/minetest/minetest/b​lob/master/src/util/serialize.cpp#L252
06:15 Zeno` Well that's why the comment is always necessary
06:15 hmmmm I've seen some pretty dumb mistakes go into minetest
06:15 Zeno` otherwise you don't know if the person simply forgot (happens) or they intended it
06:15 hmmmm this is my favorite (thanks RBA):  if (enable_shaders); {  ...
06:16 Zeno` :)
06:20 Zeno` maybe he meant it
06:34 RealBadAngel nobodys perfect hmm
06:34 hmmmm speaking of which
06:35 hmmmm are you actually nevermind
06:35 RealBadAngel i did play it and i loved it
06:35 hmmmm I just condensed a lot of bloaty, repetitive code in nodedef.cpp
06:35 RealBadAngel do you remember?
06:36 RealBadAngel most lovely rpg game out there imho
06:37 chchjesus joined #minetest-dev
06:38 RealBadAngel hmmm can i see the results?
06:46 Zeno` well, when you look at the push I did yesterday just remember you said to do it the ugly way for now hehehe
06:47 kaeza joined #minetest-dev
06:52 hmmmm special tiles can't use their own special shaders?
07:07 Zeno` https://github.com/minetest/minetest/pull/1711 <-- parse.h. What's the minetest "style" recommendation for including includes like that?
07:08 Zeno` Seems overkill to me, but I am still not fully tuned with the minetest way
07:08 Wayward_One joined #minetest-dev
07:10 hmmmm maybe it should go into util/string.cpp
07:11 hmmmm I have stuff like read_seed() and the flag string parsing in there
07:11 hmmmm also I would revise the flow of parseColorString()
07:12 hmmmm instead of if (thing) { /* ungodly huge if block with nothing underneath it */
07:12 Zeno` probably yes. He seems to have copy pasted it "as is" from it's original location
07:12 hmmmm howabout
07:12 hmmmm if (!thing) {
07:12 hmmmm do stuff that was underneath that huge block
07:12 hmmmm return;
07:12 hmmmm }
07:12 Zeno` Well, that's how I'd do it but it's not my PR :D
07:12 hmmmm i'll comment on it
07:12 Zeno` thank you
07:12 Zeno` sounds better coming from you
07:13 Zeno` also, I know it's pedantic, but: newlines at EOL
07:13 Zeno` EOF*
07:14 hmmmm yes
07:15 hmmmm oh boy
07:15 hmmmm there was a nodedef.cpp modification yesterday
07:15 hmmmm I'm gonna have lots of fun merging these
07:18 chchjesus joined #minetest-dev
07:21 alexxs joined #minetest-dev
07:23 hmmmm https://github.com/kwolekr/minetest/commit​/01ce57ade534f83d80bbb1f0c48630891b338237
07:25 hmmmm RealBadAngel, https://github.com/kwolekr/minetes​t/blob/master/src/nodedef.cpp#L798
07:26 hmmmm there was literally nothing different between those two huge hunks of code aside from the tile and tiledef it's reading from.  prime candidate for refactoring
08:02 ImQ009 joined #minetest-dev
08:08 BlockMen joined #minetest-dev
08:19 jin_xi joined #minetest-dev
08:21 alexxss joined #minetest-dev
08:21 alexxss joined #minetest-dev
08:30 PenguinDad joined #minetest-dev
08:33 sfan5 ShadowNinja: ping
08:33 Zeno` hmmm when you're finished styling can you check #1707?
09:12 Amaz joined #minetest-dev
09:29 Zeno` My PRs don't even get tags anymore ROFLOL
09:30 BlockMen sfan5, fine with https://github.com/BlockMen/minetest_game/com​mit/56cc4191ca4ce238f724805a3b180d0f3586fdf0 ?
09:30 sfan5 BlockMen: yep
09:31 Zeno` I'm not. See last comment
09:31 Zeno` it's not standard C++
09:31 Zeno` oh that one. sorry
09:31 BlockMen lel
09:32 Zeno` hey. it's 7:30PM (late!)
09:33 alexxss joined #minetest-dev
09:33 restcoser joined #minetest-dev
09:35 BlockMen Zeno`, it seems you commented on outdated code. there are no newlines missing.
09:38 Zeno` I did? I refreshed, but if that's the case then cool :)
09:38 Zeno` I'll edit the comment
09:41 Zeno` ok
09:42 Zeno` BlockMen, I like it by the way
09:42 Zeno` Seems like a good addition
09:43 BlockMen Zeno`, if not it should go in ;)
09:43 Zeno` So... if I don't like it it will go in? I don't like it then
09:43 Zeno` lol
09:45 BlockMen the other part
09:45 BlockMen "good addition"
09:45 BlockMen not "I like" ;P
09:45 Zeno` oh. yes
09:47 BlockMen and since you wanted labels, you pull has no two
09:47 BlockMen +w
09:48 Zeno` what's the reasoning behind video::SColor outcolor(255, 255, 255, 255);
09:49 Zeno` I don't think it's low priority :p
09:49 Hunterz is possible using mod change texture of digged node for player who only observe?
09:49 Zeno` lol
09:49 Zeno` I can't even play the game without the fix
09:50 Hunterz now only player who dig node see changing texture
09:50 BlockMen Zeno`, low priority since most did not agree here on IRC on you thoughts on it
09:50 Zeno` Shadowzone, hmmmm and VanessaE did
09:51 BlockMen Hunterz, i dont think that you can do that
09:51 Hunterz when dig stone see changes on stone
09:51 Hunterz breaking
09:51 Zeno` see: https://github.com/minetest/minetest/pull/1704
09:51 Hunterz others players neear see nothing changed
09:51 Zeno` which is broken and closed
09:52 Zeno` ShadowNinja*
09:52 Hunterz digging effect or something
09:52 BlockMen Zeno`, ask someone else to make it high prio. for me its not
09:54 BlockMen Hunterz, no, not supported currently.
09:54 Hunterz ok, thanks
09:54 Zeno` BlockMen, I didn't realise you were most players :)
09:55 BlockMen Zeno`, never said or claimed to be ;)
09:58 Zeno` BlockMen, https://github.com/minetest/minetest/pull/1661
09:59 Zeno` notice that the description is kind of wrong...
10:00 Zeno` and it swaps items without warning
10:00 Zeno` it's broken
10:03 BlockMen Zeno`, i wont touch it now, sry
10:13 proller joined #minetest-dev
10:19 edlothiol joined #minetest-dev
11:20 PilzAdam joined #minetest-dev
11:21 ImQ009 joined #minetest-dev
11:26 ImQ009 joined #minetest-dev
11:54 kaeza joined #minetest-dev
12:26 BlockMen can https://github.com/minetest/minetest/pull/1635 get closed?
12:44 Hunterz im trying compile minetest with no bundled lua and get this error during linking: CMakeFiles/minetestserver.dir​/script/cpp_api/s_base.cpp.o: In function `ScriptApiBase::ScriptApiBase()':
12:44 Hunterz s_base.cpp:(.text+0x122): undefined reference to `luaJIT_setmode'
12:44 Hunterz anyone can help?
12:46 shadowzone joined #minetest-dev
12:46 shadowzone joined #minetest-dev
12:50 alexxsss joined #minetest-dev
13:09 PilzAdam BlockMen, I guess yes
13:36 AnotherBrick joined #minetest-dev
13:39 ImQ009 joined #minetest-dev
14:29 hmmmm ahh good catch RBA
14:29 hmmmm thank you
14:30 hmmmm except that doesn't actually fix it.  special tiledefs are broken now
14:32 hmmmm RealBadAngel:  why is it that f->tiledef_special[j].backface_culling is used for special nodes, but f->tiledef[j].backface_culling isn't??
14:51 RealBadAngel back face culling is modified on the fly
14:51 RealBadAngel it isnt hardcoded in def
14:51 RealBadAngel gbrb
14:52 RealBadAngel *brb
14:54 RealBadAngel joined #minetest-dev
14:55 RealBadAngel sorry had to reboot
14:55 RealBadAngel open source video drivers suck big time
14:55 RealBadAngel half frame rate and hangs all the time
14:56 RealBadAngel hmmmm, i think we shall make this consistent
14:57 RealBadAngel that can be really confusing
14:57 hmmmm wait huh
14:57 RealBadAngel content feature is modified on the fly
14:57 hmmmm but why isn't that modification copied over to the tiledef
14:58 RealBadAngel ^^
14:58 RealBadAngel its based on def but not strict
14:58 RealBadAngel thus cannot be used to define the material
14:59 RealBadAngel too many things can modify it
14:59 RealBadAngel like opaque water/waving leaves etc
15:00 proller joined #minetest-dev
15:03 Anchakor joined #minetest-dev
15:05 RealBadAngel why you think that special tiles are broken?
15:11 hmmmm i don't think they're broken, i just don't understand why the special tile filling is different from the regular tile filling
15:12 RealBadAngel special tiles are kinda hacky
15:12 RealBadAngel thats not my code neihter
15:12 hmmmm whose is it??
15:13 RealBadAngel propably c55, but just guessing
15:13 hmmmm hmm
15:13 RealBadAngel i see different usage for special tiles
15:13 hmmmm so do you know if it's necessary to have the different backspace culling attribute for special tiles?
15:14 hmmmm see:  https://github.com/minetest/minetes​t/blob/5baf379f40537060a1d5111905c7​702d4563ee5c/src/nodedef.cpp#L795
15:14 RealBadAngel yes, special tiles imho should be an alternative
15:14 RealBadAngel but they need also alternative light source value to be really useable
15:15 RealBadAngel all the other code is already in
15:15 hmmmm RealBadAngel, by the way, do you realize there is a 80 column line size limit?
15:15 hmmmm it's preferred to stay under 80, but it's absolutely necessary to stay under 90
15:17 RealBadAngel sorry, where i exceeded that?
15:18 RealBadAngel sometimes its hard for me to notice that, im on wide screen
15:18 RealBadAngel 80 lines here is merely half a scren width
15:18 hmmmm yeah...
15:19 hmmmm most IDEs have a vertical line at 80 characters
15:19 hmmmm also perhaps you should start making better use of your horizontal space with a split screen view
15:19 BlockMen even notepad has :D
15:21 hmmmm https://github.com/minetest/minetest/commi​t/173beeee65289464d2541c44f753d21cd1fa3155
15:21 hmmmm I also switched the parameters around
15:22 zat joined #minetest-dev
15:24 selah joined #minetest-dev
15:26 shadowzone joined #minetest-dev
15:32 RealBadAngel hmmmm,  i think that will be wrong
15:32 RealBadAngel f->tiledef_special[j].backface_culling,
15:32 hmmmm no, no, that's what the code originally was before my cleanup commit
15:33 hmmmm it looks weird, doesn't it?
15:33 hmmmm that's why I inquired about it
15:33 RealBadAngel thats a mess indeed
15:34 RealBadAngel atm i have no idea how to make it cleaner
15:34 hmmmm well we don't know why f->tiledef_special[j].backspace_culling is needed
15:34 RealBadAngel not to mention i do have large portion of code that modifies it already
15:35 RealBadAngel i do have nearly completed drawtype mesh
15:35 RealBadAngel which does a few things just by the way
15:35 RealBadAngel one of them is massively speed up of nodeboxes code
15:36 hmmmm cool
15:37 RealBadAngel i just chosen to convert them into meshes
15:37 proller joined #minetest-dev
15:37 RealBadAngel and cache the possible rotations
15:37 RealBadAngel so the only thing that can change the mesh is the daynight cycle
15:42 iqualfragile joined #minetest-dev
15:43 BlockMen RealBadAngel, what do you mean with change in this context?
15:43 BlockMen the lighting?
15:44 Hunterz joined #minetest-dev
15:45 RealBadAngel BlockMen, not the lighting, turning nodeboxes into meshes at startup
15:45 RealBadAngel so theyre preconverted to drawtype mesh
15:49 BlockMen and how is that related to the daynight cycle?
15:50 RealBadAngel lighting is applying the vertex color
15:50 RealBadAngel to the mesh
15:52 Taoki[mobile] joined #minetest-dev
16:01 Megaf joined #minetest-dev
16:25 kaeza joined #minetest-dev
16:44 rubenwardy joined #minetest-dev
16:55 NakedFury joined #minetest-dev
17:00 BlockMen left #minetest-dev
17:11 gravgun joined #minetest-dev
17:12 gravgun Hi, has any work been already done to create a custom node rendering Lua API?
17:12 sfan5 no
17:13 gravgun I'm thinking of a node def format that could work
17:13 gravgun However I know calling custom Lua render functions 60 times a second is heavy...
17:14 sfan5 s/heavy/totally not a good idea/
17:14 gravgun sadly...
17:14 sfan5 without LuaJIT you don't even need to consider that idea
17:14 sfan5 even with it's still not a good idea
17:14 kaeza how about specifying draw commands, kinda like shaders or SVG? >_>
17:15 kaeza ...or WMF <_<
17:15 gravgun ewww WMF
17:15 gravgun but that'd require one more "language"+parser
17:16 sfan5 what you'd need if some kind of basic gfx language that can be compiled to machine code or something
17:16 gravgun or using somehow complicated def structures if the "shader" gets complex
17:16 gravgun Android RenderScript?
17:16 sfan5 whats that?
17:17 gravgun A rather high-level LLVM-compiled code that somehow gets translated to native CPU code + shader, used rarely in Android...
17:17 sfan5 does it do 3D?
17:18 gravgun Dunno, I've seen 2D particles examples in the Android SDK but that's all
17:18 sfan5 what we'd need is more like a language that can call irrlicht and is near native speed
17:19 sfan5 LLVM is not something we can use
17:19 sfan5 I don't think anyone wants to go through the troubles of compiling LLVM for windows
17:20 gravgun And isn't dynamically linking to CPP code way harder than C? Good luck with Irr then
17:20 sfan5 you could do a C -> C++ interface for the funcs needed
17:21 gravgun What comes to my mind then is tcc (Tiny C Compiler, by the same guy that wrote the Bochs emulator, very light and waaaaay faster than GCC)
17:22 gravgun Plus it can be embedded with libtcc...
17:22 gravgun But that may be a lil' out of scope of the Minetest project
17:23 gravgun (and some CPU architecture may be left behind as tcc geneates native code)
17:23 sfan5 e.g. ARM
17:24 gravgun IIRC tcc does have an ARM compiler
17:24 sfan5 what you need to support is i386, x86_64, ARMv6, ARMv7 and ARM64
17:24 sfan5 source: http://meow.minetest.net/tmp/se​rverlist_stats_2014-09-2014.txt
17:25 gravgun tcc's arm-gen.c, 2nd line: "ARMv4 code generator for TCC"
17:26 gravgun Well...
17:26 sfan5 generating armv4 when armv{6,7} is supported probably doesn't help speed
17:26 gravgun And ARM w/ VFP only, no fixed point
17:28 gravgun "probably doesn't help speed", native code is always better than interpreted
17:29 sfan5 yeah
17:29 gravgun (except when interpreters JIT optimizes really hard, e.g. luaJIT)
17:29 sfan5 but I mean potential is lost if you target v4 and run on v6 or v7
17:29 gravgun Yes
17:30 gravgun Forcing LuaJIT may be an option then, using our own Irrlicht C++ -> C wrapper and LuaJIT's FFI
17:31 sfan5 LuaJIT doesn't work on arm64, does it?
17:33 gravgun Nope
17:33 gravgun The Cocos2dx game framework, which uses LuaJIT, has problems with this on iPhones 5+ (arm64)
17:34 gravgun And so we will if we head this way
17:34 sfan5 then we can't force luajit
17:34 Calinou joined #minetest-dev
17:34 sfan5 2% of people playing the latest release use a device with arm64
17:35 gravgun Meh...
17:35 gravgun And writing a whole VM is not an option either, is it?
17:35 Calinou >VM >Minetest
17:35 Calinou you know it already
17:35 sfan5 a vm is not that hard?
17:35 sfan5 s/?//
17:35 gravgun Well it's supposed to be very light in this case
17:36 gravgun I never wrote a VM but that'd be fun :)
17:38 gravgun But darn, Minecraft is written in Java, and custom rendered blocks aren't *that* heavy
17:38 sfan5 says the person with a good computer?
17:39 gravgun :P
17:39 Calinou Minecraft runs well, yet is heavy
17:39 Calinou don't mix both
17:40 gravgun "custom rendered blocks aren't *that* heavy" compared to the whole game then
17:40 VanessaE custom-rendered blocks?  sounds like mesh draw type.
17:40 gravgun They already aid much in this regard
17:40 gravgun especially "nodebox"
17:40 sfan5 VanessaE: custom is supposed to mean 100% custom, e.g. depending on param1, depending on sourroundings
17:41 sfan5 like re-implementing the new firelike drawtype
17:41 gravgun <anachist>custom, so I can draw *rounded* shapes in the world</anarchist>
17:41 Calinou nodebox rendering speed can be improved by not setting coordinates every frame
17:41 Calinou like VanessaE says
17:41 Calinou RealBadAngel said he has a solution to it
17:42 Calinou gravgun, use the meshnodes for that!
17:42 Calinou lets you replace node models by arbitrary model (can it be animated though? not sure)
17:42 Calinou RealBadAngel made this a few days ago, but not merged yet
17:43 sfan5 Calinou: can you re-implement something like "firelike" entirely without engine changes with that?
17:43 Calinou if we can put animated textures on it, then yes
17:44 Calinou ask RBA for whether you can animate model and/or texture
17:44 sfan5 wut
17:44 Calinou the other problem here, is, is wallmounted paramtype supported?
17:44 Calinou to use one model per orientation
17:44 sfan5 how can you do sourrounding-dependent stuff with models?
17:44 sfan5 I'm not talking about wallmounted here
17:45 sfan5 using wallmounted for a firelike drawtype would be a hack
17:45 Calinou so fire is surrounding-dependant and not just wallmounted?
17:45 ImQ009 joined #minetest-dev
17:45 sfan5 fire is not wallmounted at all
17:45 Calinou then we need surrounding-dependant nodeboxes and meshnodes in the engine
17:45 Calinou then we can do everything
17:45 sfan5 param1 is just ignored
17:45 sfan5 >surrounding-dependant nodeboxes
17:45 Calinou that'd replace fences too
17:45 sfan5 that still doesn't allow me to implement firelike in lua
17:45 Calinou meshnodes then
17:46 sfan5 you don't get what I mean
17:46 sfan5 I can come up with thousands of things you can't do even with surrounding-dependant nodeboxes or meshnodes
17:46 sfan5 if you want to offer the full potential you need custom renderers
17:50 gravgun On a related note: what if one wants directly create a texture (i.e a computer screen w/ custom graphics/text)? (I thought of a minetest.Bitmap class, convertible to a minetest.Texture which is just a reference to irr::video::ITexture)
17:50 gravgun (Bitmap -> Texture conversions means GPU bitmap upload)
17:50 sfan5 you can do that in a very hacky way using texture modifiers
17:51 sfan5 you can't set the texture of a node too
17:51 gravgun "very hacky way"s bother me
17:51 exio4_ joined #minetest-dev
17:51 sfan5 so you'd need to use entities anyway
18:00 Taoki[mobile] joined #minetest-dev
18:07 Megaf Folks, how to I enable the GLES support if Im compiling minetest client on an ARM device?
18:07 Megaf Actually on ARM you dont even need X
18:07 Megaf XBMC and Quake III for example, they dont use X on the Raspberry Pi
18:08 Megaf and Quake III run very fast with all things on max
18:08 Megaf Minetest mush run quite fast too
18:08 Megaf must*
18:14 Miner_48er joined #minetest-dev
18:19 sfan5 Megaf: use irrlicht ogles
18:23 gravgun joined #minetest-dev
18:25 Megaf sfan5: oops, Im compiling the standard irrlicht already
18:26 Megaf sfan5: this one? https://github.com/kexplo/irrlicht_ogl-es.git
18:26 sfan5 Megaf: read http://irrlicht.sourceforge.net/contributing/
18:26 sfan5 And the experimental OpenGL ES driver is here:
18:26 sfan5 svn://svn.code.sf.net/p/irr​licht/code/branches/ogl-es
18:27 sfan5 </quote>
18:28 Megaf sfan5: Ok, thanks
18:31 gravgun Megaf: "Actually on ARM you dont even need X; XBMC and Quake III": those use DirectFB, Irrlicht has no support for this
18:31 gravgun Well it has but is experimental
18:31 sfan5 "Actually on ARM you dont even need X"
18:31 sfan5 wat
18:31 gravgun On any platform you can do w/o X
18:31 sfan5 needing a program does not have anything to do with the cpu arch
18:32 gravgun You can do w/o X with either DirectFB, /dev/[graphics]/fbX direct access, or /dev/[dri/]cardX with KMS+GBM+DRM
18:33 Megaf Im afraid to ask, whats the equivalent in svn to git clone?
18:33 gravgun >"Well it has but is experimental", woops, was wrong
18:33 gravgun svn co / svn checkout
18:34 Megaf hm
18:41 Megaf Thanks sfan5 and gravgun
18:43 gravgun Coming back to the custom renderer problem: a node def property "on_render",  function(pos) could return some kind of mesh definition table
18:43 sfan5 thats not exactly a custom renderer
18:43 sfan5 like you said a VM would be good
18:43 gravgun but who says VM says compiler
18:44 gravgun and who says compiler says parser
18:44 sfan5 not exactly
18:44 sfan5 let the people do assembly<
18:44 gravgun this
18:44 gravgun what I thought
18:44 gravgun but may be too hardcore
18:44 sfan5 nah
18:44 sfan5 people can write parsers/compilers for that if they want to
18:45 gravgun make some simplified instruction set (like how easy ARM assembly is compared to x86) and yes, why not
18:48 diemartin joined #minetest-dev
18:51 selah joined #minetest-dev
18:56 Amaz joined #minetest-dev
18:57 gravgun The VM solution seems good actually (I recall Garry's Mod Wire's GPU code being written in an assembly format, whose VM is itself written in Lua, but was made to be as fast as possible)
19:05 iqualfragile joined #minetest-dev
19:06 gravgun sfan5: Something like this: http://socrates.io/#IjX71wj ?
19:07 kilbith joined #minetest-dev
19:08 sfan5 gravgun: basically yes
19:08 sfan5 gravgun: one thing I'd like: call method, arg1, arg2, arg3 instead of push arg3; push arg2; push arg1; push arg0; call method
19:09 zat joined #minetest-dev
19:10 gravgun "push" (and "pop") suggests stack-based model
19:10 sfan5 yes
19:10 sfan5 stack based is better IMO
19:11 gravgun given that minetests uses strings as node IDs, metadata names and so on
19:11 gravgun registers would hold different types of data...
19:11 gravgun cuz' dealing with strings w/ only integer registers would be a PITA
19:12 sfan5 strings are not used for nodes
19:12 sfan5 nodes actually have IDs
19:13 gravgun IDstring:IDint translation table isn't it
19:13 sfan5 basically
19:14 gravgun as for metadata names...
19:14 gravgun which is probably *the* reason, alongside neighbouring blocks, why we write this
19:17 sfan5 metadata..
19:17 sfan5 is more complicated
19:17 sfan5 the "metadata" you have before doing any advanced stuff is just param1
19:17 sfan5 which is a number
19:19 gravgun number that we should bitshift (or ANDed) to get light level in sunlight/not-sunlight
19:20 gravgun need to add binary operators...
19:20 gravgun btw, how many registers should we add?
19:21 sfan5 umm no
19:21 paramat joined #minetest-dev
19:21 sfan5 thats param2
19:21 sfan5 or maybe the other way around
19:21 gravgun paramtype = "light". The value stores light with and without sun in its upper and lower 4 bits.
19:21 gravgun http://dev.minetest.net/node
19:22 sfan5 param2 is the basic "metadata" you have then
19:23 gravgun param1 and param2 should have a specific register then
19:24 gravgun readonly though
19:24 gravgun we only do rendering
19:25 sfan5 why a register?
19:25 sfan5 an address where param1 and 2 are always found suffices too
19:26 paramat the feature that runs an ABM many times to compensate for the area being unvisited for a while ... i actually find that a big problem and would like to be able to disable that with a boolean in the ABM registration. Unfortunately i doubt i can code this change myself
19:29 gravgun "why a register?" well I might not use the good term maybe (only did a very tiny little bit of assembly myself)
19:51 Megaf sfan5: weird thing is, while compiling irrlight ogles it asks for GL/gl.h, just like the regular irrlicht do. http://paste.debian.net/plain/124380 Anyway, I isntalled that file and let's see what happens
19:53 exio4 joined #minetest-dev
20:10 proller joined #minetest-dev
20:28 Calinou https://github.com/TriBlade9/minetest/commi​t/c22146a2b5073a7661dba202ec44dde9c2c23bc4
20:28 Calinou I am testing this
20:29 sfan5 Megaf: you need to disable the opengl driver in irrlicht ogles
20:32 casimir joined #minetest-dev
20:44 Anchakor_ joined #minetest-dev
20:46 Megaf now, minetest's cmake can't find OpenGL
20:46 Megaf CMake Error at /usr/share/cmake-2.8/Modules/FindP​ackageHandleStandardArgs.cmake:97 (MESSAGE):
20:46 Megaf Could NOT find OpenGL (missing: OPENGL_gl_LIBRARY)
20:46 Calinou it works
20:47 Megaf I dont want it to use OpenGL, its GL ES!
20:58 gravgun left #minetest-dev
21:11 SudoAptGetPlay joined #minetest-dev
21:14 SudoAptGetPlay Hi, I want to read some user defined values from a discrete conf file of a mod. Is that possible with io.open(), etc ?
21:14 shadowzone joined #minetest-dev
21:16 RealBadAngel SudoAptGetPlay, example: https://github.com/minetest-technic/t​echnic/blob/master/technic/config.lua
21:16 SudoAptGetPlay thanks
21:52 proller joined #minetest-dev
22:00 * Megaf still havent succeeded in compiling minetest with ogles
22:20 Megaf it was just a lib missing
22:30 Gethiox joined #minetest-dev
22:34 shadowzone joined #minetest-dev
22:34 shadowzone joined #minetest-dev
22:41 Gethiox joined #minetest-dev
23:02 blaise Megaf: which lib?
23:21 edlothiol joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext