Minetest logo

IRC log for #minetest-dev, 2013-04-29

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

All times shown according to UTC.

Time Nick Message
00:00 hmmmm it looks pretty good
00:03 Taoki joined #minetest-dev
00:03 Taoki joined #minetest-dev
00:09 jojoa1997 joined #minetest-dev
00:54 terrances joined #minetest-dev
01:01 kahrl hrm
01:02 kahrl I made an almost completely empty game to test my dependency algorithm
01:02 terrances left #minetest-dev
01:02 kahrl stumbled upon a segfault in ~CItemDefManager
01:02 kahrl itemdef.cpp:250 needs an if(cc->wield_mesh) around it
01:03 kahrl can't be bothered to make a pull request for this now
01:03 Exio what?
01:03 Exio sounds like a "non-defined" hand
01:03 kahrl yeah, I think that's what it is
01:04 kahrl it calls cc->wield_mesh->drop() but cc->wield_mesh is NULL
01:04 hmmmm great...
01:04 hmmmm i hope this is the last of the null dereference bugs introduced when sapier fixed the memory leaks
01:07 hmmmm there fixed
01:09 kahrl thanks
01:23 kahrl my algorithm doesn't work
01:23 kahrl consider 3 mods: a, b, c; b depends on a and a optionally depends on c
01:23 kahrl say the normal dependency resolver returns the sort order a, b, c
01:24 kahrl the optional dependency resolver can't move a behind c because b is in the way
01:38 hmmmm what's wrong with moving the optional dependency in front instead?
01:40 hmmmm hmmm. i think i have an idea of how to deal with structures that are larger than a single block
01:41 hmmmm but it requires recalculating all the decoration placements of the block below
01:41 hmmmm s/block/chunk
01:43 Exio what about "just adding" optional deps at the end, and when loading if (!optional && not_found) cancel; (as actually it is a if (not_found), no?)
01:43 hmmmm so let's reason this out.  if node_min.Y > heightmap[index], then we're above what was already to have been generated
01:44 hmmmm so if we are generating a decoration with a height greater than 16 (size of the border), calculate all the positions of decorations placed
01:44 hmmmm if decoration height + heightmap[index] is > chunksize.Y + MAP_BLOCKSIZE, then we know that one was definitely cut off
01:46 hmmmm so, generate it again, and blit it back to the vmanip starting at the point where it was cut off
01:46 hmmmm and of course, then there's the problem with sunlight not being propogated properly?
01:47 hmmmm i would need to fix all instances of calcLighting() to assume there is sunlight if the overtop is CONTENT_IGNORE _or_ it's a node that propagates sunlight
01:53 hmmmm i'm not sure if it's worth all the effort
01:54 hmmmm could just call spawn_ltree() after finishBlockMake on those areas
01:55 hmmmm hrm, i should only bother with that if the height passes a threshhold - same thing with schematic-based placements
01:57 jojoa1997 joined #minetest-dev
02:11 RealBadAngel damn im playing with water and ice
02:12 RealBadAngel can some1 explain why water is still drawn if i did this?
02:12 RealBadAngel case NDT_LIQUID:
02:12 RealBadAngel {
02:12 RealBadAngel continue;
02:13 RealBadAngel nvm, im tired propably ;)
02:20 RealBadAngel well, both liquid drawtypes disabled, water surface still drawn. very funny :)
02:20 jojoa1997 joined #minetest-dev
02:27 fuzzywuzzy joined #minetest-dev
02:27 fuzzywuzzy VanessaE are you there?
02:27 fuzzywuzzy kaeza estas?
02:28 kaeza hm?
02:29 fuzzywuzzy i need to know how i can make a image of my map i try this
02:29 fuzzywuzzy python minetestmapper.py ../worlds/MTVIlle map.png
02:29 fuzzywuzzy but it doesnt seem to work
02:29 kaeza fuzzywuzzy, → #minetest
02:29 fuzzywuzzy i cant go on there pm?
02:30 Exio -- [#minetest] *!*@189.191.* banned by VanessaE - »»» fuzzywuzzy (~fuzzywuzz@189.191.76.74)
02:30 fuzzywuzzy OMG its working!
02:30 kaeza Exio, guessed
02:31 fuzzywuzzy well it seems to be working
02:31 fuzzywuzzy so ill tell you if it worked in a while
02:32 fuzzywuzzy it worked!!!
02:32 fuzzywuzzy yeah baby
02:34 fuzzywuzzy thanks kaeza
02:34 fuzzywuzzy still i need to install all the mods too i get the image of the block that is under the unknown block
02:54 Exio i think all the people with access to the repo should have op in/on #mt and #mt-de
02:54 Exio v
03:00 hmmmm ._.
03:01 hmmmm +++ATM0DT911
03:07 ShadowNinja Having a public access list here would be nice...
03:47 kaeza joined #minetest-dev
04:05 ShadowNinja|Away joined #minetest-dev
04:06 ShadowNinja joined #minetest-dev
04:12 ShadowNinja joined #minetest-dev
04:14 Guest43358 joined #minetest-dev
04:22 kaeza joined #minetest-dev
04:41 hmmmm hrm
04:42 hmmmm i think it's worth looking into varying 3d noise prevalence based on biome
06:22 kaeza joined #minetest-dev
06:24 emptty joined #minetest-dev
06:27 ShadowNinja joined #minetest-dev
07:30 kahrl joined #minetest-dev
07:37 kahrl seems I'll have to rework ModConfiguration a bit to properly support optional dependencies
07:37 kahrl question: is having multiple mods with the same name (in different paths) a supported configuration?
07:38 VanessaE not really, no - but it does work.
07:38 VanessaE whichever one loads second is the one whose node defs and such take precedence.
07:38 kahrl yeah, the current ModConfiguration loads them but I'm not sure if dependencies are handled correctly
07:39 VanessaE (I ran into that exact scenario last night in fact)
07:39 kahrl oh
07:39 kahrl mind sharing the paths and dependency situation so that I can use it as a test case?
07:40 kahrl if it's not too much work
07:41 VanessaE I don't remember the specifics, because I was quick to correct it (after realizing the issue)
07:41 VanessaE but,
07:42 VanessaE it was something like ModA included a copy of ModB within, plus there was a second copy of ModB in the same folder as ModA (e.g. ~/.minetest/mods/minetest).  When ModA loaded, it loaded ModB with it, and then the second, "extra" ModB got loaded, redefining everything the copy included with ModA had established,.
07:42 VanessaE make sense
07:42 VanessaE >
07:42 VanessaE ?
07:43 kahrl I see
07:43 VanessaE I've had the same thing happen with modpacks vs. individual mods
07:44 VanessaE it really makes you scratch your head for a while if you're not in a mental state to think of such a thing.
07:44 kahrl there used to be a warning in this case
07:44 VanessaE maybe there still is, I rarely look at the console except when there's a fatal error.
07:44 kahrl see commit 6b2023dc3eb1b483c92ba967f3335bb6880d2db1
07:45 kahrl nah, it's no longer there, unless grep failed me
07:45 VanessaE https://github.com/minetest/minetest/commit/6b2023dc3eb1b483c92ba967f3335bb6880d2db1
07:45 VanessaE it's there.
07:48 VanessaE I have to wonder if that code even still exists a year later
07:50 VanessaE nope.
07:50 VanessaE at least, not that "mod name conflict" message anyway
07:51 VanessaE nor any of the other associated messages.
07:52 kahrl I wonder what the right thing to do is
07:53 VanessaE good question.
07:53 VanessaE I suppose it's possible that this IS a supported configuration now, but even so there ought to be at least a warning.
07:54 VanessaE "Warning, $MODNAME already loaded from $PATH1, also loading the copy at $PATH2" or so.
07:56 proller joined #minetest-dev
08:22 celeron55 two mods with the same name shouldn't ever be loaded at the same time
08:22 celeron55 there's no way to make the end result reasonable at all
08:23 VanessaE they shouldn't, no, but it's trivial to cause it to happen.
08:23 celeron55 it should just ignore the other one, with either a preference for modpacks or for non-modpacks or for user-installed or globally installed; dunno which
08:24 VanessaE I would guess it should prefer individual user-installed mods.
08:24 VanessaE that way a person could still, say, supply their own copy of the fire mod or something, without having to delete the original.
08:25 VanessaE look for a user mod first, then a modpack containing one, then the current game, then fall back to whatever is below that
08:25 celeron55 but what if mods in two modpacks depend on the same mod and both provide it, AND it also exists globally or not in a modpack?
08:26 VanessaE then the global one takes precedence, with a warning message printed to the log.
08:26 celeron55 the algorithm for that is going to be very hard to make
08:27 VanessaE as long as the order is predictable and there are warning messages, modders (and maybe users) will be able to sort out the conflicts.
08:27 VanessaE yeah, I guess it would be,.
08:27 celeron55 if somebody does, then fine; but i am guessing nobody will 8)
08:27 VanessaE have fun :D
08:27 celeron55 >as long as the order is predictable
08:27 celeron55 that is important, yes
08:28 celeron55 i mean, the preference order
08:28 VanessaE yes.
08:28 celeron55 mod loading order, disregarding dependencies, is not predictable by design
08:28 VanessaE is there a particular reason why that is?
08:29 celeron55 making it predictable serves no purpose because everyone has a different set of mods, breaking predictability
08:29 VanessaE well, predictable doesn't have to mean "Mod A will always load before Mod B".. It can simply mean "Mod A was found in ~/.minetest/mods/minetest and ~/.minetest/games/survival, load the one in mods/minetest and ignore the other"
08:30 celeron55 the same thing applies somewhat to the order of preference, but it's lower there
08:30 celeron55 the applicability is lower, i mean
08:30 VanessaE i.e. it only needs class granularity
08:31 kahrl implementing this is not hard at all
08:31 VanessaE there's little or nothing to be gained by trying to get too fine-grained really
08:31 kahrl I mean, look ModConfiguration(std::string)
08:31 kahrl look at*
08:31 kahrl the mods are already searched in this preference order
08:32 kahrl if a new mod is found with a duplicate name, discard the older one
08:32 VanessaE kahrl: link to that code?
08:32 * VanessaE is not familar with the engine layout.
08:33 kahrl https://github.com/minetest/minetest/blob/master/src/mods.cpp#L210
08:33 VanessaE thanks
08:33 celeron55 it needs the addition that if there are two mods at the same "level", it would revert to the previous "level" (levels being, in order: global, global+modpack, user, user+modpack (or something like that))
08:34 VanessaE celeron55: in that particular case, check the modified time of the two mods.  Whichever is newer takes precedence.  If no timestamp, alpha-order.
08:34 celeron55 timestamps make no sense at all
08:34 VanessaE (alpha order by modpack name for example)
08:35 VanessaE why so?
08:35 VanessaE or why not, rather
08:35 celeron55 there's nothing to guarantee they actually represent anything related to the version of the mod
08:35 celeron55 and both mods could be forks of a previous one with different additions
08:35 VanessaE hrm
08:35 VanessaE nono I mean the timestamp on the user's filesystem
08:36 VanessaE well no, I guess that's not too difficult to get wrong
08:36 celeron55 the timestamps will be copied in archives
08:36 VanessaE so then just alpha order.
08:36 VanessaE falling back down one "level" in that instance would probably cause neither mod to load
08:36 celeron55 alphabetic order is not useful at all either
08:36 kahrl what is the use case for reverting to a previous level?
08:37 celeron55 also i think it would be just as good to just simply fail
08:37 VanessaE why not alpha order?
08:37 celeron55 VanessaE: my question is, why the hell IN alpha order?
08:37 VanessaE kahrl: I don't see a point to that, myself, not in this particular corner case.
08:38 VanessaE celeron55: simple, you can be guaranteed that the next level up will have at least some way to differentiate the two modpacks.
08:38 VanessaE if they had the same directory name, you've got a broken filesystem on your hands anyway
08:38 celeron55 so i'll make modpack XXXXXXXgreatmods
08:38 celeron55 and it'll always override everything until someone makes XXXXXXXXxXxXXxgreatmods
08:39 VanessaE in which case a warning is printed that two mods with the same name are attempting to load - and the user can be asked to find that warning in their log if they have a problem with the resutl.
08:39 VanessaE result*
08:40 celeron55 i think it actually should just fail
08:40 VanessaE we already tell users to post their logs when some obscure-to-that-user error occurs anyway
08:40 celeron55 the end result is so uncontrollable anyway
08:40 celeron55 and it's a very far corner case resulting from bad practices
08:41 VanessaE true.
08:41 VanessaE I guess a failure is okay, as long as the error message spells out in detail what caused it.
08:41 celeron55 the error must be as clear as possible
08:41 VanessaE just saying there were two of ModA tryign to load is insufficient - it must at least give full paths, too.
08:42 VanessaE oh G*d, does that mean we agree on something again?  *faints*
08:45 kahrl suggestion for the order of levels: http://paste.dy.fi/hmb
08:45 VanessaE kahrl: where higher level numbers take precedence?
08:45 kahrl okay, so let's say that there are 3 mods with the same name: 2 in user modpacks and 1 user mod
08:46 kahrl VanessaE: yes
08:46 VanessaE kahrl: I like this.
08:46 kahrl should that fail or load the user mod?
08:46 VanessaE load the user mod.
08:46 VanessaE (and warn that the other two were ignored)
08:46 kahrl okay, that's what I'd have said
08:46 kahrl makes it a little more complicated to implement but for the better
08:51 celeron55 umm
08:51 celeron55 i think we just agreed that it should fail
08:52 celeron55 oh no, it's the other way in precendence
08:54 celeron55 i'm not sure if that actually would make sense
08:55 kahrl it would allow a user to fix a mod conflict (say in user modpacks) without having to uninstall at least one modpack
08:55 celeron55 it brings up the same question as with the other way in precedence - are the depending mods in the modpacks compatible with the user mod
08:56 celeron55 yes, that's the difference
08:56 celeron55 i guess it's good enough
08:56 kahrl it will give a warning in any case
09:03 proller joined #minetest-dev
09:07 Calinou joined #minetest-dev
09:18 kahrl should this be documented somewhere? lua_api.txt? the wiki?
09:20 celeron55 there's stuff about mod loading at the beginning of lua_api.txt
09:20 celeron55 you could define it very briefly somewhere near there
09:21 celeron55 nothing noob-proof but something that makes it clear there is an order of preference and certain conflicts will directly fail
09:22 kahrl I don't know, I have a feeling that it will bloat the file if I describe it completely
09:22 kahrl I'll make a page on dev.minetest.net if I can get past the cat photos
09:23 celeron55 i have never been able to get past them (otoh, i have an account there so i haven't had to trie too hard 8))
09:23 celeron55 try*
09:24 celeron55 (but to me it seems they just don't work)
09:25 celeron55 also, not adding anything to lua_api.txt is fine to me
09:25 darkrose joined #minetest-dev
09:25 kahrl I got past the cats somehow
09:25 kahrl woohoo :D
09:27 VanessaE and the wiki never knew what hit it......
09:27 VanessaE ;)
09:36 emptty joined #minetest-dev
09:44 darkrose joined #minetest-dev
10:12 kahrl http://dev.minetest.net/Mod_name_conflicts
10:13 kahrl brb
11:03 PilzAdam joined #minetest-dev
11:12 Calinou joined #minetest-dev
11:49 iqualfragile joined #minetest-dev
12:11 bcnjr5 joined #minetest-dev
13:00 RealBadAngel hi all
13:01 RealBadAngel does anybody know where liquid surface is drawn? i have disabled NDT_LIQUID it is still being drawn
13:19 hmmmm joined #minetest-dev
13:20 bcnjr5 left #minetest-dev
13:30 RealBadAngel hi hmmmm
13:31 RealBadAngel do you know where water surface is drawn?
14:02 kahrl RealBadAngel: NDT_LIQUID is only used when new_style_water = 1 in minetest.conf
14:02 kahrl NDT_FLOWINGLIQUID is always used
14:03 kahrl if new_style_water is 0, water source nodes are drawn in MapBlockMesh()
14:03 kahrl like all solid nodes
14:04 RealBadAngel i disabled both liquid drawtypes
14:05 RealBadAngel and surface (only) is still being drawn
14:06 RealBadAngel case NDT_FLOWINGLIQUID:
14:06 RealBadAngel {
14:06 RealBadAngel break;
14:06 kahrl Yeah. Try enabling new_style_water
14:08 RealBadAngel i am asking what code draws the surface
14:08 RealBadAngel because it does it wrong
14:09 kahrl what are you actually trying to do
14:10 RealBadAngel fix it
14:10 kahrl fix what?
14:10 RealBadAngel but cannot find code that draws it, it is ridiculous
14:10 kahrl by default it's drawn like solid nodes such as dirt, stone, ...
14:11 kahrl just with a different shader that moves it down the y axis
14:11 RealBadAngel way it is displayed, it is affedcted with some weird bug that causes it to display it in some regions properly in others not
14:11 RealBadAngel shaders are off..
14:11 kahrl screenshot?
14:13 RealBadAngel http://i.imgur.com/jrL1geS.png
14:14 RealBadAngel both drawtypes disabled, shaders off
14:14 PilzAdam kahrl, no, shaders dont move water down anymore
14:15 PilzAdam I fixed new_style_water, so shaders arent needed for that anymore
14:15 kahrl I'm getting lowered water even without new_style_water
14:15 RealBadAngel have you introduced new code to draw water surfaces?
14:15 PilzAdam RealBadAngel, liquid sources are drawn like normal nodes with new_stlye_water = 0; flowing liquids are drawn in the generate_special() function
14:16 PilzAdam so, you have disabled NDT_FLOWINGLIQUID, so you see the sources only in the screenshot
14:16 RealBadAngel what code draws the sources?
14:16 PilzAdam with new_style_water or without?
14:17 RealBadAngel drawtypes are disabled
14:17 RealBadAngel wheres the code that draws the surface
14:17 PilzAdam with new_style_water or without?
14:17 RealBadAngel whatever
14:17 RealBadAngel what draws it god damm it
14:18 RealBadAngel am i askin in chinese?
14:18 PilzAdam well, with new_style_water =  1 its drawn in mapblock_mesh_generate_special(), with new_style_water = 0 its drawn in MapBlockMesh() (like kahrl already said)
14:19 kahrl okay forget what I said, I apparently had new_style_water on without knowing
14:19 kahrl I disabled it and now the water is not lowered
14:19 RealBadAngel in mapblock_mesh_generate_special draws all NDT_'s
14:19 RealBadAngel i disabled it
14:19 kahrl umm
14:19 PilzAdam umm
14:19 RealBadAngel so MapBlockMesh(), yes?
14:20 kahrl yes.
14:20 PilzAdam do you actually read what we say?
14:21 PilzAdam mapblock_mesh_generate_special() only draws the special node drawtypes
14:21 jin_xi joined #minetest-dev
14:21 PilzAdam and with new_style_water=0 water sources arent handled special
14:21 kahrl look at nodedef.cpp:608
14:22 RealBadAngel where in mapblock_mesh.cpp?
14:22 RealBadAngel i cannot see here anythin related to liquids
14:23 PilzAdam because liquid sources are not handled special
14:23 PilzAdam they are drawn like every other node with drawtype "normal"
14:24 RealBadAngel great...
14:24 RealBadAngel thats why theyre drawn twice
14:24 PilzAdam what do you want to fix there?
14:24 RealBadAngel in several regions
14:24 RealBadAngel its screwed
14:24 RealBadAngel thats why i want to fix it
14:25 PilzAdam what is screwed?
14:25 RealBadAngel draw regions are square shape, like the chessboard
14:26 RealBadAngel in one alpha works perfectly, node next to it dont
14:26 RealBadAngel it makes transparent ice impossible
14:26 RealBadAngel also causes air bubbles visible like black hole in water
14:27 RealBadAngel there are two water surfaces displayed at the same time
14:28 RealBadAngel this code needs to be fixed
14:30 RealBadAngel how and where to do force liquids to be displayed as all other nodes with solindess!=0 ?
14:30 RealBadAngel *do you
14:30 PilzAdam <kahrl> look at nodedef.cpp:608
14:31 RealBadAngel ah, thx
14:48 celeron55 inb4 some horrible hack
14:52 emptty joined #minetest-dev
15:02 RealBadAngel http://i.imgur.com/dFOuYmY.jpg
15:02 RealBadAngel ice under and above water
15:03 RealBadAngel need just to make water face not being shown below ice
15:03 RealBadAngel but apart from it, its working fine
15:09 Jordach joined #minetest-dev
15:09 Jordach joined #minetest-dev
15:16 PilzAdam hmmmm, Im building a nether at -5000 by registering netherrack as an ore and replace stone and all the other ores; but only the stone gets replaced, the register_ore calls of netherrack with wherein="some ore" have no effect
15:18 Jordach2 joined #minetest-dev
15:19 Jordach3 joined #minetest-dev
15:21 Jordach joined #minetest-dev
15:27 ImQ009 joined #minetest-dev
15:35 Jordach2 joined #minetest-dev
15:37 Jordach3 joined #minetest-dev
15:53 Calinou joined #minetest-dev
16:14 rubenwardy joined #minetest-dev
16:20 serengeor joined #minetest-dev
16:24 khonkhortisan joined #minetest-dev
16:28 dexter0 joined #minetest-dev
17:14 serengeor joined #minetest-dev
17:32 PilzAdam hmmmm, nvm, I had a typo in my code
17:33 PilzAdam but still, not all nodes are replaced with clust_scarcity = 1
17:34 celeron55 oh by the way, did thexyz fix the 0.4.6 build?
17:34 thexyz http://minetest.ru/builds/minetest-0.4.6-2.zip
17:34 celeron55 i'll change the download page to point to that
17:34 celeron55 not worth making any news of i guess though
17:35 thexyz no idea what i broke this time
17:35 thexyz the only difference SHOULD BE cURL support
17:40 celeron55 i wonder where we'd find people who would take pride in making sure windows packages are good
17:41 celeron55 or, really, we don't really have any QC over launchpad packages or anythinge lse either
18:03 iqualfragile joined #minetest-dev
18:23 kaeza joined #minetest-dev
18:51 rubenwardy joined #minetest-dev
18:51 Jordach joined #minetest-dev
18:51 Jordach joined #minetest-dev
18:56 Jordach_ joined #minetest-dev
18:56 Jordach_ joined #minetest-dev
19:01 Jordach__ joined #minetest-dev
19:05 BlockMen joined #minetest-dev
19:05 BlockMen hi
19:09 sapier joined #minetest-dev
19:13 rubenwardy left #minetest-dev
19:16 jojoa1997 joined #minetest-dev
19:47 Taoki joined #minetest-dev
20:11 emptty joined #minetest-dev
20:29 emptty sapier: around?
20:29 sapier yes how may I help you?
20:29 emptty I was wondering about the license of your mods
20:30 emptty I'd love packaging mobf for my lazy users, but the license is not one very clear
20:30 sapier CC-BY-SA
20:31 sapier for most there are some things that are even CC0 those are stated in the attached license files
20:31 proller joined #minetest-dev
20:31 StrayBytes joined #minetest-dev
20:31 StrayBytes joined #minetest-dev
20:32 emptty thanks a lot
20:32 emptty could you add a formal notice in the git or somewhere?
20:33 sapier I'll have a look where to add it
20:34 emptty I also noted that the mention on top of every file contains a typo: "And of course you are NOT allow to pretend you have written it. "
20:34 emptty that should be "allowed"
20:35 sapier yes you're right I think there is more to change in this header
20:36 emptty Also, I wanted to say that I like these mods very much, thanks for your work
20:36 sapier yes of course thanks for the hint I didn't know about that typo by now
20:37 emptty the mese is not expensive enough by the trader, but that's the only glitch I can think of after a few days of extensive use :)
20:38 sapier :-) it's easy to change and of course you can write a issue on github for next mobf version
20:40 RealBadAngel btw i keep getting lately such strange warning when closing the client:
20:40 RealBadAngel Could not open file of texture: [inventorycube{default_lava.png{default_lava.png{default_lava.png^[forcesingle
20:40 RealBadAngel sometimes it is about 20+ textures
20:40 * PilzAdam too
20:41 BlockMen i have same warnings
20:43 jin_xi same here
20:43 sapier hmm does this happen anytime?
20:43 RealBadAngel memory leaks fixes sideeffect?
20:43 sapier sounds like it yes
20:43 sapier I'll have a look
20:43 RealBadAngel it always ends with forcesingle
20:43 PilzAdam anyone wanna dig into "git bisect"?
20:43 RealBadAngel i mean warning
20:43 fubarr joined #minetest-dev
20:44 VanessaE same here.
20:44 VanessaE I get those warnings even on stuff I know for a fact is good, like homedecor textures.
20:44 sapier lol what about looking at changes and think about what may have done it ;-)
20:46 fubarr hello all, i just came accross minetest... and I was wondering maybe to port it to IRIX, the old Silicon Graphics unix. It's semi-modern round 2005 EOL, and my hardware is OpenGL 1.2/GLX 1.3 compatible. Though it doesn;t have the multi-texture extension. Should I even consider it?
20:50 sapier rba is this the full line?
20:50 emptty fubarr: if irrlicht works on your platform, minetest should work like a charm
20:51 RealBadAngel sapier, the waring? if so then yes
20:51 emptty fubarr: in other words, you're asking on the wrong channel: ask to the creators of the graphical engine ;)
20:51 sapier I don't even find a matching error text in code :-(
20:51 fubarr lol - fair enough - i'm looking at the irrlicht pages right now.
20:52 emptty sapier: issue opened
20:53 hmmmm [01:33 PM] <PilzAdam> but still, not all nodes are replaced with clust_scarcity = 1
20:53 hmmmm holy crap that must be slow.
20:54 PilzAdam https://github.com/PilzAdam/nether/blob/master/init.lua#L356
20:54 PilzAdam its still faster than looping through the mapblock(s) with on_generated()
20:54 PilzAdam (note that also with 6 register_ore() calls there still appears stone)
20:55 hmmmm well that's because the rand used in minetest sucks
20:56 PilzAdam would ore_type = "sheet" work better?
20:56 hmmmm maybe
21:09 PilzAdam what noise_params would I use when I want everything to be replaced?
21:21 Exio PilzAdam: just some small things, gravel exists in the nether (MC) - and the soul sand (nethersand) doesn't fall like normal :P
21:28 jojoa1997 and quartz
21:29 Exio quartz should be added in mesecons, not default
21:34 jojoa1997 mesecons?
21:51 Taoki joined #minetest-dev
22:04 sapier left #minetest-dev
22:09 jojoa1997 joined #minetest-dev
22:10 iqualfragile joined #minetest-dev
22:38 BlockMen left #minetest-dev
23:59 kaeza joined #minetest-dev
23:59 hmmmm hmm

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