| Time |
Nick |
Message |
| 01:06 |
|
jin_xi joined #minetest-dev |
| 01:13 |
|
blaaaaargh joined #minetest-dev |
| 01:29 |
|
djdduty joined #minetest-dev |
| 01:29 |
|
djdduty joined #minetest-dev |
| 01:38 |
|
Taoki joined #minetest-dev |
| 02:20 |
|
us|0gb joined #minetest-dev |
| 02:20 |
|
us|0gb joined #minetest-dev |
| 02:22 |
|
khonkhortisan joined #minetest-dev |
| 02:35 |
|
smoke_fumus joined #minetest-dev |
| 03:19 |
|
blaaaaargh joined #minetest-dev |
| 03:34 |
|
OldCoder joined #minetest-dev |
| 03:50 |
hmmmm |
hey what's up with this https://github.com/minetest/minetest/commit/22dbbf0a6fc9547f0dbdb7f6076337b8c6acd48b |
| 03:51 |
hmmmm |
that's one giant race condition |
| 03:51 |
hmmmm |
not that it'll crash anything or cause invalid data accesses, it's just that it'll work about a third of the time |
| 03:51 |
hmmmm |
who thought it was a good idea to commit this |
| 03:52 |
* hmmmm |
looks at ShadowNinja |
| 04:58 |
|
Miner_48er joined #minetest-dev |
| 05:04 |
VanessaE |
thexyz, ShadowNinja: what's the status of that test with the parallax/bumpmap test that caused the shaders to turn black? Seems like you guys found a work around? |
| 05:04 |
VanessaE |
-test |
| 05:17 |
|
VanessaE joined #minetest-dev |
| 05:25 |
|
nore joined #minetest-dev |
| 05:51 |
|
mrtux joined #minetest-dev |
| 06:52 |
nore |
this should fix the shaders: https://github.com/Novatux/minetest/tree/shaders |
| 06:54 |
nore |
is anyone here? |
| 06:59 |
nore |
there: https://github.com/minetest/minetest/pull/1041 |
| 06:59 |
nore |
hmmmm, any thoughts on it? |
| 07:14 |
hmmmm |
shouldn't you be asking RealBadAngel that? |
| 07:14 |
nore |
he isn't there right now... but I mean, about code things, etc |
| 07:15 |
hmmmm |
it looks fine to me but I'm really not qualified to say whether or not it's a good fix |
| 08:16 |
|
EdB joined #minetest-dev |
| 08:18 |
|
darkrose joined #minetest-dev |
| 08:22 |
|
emptty joined #minetest-dev |
| 08:22 |
|
emptty1 joined #minetest-dev |
| 08:52 |
|
Akien joined #minetest-dev |
| 09:07 |
|
john_minetest joined #minetest-dev |
| 09:32 |
|
Calinou joined #minetest-dev |
| 09:54 |
|
ImQ009 joined #minetest-dev |
| 10:02 |
thexyz |
VanessaE: I have no idea |
| 10:03 |
nore |
thexyz, https://github.com/minetest/minetest/pull/1041 |
| 10:03 |
nore |
about the shaders thing |
| 10:03 |
thexyz |
alright |
| 10:04 |
nore |
could you tell me what you think of it? |
| 10:06 |
thexyz |
I don't know, I haven't worked with shaders at all |
| 10:07 |
nore |
nor did I before yesterday... but code-wise, is there anything to be changed? |
| 10:08 |
thexyz |
how would I know then? I guess it's ok if it works for you |
| 10:08 |
nore |
I guess I'll have to wait for RBA to join then... |
| 10:17 |
|
PilzAdam joined #minetest-dev |
| 10:46 |
|
EdB joined #minetest-dev |
| 10:49 |
|
sapier joined #minetest-dev |
| 10:50 |
|
[PavelS] joined #minetest-dev |
| 10:58 |
|
Gethiox2 joined #minetest-dev |
| 11:34 |
|
specing joined #minetest-dev |
| 11:35 |
specing |
Is there a comprehensive guide to minetest.conf somewhere? |
| 11:35 |
specing |
I am specifically interested in the mapgen variables |
| 11:37 |
specing |
In the end, I would like larger caves that aren't connected between eachother, fewer cave entrances on the ground and more frequent ore |
| 11:38 |
specing |
As far as I can learn from its name, 'indev' is the most recent map generator (and likely most featurefull?) |
| 11:44 |
|
nyuszika7h joined #minetest-dev |
| 11:45 |
specing |
Could not open file of texture: character.png |
| 11:45 |
specing |
Loaded mesh: npc_character.b3d |
| 11:45 |
specing |
Segmentation fault |
| 11:57 |
specing |
^ on git |
| 11:58 |
|
RealBadAngel_ joined #minetest-dev |
| 12:10 |
specing |
Is "Sky" proller's server? |
| 12:10 |
specing |
It looks really effed up |
| 12:13 |
sapier |
specing ignore the names |
| 12:13 |
sapier |
indev isn't latest, latest unstable is v7 (atm) indev is modified v6 |
| 12:43 |
specing |
Ah okay |
| 13:04 |
troller |
specing, my |
| 13:10 |
|
ImQ009 joined #minetest-dev |
| 13:18 |
sapier |
argh reading light information from vmanip data is a pain |
| 13:23 |
sapier |
and lua 5.1 doesn't support bitoperations... |
| 13:24 |
|
proller joined #minetest-dev |
| 13:24 |
|
troller joined #minetest-dev |
| 13:34 |
|
emptty joined #minetest-dev |
| 14:03 |
|
werwerwer joined #minetest-dev |
| 14:16 |
specing |
troller: how did you manage to generate such a weird map @ Sky? |
| 14:16 |
|
Akien joined #minetest-dev |
| 14:16 |
specing |
Also is there a normal part of that map? |
| 14:16 |
troller |
normal map at 0,0,0 |
| 14:17 |
troller |
its only adjusted noiseparams |
| 14:17 |
troller |
find point zero teleport |
| 14:18 |
|
Zeitgeist_ joined #minetest-dev |
| 14:21 |
specing |
I have mese, can I make my own teleporter? |
| 14:22 |
specing |
or a helicopter |
| 14:23 |
specing |
Ah I see it has ufos |
| 14:24 |
specing |
not sure if I have enough obsidian to make it |
| 14:25 |
specing |
sqrt distance to 0,0,0 is 40000 |
| 14:40 |
|
hmmmm joined #minetest-dev |
| 14:41 |
hmmmm |
sapier, what's painful? |
| 14:41 |
hmmmm |
local day = lightval % 16; local night = math.floor(lightval / 16) |
| 14:42 |
hmmmm |
or rather local night = (lightval - day) / 16 |
| 14:42 |
hmmmm |
the other alternative is that I create a zillion tables for every call |
| 14:45 |
|
AllegedlyDead joined #minetest-dev |
| 14:51 |
|
salamanderrake joined #minetest-dev |
| 15:05 |
|
Akien joined #minetest-dev |
| 15:19 |
|
KingsleyT joined #minetest-dev |
| 15:22 |
|
OldCoder joined #minetest-dev |
| 15:30 |
|
[PavelS] joined #minetest-dev |
| 15:34 |
|
Anchakor_ joined #minetest-dev |
| 15:49 |
|
NakedFury joined #minetest-dev |
| 15:53 |
|
Akien joined #minetest-dev |
| 15:56 |
nore |
anyone ok for https://github.com/minetest/minetest_game/pull/227 ? |
| 15:56 |
|
werwerwer_ joined #minetest-dev |
| 15:59 |
|
iqualfragile joined #minetest-dev |
| 15:59 |
|
zat joined #minetest-dev |
| 16:00 |
|
Calinou joined #minetest-dev |
| 16:05 |
|
thk joined #minetest-dev |
| 16:05 |
specing |
boats are seriously uncontrollable |
| 16:05 |
specing |
I think troller 's server is full of lag |
| 16:11 |
iqualfragile |
specing: nah, poats realy have some kind of controlability probem |
| 16:13 |
hmmmm |
hmmmm |
| 16:15 |
|
PandemoniuM joined #minetest-dev |
| 16:21 |
|
Jordach joined #minetest-dev |
| 16:29 |
sapier |
hmmmm painful because lua doesn't support bitoperations |
| 16:30 |
hmmmm |
what's wrong with what I just wrote? |
| 16:30 |
sapier |
lightval day and lightval night are stored within a single byte ;-) |
| 16:30 |
nore |
sapier, either add bit32... or use a pure-Lua implementation of binary things... |
| 16:31 |
hmmmm |
yes, but what's wrong with what I just wrote..? |
| 16:31 |
sapier |
you don't have those values in vmanip ;-) |
| 16:31 |
hmmmm |
yes you do |
| 16:31 |
sapier |
where? |
| 16:31 |
hmmmm |
local lightvals = vmanip:get_light_data() |
| 16:32 |
sapier |
returns light and day as single value |
| 16:32 |
hmmmm |
local lightval = lightvals[area:index(x, y, z)] |
| 16:32 |
sapier |
still thats a byte value containing day and night ;-) |
| 16:32 |
hmmmm |
.... |
| 16:32 |
hmmmm |
did you not read what I wrote |
| 16:32 |
hmmmm |
[09:41 AM] <hmmmm> local day = lightval % 16; local night = math.floor(lightval / 16) |
| 16:32 |
hmmmm |
[09:42 AM] <hmmmm> or rather local night = (lightval - day) / 16 |
| 16:32 |
hmmmm |
[09:42 AM] <hmmmm> the other alternative is that I create a zillion tables for every call |
| 16:32 |
sapier |
oh :-) |
| 16:33 |
sapier |
that's tooo simple hmmmm :-) can't be correct ;-) |
| 16:33 |
hmmmm |
do you not understand basic bit operations |
| 16:34 |
sapier |
I know it's correct ;-P yet it's still to simple ;-) |
| 16:34 |
hmmmm |
if you can come up with a better way to do that please notify me |
| 16:35 |
sapier |
next thing after day and night values is calculating timed values ... any suggestions to do core code more simple? |
| 16:36 |
hmmmm |
where's that algorithm I pointed out yesterday? |
| 16:36 |
hmmmm |
oh daynightratio.h |
| 16:37 |
sapier |
that one :-) |
| 16:37 |
hmmmm |
these kinds of things we don't need a separate API for since the transition between Lua and C and back again is probably way slower |
| 16:37 |
sapier |
I guess the time normalization is more complex than it's required to be |
| 16:37 |
hmmmm |
it is |
| 16:37 |
hmmmm |
each of those table values have a difference of 250 |
| 16:37 |
hmmmm |
so I guess you can do |
| 16:38 |
thexyz |
has anyone actually benchmarked it? "the transition between Lua and C and back again is probably way slower" |
| 16:38 |
hmmmm |
local values = {150, 150, 250, 350, 500, ...}; so on |
| 16:38 |
hmmmm |
values[(time_of_day - 4375) / 250] |
| 16:39 |
hmmmm |
instead of a linear search like it does |
| 16:39 |
sapier |
thexyz no need to benchmark luajited operations against mountains of code to transfere data from luastack to c++ and back |
| 16:40 |
|
Zeg9 joined #minetest-dev |
| 16:41 |
thexyz |
of course, no need, at all |
| 16:41 |
hmmmm |
I suppose that we'd have to do all the measurement from within the core in some callback without other crap messing up the results |
| 16:42 |
sapier |
on pure number crashing luajit is almost equal to c++ code |
| 16:42 |
sapier |
I verified that in pathfinder |
| 16:42 |
sapier |
-crashiing + crunching |
| 16:43 |
hmmmm |
are you able to coax it to use integer operations? |
| 16:43 |
hmmmm |
did you find a way to check what luajit actually compiles it down into? |
| 16:43 |
hmmmm |
that would be helpful |
| 16:43 |
sapier |
I don't think so luas numbers are always floating point |
| 16:43 |
sapier |
but we don't have much non fp values in minetest |
| 16:43 |
hmmmm |
that might not be true, there's a "lua_Integer" type |
| 16:44 |
sapier |
is there? |
| 16:44 |
hmmmm |
yes we do, all array indicies ever |
| 16:44 |
sapier |
positions are floa |
| 16:44 |
sapier |
t |
| 16:45 |
sapier |
mapnodes are integers of course |
| 16:45 |
sapier |
ok but my current task is reading light values from vmanip ... and reading light values directly from map is doubtless slow |
| 16:46 |
sapier |
at least if you have to read more then a single node |
| 16:47 |
hmmmm |
well |
| 16:47 |
hmmmm |
that's no longer a problem as of a couple weeks ago |
| 16:48 |
hmmmm |
i originally put the bulk light data functions in for paramat but they're really useful here too |
| 16:48 |
sapier |
sorry but what happend a couple of weeks ago? |
| 16:48 |
hmmmm |
I added get_light_data and set_light_data to vmanip |
| 16:49 |
hmmmm |
if you're having any *real* problems using them please let me know |
| 16:49 |
sapier |
oh ok that one actually adds the possibility to do what I try to do now |
| 16:50 |
sapier |
the only thing I'm not sure what to do is that light source code in ... but maybe that information is already available in lua too I didn't look for it by now |
| 16:51 |
hmmmm |
it isn't as far as I'm aware |
| 16:51 |
|
ImQ009_ joined #minetest-dev |
| 16:51 |
hmmmm |
it's really not that bad |
| 16:51 |
hmmmm |
just translate day_to_night_ratio into lua literally and then make optimizations where you can |
| 16:51 |
hmmmm |
time_to_daynight_ratio i mean |
| 16:53 |
sapier |
ok I guess I now understand what that strange time calculation on top of that function does |
| 16:53 |
hmmmm |
it translates what time of day it is to the amount of light there is in a non-linear fashion |
| 16:54 |
ShadowNinja |
hmmmm: Can you add get_param2_data()? That way WE wouldn't have to abuse schematics for saving things with facedir and the like. |
| 16:54 |
hmmmm |
ShadowNinja, did you see what I was saying before about that pull request you merged a few days ago |
| 16:54 |
sapier |
no that calculation on top shifts daytime to be able to use a single mapping table |
| 16:54 |
ShadowNinja |
hmmmm: And where's the race condition in that? |
| 16:55 |
hmmmm |
the block isn't generated on time before the player spawns |
| 16:55 |
hmmmm |
it just so happens that a cave spawns right underneath the player and he falls |
| 16:55 |
hmmmm |
or maybe a tree gets spawned there from the border of a neighboring chunk |
| 16:55 |
ShadowNinja |
Ah. |
| 16:55 |
hmmmm |
basically what i'm saying is that guy's attempts to get around this are all futile |
| 16:56 |
ShadowNinja |
How whould you recommend fixing it? |
| 16:56 |
hmmmm |
if it were simple, spawning would've been fixed a LONG time ago |
| 16:57 |
hmmmm |
if you actually wanted to FIX it you'd have to add infrastructure |
| 16:57 |
hmmmm |
i.e. a way to prioritize chunk generation and a way to block on it |
| 16:57 |
hmmmm |
if you want to freeze up ServerThread to wait for map generation to finish, though, it's your call... |
| 16:58 |
hmmmm |
that could be a really long time |
| 16:58 |
hmmmm |
then you'd have people happily building away on a server and some shmuck joins and he ends up spawning somewhere that isn't generated and all of a sudden the entire server comes to a screeching halt and everybody says |
| 16:59 |
hmmmm |
"welp, it seems like someone's trying to join the server, we've gotta stop building until he's done" |
| 16:59 |
ShadowNinja |
That's obviously non-optimal. The current one seems to work pretty well, those spawning issues should be very rare... |
| 16:59 |
ShadowNinja |
But did the other method not have these issues? |
| 17:00 |
hmmmm |
the other method assumed that CONTENT_IGNORE was a solid block and so it'd count against the number of air nodes |
| 17:00 |
hmmmm |
so if the block wasn't generated yet it'd go look around for other places that do have it generated |
| 17:02 |
specing |
boats give my screen a knockback effect |
| 17:02 |
ShadowNinja |
Well accepting only air made me spawn about 20 nodes above a ocean far from spawn... |
| 17:08 |
nore |
can someone check that please? https://github.com/minetest/minetest_game/pull/227 |
| 17:11 |
ShadowNinja |
nore: Mods shouldn't depend on hacky_swap_node, and swap_node should be local. |
| 17:11 |
hmmmm |
the method you just merged doesn't really help anything at all |
| 17:11 |
nore |
it was not local before... but I can change that too |
| 17:12 |
hmmmm |
it might seem like it does but findSpawnPos already does an emergeBlock() on the place it's querying which makes the emergeBlock calls in Map::findGroundLevel completely redundant |
| 17:12 |
hmmmm |
EFFECTIVELY the only thing that patch does is |
| 17:12 |
hmmmm |
1). increase the maximum spawn height by a lot |
| 17:12 |
nore |
ShadowNinja, changed |
| 17:13 |
hmmmm |
2). revert back to the old way of finding the ground level |
| 17:13 |
|
john_minetest left #minetest-dev |
| 17:13 |
hmmmm |
#2 is bad because again, if that piece of the map doesn't exist yet, you're not going to find the ground level by probing! |
| 17:14 |
hmmmm |
so you need to rely on the map generator's findGroundLevel |
| 17:14 |
nore |
ShadowNinja, do you know a bit about shaders? |
| 17:14 |
hmmmm |
and no, it help you spawn outside of trees or caves, that's just the reality of it |
| 17:14 |
hmmmm |
I say we revert it |
| 17:14 |
ShadowNinja |
nore: No. Your patch looks OK to me, but better check with RBA. |
| 17:15 |
nore |
and can I merge the minetest_game thing? |
| 17:15 |
celeron55 |
there should probably be some queue of players that need a spawn position when the map isn't loaded yet, and the server would reposition them once it gets to loading or generating a suitable position |
| 17:15 |
hmmmm |
it won't help you* |
| 17:16 |
nore |
ShadowNinja, ^ |
| 17:18 |
ShadowNinja |
nore: That looks good. |
| 17:18 |
hmmmm |
so here's the deal |
| 17:19 |
hmmmm |
revert 22dbbf0a6fc9547f0dbdb7f6076337b8c6acd48b and I'll modify Map::getGroundLevel to use a mixture of the old probe method and use the new query-mapgen method if the former fails because it's not generated |
| 17:20 |
hmmmm |
and eventually I'll put in an async emergeBlock callback which we can trigger the remainder of the spawning process on |
| 17:22 |
ShadowNinja |
That seems good. |
| 17:25 |
|
Calinou joined #minetest-dev |
| 17:29 |
sapier |
does read_from_map read node as well as light data? |
| 17:29 |
hmmmm |
it loads the map contents into the voxel manipulator |
| 17:30 |
hmmmm |
the various get_*data functions just put the stuff into table format so lua can do something with it |
| 17:30 |
sapier |
ok thanks that's the answer I was looking for |
| 17:32 |
sapier |
light works partly now ... obviously light sources are missing ... and there seems to be another effect where voxellight is more then core light data ... not sure what this is |
| 17:33 |
sapier |
could be missing sunlight_propagates check |
| 17:49 |
|
jojoa1997 joined #minetest-dev |
| 18:06 |
|
kaeza joined #minetest-dev |
| 18:09 |
sapier |
any idea how to match vmanip and real world data? |
| 18:10 |
hmmmm |
?? |
| 18:11 |
sapier |
local voxel_light_data = voxeldata:get_light_data() |
| 18:11 |
sapier |
local node_data = voxeldata:get_data() |
| 18:11 |
sapier |
local voxelhelper = VoxelArea:new(minp,maxp) |
| 18:11 |
hmmmm |
noo noo noo. minp and maxp is the generated area |
| 18:11 |
hmmmm |
you want the area that was emerged into the voxelmanip |
| 18:11 |
sapier |
wait |
| 18:11 |
hmmmm |
(the two positions you get from read_from_map) |
| 18:11 |
sapier |
local voxeldata = minetest.get_voxel_manip() |
| 18:11 |
sapier |
voxeldata:read_from_map(minp,maxp) |
| 18:12 |
sapier |
missed those lines I have them before the others |
| 18:12 |
hmmmm |
read_from_map returns two parameters |
| 18:12 |
sapier |
now doing local raw_node_data = node_data[helper:indexp(pos)] |
| 18:12 |
sapier |
ok I guess i need to check those? |
| 18:12 |
hmmmm |
yup, ya sure do |
| 18:13 |
hmmmm |
check out some voxelmanip reference code |
| 18:14 |
sapier |
not sure if I like that interface ... it passes all that data even as it may be useless for me |
| 18:14 |
hmmmm |
i didn't come up with it |
| 18:14 |
sapier |
but for some situations it may be usefull to have at least some of the data you actually wanted to get |
| 18:15 |
|
werwerwer joined #minetest-dev |
| 18:15 |
hmmmm |
if you want to get a 2x2x2 sized area of block data from voxelmanip |
| 18:15 |
hmmmm |
that's fine, it'll get that |
| 18:15 |
hmmmm |
but it needs to get all of the containing chunks |
| 18:15 |
hmmmm |
this is why voxelarea exists |
| 18:15 |
hmmmm |
to simplify that |
| 18:16 |
hmmmm |
eminp, emaxp = voxeldata:read_from_map(minp, maxp) |
| 18:16 |
hmmmm |
voxelphelper = VoxelArea:new(eminp, emaxp) |
| 18:17 |
sapier |
I try |
| 18:17 |
sapier |
nope still doesn't match |
| 18:18 |
sapier |
seem to be less errors |
| 18:18 |
sapier |
RAW: 0 NodeVM: default:dirt NodeDirect: air VL: 0 ND:2 Pos: (25,4,-358) |
| 18:19 |
sapier |
of course light is calculated to 0 by vmanip data as it's dirt |
| 18:19 |
hmmmm |
you're simply doing something wrong |
| 18:19 |
hmmmm |
voxelmanip at this point has all the bugs worked out |
| 18:20 |
sapier |
I don't think anyone would recognize a shift |
| 18:20 |
hmmmm |
why don't you copy and paste your source code you're working with to pastebin |
| 18:20 |
sapier |
especialy as ppl usualy use it to modify things and not to just read data |
| 18:21 |
sapier |
https://gist.github.com/sapier/7861582 |
| 18:23 |
sapier |
the pos calculation is exactly what core does on convertin float vector to int vector |
| 18:24 |
hmmmm |
oh you're rounding things |
| 18:24 |
hmmmm |
if you floored all of that, what happens then? |
| 18:25 |
sapier |
let me try again with those vmanip return values |
| 18:26 |
hmmmm |
well in this case it may be that VoxelArea is bugged |
| 18:26 |
sapier |
ok first try (not rounding anything --> no change |
| 18:26 |
hmmmm |
it treats everything as if they were integers |
| 18:27 |
sapier |
doing floor without 0.5 doesn't help either |
| 18:27 |
sapier |
ok maybe I should round minp and maxp first too |
| 18:27 |
hmmmm |
yes |
| 18:28 |
hmmmm |
please round things before passing them on to voxelmanip or voxelarea |
| 18:30 |
sapier |
no change |
| 18:31 |
hmmmm |
I hope you realize that origpos is bound to pos |
| 18:31 |
hmmmm |
they're references, not actual v3fs |
| 18:32 |
sapier |
ok that wasn't intended |
| 18:34 |
sapier |
ok that may have done the trick ... any chance to get the rounding to indexp and index? |
| 18:34 |
sapier |
stop |
| 18:34 |
hmmmm |
that would compromise speed for everybody who uses them as integers |
| 18:34 |
sapier |
got the error again |
| 18:34 |
ShadowNinja |
vector.new() and vector.round() may help... |
| 18:36 |
hmmmm |
hmm |
| 18:36 |
hmmmm |
well the code looks fine |
| 18:36 |
hmmmm |
it's not like your particular use case is unique any way |
| 18:37 |
RealBadAngel |
hi all |
| 18:38 |
ShadowNinja |
hmmmm: So, what about get_param2_data()? |
| 18:38 |
sapier |
unique? I want to verify environment information within lua without having to callback to c++ for each single node ... I intend to us this for mob environment check too ... but It's only usefull if I can match get_node() values to vmanip node values |
| 18:38 |
sapier |
+e |
| 18:39 |
hmmmm |
ShadowNinja, I'll think about it |
| 18:39 |
sapier |
and as long as vmanip keeps telling me there is stone where get_node tells air ... I've got a problem ;-) |
| 18:39 |
hmmmm |
well it's not magic |
| 18:39 |
hmmmm |
VoxelManip is really simple |
| 18:40 |
sapier |
seems to be that simple that it's hard to understand it's issues |
| 18:41 |
sapier |
most time information seems to match but there are rare cases where they don't as noone is moving around in this world there can't ne any mapgen artifacts in there |
| 18:41 |
ShadowNinja |
sapier: assert((minetest.get_node(pos).name == "air") == (data[area:index(pos.x, pos.y, pos.z)] == c_air)) |
| 18:42 |
sapier |
assert doesn't work in minetest ... and I get those missmatches when I try to calculate light |
| 18:43 |
ShadowNinja |
sapier: How doesn't it work? |
| 18:43 |
ShadowNinja |
(assert that is) |
| 18:43 |
ShadowNinja |
The backtrace issue is fixed, if that's what you are refering to. |
| 18:43 |
sapier |
if you do an assert it's pure chance you really see correct error (at least if there are more at once) |
| 18:44 |
sapier |
at least until yesterdays core ... didn't update today |
| 18:48 |
ShadowNinja |
Um, it isn't any worse than doing something like error("Assertation failed"). What you were talking about yesterday are programer errors that the interpreter can not warn you about until they actually result in a crash. |
| 18:48 |
sapier |
no it isn't but I don't need an error to see the missmatch ;-) |
| 18:49 |
|
lanxu joined #minetest-dev |
| 18:50 |
sapier |
ok as I don't know that code in vmanip I'm not gonna fix it now ... as long as there ain't anyone telling me what I'm doing wrong I'll consinder vmanip as broken ... it's usefull for spawning but useless for speeding up environment checks |
| 18:53 |
ShadowNinja |
sapier: Update your gist. |
| 18:54 |
sapier |
updated |
| 18:55 |
sapier |
one last try ... traditional position rounding instead of core conversion format |
| 18:55 |
ShadowNinja |
sapier: What does the light_around tabe contain? |
| 18:56 |
sapier |
light_around definitions as of specified for adv_spawning ... not relevant to vmanip issues |
| 18:57 |
sapier |
no traditional rounding doesn't seem to work too |
| 18:57 |
|
VanessaE joined #minetest-dev |
| 18:58 |
ShadowNinja |
sapier: You are passing i to get_node_light(). |
| 19:00 |
ShadowNinja |
sapier: Oh, two i's. You should change that to i and j or similar. And get_node_light takes a foating point number from 0 to 1. |
| 19:00 |
sapier |
oops another issue yes |
| 19:00 |
sapier |
thanks .. but still not the vmanip issue |
| 19:01 |
sapier |
I pinpointed a occasion where vmanip tells default:water_source while direct tells papyrus ... direct is right of course |
| 19:01 |
sapier |
and next default water is 2 nodes below and one to left or front |
| 19:02 |
sapier |
so it can't even be a off by one issue |
| 19:04 |
sapier |
ok lets try writing a simple test mod ... :-/ |
| 19:04 |
ShadowNinja |
Well, your rounding is odd... |
| 19:04 |
sapier |
that's what core does |
| 19:04 |
ShadowNinja |
-10 -> -9 |
| 19:05 |
sapier |
but it doesn't work for any other variant of rounding |
| 19:05 |
ShadowNinja |
Er, -11. |
| 19:06 |
sapier |
yes seems to be wrong but as I told math.floor(x+0.5) doesn't work either |
| 19:06 |
ShadowNinja |
sapier: origpos is never restored from what I see. Use vector.round, it copies it too. |
| 19:07 |
ShadowNinja |
That turns 20 lines into one... |
| 19:08 |
sapier |
I'll try too but I don't expect it to change anything |
| 19:08 |
nore |
RealBadAngel, so, can I merge #1041? |
| 19:09 |
ShadowNinja |
sapier: > =round(round(round(round(-10)))) --> -14 Does that seem right? |
| 19:09 |
sapier |
as expected no change |
| 19:09 |
ShadowNinja |
sapier: Update the gist. |
| 19:09 |
sapier |
that's only been an attempt to use lua code as close to core as possible |
| 19:10 |
RealBadAngel |
nore, yes, the code is fine, i will use that idea to further configure the shaders |
| 19:10 |
ShadowNinja |
If the core does that then is's wrong. But it seems more likely that your mis-reading something. |
| 19:10 |
nore |
ok, merging it now except if anyone is against it... |
| 19:10 |
sapier |
updated |
| 19:11 |
sapier |
I guess what core does works due to int/float mechanics of c |
| 19:11 |
hmmmm |
mm oh you do realize that C rounds to -inf right? |
| 19:11 |
hmmmm |
not to 0 |
| 19:11 |
nore |
ok, I'm going to merge the shader thing |
| 19:12 |
|
Neological joined #minetest-dev |
| 19:13 |
ShadowNinja |
sapier: The rounding should be above the contains check. |
| 19:14 |
sapier |
what are you talking about hmmmm? |
| 19:16 |
ShadowNinja |
sapier: You try to convert a 0-24000 time range to a 0-24000 time range as if it were a 0-1 range. |
| 19:16 |
ShadowNinja |
(170 & 171) |
| 19:17 |
thexyz |
nore: uh, you shouldn't create pull requests from master branch if you plan to change it |
| 19:17 |
thexyz |
nore: https://github.com/minetest/minetest/pull/606 https://github.com/minetest/minetest/pull/1041 |
| 19:21 |
hmmmm |
sapier: err, I mean toward zero, but you round toward -inf |
| 19:21 |
hmmmm |
if you check the actual code in the core, after it does the +- 0.5 adjustment, it rounds toward zero |
| 19:22 |
hmmmm |
because it implicitly converts float to int |
| 19:23 |
hmmmm |
can you try doing math.ceil for the less-than-0 case? |
| 19:27 |
ShadowNinja |
local function round_to_zero(x) if x > 0 then return math.floor(x) else return math.ceil(x) end end <-- Something like that should make it a lot shorter. |
| 19:28 |
sapier |
trying ceil rounding ... shadow even if time was wrong the node still should be same ;-P |
| 19:30 |
sapier |
the rounding result seems to be more correct with ceil but vmanip <-> real world matching aint better |
| 19:30 |
sapier |
I try to create a simple mod only checking consistency |
| 19:37 |
|
Akien joined #minetest-dev |
| 19:39 |
|
Calinou joined #minetest-dev |
| 19:43 |
|
Gethiox joined #minetest-dev |
| 19:51 |
sapier |
ok guess I found the main issue |
| 19:51 |
sapier |
why does it alway break once I said this |
| 19:56 |
hmmmm |
well what was the main issue? is it valid or did you just think you found an issue? |
| 19:56 |
hmmmm |
because it could be that there are multiple unrelated problems |
| 19:56 |
sapier |
VoxelHelper:new doesn't complain about invalid parameters |
| 19:56 |
hmmmm |
of course not |
| 19:56 |
hmmmm |
and you mean VoxelArea btw |
| 19:57 |
sapier |
I do but having nil as a parameter that is required is an error to me ;-) |
| 19:57 |
hmmmm |
the entire voxelcrap was made with speed in mind, not ease of use |
| 19:58 |
sapier |
ok for my simple testmod vector.round() seems to be valid |
| 19:59 |
sapier |
sorry speed in mind is not a excuse for skipping error check in a function called ONCE ;-) |
| 20:00 |
nore |
thexyz, ? |
| 20:00 |
nore |
<thexyz> nore: uh, you shouldn't create pull requests from master branch if you plan to change it <-- about that |
| 20:00 |
hmmmm |
well I was opposed to error checking in general for that reason |
| 20:01 |
sapier |
especialy if parameters are passed in a non intuitive way as VoxelArea:new({MinEdge=got_minp,MaxEdge=got_maxp}) |
| 20:01 |
sapier |
btw () is missing in lua_api.txt |
| 20:01 |
hmmmm |
you can skip that |
| 20:01 |
hmmmm |
VoxelArea:new{} is valid |
| 20:02 |
sapier |
realy with {}? |
| 20:02 |
hmmmm |
shockingly yes |
| 20:02 |
|
Sokomine joined #minetest-dev |
| 20:02 |
hmmmm |
must be some oddity of lua syntax that I accidentally discovered |
| 20:02 |
sapier |
where's that syntax from? |
| 20:03 |
hmmmm |
shrug |
| 20:03 |
sapier |
never seen anything like that |
| 20:03 |
hmmmm |
try it |
| 20:03 |
sapier |
and how to passt the edges? |
| 20:03 |
nore |
thexyz, if that was about my force loading pull request, it is because I made that pull request when I didn't even know how to use git... |
| 20:04 |
nore |
and IIRC I haven't been able to change the branch without creating another pull |
| 20:05 |
celeron55 |
sapier: yes, you can leave out () from a function call that has a single table argument |
| 20:05 |
sapier |
that one should be forbidden ;-) |
| 20:07 |
kaeza |
works for strings too |
| 20:08 |
sapier |
I'm working with lua for 2 years now and I'm still astonished what strange constructs are possible |
| 20:08 |
kaeza |
it's some wonky way to support "extensions" to the syntax, like require "foo" |
| 20:08 |
hmmmm |
scripting languages in general |
| 20:08 |
hmmmm |
I've grown to strongly hate scripting languages |
| 20:08 |
sapier |
but still Imho new should not pass without error if MinEdge and MaxEdge are missing |
| 20:09 |
hmmmm |
at work I have a side project that I have to do JS and python for and it's horrid |
| 20:09 |
sapier |
ok seems now I don't get node missmatches any longer ... *crossing fingers* |
| 20:11 |
celeron55 |
that particular lua shortcut is probably due to how they based lua on some older projects and wanted the old file format to be loadable as a lua script |
| 20:12 |
celeron55 |
here's a very old text about lua in which they describe it in an... interesting way: http://www.lua.org/semish94.html |
| 20:13 |
celeron55 |
it's about the first ever version i guess 8) |
| 20:13 |
sapier |
do we really want to encourage users to use that old syntax? |
| 20:16 |
celeron55 |
(of course it also for what kaeza said; fancier syntax; eg. if you implement a class system in lua, it's very useful) |
| 20:16 |
celeron55 |
sapier: probably not |
| 20:17 |
kaeza |
someone on #lua posted the other day a C++-like syntax, like class "Foo" : extends { ... } |
| 20:17 |
kaeza |
with some clever constructs :P |
| 20:17 |
sapier |
I'd not be surprised if others would assume that to be an error too ... at least you wonder what is meant by it |
| 20:18 |
sapier |
I missinterpreted it to be pseudocode |
| 20:18 |
kaeza |
err Java-like rather |
| 20:18 |
celeron55 |
sapier: and it's of course completely out of question to actually learn the language one is using? |
| 20:18 |
celeron55 |
one can read the "programming in lua" book in one afternoon and it's super useful |
| 20:18 |
sapier |
I assume you know any special construct and meaning of c? :-) |
| 20:19 |
hmmmm |
when you hate the language you're working with you don't necessarily want to read a book on it |
| 20:19 |
celeron55 |
you can know practically everything about lua |
| 20:19 |
sapier |
there are very less languages where you have only one possible way to do something ... most ppl don't memorize any single possible way if there are hundreds ;-) |
| 20:20 |
celeron55 |
hmmmm: it helps because then you are able to avoid the pitfalls and that way be more happy |
| 20:20 |
sapier |
I don't deny this would be usefull ... yet it's like backups ... everyone knows you should do them ;-) |
| 20:21 |
lanxu |
Wait? reading "programming in lua" in one afternoon... And understand everything? :) |
| 20:21 |
sapier |
and memorize everything |
| 20:22 |
PilzAdam |
hmmmm, how can you "hate" a programming language? |
| 20:22 |
celeron55 |
lanxu: well at least you'll immediately recall single argument functions from the book when seeing them elsewhere |
| 20:22 |
sapier |
celeron page 10 line 5 word 2? :-) |
| 20:22 |
hmmmm |
PilzAdam, easily |
| 20:22 |
celeron55 |
sapier: if that's how you read books, then i understand you hate it |
| 20:22 |
celeron55 |
you probably also make backups by copying files by hand |
| 20:23 |
celeron55 |
anyway! |
| 20:23 |
sapier |
I didn't say I hate it thats hmmmms saying... I've seen worse languages ;-) |
| 20:23 |
sapier |
scheme for example |
| 20:23 |
kaeza |
I don't see anything wrong with implementing foo{...} as convenience for foo({...}) |
| 20:23 |
celeron55 |
just change the docs to not suggest the parenthesis-less syntax |
| 20:23 |
kaeza |
fun fact: foo:bar() is the same as foo.bar(foo), except 'foo' is only evaluated once |
| 20:23 |
jin_xi |
lets rely on things like that |
| 20:24 |
sapier |
I knew that kaeza ... that feature is particulary usefull :-) |
| 20:24 |
celeron55 |
kaeza: so can we detect the evaluation count and screw people up? |
| 20:25 |
kaeza |
no I mean, if you do foo[bleh].bar:baz(), it does less lookups than foo[bleh].bar.baz(foo[bleh].bar) |
| 20:26 |
celeron55 |
i know you mean that |
| 20:26 |
kaeza |
oookay, moving on... |
| 20:26 |
kaeza |
:P |
| 20:26 |
sapier |
yea I thought about fixing mobf to use that syntax ... but was to lazy to do by now :-) |
| 20:27 |
|
KingsleyT joined #minetest-dev |
| 20:30 |
sapier |
ok I may have succeeded in fetching light values from vmanip |
| 20:30 |
sapier |
... light values are floored uppon return to lua |
| 20:42 |
sapier |
https://gist.github.com/sapier/7863517 that code might be usefull for others ... what do you think about adding it to builtin? |
| 20:43 |
hmmmm |
possibly |
| 20:43 |
hmmmm |
if I were you I'd compare it against computing in the core and see what's better |
| 20:44 |
sapier |
good Idea as I have identical code here I may even get a valid result |
| 20:46 |
|
EdB joined #minetest-dev |
| 20:48 |
|
ImQ009 joined #minetest-dev |
| 21:04 |
|
Miner_48er joined #minetest-dev |
| 21:16 |
|
Akien joined #minetest-dev |
| 21:16 |
|
us|0gb joined #minetest-dev |
| 21:20 |
|
sapier joined #minetest-dev |
| 21:20 |
sapier |
ok ... answer to is it worth using voxel is a absolute exact and non missinterpretable "maybe" :-/ |
| 21:21 |
sapier |
if you only want to read a single(up to some value) light value core is way faster ... but as of some threshold voxelmanip starts to become faster |
| 21:22 |
|
PilzAdam joined #minetest-dev |
| 21:25 |
|
EdB left #minetest-dev |
| 21:28 |
sapier |
wow ... guess there's a situation where core lighting really looses "Comparing core to voxel : 1805.3405761719 <--> 0.0048828125" |
| 21:33 |
sapier |
forget about it ... benchmark error :-) |
| 21:56 |
sapier |
ok without luajit voxelmanip light isn't at all a competitior ... with luajit you need to check very high numbers of nodes to gain some benefit ... but there's way more spread then expected |
| 21:57 |
sapier |
very high numbers == >10k nodes |
| 22:01 |
|
ImQ009_ joined #minetest-dev |
| 22:08 |
|
djdduty joined #minetest-dev |
| 22:14 |
|
emptty joined #minetest-dev |
| 22:41 |
hmmmm |
by "core lighting" you mean get_node_light()? |
| 22:42 |
hmmmm |
also you're taking into account the C->lua switching, right? you need to benchmark in the core to figure that one out |
| 22:56 |
sapier |
yes I do |
| 22:57 |
sapier |
why do I need to benchmark in core? I'm interested in how much time to get that information to lua mod |
| 22:58 |
sapier |
if whole spawning is done withing core that'll be way faster of course |
| 23:00 |
|
EvergreenTree joined #minetest-dev |
| 23:01 |
emptty |
ShadowNinja: you said a while ago that the furnace should use minetest.swap_node. Could you please be more specific? That bug of blinking furnaces is driving me crazy |
| 23:01 |
emptty |
(but I'm a complete noob with the minetest codebase) |
| 23:03 |
|
Anchakor_ joined #minetest-dev |
| 23:07 |
hmmmm |
sapier, well you also need to consider that an 80*80*80 chunk is 512000 nodes, which is way more than 10k |
| 23:09 |
sapier |
yes I tried 21*21*21 (distance 10) |
| 23:09 |
hmmmm |
is this the number of checks that need to be done for a single spawn? |
| 23:09 |
sapier |
but if you don't have luajit that value ise more 1 milion then 10k |
| 23:10 |
sapier |
no I increased the number till I found the point where core and voxel have been equal |
| 23:10 |
hmmmm |
to be fair, VoxelManip was designed for way bigger jobs than 21x21x21 |
| 23:11 |
hmmmm |
and not for get_node_light() which is pretty lightweight compared to setNode() |
| 23:11 |
sapier |
worst thing I have right now is 7*7*7 |
| 23:12 |
sapier |
true |
| 23:12 |
sapier |
wrong tool for this job |
| 23:12 |
hmmmm |
see, the thing about VoxelManip is that you're able to check multiple things about that node at once |
| 23:12 |
hmmmm |
like the content as well |
| 23:13 |
hmmmm |
so you can have one voxelmanip object on that area, find the surface, spawn on a specific node, with a specific number of nodes around it, and then check the light values, etc. |
| 23:13 |
sapier |
doing all of those things requires way less then 10k nodes |
| 23:14 |
sapier |
counting of nodes can be done completely in core no need to transfere all data up (most time) |
| 23:14 |
sapier |
more relevant is you can't check for objects more then 32 nodes away |
| 23:15 |
sapier |
e.g. if you want mobs to be rare |
| 23:16 |
sapier |
if you do on a single spawn you can use spawn chance ... but if you do continous spawning it's just a matter of time till that mob will be everywhere |
| 23:18 |
hmmmm |
so it's just based on the proximity to other mobs |
| 23:18 |
hmmmm |
Minecraft has a "mobcap" that deals more with the number of mob objects in the loaded area |
| 23:18 |
sapier |
yes but that does only work for distances below activity range ... need to find some way to work that one around |
| 23:19 |
hmmmm |
see, we could do that instead if it weren't for the current crappy block loading scheme |
| 23:19 |
sapier |
current adv_spawning can already do mobcap |
| 23:20 |
sapier |
one possibility is to store unloaded mob locations within a separate metadata file |
| 23:20 |
sapier |
do you know how fast lua's hashtable implementation is? does it do linear search? |
| 23:21 |
hmmmm |
hahaha |
| 23:21 |
hmmmm |
lua's hashtable implementation called a "table" |
| 23:21 |
sapier |
ok so linear search :-) |
| 23:21 |
hmmmm |
if lua really did linear searching for table lookups the result would be an unusable toy language |
| 23:21 |
sapier |
no linear search? |
| 23:22 |
sapier |
if not it might be an option |
| 23:22 |
hmmmm |
I'm saying there's no way that Lua could possibly be using linear search without the performance being even MORE dogshit than it is currently |
| 23:22 |
sapier |
ok ok :-) |
| 23:23 |
sapier |
guess we really need a real on_deactivate callback for entities |
| 23:25 |
hmmmm |
ugh, I need to add a vector to the Mapgen class but I really don't like the idea of adding yet another non-POD datatype... |
| 23:25 |
hmmmm |
or no, it is POD right now. |
| 23:28 |
ShadowNinja |
emptty: swap_node doesn't reset the formspec. It's added in master now. |
| 23:30 |
emptty |
ShadowNinja: so, there is no workaround for 0.4.8? |
| 23:31 |
ShadowNinja |
emptty: Well, you could manually apply the patches to the core and game. But not without modifying it. |
| 23:36 |
emptty |
ShadowNinja: will this one be enough? https://github.com/minetest/minetest/commit/d879a539cd19ddd1ee34afec2512fb2238de2822 |
| 23:37 |
Exio4 |
you need the patch for minetest_game too |
| 23:37 |
ShadowNinja |
emptty: You'll also want the doc fix, and the..^ |
| 23:37 |
emptty |
I don't really want the doc fix for now ;) |
| 23:38 |
emptty |
That one? https://github.com/minetest/minetest_game/commit/47a49eccf4bd59427fa7486fd413e6eade1db896 |
| 23:40 |
Exio4 |
yeah |
| 23:52 |
emptty |
let me try it :) |
| 23:53 |
emptty |
But that's quite a huge bug, by the way. It kinda ruins the gameplay. |
| 23:54 |
emptty |
don't you think that it could justify a 0.4.8.1 or something? |
