| 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 |
