| Time |
Nick |
Message |
| 00:22 |
|
sfan5 joined #minetest-dev |
| 00:54 |
|
cg72 joined #minetest-dev |
| 00:55 |
|
Zeno` joined #minetest-dev |
| 00:59 |
|
Taoki joined #minetest-dev |
| 01:06 |
|
sfan5 joined #minetest-dev |
| 01:07 |
|
diemartin joined #minetest-dev |
| 01:08 |
cg72 |
https://github.com/minetest/minetest/pull/1584 << anyone care to tell me if and how i did this one wrong??? i know no one likes me trying to dev ;) |
| 01:13 |
RealBadAngel |
openin a folder as a file to read? |
| 01:14 |
Zeno` |
That should be ok. Lua directly calls libc fopen() which will open a directory as a stream if it exists (you can't do anything with said stream AFAIK though) |
| 01:14 |
Zeno` |
except close it again |
| 01:15 |
Zeno` |
Who knows what it does on Windows though... |
| 01:16 |
Zeno` |
http://codepad.org/gxE6Iy1M |
| 01:18 |
|
kaeza joined #minetest-dev |
| 01:20 |
|
CraigyDavi`` joined #minetest-dev |
| 01:21 |
|
NakedFury joined #minetest-dev |
| 01:22 |
|
cg72_ joined #minetest-dev |
| 01:22 |
Zeno` |
http://codepad.org/h3lmZBmN |
| 01:23 |
|
ImQ009 joined #minetest-dev |
| 01:23 |
Zeno` |
$ ./a.out |
| 01:23 |
Zeno` |
Could not read: : Is a directory |
| 01:23 |
cg72_ |
ok that was weird |
| 01:24 |
|
NakedFury joined #minetest-dev |
| 01:27 |
|
lanxu_ joined #minetest-dev |
| 01:32 |
|
paramat left #minetest-dev |
| 01:40 |
|
Jordach joined #minetest-dev |
| 01:50 |
RentedMule |
solved my port problem by recompiling from git HEAD. |
| 01:50 |
|
Zeno` joined #minetest-dev |
| 01:50 |
|
hmmmm joined #minetest-dev |
| 01:50 |
|
Anchakor1 joined #minetest-dev |
| 01:50 |
|
HLuaBot joined #minetest-dev |
| 01:50 |
|
deltib joined #minetest-dev |
| 01:50 |
|
CraigyDavi joined #minetest-dev |
| 02:11 |
Sokomine |
paramat, hmmmm: the forceplacement parameter is very hepful, yes. as far as extending schematics goes - perhaps it might be useful to make it possible to insert a schematic directly into a luavoxelmanip data structure from withhin lua. it would also be great to have an api function to uncompress (unzip) the schematic's data structure from withhin lua without additional libraries, if possible |
| 02:15 |
|
Miner_48er joined #minetest-dev |
| 02:42 |
|
proller joined #minetest-dev |
| 02:56 |
|
zat joined #minetest-dev |
| 03:07 |
|
paramat joined #minetest-dev |
| 03:42 |
paramat |
VanessaE, hmmmm, first test of running a 'get node'/'add node' mapgen mod alongside a voxelmanip mapgen mod (canyon mod plus landup mod): no problems. But of course this is just one mod combination |
| 03:45 |
|
CraigyDavi` joined #minetest-dev |
| 03:45 |
Zeno` |
Do both mods affect the same area? |
| 03:46 |
VanessaE |
but how are the two mods actually DOING it? |
| 03:46 |
VanessaE |
paramat: the problem I think comes from the vmanip mod writing not just the underlying land but the adjacent layer of *air* too |
| 03:47 |
VanessaE |
I guess that's what snow mod did before the hack |
| 03:47 |
VanessaE |
(either you had grass with air above, or you had dirt-with-snow with more snow above) |
| 03:47 |
VanessaE |
but I haven't looked at the code in detail |
| 03:50 |
paramat |
Zeno` yes, i tried to replicate the conditions as close as i could |
| 03:51 |
paramat |
but im still outvoted 2 to 1 :) more people should test |
| 03:53 |
paramat |
to be fair i did try snow mod plus plantlife and indeed had the same problems as you did |
| 03:56 |
VanessaE |
paramat: and you saw nothing wrong with plants_lib's code that could cause it? |
| 03:58 |
paramat |
correct, but plantslib/plantlife are complex i don't have my head completely around the code |
| 03:58 |
VanessaE |
heh |
| 03:59 |
paramat |
i need to try more combinations that write to the air above a terrain, so am suspending judgement |
| 04:00 |
VanessaE |
well there ain't much to it. it does a register_on_gen in which it reads from the map with a find_nodes_in_area, finds all surfaces therein, runs through the action loop to put stuff on the map, and exits from the callback |
| 04:00 |
Zeno` |
my glow worms don't write to air above the terrain |
| 04:00 |
VanessaE |
there's two of those (one for where checking for air above the target is needed, and one for where it isn't) |
| 04:01 |
Zeno` |
but they do write to air below ground level |
| 04:01 |
VanessaE |
Zeno`: ok, so then that theory isn't valid. *shrug* |
| 04:01 |
Zeno` |
paramat, https://github.com/Zeno-/minetest_mtz/blob/master/glowworms/init.lua |
| 04:01 |
VanessaE |
I have to wonder if find_nodes_in_area() is the problem? |
| 04:01 |
VanessaE |
no, that can't be it |
| 04:02 |
VanessaE |
because the writes are happening and then being overwritten |
| 04:02 |
VanessaE |
(hence the dry grasses in-the-water entities still surviving) |
| 04:04 |
* paramat |
looks at glowworms |
| 04:07 |
paramat |
and what failed, glowworms or plantslib? |
| 04:07 |
Zeno` |
glowworms made the plantslib not work |
| 04:08 |
Zeno` |
i.e. plantlibs plants were not staying in the world |
| 04:08 |
VanessaE |
Zeno`: didn't you write a little stub of mod that does what plants_lib does? |
| 04:08 |
VanessaE |
just as a test I mean |
| 04:08 |
Zeno` |
I don't think so. I ended up doing: https://github.com/Zeno-/minetest_mtz/blob/altgworms/glowworms/init.lua |
| 04:08 |
Zeno` |
So they'd work together |
| 04:09 |
Zeno` |
So I still read the voxelmanip data but use set_node() to modify (yeah I was lazy heh) |
| 04:10 |
paramat |
perhaps i will try plantlife and voxelmanip landup |
| 04:11 |
Zeno` |
Oh you mean for testing Vanessa? |
| 04:11 |
VanessaE |
Zeno`: yeahg |
| 04:11 |
VanessaE |
-g |
| 04:11 |
Zeno` |
Yeah I wrote a little stub to put plants in random places |
| 04:11 |
Zeno` |
let me see if I still have it |
| 04:11 |
VanessaE |
point being, I seem to recall you ruled out plants_lib as being the fault here :) |
| 04:12 |
Zeno` |
Yeah I do remember doing that now |
| 04:20 |
Zeno` |
I can't find it :( |
| 04:20 |
Zeno` |
I found some really useful C snippets though... blah.c shit.c test.c |
| 04:21 |
paramat |
so far plantlife works alongside landup, but is slow, i recommend rewriting using voxelmanip and not 'find nodes in area' |
| 04:21 |
VanessaE |
vmanip won't be any faster |
| 04:21 |
VanessaE |
find_nodes_in_area() is capable of filtering the map in one cal |
| 04:21 |
VanessaE |
call* |
| 04:21 |
VanessaE |
can't do that with vmanip |
| 04:23 |
VanessaE |
though I'll consider doing that later |
| 04:24 |
Zeno` |
Perhaps I am using voxelmanip incorrectly? |
| 04:25 |
Zeno` |
I haven't ruled that out yet |
| 04:25 |
* paramat |
finds a mountain range at last |
| 04:25 |
Zeno` |
If I am using it incorrectly then of course I could have ruled out plants_lib |
| 04:26 |
VanessaE |
Zeno`: yeah but if you are, then SPlizard is also... |
| 04:27 |
Zeno` |
Well, I copied someone else's code. Just looking at it now, is vm:write_to_map(data) correct? It seems I could be calling it simply as vm:write_to_map() |
| 04:27 |
Zeno` |
Not sure... reading docs |
| 04:27 |
paramat |
where landup and plantlife share chunks both work good |
| 04:27 |
VanessaE |
Zeno`: it shouldn't matter *what* you do to the map though. |
| 04:27 |
paramat |
glowworms code looks okay to me |
| 04:28 |
Zeno` |
hmm ok |
| 04:29 |
paramat |
i don't trust 'find nodes in area' because i once used 'find nodes near' and it was very slow even for small radii |
| 04:29 |
VanessaE |
paramat: it's always worked for me :) |
| 04:29 |
paramat |
and this modpack has multiple calls to plantslib |
| 04:29 |
VanessaE |
paramat: nope.avi |
| 04:29 |
paramat |
oh okay |
| 04:29 |
VanessaE |
one single call to that function |
| 04:29 |
paramat |
wise |
| 04:30 |
VanessaE |
well there are two (one in the legacy don't-check-for-air code) |
| 04:30 |
VanessaE |
but it's not like it used to be |
| 04:31 |
VanessaE |
register_on_generated [start] --> read the map with one call to find_nodes_in_area() with a list of potential surfaces, search that list for surfaces with air above, pass the result into the action loop which populates the surfaces according to the biome defs (this is where all those calls actually went), loop ends ---> [exit on_generated] |
| 04:32 |
VanessaE |
the no-air-check does the same thing, from a separate table and a separate call to find_nodes. |
| 04:32 |
VanessaE |
s/search that list/search the returned table/ |
| 04:33 |
VanessaE |
the code got only about 2.5x faster when I reduced the number of calls to find_nodes from 123 to 2. |
| 04:33 |
VanessaE |
so it's not really slow at all compared to the rest of the code :) |
| 04:35 |
paramat |
it's still slow for what it does, i recommend simplifying and using voxelmanip |
| 04:35 |
VanessaE |
it's a latency issue more than a speed issue |
| 04:36 |
VanessaE |
the mapgen queues up too many blocks all at once and then spits them out in a big glob |
| 04:36 |
VanessaE |
but I'll do what I can |
| 04:39 |
paramat |
are various experiences are still bemusing though, however, still IMO too early to say there is a bug with voxelmanip |
| 04:39 |
paramat |
(our various ...) |
| 04:45 |
* paramat |
thus evades having to kick hmmmmm's ass |
| 04:53 |
|
paramat left #minetest-dev |
| 04:54 |
hmmmm |
darn |
| 04:54 |
hmmmm |
he left |
| 04:54 |
hmmmm |
--; |
| 04:54 |
hmmmm |
and one minute ago too |
| 04:54 |
hmmmm |
ghghghghghgh |
| 04:55 |
VanessaE |
heh |
| 05:01 |
|
OldCoder joined #minetest-dev |
| 05:35 |
|
paramat joined #minetest-dev |
| 05:35 |
paramat |
here hmmmm |
| 05:43 |
|
Hunterz joined #minetest-dev |
| 05:43 |
Zeno` |
hmmmm, do you know why LuaVoxelManip::l_read_from_map() calls vm->initialEmerge() ? |
| 05:44 |
Zeno` |
Doesn't that get the map as if it was unmodified mapgen data? Or am I misunderstanding |
| 05:45 |
Zeno` |
hi paramat |
| 05:45 |
paramat |
o/ |
| 05:57 |
hmmmm |
Zeno`: it calls initialEmerge because initialEmerge reads the map |
| 05:58 |
paramat |
'unturned' is a cute new game worth checking out, however the 'sun rays' are irritating, as they are in any game |
| 06:00 |
Zeno` |
hmmmm, yes I see that now |
| 06:14 |
hmmmm |
paramat, there's a specific combination of mods that has the issue vanessae mentioned |
| 06:14 |
hmmmm |
snow biomes and the flower mod |
| 06:15 |
Zeno` |
my mod (glowworms) and plantlife as well |
| 06:15 |
paramat |
interesting ... |
| 06:15 |
hmmmm |
ughhh |
| 06:15 |
hmmmm |
i'm gonna have to install mods |
| 06:15 |
hmmmm |
i hate having to install mods |
| 06:15 |
Zeno` |
fortunately changing my mod to use set_node() makes very little difference performance wise (I still read the map using voxelmanip) so I worked around it |
| 06:23 |
paramat |
hmmmm, hope you saw my request for 'force placement' bool to remain in schematics |
| 06:23 |
hmmmm |
i would never remove features |
| 06:28 |
paramat |
cool, thanks |
| 06:29 |
Zeno` |
interesting |
| 06:29 |
Zeno` |
https://github.com/minetest/minetest/blob/master/builtin/game/register.lua#L347 |
| 06:30 |
Zeno` |
If I change that to for i = cb_len, 1, -1 do then my mod and plantlife coexist nicely, so obviously order is important |
| 06:33 |
|
khonkhortisan joined #minetest-dev |
| 06:34 |
paramat |
order of multiple 'on generated' callbacks? |
| 06:36 |
Zeno` |
the order they're called in, yeah |
| 06:36 |
paramat |
perhaps the order can be controlled with dependancies |
| 06:36 |
Zeno` |
Is there a way to force/prioritise order of on_generated callbacks? |
| 06:37 |
paramat |
i was told the order is the order of registration |
| 06:37 |
Zeno` |
I think VanessaE tried that, but the problem I have with that is putting plantlife as a dependency when it's not *really* a dependency in the strict sense of the word (IMO) |
| 06:37 |
Zeno` |
Yeah that seems to be the case |
| 06:38 |
paramat |
okay so that might explain your exception to our findings |
| 06:39 |
Zeno` |
possibly yes |
| 06:40 |
Zeno` |
There is no other way to control the order of callbacks other than the order mods are loaded? |
| 06:40 |
Zeno` |
on_generated callbacks* |
| 06:41 |
paramat |
doubt it |
| 06:44 |
Zeno` |
paramat, the depends doesn't fix it :/ |
| 06:44 |
paramat |
8/ |
| 06:44 |
Zeno` |
I think I would need to add my mod as a dependency to plantlife... which is kind of back to front |
| 06:44 |
hmmmm |
stop with the hacks already |
| 06:44 |
Zeno` |
I'm not hacking |
| 06:44 |
Zeno` |
I'm experimenting |
| 06:44 |
hmmmm |
it's a bug, simple |
| 06:44 |
hmmmm |
heh |
| 06:45 |
hmmmm |
honestly you're not getting too far with experimenting |
| 06:45 |
Zeno` |
experimenting to understand is helpful to ME |
| 06:45 |
hmmmm |
this is something i am pretty sure i know what's going on about |
| 06:45 |
paramat |
so the order isn't determined by order of registration? |
| 06:45 |
Zeno` |
well I am, because now I know that order is important and I know how the callbacks are actually called, so I learned something |
| 06:45 |
hmmmm |
vanessae insists that somehow set_node calls are overwritten by a voxelmanip object that has already committed its changes |
| 06:46 |
Zeno` |
It must be terribly boring to never experiment with things to see how they work :p |
| 06:46 |
hmmmm |
i can't say this is false because i haven't even run minetest in months, but it certainly smells like a lot of bullshit |
| 06:47 |
Zeno` |
How do you explain that things work if I reverse the order of callbacks? |
| 06:47 |
hmmmm |
it's probably that vanessa got confused with the order of the mods running, and set_node callbacks in on_generated are getting run before voxelmanip ones, and the voxelmanip object obviously doesn't get updated from a set_node call |
| 06:47 |
hmmmm |
in that case all I'd do is add a new voxelmanip function to check if the area it has loaded is dirty or not |
| 06:47 |
Zeno` |
I'm not suggesting that as a SOLUTION |
| 06:48 |
hmmmm |
changing order of callbacks is not a solution |
| 06:48 |
Zeno` |
I'm not suggesting that as a SOLUTION |
| 06:48 |
hmmmm |
i already know how to fix it --; |
| 06:48 |
Zeno` |
I did it to confirm that order was important and to aid in my understanding |
| 06:48 |
hmmmm |
if it is what i think i tis |
| 06:48 |
Zeno` |
sorry for being curious :p |
| 06:48 |
hmmmm |
anyway read my explanation from a couple lines up |
| 06:48 |
hmmmm |
you realize that a voxelmanip object contains a *copy* of the map, right? |
| 06:49 |
Zeno` |
I did. I think it's the reverse of what you said :) |
| 06:49 |
Zeno` |
Yes I do |
| 06:49 |
Zeno` |
A copy of when the object is created |
| 06:49 |
hmmmm |
when the map gets updated independently from the voxelmanip, the voxelmanip memory won't have those things that got changed |
| 06:49 |
Zeno` |
It doesn't seem threaded though |
| 06:49 |
hmmmm |
so then when you have a mod's on_generated callback get the voxelmanip for that area you just did some set_nodes on, it's going to have the way the map looks just after mapgen generation |
| 06:50 |
paramat |
! |
| 06:50 |
Zeno` |
so the data from the voxelmanip is not written back to the map when you call write_to_map()? |
| 06:50 |
hmmmm |
then when that voxelmanip memory is committed, it'll effectively "wipe out" changes |
| 06:50 |
hmmmm |
it is |
| 06:50 |
hmmmm |
it is written back to the map once you call that |
| 06:51 |
hmmmm |
but the data being written back is the data the voxelmanip currently has |
| 06:51 |
hmmmm |
not what the map has |
| 06:51 |
Zeno` |
ok it is. So why doesn't vmanip have a copy of the map in it's state after the previous on_generated callback? |
| 06:51 |
paramat |
voxelmanip should read from map the results of the previously run mod's actions |
| 06:51 |
hmmmm |
what vanessae contends is that this, in fact, is incorrect, and nonsensically, set_node changes are being wiped out far after the voxelmanip mod has run |
| 06:52 |
Zeno` |
It obviously does, otherwise the order of execution wouldn't matter and I've already shown that it does |
| 06:53 |
hmmmm |
Zeno`, the actual voxelmanip that was used by the mapgen is being modified whenever you call vm.set_data() |
| 06:53 |
hmmmm |
so if you have mod #1 get the voxelmanip object in on_generated and you set_data to all... stone or something |
| 06:53 |
Zeno` |
So there needs to be a way to call all the vmanip callbacks first |
| 06:53 |
hmmmm |
and then mod #2 on_generated fires, and gets the voxelmanip object... it'll have the stone there |
| 06:54 |
hmmmm |
but set_node() is completely different mechanism from voxelmanip |
| 06:54 |
hmmmm |
set_node directly modifies map |
| 06:54 |
hmmmm |
it does not know about any such voxelmanip objects that may have that area loaded in |
| 06:54 |
Zeno` |
ok it is. So why can't vmanip get a copy of the map in it the maps current state after the previous on_generated callback? |
| 06:54 |
hmmmm |
so you're saying you want every single on_generated callback to re-read the map? |
| 06:54 |
hmmmm |
that would certainly work, but do you realize how inefficient that is? |
| 06:54 |
Zeno` |
Probably not |
| 06:54 |
Zeno` |
Yes |
| 06:55 |
hmmmm |
now like i said |
| 06:55 |
hmmmm |
you'd only want to re-read this if the voxelmanip is dirty |
| 06:55 |
hmmmm |
i.e. if a node being contained inside the area of a voxelmanip had been modified outside of the voxelmanip |
| 06:55 |
Zeno` |
I can follow that, yes |
| 06:55 |
paramat |
ah i think i see ... |
| 06:56 |
Zeno` |
And that's how I've understood it all along |
| 06:56 |
Zeno` |
So a combination of order and some kind of dirty flag would, surely, solve the problem |
| 06:56 |
Zeno` |
anyway, bbiab |
| 06:56 |
Zeno` |
dinner time |
| 06:56 |
hmmmm |
so then i would just modify the get_data() to have a new boolean parameter to control the cache state |
| 06:56 |
hmmmm |
by default this would be 'true', as in "yes, re-load the map if the area had been invalidated since the last read" |
| 06:57 |
hmmmm |
and then get_data() would look like: |
| 06:57 |
Zeno` |
Thanks for explaining what bools are :p |
| 06:57 |
hmmmm |
if (this->is_dirty) |
| 06:57 |
hmmmm |
this->initialEmerge(p1, p2); |
| 06:57 |
hmmmm |
this->is_dirty = false; |
| 06:58 |
hmmmm |
or whatever |
| 06:58 |
hmmmm |
the difficult part here would be how to decide which voxelmanips are listening for changes to their area |
| 06:58 |
hmmmm |
i'd have to keep track of voxelmanips that are currently active on that Map object |
| 06:59 |
|
Anchakor joined #minetest-dev |
| 06:59 |
paramat |
i had assumed each 'on generated' always re-reads the map as it was left by the previous 'on generated' *:/ |
| 06:59 |
hmmmm |
so then when Map::setNode() is called, it'll loop through all the voxelmanips and then check if the position of the node being set is contained in a cuboid of one or more of the voxelmanips and then set their dirty flag |
| 07:00 |
hmmmm |
as you can already imagine, this is going to require synchronization nonsense |
| 07:00 |
hmmmm |
but without a doubt, it is the most efficient solution to the problem |
| 07:01 |
hmmmm |
for completeness, i'll have the mark-as-dirty check in voxelmanip blitbacks as well, to take care of the unusual edge case of two active voxelmanips with an intersecting area |
| 07:02 |
* paramat |
will probably make that unusual case happen |
| 07:02 |
hmmmm |
--; |
| 07:02 |
Zeno` |
or you could just add a some kind of priority when registering the callback and if none given put it at the back of the queue, and leave it for modders to decide in the meantime |
| 07:02 |
hmmmm |
..eh |
| 07:03 |
hmmmm |
how about i just do my non-hacky solution |
| 07:03 |
hmmmm |
grr |
| 07:03 |
hmmmm |
fine whatever |
| 07:03 |
Zeno` |
yep, ok. I didn't realise priorities were a hack. Most kernels use them. |
| 07:03 |
hmmmm |
priority should not matter here |
| 07:04 |
hmmmm |
there is no concept of priority for callbacks |
| 07:04 |
Zeno` |
In a perfect world, no |
| 07:04 |
Zeno` |
make it a concept |
| 07:04 |
paramat |
thanks for explaining hmmmmm |
| 07:04 |
Zeno` |
How does it hurt? |
| 07:05 |
hmmmm |
https://github.com/minetest/minetest/blob/master/builtin/game/register.lua#L378 |
| 07:06 |
Zeno` |
err, not exactly what I envisioned |
| 07:06 |
hmmmm |
change "function (func)" to "function (func, index)" and do table.insert(t, func) |
| 07:06 |
Zeno` |
yes |
| 07:06 |
hmmmm |
t, index, func rather |
| 07:06 |
Zeno` |
or just priority |
| 07:07 |
Zeno` |
and insert at the appropriate index |
| 07:07 |
hmmmm |
priority = priority or table.size |
| 07:07 |
Zeno` |
yes |
| 07:07 |
hmmmm |
so that way if the parameter isn't provided it'll just append |
| 07:07 |
Zeno` |
so that wouldn't break existing mods |
| 07:13 |
paramat |
okay 8am ... i'm off will read logs later |
| 07:13 |
Zeno` |
bye bye |
| 07:13 |
* paramat |
will sleep easier now |
| 07:14 |
|
paramat left #minetest-dev |
| 07:24 |
|
Garmine joined #minetest-dev |
| 07:24 |
|
PenguinDad joined #minetest-dev |
| 07:27 |
|
Calinou joined #minetest-dev |
| 07:53 |
|
Krock joined #minetest-dev |
| 08:06 |
|
casimir joined #minetest-dev |
| 08:31 |
|
proller joined #minetest-dev |
| 10:08 |
|
proller joined #minetest-dev |
| 10:14 |
|
kahrl joined #minetest-dev |
| 10:20 |
|
Krock joined #minetest-dev |
| 10:31 |
Zeno` |
Anything new happening? |
| 10:49 |
|
PenguinDad joined #minetest-dev |
| 10:50 |
|
PenguinDad joined #minetest-dev |
| 11:09 |
|
Megaf joined #minetest-dev |
| 11:09 |
Megaf |
heh, Minetest is abusing and burning my CPU acording to OS X dmesg, http://paste.debian.net/118344/ |
| 11:18 |
|
darkrose_ joined #minetest-dev |
| 11:20 |
|
ottodachshund joined #minetest-dev |
| 11:23 |
|
kahrl_ joined #minetest-dev |
| 11:27 |
|
VargaD_ joined #minetest-dev |
| 11:41 |
|
ImQ009 joined #minetest-dev |
| 11:49 |
|
proller joined #minetest-dev |
| 11:50 |
|
realbadangel_ joined #minetest-dev |
| 11:51 |
|
ImQ009_ joined #minetest-dev |
| 11:51 |
|
alexxss joined #minetest-dev |
| 11:52 |
|
AnotherBrick joined #minetest-dev |
| 11:52 |
|
kahrl joined #minetest-dev |
| 11:52 |
|
Zeno`` joined #minetest-dev |
| 11:53 |
Zeno`` |
yikes |
| 11:53 |
|
Zeno`` left #minetest-dev |
| 11:59 |
|
casimir joined #minetest-dev |
| 12:10 |
|
proller joined #minetest-dev |
| 12:12 |
Megaf |
heh, Minetest is abusing and burning my CPU acording to OS X dmesg, http://paste.debian.net/118344/ |
| 12:13 |
|
PilzAdam joined #minetest-dev |
| 12:14 |
|
Zeno` joined #minetest-dev |
| 12:16 |
Zeno` |
Well, it appears nobody has implemented the simple fix for voxelmanip. I guess we have to wait for the overly complex solution because the more complex it is the less likely it's a hack. |
| 12:18 |
PenguinDad |
Zeno`: simple fix for what? |
| 12:19 |
Zeno` |
voxelmanip; actuallt, order of on_generated callbacks |
| 12:20 |
|
ImNotQ009 joined #minetest-dev |
| 12:21 |
|
Weedy joined #minetest-dev |
| 12:21 |
|
Weedy joined #minetest-dev |
| 12:21 |
Zeno` |
hmmmm wants to do some crazy transaction based method when being able to simply specify the order or priority of those callbacks will solve the problem |
| 12:22 |
Zeno` |
Because the simple answer is a "bullshit hack" |
| 12:22 |
|
kahrl_ joined #minetest-dev |
| 12:24 |
Zeno` |
I have no idea why the more complex a solution is the "better" it is |
| 12:25 |
|
troller joined #minetest-dev |
| 12:27 |
Zeno` |
I guess IRQ priorities are a hardware hack |
| 12:27 |
Zeno` |
that don't address the order of execution problem properly :/ |
| 12:28 |
|
Zeitgeist_ joined #minetest-dev |
| 12:29 |
|
book` joined #minetest-dev |
| 12:41 |
|
troller joined #minetest-dev |
| 12:41 |
|
Zeitgeist_ joined #minetest-dev |
| 12:42 |
|
Krock2 joined #minetest-dev |
| 12:43 |
|
crazyR joined #minetest-dev |
| 12:49 |
|
Jordach joined #minetest-dev |
| 13:01 |
|
darkrose_ joined #minetest-dev |
| 13:03 |
|
realbadangel__ joined #minetest-dev |
| 13:06 |
|
ImQ009_ joined #minetest-dev |
| 13:07 |
|
crazyR joined #minetest-dev |
| 13:07 |
|
sfan5 joined #minetest-dev |
| 13:09 |
|
FungusAdam joined #minetest-dev |
| 13:21 |
|
realbadangel__ joined #minetest-dev |
| 13:21 |
|
Zeno` joined #minetest-dev |
| 13:30 |
|
ImNotQ009 joined #minetest-dev |
| 13:32 |
|
Robby_ joined #minetest-dev |
| 13:33 |
|
Kray_ joined #minetest-dev |
| 13:48 |
|
NakedFury joined #minetest-dev |
| 14:16 |
|
EvergreenTree joined #minetest-dev |
| 14:17 |
|
^v joined #minetest-dev |
| 14:23 |
|
CraigyDavi joined #minetest-dev |
| 14:32 |
Sokomine |
i'm not sure if a dirty flag will help. the villages-code uses voxelmanip for the entire area; yet it has to resort to set_node or similar for metadata. perhaps it might be easier to pass changes done via set_node/add_node/remove_node in on_generated to the voxelmanip data? |
| 14:33 |
Sokomine |
but i don't really know the code. if this suggestion is rubbish, just forget about it |
| 14:35 |
|
PenguinDad joined #minetest-dev |
| 14:35 |
Zeno` |
Being able to set the order that the on_generated callbacks are called can solve the issue |
| 14:35 |
Zeno` |
there is no need to complicated this Sokomine |
| 14:35 |
Zeno` |
complicate* |
| 14:36 |
Zeno` |
But, I don't thing voxelmanip affects metadata anyway so that's probably a separate issue (from memory the only thing that voxelmanip does is set param0 aka the node id) |
| 14:37 |
Zeno` |
content id* |
| 14:37 |
Zeno` |
whatever it's called :) |
| 14:42 |
Sokomine |
that's right. and that's why - in this special case - further calls are needed additionally to voxelmanip. the main work can be done by voxelmanip though. just the chests etc. need special treatment |
| 14:42 |
Zeno` |
What I am annoyed about it hmmm's attitude |
| 14:42 |
Zeno` |
<Zeno`> interesting |
| 14:42 |
Zeno` |
<Zeno`> https://github.com/minetest/minetest/blob/master/builtin/game/register.lua#L347 |
| 14:42 |
Zeno` |
<Zeno`> If I change that to for i = cb_len, 1, -1 do then my mod and plantlife coexist nicely, so obviously order is important |
| 14:43 |
Sokomine |
there'd be no need to invoke any dirty flags in this case as the nodes themshelves are not changed |
| 14:43 |
Zeno` |
<hmmmm> stop with the hacks already |
| 14:43 |
Zeno` |
<Zeno`> I'm not hacking |
| 14:43 |
Zeno` |
<Zeno`> I'm experimenting |
| 14:43 |
Zeno` |
after that I reiterated that what I was doing was not a solution |
| 14:44 |
Zeno` |
and he kept going on about how my solution was a hack when it was never meant as a solution, merely an observation |
| 14:44 |
Sokomine |
hmmmm is not always easy to get around with. yet he does excellent work. |
| 14:44 |
Zeno` |
I agree |
| 14:45 |
Zeno` |
but jumping to conclusions about what I was saying is... insulting |
| 14:45 |
Zeno` |
putting words in my mouth and not even listening when I try to correct those assumptions |
| 14:45 |
Zeno` |
anyway, I'm over it :) |
| 14:46 |
Zeno` |
the "proper" way is not always the correct way btw |
| 14:47 |
Sokomine |
fine :-) getting along with each other and managing to communicate is sometimes difficult with all those diffrent languages, cultures and personalities out there |
| 14:47 |
Zeno` |
yep |
| 14:49 |
|
Tesseract joined #minetest-dev |
| 14:50 |
|
gentoobr1 joined #minetest-dev |
| 14:53 |
|
Ritchie_ joined #minetest-dev |
| 14:55 |
|
rmilan joined #minetest-dev |
| 14:55 |
|
Robby joined #minetest-dev |
| 14:56 |
celeron55_ |
i'm sure all of you know how to discuss things objectively, so just do that with the goal of making stuff that will work years into the future without becoming a PITA |
| 15:00 |
celeron55_ |
(the hardest part for me tends to be having to explain complex things to some random people on the internet who are likely to just do nothing and disappear and make the whole discussion a wasted effort; there's no good way of fixing that; every established developer can have that problem) |
| 15:02 |
celeron55_ |
(so new guys: yes, you're almost worthless until you prove otherwise and you will always see it in how busy people act towards you; however, it will change at the instant you make something that is accepted into the project) |
| 15:03 |
Zeno` |
Ok, well I was being objective |
| 15:03 |
Zeno` |
I don't expect to be attacked for making an observation |
| 15:04 |
|
sfan5_ joined #minetest-dev |
| 15:04 |
Zeno` |
I don't expect it in real life and I don't expect in on IRC |
| 15:04 |
Zeno` |
it* |
| 15:04 |
celeron55_ |
yes hmmmm isn't always fair at all; don't take it too personally |
| 15:05 |
Zeno` |
Oh, I'm over it now |
| 15:05 |
celeron55_ |
me neither |
| 15:05 |
|
sfan5- joined #minetest-dev |
| 15:05 |
celeron55_ |
i just decided to throw some random half-philosophical thoughts in here and that's almost always a bad idea |
| 15:08 |
Zeno` |
The strange thing is that I'm asleep right now |
| 15:08 |
Zeno` |
I have no idea who's typing this |
| 15:08 |
|
Ritchie joined #minetest-dev |
| 15:09 |
celeron55_ |
i'm being very random but... like, i'm bothered by you having to get over it 8) |
| 15:10 |
Zeno` |
I'm sorry for making you bothered |
| 15:10 |
Zeno` |
:p |
| 15:10 |
celeron55_ |
anyway it looks like you got a lot of answers so that discussion doesn't seem all that bad |
| 15:10 |
Zeno` |
In the end it turned out fine, which is why "I'm over it" (perhaps a bad choice of words) |
| 15:11 |
Sokomine |
it's good that you're bothered about it :-) apart from all the technical aspects, we sometimes have to remind ourshelves that there are other humans behind the screen - and that missunderstandings are easy and some things sound more harsh. while at the same time devs prefer to get a good solution to a problem |
| 15:11 |
celeron55_ |
my point is, always when discussing with someone who originally made a feature, the discussion will be harsh |
| 15:12 |
celeron55_ |
more or less such, depending on the personality of the author |
| 15:12 |
Sokomine |
(and yes, i know that all those "users" can be very annoying :-) especially if they take a long time to understand what's so obvious to oneshelf) |
| 15:12 |
Zeno` |
no no, I was more bothered by the immediate assumption that I was suggesting a solution (when I was not, and I thought I made that clear) |
| 15:12 |
Zeno` |
Perhaps I need to brush up on MY communication skills |
| 15:12 |
celeron55_ |
oh yeah, making a distinction between an experiment and a proposal is important |
| 15:12 |
celeron55_ |
half of MT is a bodge of random experiments that were just left there so that is easy to miss |
| 15:13 |
Zeno` |
Anyway, can we move on from this? :) |
| 15:13 |
realbadangel__ |
hi |
| 15:13 |
celeron55_ |
yes |
| 15:13 |
PenguinDad |
Hey RealBadAngel |
| 15:14 |
Zeno` |
Thanks. And good night :) |
| 15:14 |
Zeno` |
Hi RBA, bye RBA |
| 15:14 |
|
Zeno` left #minetest-dev |
| 15:14 |
RealBadAngel |
celeron55_, lately i made a commit with main menu music score |
| 15:15 |
RealBadAngel |
it was kinda old style, demoscene |
| 15:15 |
RealBadAngel |
most of the folks do not like it (why oh why) ;) |
| 15:15 |
RealBadAngel |
so i found a new one |
| 15:16 |
RealBadAngel |
http://incompetech.com/music/royalty-free/mp3-royaltyfree/The%20Descent.mp3 |
| 15:17 |
RealBadAngel |
celeron55_, can you try it? |
| 15:18 |
celeron55_ |
no we won't have common main menu music |
| 15:19 |
RealBadAngel |
you want them per game? |
| 15:19 |
celeron55_ |
at most |
| 15:19 |
RealBadAngel |
two cons then |
| 15:19 |
RealBadAngel |
minimal is default |
| 15:19 |
celeron55_ |
but games don't really need main menu music and MT doesn't really need music anywhere anyway |
| 15:19 |
RealBadAngel |
and will be chosen at first sight |
| 15:20 |
celeron55_ |
minimal should be disabled from the menu by defauult |
| 15:20 |
celeron55_ |
-u |
| 15:20 |
celeron55_ |
(unless it's the only one available, maybe) |
| 15:20 |
RealBadAngel |
thats good idea |
| 15:21 |
RealBadAngel |
but my 2nd thought, if music score will be per game, selecting games will make it a jukebox |
| 15:21 |
RealBadAngel |
and above all yes, we do need music |
| 15:22 |
RealBadAngel |
you may curse me or whatever, but a game need a music |
| 15:24 |
|
Calinou joined #minetest-dev |
| 15:25 |
celeron55_ |
well, it can improve the experience of a game, which is why i'm okay with having it per-game for that purpose |
| 15:25 |
|
troller joined #minetest-dev |
| 15:25 |
PenguinDad |
RealBadAngel: that song is much better than your previous suggestion imo |
| 15:27 |
|
Amaz joined #minetest-dev |
| 15:28 |
Sokomine |
many players did indeed complain about lack of music/sound effect quality and asked for improvements on the forum |
| 15:31 |
RealBadAngel |
celeron55_, ingame music is up for games |
| 15:32 |
RealBadAngel |
we are talkin now bout main score |
| 15:32 |
RealBadAngel |
the flagship |
| 15:32 |
Calinou |
music playing by default is problematic for users with high OS/hardware volume and people using headphones |
| 15:33 |
celeron55_ |
there is no common feeling or anything to try to embrace in the main menu with music |
| 15:33 |
RealBadAngel |
stop jokin |
| 15:33 |
celeron55_ |
it's not useful at all |
| 15:33 |
Calinou |
it leads to people starting the game for the first time, then going all “Argh! My Sennheisers!â€â€¦ |
| 15:33 |
RealBadAngel |
sound playing was problematic in 8-bit age |
| 15:33 |
celeron55_ |
instead, games can have such in the menu so game-specific makes sense |
| 15:33 |
Calinou |
it's not a matter of sound quality here |
| 15:33 |
RealBadAngel |
not 21st century |
| 15:33 |
Calinou |
volume is the problem |
| 15:33 |
|
mrtux joined #minetest-dev |
| 15:34 |
celeron55_ |
Calinou: you can't be serious |
| 15:34 |
RealBadAngel |
and before any dare to ask |
| 15:34 |
celeron55_ |
if you start a game, you expect it to have sound |
| 15:34 |
celeron55_ |
that isn't an issue |
| 15:34 |
RealBadAngel |
i tested a few tunes on my sennheisers |
| 15:34 |
RealBadAngel |
at work |
| 15:35 |
RealBadAngel |
few hours per tune |
| 15:35 |
RealBadAngel |
they dont get annoying |
| 15:36 |
Calinou |
not really |
| 15:36 |
Calinou |
I am serious. |
| 15:36 |
Calinou |
it's as problematic as sound-playing sites that play on page load. |
| 15:37 |
Calinou |
by the way, Minecraft doesn't play immediatly music when starting it |
| 15:37 |
RealBadAngel |
fade in and fade out |
| 15:38 |
Calinou |
you need a long fade in, at least 5 seconds |
| 15:38 |
RealBadAngel |
(in case we would make them per gme) |
| 15:38 |
RealBadAngel |
*game |
| 15:39 |
RealBadAngel |
btw technic and dreambuilder scores are also propably picked |
| 15:39 |
RealBadAngel |
dreambuilder: http://incompetech.com/music/royalty-free/mp3-royaltyfree/Americana.mp3 |
| 15:40 |
RealBadAngel |
technic game: http://incompetech.com/music/royalty-free/mp3-royaltyfree/Americana.mp3 |
| 15:40 |
RealBadAngel |
ooops |
| 15:40 |
RealBadAngel |
http://incompetech.com/music/royalty-free/mp3-royaltyfree/Future%20Gladiator.mp3 |
| 15:41 |
RealBadAngel |
^^ above is for Technic |
| 15:41 |
Calinou |
.mp3? no thanks |
| 15:41 |
Calinou |
not even converted |
| 15:41 |
Calinou |
royalty-free is not enough |
| 15:42 |
Calinou |
also no loaded songs |
| 15:44 |
RealBadAngel |
license is good to go |
| 15:44 |
RealBadAngel |
convertion is not a problem |
| 15:44 |
RealBadAngel |
its cc license |
| 15:44 |
Calinou |
it decreases quality in a visible way |
| 15:44 |
Calinou |
“Which CC?†|
| 15:44 |
Calinou |
modification and commercial use must be allowed |
| 15:45 |
RealBadAngel |
we are not commercial |
| 15:45 |
Calinou |
… |
| 15:45 |
Calinou |
preventing commercial use is non-free: http://freedomdefined.org/Licenses/NC |
| 15:45 |
RealBadAngel |
we do not need that |
| 15:45 |
Calinou |
we sure do |
| 15:45 |
RealBadAngel |
no we dont |
| 15:45 |
RealBadAngel |
cc by sa is enough for us |
| 15:45 |
Calinou |
forks of Minetest are getting sold right as we speak 8) |
| 15:45 |
Calinou |
… |
| 15:45 |
Calinou |
whoa |
| 15:46 |
Calinou |
you really have no idea what you're talking about |
| 15:46 |
Calinou |
CC BY-SA doesn't prevent commercial use |
| 15:46 |
Calinou |
what does is CC BY-NC or CC BY-NC-SA |
| 15:46 |
RealBadAngel |
The Standard License is available for projects where attribution is not wanted or is otherwise impossible. (radio ad, TV ad, corporate presentation, commercial short, on-hold music, etc.) |
| 15:46 |
RealBadAngel |
There is no charge for a Creative Commons license. It does require that you credit the music. |
| 15:47 |
Calinou |
if you buy a license, it's exclusive and thus non-free |
| 15:47 |
RealBadAngel |
but if you fuckin insist i will buy the license |
| 15:47 |
RealBadAngel |
is that ok with you? |
| 15:49 |
Calinou |
no. |
| 15:49 |
RealBadAngel |
credit is enough in our case |
| 15:50 |
Calinou |
do you understand what I say? |
| 15:50 |
Calinou |
there are several CC licenses |
| 15:50 |
Calinou |
some are free, some aren't |
| 15:50 |
Calinou |
(free as in freedom.) |
| 15:51 |
RealBadAngel |
There is no charge for a Creative Commons license. It does require that you credit the music. |
| 15:51 |
RealBadAngel |
please translate it to english |
| 15:52 |
Calinou |
<Calinou> (free as in freedom.) |
| 15:52 |
Calinou |
not about price |
| 15:53 |
RealBadAngel |
facts please |
| 15:53 |
VanessaE |
Calinou: on the site RBA gets that music from, all of the "royalty free" music, the license is CC-by-SA 3.0 unported. No ND or NC clause. |
| 15:53 |
RealBadAngel |
usage, pirce, conditions |
| 15:53 |
Calinou |
ah |
| 15:53 |
Calinou |
still .mp3 and possibly sounds like crap |
| 15:53 |
VanessaE |
Calinou: nope, sounds pretty good. |
| 15:54 |
RealBadAngel |
why the fuck you are thinkin we gonna use mp3? |
| 15:54 |
RealBadAngel |
and even if, so what |
| 15:54 |
VanessaE |
RealBadAngel: "Americana" sounds like something by Alan Silvestri.. "Forrest Gump" or similar |
| 15:55 |
RealBadAngel |
i picked that because youre female and i kinda know your taste |
| 15:55 |
RealBadAngel |
was i right? |
| 15:55 |
VanessaE |
mmhmm |
| 15:55 |
VanessaE |
pretty close yes |
| 15:55 |
Calinou |
conversion decreases quality |
| 15:55 |
RealBadAngel |
kinda opposite to technic tribal one yes? ;) |
| 15:56 |
VanessaE |
RealBadAngel: yeah |
| 15:56 |
VanessaE |
about as opposite as it gets :P |
| 15:56 |
RealBadAngel |
calinou for that i can buy aiifs |
| 15:56 |
VanessaE |
Calinou: it can if the codecs suck |
| 15:56 |
VanessaE |
Calinou: but if you have a high enough bitrate for the source material, then it doesn't matter - if you can't hear the loss of quality, then it's not important that there is one |
| 15:56 |
* Calinou |
facepalms |
| 15:57 |
Calinou |
VanessaE, yes, if your mp3 is 320 kb/s it'll be fine |
| 15:57 |
Calinou |
sadly, most of them are 192 kb/s |
| 15:57 |
RealBadAngel |
calinou, you realize that for game usage we have to make it mono |
| 15:57 |
RealBadAngel |
and lower the bitrate? |
| 15:57 |
VanessaE |
Calinou: that "Americana" was 320 kbps. |
| 15:58 |
Calinou |
OK |
| 15:58 |
troller |
olly .flac!!! |
| 15:58 |
troller |
only |
| 15:58 |
Calinou |
making it mono isn't a problem |
| 15:58 |
Calinou |
RealBadAngel, you don't have to lower bitrate |
| 15:58 |
RealBadAngel |
only troller :P |
| 15:58 |
Calinou |
keep it reasonably high |
| 15:58 |
Calinou |
I don't think the music is even sent in multiplayer |
| 15:58 |
RealBadAngel |
i know what i wanna do with main menu |
| 15:58 |
VanessaE |
Future Gladiator is also 320 kbps. |
| 15:58 |
troller |
all music lower 1mbps - noisy shit!!! |
| 15:59 |
RealBadAngel |
i want the scene, with player in the middle |
| 15:59 |
RealBadAngel |
and 360degs panorama |
| 15:59 |
RealBadAngel |
and fuckin music for that |
| 15:59 |
RealBadAngel |
cinematic |
| 15:59 |
* Calinou |
facepalm |
| 15:59 |
Calinou |
I stopped reading at “panorama†|
| 15:59 |
VanessaE |
troller: double-blind studies have already ruled that even the best audiophiles can't tell the difference between FLAC and anything over roughly 256 kbps. |
| 15:59 |
Calinou |
stop imitating Minecraft stuff |
| 16:00 |
Calinou |
VanessaE, high-quality OGG is still useful |
| 16:00 |
RealBadAngel |
lol |
| 16:00 |
VanessaE |
Calinou: indeed, good for a "master" format |
| 16:00 |
VanessaE |
sorta like the 2k and higher files I use for HDX |
| 16:00 |
RealBadAngel |
calinou, i was demoscene coder before notch started to shit in his pants |
| 16:00 |
Calinou |
no, for listening |
| 16:01 |
VanessaE |
Calinou: for listening only if the quality is above your personal threshold, yes |
| 16:01 |
Calinou |
not everyone has the same threshold |
| 16:01 |
VanessaE |
I know |
| 16:01 |
VanessaE |
but as I said, double-blind studies already worked this out. |
| 16:01 |
RealBadAngel |
if i mean main menu score i mean whole the effect |
| 16:01 |
RealBadAngel |
movie plus music |
| 16:02 |
VanessaE |
most people in a silent, sound-controlled environment can't tell the difference between 256 kbps and an uncompressed source. |
| 16:02 |
RealBadAngel |
the way how it should look like |
| 16:02 |
VanessaE |
hell most can't tell 128 kpbs from an uncompressed source if the codec is good enough and the speakers/headphones are "just okay" |
| 16:02 |
VanessaE |
and that's like 90% of the listening public. |
| 16:02 |
RealBadAngel |
to attract the folks and bring them to their knees |
| 16:03 |
|
zat joined #minetest-dev |
| 16:03 |
VanessaE |
(and I say this as someone who always uses the highest quality settings or opts for FLAC whenever possible in her own music library) |
| 16:03 |
RealBadAngel |
game doesnt need loseless formats |
| 16:03 |
RealBadAngel |
ogg is enougn |
| 16:04 |
VanessaE |
ogg is fine as long as the source material is well-mastered, noise-free, and a good codec is used to create the ogg |
| 16:04 |
RealBadAngel |
decent music i managed to play on RS latches |
| 16:04 |
RealBadAngel |
on Z80 |
| 16:05 |
RealBadAngel |
and i made and soldered all of them |
| 16:08 |
VanessaE |
I'll do you one better - I did it with an R-2R ladder on the C64 user port :D |
| 16:09 |
RealBadAngel |
latches were first, to hold the signal |
| 16:09 |
RealBadAngel |
ladders were after them |
| 16:10 |
Calinou |
and you whine about audiophiles… |
| 16:12 |
VanessaE |
Calinou: this was before MP3 existed :P |
| 16:13 |
RealBadAngel |
im not audiophile, im technocrate |
| 16:13 |
VanessaE |
neither am I an audiophile. :) |
| 16:13 |
VanessaE |
a music lover listens to the music. an audiophile listens to the noise :P |
| 16:14 |
RealBadAngel |
vinyl noise is rare and precious |
| 16:33 |
|
Krock joined #minetest-dev |
| 16:38 |
casimir |
For main menu music this is a good source: http://opengameart.org/art-search-advanced?keys=loop&field_art_type_tid[]=12 |
| 16:54 |
RealBadAngel |
from what i can see, whatever i will choose and make, there will be always a hater there |
| 16:54 |
RealBadAngel |
so i will just do my best to make it shine |
| 16:56 |
|
OldCoder joined #minetest-dev |
| 16:56 |
RealBadAngel |
game main menu should be a visit card of the game |
| 16:56 |
RealBadAngel |
not pull down submenu of the system |
| 17:00 |
Calinou |
make it have a better theme first |
| 17:00 |
Calinou |
more readable buttons, larger font |
| 17:04 |
VanessaE |
Calinou: sapier's working on that. |
| 17:04 |
VanessaE |
and zefram_fysh |
| 17:04 |
Calinou |
textures are not necessarily a better choice. |
| 17:05 |
Calinou |
procedural generation is preferable |
| 17:05 |
Calinou |
hello, high-DPI screens… |
| 17:26 |
|
paramat joined #minetest-dev |
| 17:46 |
paramat |
320mp3 sounds okay, but i notice a difference to FLAC. The game engine is neutral so can't have music, it's a game thing. Music in menus is a waste of memory because players only spend a few seconds there. Music files are super-heavy, it's far better for players to provide their own music than doubling/tripling the size of a MT download for music most will tire of quickly, i'd rather download additional subgames. |
| 17:53 |
Calinou |
^ |
| 17:53 |
Calinou |
theme-less games can't really have music |
| 17:53 |
Calinou |
or very neutral, classical one |
| 17:54 |
paramat |
Would music be downloaded to clients? seems to me media download would become unbearable. |
| 17:55 |
Calinou |
unlikely |
| 17:57 |
paramat |
If players ask for music it's because they're used to mainstream games, we should give them a refreshing change and encourage them to provide their own choice of music. |
| 17:59 |
paramat |
Also, i'm impresses that RBA can listen to a tune on repeat for hours without getting tired of it, who else could do that? ;) |
| 18:00 |
paramat |
(impressed) |
| 18:00 |
Calinou |
our issue list is long enough |
| 18:00 |
Calinou |
how about we instead tackle it? |
| 18:04 |
VanessaE |
Calinou: what? are you crazy? |
| 18:04 |
VanessaE |
FIX ISSUES? |
| 18:04 |
* VanessaE |
gasps at the horror |
| 18:04 |
Calinou |
eg. https://github.com/minetest/minetest_game/pull/312 |
| 18:08 |
paramat |
We'ew so lucky to have the top devs we do, this game would be such a mess otherwise |
| 18:08 |
paramat |
(we're) |
| 18:10 |
Calinou |
top devs?! |
| 18:10 |
Calinou |
developers are mostly bad |
| 18:10 |
Calinou |
we have a lunatic, a Minecraft emulator, a troll, a mathematician… |
| 18:11 |
PenguinDad |
What's bad about mathematicians? |
| 18:13 |
Calinou |
they spend their time making stupid mapgens that look pretty :/ |
| 18:13 |
Calinou |
we've clearly seen this last year |
| 18:13 |
Calinou |
but they're unplayable |
| 18:14 |
paramat |
Zeno`, if you see this, hmmmmm would have been sleeping straight after our chat so could not have worked on voxelmanip |
| 18:23 |
paramat |
anyway bbl |
| 18:23 |
|
paramat left #minetest-dev |
| 18:29 |
Jordach |
Calinou, if someone fucking asked I'd make MGV7 mapgens a thing |
| 18:30 |
Calinou |
meh, just look at small issues, fix them |
| 18:30 |
Jordach |
and i noticed the -dev attachment again |
| 18:33 |
* Jordach |
purrs at Calinou |
| 18:33 |
Jordach |
again |
| 18:34 |
|
Jordach left #minetest-dev |
| 18:36 |
* sfan5 |
meows at Calinou |
| 18:45 |
|
Calinou joined #minetest-dev |
| 18:53 |
RentedMule |
does anyone know the name of the prefered deb/ubuntu package for redis library support? |
| 18:55 |
RentedMule |
ah, it's hiredis. |
| 19:31 |
|
Megaf joined #minetest-dev |
| 19:34 |
Sokomine |
if you want to fix bugs, there's still https://github.com/minetest/minetest/issues/944 |
| 19:34 |
* Sokomine |
looks hopefully |
| 19:35 |
Sokomine |
upon celerons suggestion, i've added more documentation regarding the bug and a simple mod that makes testing regarding potential bugfixes easier: https://github.com/Sokomine/experimental |
| 19:38 |
Sokomine |
the documentation of the bug and the steps to reproduce it can be found in the README.txt of said mod |
| 19:47 |
celeron55_ |
Sokomine: i don't think the api needs any extensions for this |
| 19:47 |
celeron55_ |
what should happen is that both of the slots get called allow_put and allow_take, and then that happens if all of those four things are allowed |
| 19:51 |
Sokomine |
if all four calls where done, that'd be fine, yes. 2 calls may do already - player inventory is usally of less intrest/does not have those limitations |
| 19:51 |
celeron55_ |
it's a bit weird though, i'm not sure if it causes ambiguous situations |
| 19:51 |
Sokomine |
although...a function that checks when a player gets or looses inventory might also be useful as an api fucntcion |
| 19:52 |
celeron55_ |
well there can be other inventories than the player's inventory |
| 19:52 |
Sokomine |
perhaps the swapping parameter might be easier to implement. it would solve the current problem |
| 19:52 |
Sokomine |
hm. you're right. it's just that we somehow always have the player's inventory at the bottom half of the screen. it's so common players may even get confused if it where otherwise |
| 19:53 |
celeron55_ |
well, you can put them side by side or something to make the distinction; in any case, it's entirely possible |
| 19:53 |
celeron55_ |
anyway, that extra will_swap parameter doesn't give control for what the item to be swapped into the place is, which could be bad for some purpose |
| 19:54 |
celeron55_ |
i guess extending the api could be done by adding an entirely new allow_swap call for this, IF extending it is needed |
| 19:55 |
Sokomine |
no, it doesn't give control. the only thing which could be done then would be to deny the move - which would be better than the current state |
| 19:55 |
celeron55_ |
any decision made here will certainly shape the feel of the system to both players and modders |
| 19:55 |
Sokomine |
i thought about providing information about the destination stack, but that seemed more complicated |
| 19:57 |
celeron55_ |
i think i could accept the will_swap parameter if more modders agree that it will work for enough purposes |
| 19:58 |
Sokomine |
not necessarily. if we choose your patch, it would have a lot of impact and be rather impractical, although it does fix the bug. trouble is: in most cases, the swapping is a good/convenient solution for the player |
| 19:58 |
celeron55_ |
then checking the move will require just two allow_take calls with that parameter set |
| 19:59 |
Sokomine |
good question. i don't know how many ran into this problem. i'm not sure there's any other mod out there which might have that issue; for most inventories, it might be a slight inconvenience to have input in an output-only slot, but it does not matter (i.e. furnaces - who really cares if they get input in their output slots?) |
| 20:04 |
Megaf |
what do you think about this? |
| 20:04 |
Megaf |
process minetest[3462] thread 200631 caught burning CPU!; EXC_RESOURCE supressed due to audio playback |
| 20:04 |
Megaf |
That’s what my OS X’s dmesg says |
| 20:13 |
|
hmmmm joined #minetest-dev |
| 20:22 |
|
casimir joined #minetest-dev |
| 20:59 |
hmmmm |
Zeno`: I did not say that priorities were a hack, my point was that using priorities to solve this particular problem is a hack |
| 21:00 |
hmmmm |
like for example how many CPUs do you know order multiple loads/stores across different threads in order to save on cache invalidation/flush logic? none |
| 21:01 |
hmmmm |
i didn't implement that load order thing last night because it was past 3 AM and i thought i sufficiently explained what needed to be done so somebody else (like you) could do it... |
| 21:02 |
hmmmm |
it might take 5 seconds to code but you still have to test it to make sure it works and that's what will take longer to do |
| 21:02 |
hmmmm |
so i can't do that at 3 AM in the morning |
| 21:02 |
hmmmm |
s/load order/callback order/ |
| 21:03 |
VanessaE |
I wanted to ask...exactly what IS the order of callbacks? determined by dependency resolving, alpha order otherwise? or something else? |
| 21:03 |
hmmmm |
the most recently registered callback gets added last |
| 21:04 |
hmmmm |
so if mod A is a dependency of mod B, and mod A has an on_generated as well as mod B, mod A's callback will be called first followed by mod B |
| 21:04 |
VanessaE |
ok, that's what I figured. |
| 21:05 |
hmmmm |
all this morning i've been doing family stuff and cleaning the house, and soon I'm going to some festival with my gf, so I don't know how much work I can put in |
| 21:05 |
hmmmm |
see I only get the weekends to do this |
| 21:05 |
hmmmm |
=/ |
| 21:05 |
VanessaE |
I know. |
| 21:06 |
hmmmm |
and I'm only basing my solution to this issue off of what it sounds like from people talking and my knowledge of the code |
| 21:06 |
hmmmm |
you maintain that i'm incorrect though |
| 21:06 |
hmmmm |
i can only know for sure if i try it independently |
| 21:07 |
VanessaE |
the only thing I maintain being incorrect is that you can't pass the same map data to two or more callbacks. it's nonsensical. Somewhere, one of them has to be able to get the results of the other so that it can modify that data. |
| 21:08 |
hmmmm |
did you read the log of last night |
| 21:08 |
hmmmm |
i explained exactly what the issue is if mod A does set_node() and mod B does voxelmanip |
| 21:08 |
VanessaE |
I did, but I'm not entirely sure I understand what the solution will end up being,. |
| 21:08 |
hmmmm |
you say that the problem exists if mod A does voxelmanip and mod B does set_node() which makes nosense |
| 21:09 |
hmmmm |
(the order of execution being A, then B, to be precise) |
| 21:09 |
VanessaE |
yes and you also explained that you still have yet to actually install mods and *try* it. |
| 21:09 |
VanessaE |
whereas Zeno, paramat, SPlizard, jp and I have all done so to one degree or another. |
| 21:09 |
hmmmm |
don't know who jp is |
| 21:10 |
* VanessaE |
grumbles. |
| 21:10 |
VanessaE |
you didn't read what I wrote then. |
| 21:10 |
VanessaE |
[08-29 01:33] <VanessaE> is *anyone* gonna look into it? it's been a problem since last February. |
| 21:10 |
VanessaE |
[08-29 01:35] <VanessaE> https://forum.minetest.net/viewtopic.php?p=129941#p129941 <---- first report I recall seeing of this issue. |
| 21:11 |
VanessaE |
I understand perfect about not having time to look into stuff. |
| 21:11 |
VanessaE |
I get that. |
| 21:11 |
VanessaE |
but ^^^^^ that, I don't get. |
| 21:11 |
VanessaE |
no reasonable person would. |
| 21:13 |
VanessaE |
since I wrote that within 1 minute of your last statement to the same effect, and you never responded, I assumed you had me on /ignore at that point, so I just left for the night. |
| 21:13 |
hmmmm |
i don't ignore people |
| 21:13 |
hmmmm |
i find that rather juvenile |
| 21:13 |
VanessaE |
same here. |
| 21:13 |
hmmmm |
compiling the most recent minetest now |
| 21:14 |
hmmmm |
so what two mods do I need to replicate the problem? |
| 21:14 |
VanessaE |
SPLizard's snow mod and my plantlife modpack. |
| 21:14 |
VanessaE |
https://github.com/Splizard/minetest-mod-snow/ |
| 21:14 |
VanessaE |
https://github.com/VanessaE/plantlife_modpack |
| 21:15 |
hmmmm |
is there a reason why splizzard's name is capitalized in that manner? |
| 21:15 |
VanessaE |
you will have to disable SPlizard's compatibility "hack" - edit snow mod's src/mapgen_v6.lua and comment out lines 307 and 324 |
| 21:15 |
hmmmm |
lol exit to menu crashes minetest |
| 21:16 |
hmmmm |
hooray |
| 21:16 |
VanessaE |
the capitalization? I think that's how he writes it in the forum. |
| 21:16 |
hmmmm |
S.P. Lizard |
| 21:16 |
VanessaE |
*checks*... actually it's Splizard |
| 21:17 |
VanessaE |
(also I have a rollover glitch between my hands and this piece of shit keyboard, so stuff comes out with excess caps) |
| 21:17 |
hmmmm |
just drag & drop the mod directory into minetest/mods? |
| 21:18 |
VanessaE |
for plkntlife, yeah |
| 21:18 |
hmmmm |
so the directory layout is like minetest/mods/minetest-mod-snow-master/init.lua? |
| 21:18 |
VanessaE |
plantlife* |
| 21:18 |
hmmmm |
does the directory name matter? |
| 21:18 |
VanessaE |
for snow mod, I think it has to be named "snow" |
| 21:18 |
hmmmm |
how about yours |
| 21:18 |
VanessaE |
directory name matters for mods, but not for modpacks. |
| 21:18 |
VanessaE |
mine can be anything; the existing name should be fine |
| 21:19 |
hmmmm |
jesus christ |
| 21:20 |
hmmmm |
i don't mean to knock splizard, but doesn't he realize the importance of breaking up functions into smaller chunks? |
| 21:20 |
VanessaE |
heh |
| 21:20 |
hmmmm |
if you have more than 4 levels of indentation, you're doing it wrong |
| 21:20 |
VanessaE |
well I'm not much better though I have some changes to make in plantlife (for that very reason) |
| 21:21 |
* VanessaE |
inserts a missing comma where needed. |
| 21:21 |
hmmmm |
agh shoot did i need to do something special to enable the mods on map creation |
| 21:21 |
VanessaE |
yes |
| 21:21 |
hmmmm |
s/map/world/ |
| 21:21 |
VanessaE |
click the map name, hit "Configure" |
| 21:22 |
hmmmm |
yeah found it |
| 21:22 |
hmmmm |
i don't recall needing to do that... |
| 21:22 |
VanessaE |
click the mod in the list, check the "enable" checkbox at the top, and for the modpack, click the top level of the modpack name and click "Enable MP" |
| 21:22 |
VanessaE |
yeah, been that way for a while |
| 21:22 |
VanessaE |
this is why I keep telling you guys to actually *play* now and then ;) |
| 21:22 |
hmmmm |
wow map generation is so slow |
| 21:22 |
VanessaE |
you mean with plantlife + snow? |
| 21:23 |
hmmmm |
yeah but i'm not seeing any snow areas yet |
| 21:23 |
hmmmm |
did I need to enable MP? |
| 21:23 |
hmmmm |
i don't play on MP ever |
| 21:23 |
VanessaE |
MP for modpack |
| 21:24 |
VanessaE |
so yeah, find the top level of plantlife in the list, click "EnableMP" to turn it on, then delete the map and try again |
| 21:24 |
VanessaE |
(or just find some new land) |
| 21:24 |
VanessaE |
expect it to take a while, 15-20 seconds |
| 21:25 |
VanessaE |
big lag there because it queues up a whole bunch of mapblocks all at once for some reason |
| 21:25 |
VanessaE |
(I have a plan to mitigate that somewhat) |
| 21:26 |
hmmmm |
how far do i typically need to look in order to find a snowy area |
| 21:26 |
VanessaE |
I'm not sure, around 50-100 nodes should be adequate |
| 21:26 |
VanessaE |
you should see at least *something* pretty readily |
| 21:27 |
hmmmm |
well i'm seeing tons of plantlife but no snow |
| 21:27 |
VanessaE |
for plantlife, you'll know right away due to seeing a bunch of new stuff all over the map |
| 21:27 |
VanessaE |
ok |
| 21:28 |
VanessaE |
now, did you disable the hack I mentioned? |
| 21:28 |
hmmmm |
yes |
| 21:28 |
hmmmm |
still not seeing any snow at all |
| 21:29 |
hmmmm |
with this issue, what am I supposed to be seeing exactly? |
| 21:29 |
VanessaE |
actually you're seeing... if you'll excuse the pun... the polar opposite problem. |
| 21:29 |
VanessaE |
you should *also* be seeing snow here and there |
| 21:29 |
hmmmm |
i smiled |
| 21:30 |
VanessaE |
snow biomes are only around 100 nodes or so in size if Splizard's map in the first post is still valid |
| 21:30 |
hmmmm |
this is taking longer to find than i thought |
| 21:30 |
VanessaE |
http://img802.imageshack.us/img802/3824/mapabu.png |
| 21:30 |
hmmmm |
i need to do this later |
| 21:31 |
hmmmm |
what is the seed for that? |
| 21:31 |
hmmmm |
and coordinates |
| 21:31 |
VanessaE |
none given in the first post |
| 21:31 |
VanessaE |
however you can see that that particular map is old as fuck too |
| 21:31 |
VanessaE |
it still has pre-mudflow trenches |
| 21:32 |
hmmmm |
is snow not working because moreblocks isn't installed |
| 21:32 |
hmmmm |
I see it has "moreblocks?" as a dependency |
| 21:32 |
VanessaE |
nope. |
| 21:32 |
hmmmm |
hrmm okay |
| 21:32 |
VanessaE |
? means it's optional. |
| 21:32 |
hmmmm |
bbl |
| 21:32 |
hmmmm |
i'll look more into it |
| 21:32 |
VanessaE |
ok. |
| 21:45 |
|
alexxs joined #minetest-dev |
| 21:47 |
hmmmm |
alright i have a little more time |
| 21:47 |
hmmmm |
vanessae: are you still around? |
| 21:47 |
VanessaE |
yeah |
| 21:47 |
* VanessaE |
hides |
| 21:47 |
VanessaE |
should I be worried? |
| 21:47 |
hmmmm |
just to verify, the modpack 'plantlife' is dark green and has a lot of indented subentries that are lime green |
| 21:47 |
hmmmm |
and snow is green as well |
| 21:48 |
VanessaE |
lemme check that |
| 21:48 |
hmmmm |
it looks like a poor attempt to make a TreeView =/ |
| 21:48 |
hmmmm |
the irrlicht toolkit is wholy unsuitable for a gui |
| 21:48 |
VanessaE |
for plantlife, that's correct |
| 21:48 |
hmmmm |
and then all the rest are blue |
| 21:48 |
VanessaE |
I'm not sure if snow should that too - probably yet. been a while since I last ran it (because of this issue) |
| 21:48 |
VanessaE |
blue = a regular mod |
| 21:49 |
VanessaE |
(and a poor choice of color) |
| 21:49 |
VanessaE |
jesus, my typing sucks. |
| 21:49 |
VanessaE |
I'm not sure if snow should do that too - probably yes. been a while since I last ran it (because of this issue) |
| 21:49 |
VanessaE |
that's better. |
| 21:49 |
hmmmm |
hmmmmmm I am still not seeing any snow |
| 21:50 |
hmmmm |
http://pastebin.com/E47UxCr4 i don't see Snow in here... bad? |
| 21:51 |
VanessaE |
yeah, I'm pretty sure the snow mod prints a notification that it is enabled. |
| 21:51 |
* VanessaE |
checks the code |
| 21:52 |
VanessaE |
hm, it's a regular mod so it'll be among the blue ones.... |
| 21:52 |
hmmmm |
vanessae, are you sure I didn't comment out the critical part of the code |
| 21:52 |
hmmmm |
you told me to comment out lines 307 to 324 |
| 21:52 |
VanessaE |
positive. |
| 21:52 |
hmmmm |
but voxelmanip data is never being written if i do that.... |
| 21:52 |
VanessaE |
by doing that you're forcing it to always write its vmanip |
| 21:52 |
hmmmm |
umm, are you sure you didn't mean to comment out lines 307 and 324? |
| 21:53 |
VanessaE |
that's what I said to do. |
| 21:53 |
hmmmm |
you said "to" |
| 21:53 |
VanessaE |
[08-30 17:16] <VanessaE> you will have to disable SPlizard's compatibility "hack" - edit snow mod's src/mapgen_v6.lua and comment out lines 307 and 324 |
| 21:53 |
VanessaE |
nope.avi |
| 21:53 |
VanessaE |
I said "and". |
| 21:53 |
hmmmm |
mm okay |
| 21:53 |
hmmmm |
misread that |
| 21:53 |
VanessaE |
you suck :) |
| 21:54 |
VanessaE |
now, delete the map and start clean |
| 21:54 |
VanessaE |
you'll find snow, and no plantlife stuff |
| 21:54 |
VanessaE |
with that hack, plantlife will be able to run in the non-snow areas but only because he obviously doesn't run the vmanip then |
| 21:54 |
hmmmm |
i see reedmace |
| 21:54 |
hmmmm |
what is that |
| 21:55 |
VanessaE |
it's one of plantlife's mods |
| 21:55 |
VanessaE |
but I guess you only see part of it? |
| 21:55 |
VanessaE |
the part in the water |
| 21:55 |
hmmmm |
well i do see some reedmace |
| 21:55 |
VanessaE |
yeah, reedmace is a special case, it's part entity. |
| 21:56 |
VanessaE |
what you should see it a metric assload of...well what you saw before. |
| 21:56 |
hmmmm |
hmm okay I see the issue you're describing |
| 21:56 |
VanessaE |
yes |
| 21:56 |
VanessaE |
*nods* |
| 21:56 |
hmmmm |
snow things, and almost no plantlife |
| 21:56 |
VanessaE |
yup |
| 21:57 |
VanessaE |
THIS is what we've been banging our heads against the wall over :) |
| 21:57 |
VanessaE |
same thing happened with zeno's MTZ mod, with those glowworms |
| 21:57 |
VanessaE |
it used vmanip to place them, and so plants were no-go |
| 21:58 |
VanessaE |
soon as he ditched the vmanip's, the plants were able to grow |
| 22:02 |
hmmmm |
so let's see this |
| 22:02 |
hmmmm |
splizzard's mod is the one being able to function properly and it uses voxelmanip |
| 22:02 |
hmmmm |
your mod is the thing getting broken, which uses set_node |
| 22:02 |
VanessaE |
yup |
| 22:02 |
hmmmm |
does your mod get run before splizzard's mod? |
| 22:03 |
VanessaE |
I am unsure what runs first, but putting snow into plants_lib's depends.txt doesn't always work - it's been tried in the past and didn't work. |
| 22:03 |
VanessaE |
paramat also tried and was not successful |
| 22:03 |
hmmmm |
how are you unsure what runs first |
| 22:03 |
hmmmm |
the entire mystery here is based on you being "certain" that splizzard's mod ran first |
| 22:03 |
VanessaE |
because neither snow mod nor plants_lib have each other as depends |
| 22:04 |
hmmmm |
you fought with me tooth & nail that splizzard's mod ran first in fact |
| 22:04 |
VanessaE |
but the only thing that makes sense to me is that snow is running first. |
| 22:04 |
hmmmm |
that wouldn't make sense |
| 22:04 |
VanessaE |
well, |
| 22:04 |
hmmmm |
that's what i was arguing against because it just makes no logical sense |
| 22:04 |
VanessaE |
if plants_lib were running first, wouldn't snow mod be starting with a plantlife- populated map? |
| 22:04 |
hmmmm |
how can your mod's output get overwritten if splizzard's mod runs first |
| 22:04 |
hmmmm |
what? |
| 22:04 |
VanessaE |
s/map/mapblock/ |
| 22:04 |
hmmmm |
are you kidding me |
| 22:04 |
* hmmmm |
falls out of chair |
| 22:05 |
hmmmm |
you CLEARLY didn't read what i have been explaining is the problem for the past 4, no 5 times we discussed this |
| 22:05 |
hmmmm |
oh god |
| 22:05 |
hmmmm |
just read the conversation i was having with paramat and zeno` last night, i'm not going to repeat myself |
| 22:06 |
VanessaE |
I *did* read, but now you're coming back to whether execution order matters. If execution order matters, then that means that map data can change between on_gen callbacks. |
| 22:06 |
hmmmm |
MAP data can change between on_generate callbacks |
| 22:06 |
VanessaE |
yes |
| 22:06 |
VanessaE |
and vmanip data doesn't |
| 22:06 |
hmmmm |
VOXELMANIP data is different from MAP data |
| 22:06 |
VanessaE |
I get that |
| 22:06 |
VanessaE |
I know this |
| 22:06 |
hmmmm |
wtf then |
| 22:06 |
hmmmm |
where is the mystery |
| 22:07 |
hmmmm |
i knew precisely what the issue was, within 5 minutes of first hearing about the problem |
| 22:07 |
VanessaE |
so how then am I, in plants_lib, supposed to be able to tell $RANDOM_MAPGEN_MOD that what it read from the map is not in fact valid? |
| 22:07 |
hmmmm |
and you kept on going "NO NO NO NO YOU'RE WRONG" |
| 22:07 |
hmmmm |
you cannot |
| 22:07 |
hmmmm |
I however, can |
| 22:07 |
VanessaE |
ok, |
| 22:07 |
VanessaE |
I didn't think so. |
| 22:07 |
hmmmm |
yes |
| 22:08 |
VanessaE |
see, we're on the same page here. |
| 22:08 |
hmmmm |
you weren't for a long while |
| 22:08 |
VanessaE |
it's just that you tend to explain with a shotgun approach, and you know it. |
| 22:08 |
VanessaE |
blam! here's a whole bunch of explanations all at once |
| 22:08 |
hmmmm |
now if I add "print "hello there 1" in your mod and "print "hello there 2"" in splizzard's mod, is it going to say "hello there 1 hello there 2"? |
| 22:08 |
VanessaE |
intermixed with links to code that you know I don't understand as ell as you do |
| 22:09 |
VanessaE |
well* |
| 22:09 |
hmmmm |
you obviously have a lot of free time on your hands.... what's wrong with learning the code |
| 22:10 |
VanessaE |
hah |
| 22:10 |
VanessaE |
you try diving into a project as complex as this one with no prior knowledge. |
| 22:11 |
VanessaE |
I took C in college. about 20 years ago, when it was still K&R. that's as close to C++ as I can get. |
| 22:11 |
VanessaE |
passed the class, then moved on to stuff I could actually *use* at the time |
| 22:11 |
hmmmm |
... |
| 22:11 |
hmmmm |
it doesn't take a genius to learn how2C++ |
| 22:12 |
VanessaE |
learning the language may not be all that hard, but learning Minetest's codebase would be a real bitch and you KNOW that. |
| 22:13 |
VanessaE |
plus, this: |
| 22:13 |
hmmmm |
i got used to it fairly quickly |
| 22:13 |
hmmmm |
you started playing minetest way before i have |
| 22:13 |
VanessaE |
[08-30 11:02] <celeron55_> (so new guys: yes, you're almost worthless until you prove otherwise and you will always see it in how busy people act towards you; however, it will change at the instant you make something that is accepted into the project) |
| 22:13 |
VanessaE |
Why should I even try to learn and contribute to the core codebase with an attitude like this? |
| 22:14 |
VanessaE |
(and this is *after* I've already done so) |
| 22:14 |
hmmmm |
because it's rewarding as hell |
| 22:14 |
hmmmm |
there's something you don't like with the engine? bam you can change it just like that |
| 22:14 |
hmmmm |
no nagging 500 people |
| 22:14 |
hmmmm |
for weeks and weeks |
| 22:14 |
VanessaE |
HAH! |
| 22:14 |
VanessaE |
you're funny |
| 22:15 |
VanessaE |
change it? sure. |
| 22:15 |
hmmmm |
I just see excuses |
| 22:15 |
VanessaE |
theoretically true. |
| 22:15 |
VanessaE |
then change it again, and again, and repeat every time some upstream change breaks my patch |
| 22:15 |
VanessaE |
not nag 500 people? no, nag half a dozen to get said change merged. |
| 22:15 |
VanessaE |
I've seen the process here. |
| 22:16 |
hmmmm |
well, you do what you want then. |
| 22:16 |
VanessaE |
it is NOT conducive to "get it working right and right now". |
| 22:18 |
hmmmm |
ugh |
| 22:18 |
hmmmm |
i'm gonna have to add a mutex to voxelmanips |
| 22:19 |
celeron55_ |
that's ugly |
| 22:19 |
hmmmm |
i know.. |
| 22:19 |
celeron55_ |
originally they were intended to be mostly pure data objects |
| 22:19 |
hmmmm |
map is going to need a mutex that isn't an envlock |
| 22:19 |
hmmmm |
well |
| 22:19 |
blaise |
hey guys, check this out.. https://github.com/mnagel/clustergit |
| 22:20 |
hmmmm |
set_node gets called, locks non-envlock mutex, updates list of registered voxelmanip areas |
| 22:20 |
hmmmm |
so alright |
| 22:20 |
|
paramat joined #minetest-dev |
| 22:20 |
* blaise |
waves to paramat |
| 22:21 |
hmmmm |
when MapVoxelManipulator does an initialEmerge, it'll lock a Map::vmanip_area_lock, and add its active area to the list of active voxelmanips |
| 22:21 |
celeron55_ |
yeah obviously you need it if you're feeding back something to them, but that's... ehm... well, it might be needed then |
| 22:21 |
paramat |
hiya :) i tried to make snow mod run before plantlife using dependancies but still no plantlife except underwater reedmace which is an entity |
| 22:21 |
hmmmm |
then when set_node() gets called, lock, check the node is contained in any areas active with vmanips, then if so mark as dirty |
| 22:21 |
celeron55_ |
it's not like VMs are used for their original purpose much at all now |
| 22:21 |
hmmmm |
unlock |
| 22:21 |
hmmmm |
what was their original purpose |
| 22:22 |
blaise |
heh |
| 22:22 |
hmmmm |
the purpose i see is just some nearly-direct-access fast way to do map operations |
| 22:22 |
celeron55_ |
their original purpose was to be fast buffers for map data |
| 22:22 |
hmmmm |
yeah |
| 22:22 |
hmmmm |
except now when you have this kind of situation you need to be able to tell if it's dirty or not |
| 22:23 |
celeron55_ |
well it still is kind of the same usage |
| 22:24 |
celeron55_ |
adding locks and dirty flags like that can cause very painful slowness in some cases |
| 22:24 |
celeron55_ |
goes against KISS |
| 22:24 |
hmmmm |
got any better ideas |
| 22:25 |
celeron55_ |
just... don't do dirty flags? 8) |
| 22:25 |
celeron55_ |
it's not like people can't understand what using a separate buffer implies |
| 22:25 |
hmmmm |
how can this be slow? the only way this could ever cause slowness is if futexes start having lots of overhead (they don't - they never go into kernel mode) or there are like millions of active voxelmanips |
| 22:26 |
hmmmm |
just scan a list, compare some numbers, set a flag |
| 22:26 |
hmmmm |
okay, be back later |
| 22:27 |
hmmmm |
celeron55_: one really dirty solution would be to tell people to call initialEmerge every time the voxelmanip object gets acquired |
| 22:28 |
celeron55_ |
i guess the question is, how of then it would be a useless call then |
| 22:28 |
celeron55_ |
often* |
| 22:29 |
celeron55_ |
(i need to sleep) |
| 22:32 |
celeron55_ |
are you intending on locking the mutex every time any operation is done on the VM? |
| 22:32 |
paramat |
so i understood last night's discussion: that each on generated doesn't necessarily read the resulting map of the previous one, so it's essential to run the voxelmanip mod before the add_node mod, so i tried correctly ordering snow and plantlife using dependancies but with no success, weird 8/ |
| 22:33 |
celeron55_ |
i have very much not read the discussion, but is that because the VM changes are applied to the map only after all the on_generated calls have been run? |
| 22:34 |
* VanessaE |
hands hmmmm a towen to clean up his exploded brains |
| 22:34 |
VanessaE |
towel* |
| 22:35 |
VanessaE |
celeron55_: it's because all on_generated callbacks are given the same map content, and if a vmanip callback runs last, it writes out the clean map + its changes, because the set_node() stuff wasn't included into the vmanip object it received. |
| 22:36 |
celeron55_ |
well that explanation doesn't fully explain what paramat said |
| 22:36 |
celeron55_ |
mine would |
| 22:37 |
|
AnotherBrick joined #minetest-dev |
| 22:37 |
celeron55_ |
(what i said is just an addition of an important detail to that) |
| 22:37 |
paramat |
apparently multiple vms do read the result of each previous vm |
| 22:37 |
VanessaE |
indeed - thing is, I guess something very much like your explanation a little while back |
| 22:37 |
paramat |
the problem is mixing vm with add_node |
| 22:37 |
VanessaE |
but my guess was quickly ... invalidated, shall we say |
| 22:38 |
paramat |
note i tried replicating this situation with 2 of my own mods, no bug |
| 22:38 |
paramat |
this may be specific to plantlife plus snow, or either of those plus some other mod |
| 22:39 |
VanessaE |
paramat: zeno duplicated the issue without involving either plantlife nor snow |
| 22:39 |
VanessaE |
neither* |
| 22:40 |
paramat |
yeah |
| 22:40 |
celeron55_ |
hmmmm: isn't your automated dirty flag list also going to have to be checked through in all VM operations so that VMs are synchronized with each other? |
| 22:41 |
celeron55_ |
hmmmm: or how do you intend to do that? it's going to require rather much extra handling |
| 22:42 |
celeron55_ |
i wonder if it would be possible to special case map generation and redirect set_node calls only then 8) |
| 22:43 |
celeron55_ |
(probably not without issues) |
| 22:43 |
paramat |
VE: "it's because all on_generated callbacks are given the same map content ..." < celeron55, what VE said in that line |
| 22:44 |
paramat |
at least that's my understanding, i may be wrong |
| 22:45 |
VanessaE |
zeno came to the same conclusion when he started reading through the code. |
| 22:46 |
paramat |
however even the correct order of snow then plantlife didn't help |
| 22:46 |
paramat |
which makes me suspect something to do with the slowness of plantlife, perhaps the use of 'find nodes in area' on a large volume (whole chunk) |
| 22:47 |
paramat |
i'll do more testing with my own mods in various orders |
| 22:49 |
celeron55_ |
the same VM is shared between the map generator and all the get_mapgen_object("voxelmanip") calls |
| 22:50 |
celeron55_ |
but the stuff in the VM is written to the map before the on_generated calls are made |
| 22:50 |
celeron55_ |
but not between them |
| 22:51 |
celeron55_ |
except that... the on_generated implementations call vm:write_to_map it by themselves |
| 22:52 |
celeron55_ |
this is quite clear |
| 22:53 |
paramat |
best i don't try to explain, best to read logs. still too early IMO to say there's a bug |
| 22:53 |
celeron55_ |
there's no bug |
| 22:53 |
celeron55_ |
it just wasn't designed with direct map access in mind |
| 22:54 |
Sokomine |
how was it designed/intended? |
| 22:54 |
celeron55_ |
well, design bug |
| 22:54 |
paramat |
yeah i suspect its a case of modders pushing things to breaking point again |
| 22:54 |
* paramat |
is good at this |
| 22:54 |
* VanessaE |
hides |
| 22:54 |
celeron55_ |
Sokomine: hmmmm probably intended that lua mapgens would use either way but not both at the same time |
| 22:54 |
VanessaE |
paramat: I plead the 5th |
| 22:56 |
celeron55_ |
i don't understand why this wouldn't work when the direct map access mods are run after the VM mods though |
| 22:56 |
celeron55_ |
there seems to be nothing preventing that from working |
| 22:57 |
celeron55_ |
as long as the VM isn't written by any mod anymore after any set_node()s are made by other mods, it should work |
| 22:57 |
celeron55_ |
but paramat just described that this doesn't work |
| 22:57 |
celeron55_ |
paramat: are you sure this doesn't work? |
| 23:00 |
|
proller joined #minetest-dev |
| 23:06 |
paramat |
yeah correct order of snow then plantlife doesnt work |
| 23:07 |
paramat |
except for reedmace entity |
| 23:07 |
VanessaE |
.....which proves that plantlife's calls are being run. |
| 23:07 |
paramat |
which i suspect survives because it is an entity |
| 23:08 |
paramat |
so i suspect plantlife's code is the cause for that bizarre result |
| 23:08 |
celeron55_ |
does plantlife use VM? |
| 23:08 |
VanessaE |
no. |
| 23:08 |
VanessaE |
only set_node() (and those entities for the reedmase) |
| 23:09 |
VanessaE |
reedmace* |
| 23:09 |
celeron55_ |
if it would at all, it would break itself when run after a full map generating VM mod |
| 23:09 |
paramat |
i'll try my own mods: mixing vm with add_node, and i'll try both orders |
| 23:09 |
celeron55_ |
(or... maybe would) |
| 23:10 |
paramat |
and snow mod is the vm mod |
| 23:11 |
paramat |
btw does a modpacneed it's own depends.txt to order it correctly? i put snow in each mod's depends.txt |
| 23:11 |
paramat |
(modpack) |
| 23:11 |
celeron55_ |
no |
| 23:12 |
celeron55_ |
at least shouldn't |
| 23:12 |
paramat |
*phew* |
| 23:12 |
paramat |
plantlife is as slow as watershed 8/ |
| 23:15 |
VanessaE |
:P |
| 23:18 |
|
proller joined #minetest-dev |
| 23:30 |
|
PilzAdam joined #minetest-dev |
