| Time |
Nick |
Message |
| 00:28 |
hmmmm |
Zeno`: So have you or have you not been able to replicate it? |
| 00:30 |
Zeno` |
hmmmm, yes. But it's strange |
| 00:30 |
Zeno` |
I've been able to replicate it 75% let's put it that way. And the issue happens before your commits anyway |
| 00:31 |
hmmmm |
A++++++ accusations would raise again |
| 00:31 |
hmmmm |
s/raise/rage/ |
| 00:31 |
Zeno` |
That would apparently be the case |
| 00:33 |
jin_xi |
hmmmm: im currently using a double vm setup to first find nodes placed by decorations and then replace them with generated structures. this produces holes in the map reliably |
| 00:33 |
jin_xi |
anyways, if decorations could directly call some lua it would be easier |
| 00:33 |
Zeno` |
hmmmm, as for the assertion failure (which I didn't report I don't think), it hasn't happened again so it must be some weird and very rare case. The server is still running under gdb anyway |
| 00:34 |
hmmmm |
jin_xi, that shouldn't happen. can you show me how you're running it? |
| 00:34 |
hmmmm |
Zeno`, my guess is that it might occur in out-of-memory conditions. |
| 00:34 |
hmmmm |
a/in/under/ |
| 00:35 |
Zeno` |
hmmmm, you might be right |
| 00:35 |
jin_xi |
sure, gimme a sec |
| 00:35 |
hmmmm |
that's literally the only condition in which get_data() could throw an exception |
| 00:38 |
|
kaeza joined #minetest-dev |
| 00:39 |
jin_xi |
http://paste.ubuntu.com/8294886/ http://i.imgur.com/ESb1hYw.png |
| 00:39 |
hmmmm |
is that hole made of air or content_ignore? |
| 00:40 |
jin_xi |
how can i check? |
| 00:40 |
hmmmm |
try walking into it with noclip disabled |
| 00:40 |
jin_xi |
can walk |
| 00:42 |
hmmmm |
okay |
| 00:42 |
hmmmm |
anyway so find_dummies is run first, in on_generated |
| 00:43 |
hmmmm |
by the way jin_xi, that code is actually not required at all. you're not using a rather obscure mapgen object that was made for this situation. |
| 00:43 |
jin_xi |
pls tell me more |
| 00:43 |
hmmmm |
decoration callback |
| 00:43 |
jin_xi |
its there? |
| 00:44 |
jin_xi |
oh |
| 00:44 |
hmmmm |
yes, it's been there for about a year now |
| 00:44 |
jin_xi |
i missed that, i asked for it long time ago |
| 00:44 |
hmmmm |
i used it to place chests inside of dungeons and desert temples |
| 00:45 |
hmmmm |
see "gennotify"? |
| 00:46 |
jin_xi |
um, yes but i fail to parse |
| 00:46 |
hmmmm |
actually sorry about that |
| 00:46 |
hmmmm |
shoot |
| 00:46 |
hmmmm |
it didn't have a schematic flag |
| 00:47 |
jin_xi |
Returns a table mapping requested generation notification types to arrays of positions at which the |
| 00:47 |
jin_xi |
corresponding generated structures are located at within the current chunk. |
| 00:47 |
jin_xi |
??? |
| 00:47 |
hmmmm |
i'll have to expand gennotify to include decorations |
| 00:49 |
jin_xi |
oh i see now. took a lot of repeated reading |
| 00:50 |
hmmmm |
ah uh oh |
| 00:50 |
hmmmm |
i don't think i have minetest.set_gen_notify() documented |
| 00:51 |
jin_xi |
it is kindof obscure as it is now, yes |
| 00:51 |
hmmmm |
yep, so minetest.set_gen_notify() |
| 00:52 |
hmmmm |
takes a flags table of events to notify on |
| 00:52 |
hmmmm |
current flags being dungeon, temple, cave_begin, cave_end, large_cave_begin, large_cave_end |
| 00:52 |
hmmmm |
i think the idea was to have one associated with a specific schematic ID |
| 00:52 |
hmmmm |
but that never got implemented because i forgot about it |
| 00:53 |
hmmmm |
then, in your on_generated callback |
| 00:54 |
hmmmm |
foobar = minetest.get_mapgen_object("gennotify") -- at this point, foobar = {cave_begin = {x = blah, y = blah, z = blah}, cave_end = {x=400, y=-200, z=200}} |
| 00:54 |
hmmmm |
so on |
| 00:54 |
hmmmm |
so it'd have a table containing tables |
| 00:55 |
hmmmm |
table containing an array of tables that are the position vectors |
| 00:55 |
jin_xi |
or a list of positions where decos were placed, nice |
| 00:55 |
hmmmm |
right |
| 00:55 |
hmmmm |
that was the idea |
| 00:55 |
hmmmm |
the list of the decorations for a certain node placed |
| 00:55 |
hmmmm |
so that should be trivial to implement |
| 00:56 |
hmmmm |
add an option to register_decoration where you provide a gennotify "feature ID" and that'll be the key where things are stored in the table |
| 00:56 |
hmmmm |
so it'd be like |
| 00:56 |
hmmmm |
minetest.register_decoration{ blah blah blah blah, |
| 00:57 |
hmmmm |
gennotify_feature_id = "SomeShittyDecoration23" |
| 00:57 |
hmmmm |
}) |
| 00:57 |
jin_xi |
or just gennotify flag decorations, and get a list of all decorations for a chunk? should be small enough |
| 00:58 |
hmmmm |
so then in your on_generated, foobar = minetest.get_mapgen_object("gennotify"); foobar = {SomeShittyDecoration23 = {{x=400, y=-200, z=200}, {x=410, y=-220, z=220}} |
| 00:58 |
hmmmm |
or so on |
| 00:58 |
hmmmm |
no no no. |
| 00:58 |
hmmmm |
no. |
| 00:58 |
hmmmm |
you can't control other mods that way |
| 00:58 |
hmmmm |
do it this way |
| 01:10 |
|
Miner_48er joined #minetest-dev |
| 01:15 |
|
ImQ009 joined #minetest-dev |
| 02:11 |
|
ImQ009 joined #minetest-dev |
| 02:28 |
|
OldCoder joined #minetest-dev |
| 03:41 |
|
darkrose joined #minetest-dev |
| 03:43 |
|
darkrose joined #minetest-dev |
| 03:45 |
|
Hunterz joined #minetest-dev |
| 03:45 |
|
hax404_ joined #minetest-dev |
| 03:45 |
|
rmilan joined #minetest-dev |
| 03:46 |
|
sol_invictus joined #minetest-dev |
| 04:25 |
|
blaise joined #minetest-dev |
| 05:14 |
|
CraigyDavi joined #minetest-dev |
| 05:17 |
|
Megaf_ joined #minetest-dev |
| 06:47 |
|
CWz joined #minetest-dev |
| 07:39 |
Zeno` |
are you awake ShadowNinja? |
| 07:39 |
Zeno` |
Thanks for the detailed explanation |
| 07:40 |
Zeno` |
I still don't like the idea of sandboxing (not in a 0.4.x release anyway) but... *shrug* |
| 07:53 |
|
JTE_ joined #minetest-dev |
| 08:18 |
|
Hunterz joined #minetest-dev |
| 08:18 |
|
JTE_ joined #minetest-dev |
| 08:27 |
|
^v joined #minetest-dev |
| 08:32 |
|
jin_xi joined #minetest-dev |
| 08:59 |
kahrl |
could someone who speaks French take a look at #1202? |
| 09:03 |
kahrl |
also I'm adding a Translation subsystem (with no subsystem maintainer at the moment) |
| 09:04 |
kahrl |
just so we can label these kind of PRs as "@ Translation" |
| 09:04 |
kahrl |
if anyone is against that subsystem please say so |
| 09:07 |
|
diemartin joined #minetest-dev |
| 09:11 |
|
CraigyDavi` joined #minetest-dev |
| 09:17 |
kahrl |
I'd like to resolve as many of the issues/PRs at https://github.com/minetest/minetest/labels/@%20Translation as possible before weblate goes back up, so comments on those are welcome |
| 09:32 |
|
Mimilus joined #minetest-dev |
| 09:43 |
|
XDGAMERZzZ_ joined #minetest-dev |
| 10:17 |
|
deltib joined #minetest-dev |
| 10:41 |
|
CraigyDavi`` joined #minetest-dev |
| 10:45 |
|
proller joined #minetest-dev |
| 11:17 |
|
proller joined #minetest-dev |
| 11:26 |
|
ImQ009 joined #minetest-dev |
| 11:46 |
|
PenguinDad joined #minetest-dev |
| 11:51 |
|
ImQ009_ joined #minetest-dev |
| 11:53 |
|
diemartin joined #minetest-dev |
| 11:56 |
|
JTE_ joined #minetest-dev |
| 11:57 |
|
PenguinDad joined #minetest-dev |
| 12:06 |
|
s4mu3l_ch joined #minetest-dev |
| 12:24 |
|
Weedy joined #minetest-dev |
| 12:24 |
|
Weedy joined #minetest-dev |
| 12:42 |
|
proller joined #minetest-dev |
| 13:21 |
|
hmmmm joined #minetest-dev |
| 13:40 |
|
proller joined #minetest-dev |
| 14:04 |
|
OldCoder joined #minetest-dev |
| 14:24 |
|
Amaz joined #minetest-dev |
| 14:30 |
|
proller joined #minetest-dev |
| 14:42 |
|
proller joined #minetest-dev |
| 14:49 |
|
NakedFury joined #minetest-dev |
| 14:54 |
|
Megaf joined #minetest-dev |
| 14:54 |
|
Megaf joined #minetest-dev |
| 14:58 |
jin_xi |
hmmmm: ok, so i tried adding the feature, but im not exactly sure what im doing. |
| 15:00 |
hmmmm |
well no no |
| 15:00 |
hmmmm |
you don't need to! i will! |
| 15:00 |
hmmmm |
just not right now, I'm on work |
| 15:01 |
hmmmm |
i was just raising awareness that there is something already existing that you tried to do in your mod. really I'd like to solve your voxelmanipulator issues |
| 15:02 |
hmmmm |
now yesterday you said that there were two voxelmanipulators but in your posting i only saw one where you scanned for nodes and then called remove_node() on it |
| 15:04 |
jin_xi |
see line 45 http://paste.ubuntu.com/8294886/ (same paste) |
| 15:04 |
jin_xi |
this calls the turtle system, which does a dry run to determine the size of the structure and then calls vm with that area |
| 15:08 |
jin_xi |
here is what i tried so far... http://paste.ubuntu.com/8300598/ |
| 15:25 |
|
sol_invictus joined #minetest-dev |
| 15:25 |
|
Megaf_ joined #minetest-dev |
| 15:43 |
hmmmm |
jin_xi: what does p[2].spawn(p[1]) do? where is spawn()? |
| 15:44 |
hmmmm |
what you've done so far on implementing decoration stuff so far is mostly correct |
| 15:47 |
jin_xi |
http://paste.ubuntu.com/8300881/ http://paste.ubuntu.com/8300591/ its a cascade of functions named spawn... so the call p[2].spawn(p[1]) is basically tetris2.spawn(pos) |
| 15:47 |
jin_xi |
tetris2.spawn calls turtle.spawn which does the vm stuff |
| 15:48 |
hmmmm |
ahhh okay... so you build up a buffer table of things to write |
| 15:48 |
hmmmm |
you realize that voxelmanip is a buffer to the map |
| 15:48 |
hmmmm |
so you're writing to a buffer so that you can write to a buffer |
| 15:49 |
hmmmm |
you can change the table.insert things to vm_data[vm_area:index(rpos)] = materials[mat]; |
| 15:50 |
hmmmm |
hrmm, the code looks solid enough. you don't write to the mapgen object VM |
| 15:50 |
hmmmm |
however if another mod runs after your code uses a voxelmanip |
| 15:50 |
hmmmm |
that'd overwrite your changes |
| 15:52 |
|
Megaf joined #minetest-dev |
| 15:55 |
hmmmm |
assuming turtle.spawn is called once, this code should work. |
| 15:55 |
hmmmm |
and assuming there are no mods that use voxelmanip that might be overwriting your changes |
| 15:56 |
hmmmm |
could i have a copy of your mod to debug this? |
| 15:58 |
jin_xi |
sure |
| 16:07 |
|
zat joined #minetest-dev |
| 16:27 |
|
Hunterz joined #minetest-dev |
| 16:33 |
|
zat joined #minetest-dev |
| 16:36 |
hmmmm |
you know, I don't usually recommend hacks, but here's a really simple way to prevent cavegen from shitting over your stone/sand/dirt structures: |
| 16:36 |
hmmmm |
build the structures with nodes identical to the original node you wish to use, except with is_ground_content = false |
| 16:36 |
hmmmm |
and then on dig, have them drop the regular, is_ground_content = true variety |
| 16:37 |
VanessaE |
I already suggested that to Sokomine weeks ago :P |
| 16:37 |
hmmmm |
as long as people don't go overboard it should be okay |
| 16:37 |
hmmmm |
this is good enough until we get hardware lighting in minetest and we're able to free up an extra 8 bits in a mapnode |
| 16:38 |
hmmmm |
VanessaE: I think it may be worthwhile to add some sort of "inheritance" mechanism to nodedefs. |
| 16:38 |
VanessaE |
how would it work? |
| 16:38 |
hmmmm |
add a new api? |
| 16:39 |
hmmmm |
minetest.register_node_inherit("default:stone", {is_ground_content = false}) ? |
| 16:39 |
VanessaE |
I meant... |
| 16:39 |
hmmmm |
it would copy the nodedef from default:stone, and then override the settings with the custom ones you specify |
| 16:39 |
hmmmm |
the best part about what I'm suggesting is that in order to implement this feature, there are no additions to the core required. |
| 16:39 |
VanessaE |
the equivalent of doing this: https://github.com/VanessaE/angled_walls/blob/master/init.lua#L108 ---> https://github.com/VanessaE/angled_walls/blob/master/init.lua#L145 |
| 16:40 |
VanessaE |
but not in that sort of hacky way |
| 16:40 |
VanessaE |
ok so yeah, the same sorta thing. |
| 16:40 |
hmmmm |
yeah it seems you have the idea mostly |
| 16:41 |
hmmmm |
that's what I'd want to do, except all in one call and it'd be officially part of the API |
| 16:41 |
VanessaE |
right |
| 16:41 |
hmmmm |
does it make sense? |
| 16:41 |
hmmmm |
I realize that modders had probably thought of all these tricks a long time ago |
| 16:41 |
VanessaE |
it DOES make sense but I wonder if it's the right way to actually do it |
| 16:41 |
hmmmm |
but I'm just saying, we should actually do something about it rather than just let people do their own thing |
| 16:41 |
VanessaE |
*nod* I agree |
| 16:42 |
hmmmm |
VanessaE, there is no other way to do it |
| 16:42 |
VanessaE |
this clone method originally came from pilzadam, though what I do here required a recursive copy to avoid some hidden pass-by-reference fuckups I was running into. |
| 16:42 |
VanessaE |
but yeah, if there's no other way, then so be it |
| 16:42 |
hmmmm |
I mean you're probably thinking of not maintaining a copy of the node internally |
| 16:43 |
|
kahrl joined #minetest-dev |
| 16:43 |
hmmmm |
but that won't make a difference because the vector containing the nodedefs isn't a list of pointers, it's a list of actual NodeDef structures |
| 16:43 |
hmmmm |
so you wouldn't be saving any space |
| 16:44 |
VanessaE |
right |
| 16:44 |
VanessaE |
well I got that ^^^^ code from the Roblox wiki but it's just a generic copy so feel free to use it :) |
| 16:44 |
hmmmm |
it'd also make access non-trivial. you'd need to use getters/setters for all of the nodedef members |
| 16:44 |
VanessaE |
(line 11 in the file) |
| 16:45 |
hmmmm |
so, yeah, copying a node definition of something already registered then applying modifications, and registering the new one is the way to go. |
| 16:45 |
hmmmm |
i don't think it's hacky really. |
| 16:49 |
VanessaE |
I'll back it, since I've had to use this same construct more times than I care to remember ;-) but you can expect others will bitch |
| 16:57 |
|
OldCoder joined #minetest-dev |
| 17:20 |
|
Calinou joined #minetest-dev |
| 17:30 |
|
khonkhortisan joined #minetest-dev |
| 17:36 |
|
Krock joined #minetest-dev |
| 17:58 |
diemartin |
re: subclassing, it's trivial to do it with `setmetatable()` and `__index` |
| 17:58 |
diemartin |
(assuming register_xxx works by using `lua_getfield` instead of `lua_rawget`) |
| 18:00 |
diemartin |
just point `__index` to the "superclass", and explicitly set the overrides |
| 18:01 |
|
proller joined #minetest-dev |
| 18:12 |
|
ImQ009 joined #minetest-dev |
| 18:22 |
ShadowNinja |
How should a Lua API for mkdir be implemented? Add os.mkdir from ScriptApiUtil? minetest.mkdir? minetest.{fs,path}.mkdir? Should we include something like LuaFileSystem? |
| 18:22 |
VanessaE |
minetest_fs.mkdir |
| 18:22 |
VanessaE |
strictly filtered to never overwrite and only to create within certain areas e.g. the world dir or mod dir |
| 18:23 |
* VanessaE |
looks at Luafs |
| 18:23 |
kaeza |
minetest.fs.mkdir doesn't follow the naming conventions; we don't see minetest.game.register_node or such |
| 18:23 |
Krock |
ShadowNinja, minetest.create_folder("foobar") ? |
| 18:23 |
VanessaE |
folder? |
| 18:23 |
Calinou |
it needs to work easily on all operating systems |
| 18:23 |
VanessaE |
no fucking way |
| 18:24 |
Krock |
VanessaE, Y no? |
| 18:24 |
VanessaE |
it's a G*d damned directory |
| 18:24 |
VanessaE |
that's why no. |
| 18:24 |
kaeza |
also, `listdir()` pls |
| 18:24 |
ShadowNinja |
VanessaE: Nah, no new table. Then we'd need core_fs too. |
| 18:24 |
VanessaE |
ShadowNinja: hrm. well ok |
| 18:24 |
VanessaE |
core.mkdir or minetest.mkdir then |
| 18:24 |
ShadowNinja |
kaeza: for x in require("lfs").dir(...) do... |
| 18:25 |
VanessaE |
either one is about the same |
| 18:25 |
ShadowNinja |
VanessaE: (core == minetest) == true |
| 18:25 |
VanessaE |
looking at lfs, there's a lot of stuff here that some OS's might not allow |
| 18:25 |
VanessaE |
I wonder if lfs might be overkill. |
| 18:26 |
VanessaE |
ShadowNinja: case in point. it's just a matter of which name looks better in the API doc. |
| 18:27 |
VanessaE |
I guess you could add in lfs and just disable the functions that we don't need. |
| 18:27 |
VanessaE |
e.g. symlinks, file locking a |
| 18:27 |
VanessaE |
-a |
| 18:32 |
ShadowNinja |
Symlinks work on Windows, and file locking might be usefull. |
| 18:34 |
VanessaE |
mmmh |
| 18:39 |
|
Calinou joined #minetest-dev |
| 19:14 |
|
Columbus joined #minetest-dev |
| 19:15 |
Columbus |
Excuse me, a bit off topic question, about Graphics Processing |
| 19:15 |
|
luizrpgluiz joined #minetest-dev |
| 19:15 |
Columbus |
A CPU uses Pipelining, so that multiple instructions at once are processed. |
| 19:16 |
Columbus |
Would a programm be able, to emulate such function, |
| 19:16 |
Columbus |
that a program pipelines the draw (and so on) process |
| 19:16 |
Columbus |
Could that work? |
| 19:18 |
Columbus |
When someone could, please give that idea to someone of OpenGL, because maybe, that it works, and it could create new technology |
| 19:18 |
Columbus |
Excuse me for my bad english, it isn't my mother-language |
| 19:20 |
luizrpgluiz |
guys because minetest runs faster on Linux? |
| 19:25 |
luizrpgluiz |
? |
| 19:34 |
|
GhostDoge joined #minetest-dev |
| 20:01 |
|
mberends joined #minetest-dev |
| 20:02 |
|
Taoki[laptop] joined #minetest-dev |
| 20:06 |
|
luizrpgluiz left #minetest-dev |
| 20:18 |
|
deltib joined #minetest-dev |
| 21:29 |
|
proller joined #minetest-dev |
| 21:31 |
|
mberends joined #minetest-dev |
| 22:14 |
|
ImQ009 joined #minetest-dev |
| 23:07 |
|
Aaron1011 joined #minetest-dev |
| 23:10 |
|
proller joined #minetest-dev |
| 23:12 |
|
Zeno` joined #minetest-dev |
| 23:22 |
|
celeron55 joined #minetest-dev |
| 23:38 |
|
mrtux joined #minetest-dev |
