| Time |
Nick |
Message |
| 00:01 |
|
twoelk joined #minetest-dev |
| 00:04 |
|
mrtux joined #minetest-dev |
| 00:18 |
Zefram_Fysh |
with recent master, I can't get the label and buttons in the creative form to align at any window size. they're most nearly aligned for large window sizes, but even at fullscreen they're visibly misaligned |
| 00:18 |
Zefram_Fysh |
can you show me a screenshot of the aligned state? |
| 00:23 |
Zefram_Fysh |
''tell sapier with recent master, I can't get the label and buttons in the creative form to align at any window size. they're most nearly aligned for large window sizes, but even at fullscreen they're visibly misaligned. can you show me a screenshot of the aligned state? |
| 00:23 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 00:34 |
|
exio4 left #minetest-dev |
| 00:39 |
|
CraigyDavi` joined #minetest-dev |
| 01:02 |
|
hmmmm joined #minetest-dev |
| 01:28 |
|
Zeno` joined #minetest-dev |
| 01:29 |
|
domtron joined #minetest-dev |
| 01:34 |
|
domtron left #minetest-dev |
| 01:36 |
|
^v joined #minetest-dev |
| 03:10 |
|
Robby joined #minetest-dev |
| 03:43 |
|
Hunterz joined #minetest-dev |
| 04:28 |
|
CraigyDavi`` joined #minetest-dev |
| 05:45 |
|
Hunterz1 joined #minetest-dev |
| 05:54 |
|
kahrl joined #minetest-dev |
| 06:17 |
|
Jordach joined #minetest-dev |
| 07:11 |
|
OldCoder joined #minetest-dev |
| 07:12 |
|
SmugLeaf joined #minetest-dev |
| 07:12 |
|
SmugLeaf joined #minetest-dev |
| 07:14 |
realbadangel_ |
https://github.com/RealBadAngel/minetest/commit/7847614784758b009e41ac4b0a4cea6fb26954e8 |
| 07:14 |
realbadangel_ |
any comments? |
| 07:19 |
Zeno` |
yes, why is continuous_tiles_count cast to f32? |
| 07:20 |
Zeno` |
the other values in the expression are double, so I'm not sure why that cast is needed (it will be "recast" to double) |
| 07:23 |
Zeno` |
gosh I'm sorry |
| 07:23 |
Zeno` |
that's pretty pedantic lol |
| 07:23 |
RealBadAngel |
v3f is vector of floats |
| 07:24 |
RealBadAngel |
but i touched that line because 2. and changed it to 2.0 |
| 07:26 |
RealBadAngel |
btw, http://forum.voxelands.com/viewtopic.php?id=256 |
| 07:26 |
RealBadAngel |
darkrose has nodeboxes with def in meta |
| 07:27 |
Zeno` |
well as far as I can see, and for what little it matters, your code looks good |
| 07:27 |
RealBadAngel |
using decode_light there was a bug |
| 07:27 |
|
nore joined #minetest-dev |
| 07:27 |
darkrose |
>.> |
| 07:28 |
RealBadAngel |
hi darkrose |
| 07:28 |
RealBadAngel |
i was just reading that code |
| 07:28 |
darkrose |
hi |
| 07:28 |
RealBadAngel |
was also lookin at nodeboxes lighting code |
| 07:28 |
RealBadAngel |
its quite ok, but have some flaws |
| 07:29 |
darkrose |
I need to redo that lightinng code, it's kinda dodgy |
| 07:29 |
darkrose |
yeah |
| 07:29 |
RealBadAngel |
you can see that on stairs especially |
| 07:29 |
darkrose |
the nodebox meta stuff lets me do things like: https://www.youtube.com/watch?v=blfvdffe11w |
| 07:30 |
RealBadAngel |
neat |
| 07:30 |
RealBadAngel |
that thing is needed to cut down number of nodedef for many things |
| 07:30 |
RealBadAngel |
pipes, cables, tubes etc |
| 07:30 |
|
hmmmm joined #minetest-dev |
| 07:31 |
RealBadAngel |
basically all the nodes that previously required multiple defs can become just one |
| 07:31 |
darkrose |
yeah, well in voxelands I just add new drawtypes for things like wires and roofs |
| 07:32 |
RealBadAngel |
i havent saw the wires yet, theyre already in? |
| 07:32 |
darkrose |
in next, will be in the next release |
| 07:33 |
darkrose |
pistons: https://www.youtube.com/watch?v=viK1NV96Kyg |
| 07:33 |
RealBadAngel |
i wanted to code them but have no time for that |
| 07:34 |
RealBadAngel |
btw, highlighting is nice idea |
| 07:34 |
RealBadAngel |
way better than selection boxes |
| 07:34 |
darkrose |
yeah, I've got it as a setting though... someone claimed the highlighting was hypnotising them o.0 |
| 07:35 |
RealBadAngel |
rotfl |
| 07:38 |
darkrose |
mind you, this is the same person who removes oerkkis because they're against his religion |
| 07:39 |
Jordach |
not even ghosts ;) |
| 07:42 |
|
MichaelRpdx joined #minetest-dev |
| 07:47 |
RealBadAngel |
darkrose, bout nodeboxes lights, it should be enough to do some scaling with distance to the edge of full node |
| 07:48 |
darkrose |
maybe, the problem is take a slab on top of stone, put a torch on top... the top should be fully lit, but it'd show as dark |
| 07:50 |
RealBadAngel |
i need to fix that to have work with current lighting system finished |
| 07:50 |
RealBadAngel |
then going to make it optional |
| 07:51 |
RealBadAngel |
and strip it down just to light level calculations and work with irrlicht lights |
| 07:51 |
RealBadAngel |
effects are pretty promising |
| 07:51 |
RealBadAngel |
http://i.imgur.com/wHjL1dJ.png |
| 07:52 |
darkrose |
yeah I had a bit of a play with irrlicht lighting a while ago... was cool watching shadows moving around throughout the day |
| 07:52 |
RealBadAngel |
that will play nicely with bumpmapping and specular lights |
| 07:53 |
RealBadAngel |
but im a bit afraid of one thing i found out, one scene node can have max of 8 dynamic lights |
| 07:55 |
darkrose |
yeah, that was ultimately why I stopped experimenting |
| 07:55 |
RealBadAngel |
while its not a problem when doing sunlight, it may be a problem to use them for nodes |
| 07:55 |
RealBadAngel |
so maybe combination of two light systems will be needed |
| 07:55 |
RealBadAngel |
one for torches etc and irrlicht for sun |
| 07:59 |
|
PilzAdam joined #minetest-dev |
| 07:59 |
RealBadAngel |
hi PilzAdam |
| 08:00 |
RealBadAngel |
PilzAdam, https://github.com/RealBadAngel/minetest/commit/7847614784758b009e41ac4b0a4cea6fb26954e8 |
| 08:00 |
RealBadAngel |
anything against those fixes? |
| 08:52 |
|
Megaf joined #minetest-dev |
| 09:30 |
|
Calinou joined #minetest-dev |
| 09:31 |
|
Garmine joined #minetest-dev |
| 09:39 |
|
MichaelRpdx joined #minetest-dev |
| 09:50 |
|
proller joined #minetest-dev |
| 09:58 |
|
sapier joined #minetest-dev |
| 09:59 |
|
rubenwardy joined #minetest-dev |
| 10:01 |
sapier |
Zefram_Fysh: A screenshot with correct alignment on fullscreen was within those where I showed you the wrong alignment, but no problem http://imgur.com/eeaMcGN,tExC4hr,f38B2Kc,Bc7XFKy,9EtZoJz,AO0ODuy,bJbBz9c,Pk7arBt,0nXfr0Q,P5O3gN2,RXpGmth,NXylk2C#10 |
| 10:02 |
sapier |
Zefram_Fysh: don't rely on hulabot it did fail ... again |
| 10:08 |
Zeno` |
Can https://github.com/minetest/minetest/pull/1543 me merged? It doesn't affect make_ltree() calls by mapgen |
| 10:08 |
RealBadAngel |
sapier, going to merge this: https://github.com/RealBadAngel/minetest/commit/7847614784758b009e41ac4b0a4cea6fb26954e8 |
| 10:08 |
RealBadAngel |
any objections? |
| 10:09 |
Zeno` |
in fact I'm not even sure mapgen calls make_ltree() at all |
| 10:10 |
RealBadAngel |
no, mapgens do not use l-system trees yet |
| 10:10 |
RealBadAngel |
v7 is supposed to do so |
| 10:12 |
Zeno` |
It shouldn't affect v7 though (if it supplies a seed) |
| 10:13 |
Zeno` |
if v7 /doesn't/ supply a seed then that's a different issue (IMO) |
| 10:13 |
sapier |
RealBadAngel: hope you know what you're doing ;-) ... wait |
| 10:13 |
sapier |
line 274 what happens if light_amount becomes negative? |
| 10:15 |
Zeno` |
line 274 of what? |
| 10:15 |
sapier |
was talking to rba |
| 10:15 |
Zeno` |
that's ok, I'd still like to know :) |
| 10:15 |
sapier |
as that situation would be a new reason for a crash, in original code this couldn't happen |
| 10:16 |
|
rubenwardy joined #minetest-dev |
| 10:17 |
sapier |
sqrtf(light_amount) ... without making sure light_amount is >= 0 is usually a bad idea |
| 10:20 |
Zeno` |
it's not possible for light_amount to be < 0 |
| 10:21 |
sapier |
why? |
| 10:21 |
kahrl |
sapier: wouldn't sqrtf(something negative) just return NaN? not crash? |
| 10:21 |
Zeno` |
because 0 <= ambient_occlussion <= 8 |
| 10:22 |
sapier |
where's that limit enforced? |
| 10:22 |
Zeno` |
in the loop 236-258 |
| 10:23 |
sapier |
kahrl: are you sure rounding clamping and multiplying and passing NAN to irrlicht wouldn't cause a crash? |
| 10:24 |
kahrl |
no |
| 10:24 |
Zeno` |
it's not "enforced" as such, it's a post-condition |
| 10:24 |
sapier |
Zeno`: ok seems to be fine, yet I'd feel better if taht strange "ambient_occlusion -= 4;" would be replaced by mentioning this :) |
| 10:24 |
Zeno` |
yeah, or make 8 a constant |
| 10:25 |
Zeno` |
and even add an assert() to make it obvious |
| 10:25 |
|
MichaelRpdx joined #minetest-dev |
| 10:25 |
sapier |
well as long as it's ensured within the function Imho an assert isn't necessary but that's a personal preference |
| 10:26 |
RealBadAngel |
sapier it cannot be negative |
| 10:26 |
RealBadAngel |
if(ambient_occlusion > 4) |
| 10:27 |
sapier |
RealBadAngel: sorry but that check doesn't help ;-) |
| 10:27 |
sapier |
well not completely |
| 10:28 |
sapier |
if ambient_occlusion would be 9 it'd stell be > 4 ... yet a negative value would happen .. but it' can't be 9 as zeno mentioned |
| 10:29 |
RealBadAngel |
code runs in my sandbox for 3 days already, havent experienced any crashes |
| 10:31 |
sapier |
RealBadAngel: In this special case it can't crash because of the precondidion Zeno`mentioned which I did miss, yet testing is not a proove for correctness ;-) ... btw what's that comment about -4 there? at least I don't understand what it's supposed to tell. maybe it's a relic of old code? |
| 10:32 |
RealBadAngel |
idk |
| 10:32 |
RealBadAngel |
the equation is still present in voxelands for example |
| 10:32 |
RealBadAngel |
here it is commented out for ages |
| 10:33 |
Zeno` |
a comment would be nice, but the code is correct |
| 10:34 |
sapier |
to me that comment seems to be some old variant of this calculation, but I'm not sure |
| 10:34 |
RealBadAngel |
light_amount have values 0-1 |
| 10:36 |
RealBadAngel |
and ambient_occlusion passed there is in range 5-7 |
| 10:39 |
RealBadAngel |
ok loop is 0-8, ambient_occlusion start value is 0, it can be increased up to 8 times |
| 10:39 |
rubenwardy |
Has there been any investigations / proof of concepts into client side ambient sounds? |
| 10:39 |
RealBadAngel |
so the value expressed cannot become negative in any way |
| 10:40 |
RealBadAngel |
check is not necesary |
| 10:40 |
Zeno` |
I said that earlier RBA :p |
| 10:41 |
sapier |
RealBadAngel: yes you're right we already found that out ;-) a comment would be nice to save next one from having to find out again but it'd be not "necassary" as of causing a crash without ;-) |
| 10:41 |
RealBadAngel |
yup i know, but i had to check rthat too |
| 10:41 |
sapier |
see sqrt(variable) is one of those operations causing a trigger to look at code more close ;-) |
| 10:42 |
sapier |
same as / variable |
| 10:42 |
RealBadAngel |
what i should comment? that it cannot be negative? |
| 10:42 |
sapier |
something like // caclulated before rane 0-7 |
| 10:42 |
sapier |
range |
| 10:43 |
RealBadAngel |
force me to comment the math and i will make a precalculated table for that |
| 10:43 |
RealBadAngel |
;) |
| 10:43 |
RealBadAngel |
and we will gain some more cycyles ;) |
| 10:44 |
sapier |
I don't force you I do only suggest commenting it as it'd make life more easy for others |
| 10:44 |
RealBadAngel |
in fact its a good idea |
| 10:44 |
RealBadAngel |
changing it now to const table of floats |
| 10:46 |
sapier |
not a problem but tables usually need some comments to explain what they represent too ;-) |
| 10:46 |
RealBadAngel |
it can have just three possible values |
| 10:46 |
RealBadAngel |
lol |
| 10:46 |
RealBadAngel |
0.25 0.5 and 0.75 |
| 10:46 |
RealBadAngel |
so nonsense using sqrt here |
| 10:47 |
Zeno` |
I'd just write //assert(ambient_occlusion >=0 && ambient_occlusion <= 8) (as a comment) |
| 10:47 |
sapier |
quite a small table then ;-) guess comment would be more then table |
| 10:47 |
RealBadAngel |
but sqrt is quite heavy |
| 10:47 |
RealBadAngel |
reading a table is fast |
| 10:47 |
sapier |
Zeno`: doing it that way would make me interpret it as "someone did comment out that assert because it tid hit" ;-) |
| 10:47 |
Zeno` |
heh, maybe |
| 10:48 |
Zeno` |
sqrt() is not *that* heavy (at least on x86) |
| 10:48 |
sapier |
Zeno`: but we do have arm too |
| 10:48 |
sapier |
and mips |
| 10:48 |
sapier |
ohhh ..... |
| 10:48 |
Zeno` |
yeah, I'd have to look at mips. I think sqrt() is an intrinsic instruction for ARM though |
| 10:49 |
sapier |
for what I've seen in profiler all those multiplication division operations are quite heavy on arm |
| 10:49 |
Zeno` |
but since it's only 8 values a LUT may be ok |
| 10:49 |
Zeno` |
ok, I haven't profiled on ARM :) |
| 10:49 |
sapier |
well they're not done in draw loop ... they aren't RealBadAngel? |
| 10:50 |
sapier |
Zeno`: it's quite amazing how prominent those math calculations are in "top cpu time per function" list on arm ... especially compared to x86 |
| 10:51 |
RealBadAngel |
sapier, its called pretty often |
| 10:51 |
RealBadAngel |
whenever lights are changing |
| 10:51 |
RealBadAngel |
that includes change of daynight ratio |
| 10:54 |
sapier |
hmm well the original code wasn't exactly "lightweight" too |
| 10:55 |
sapier |
5 multiply operations to 1 mp + sqrt .. on first glance I'd guess a slight benefit for new variant |
| 11:02 |
|
proller joined #minetest-dev |
| 11:03 |
RealBadAngel |
new one is twice as fast |
| 11:04 |
RealBadAngel |
and the next will even more faster |
| 11:04 |
RealBadAngel |
ambient_occlusion -= 5; |
| 11:04 |
RealBadAngel |
const float light_amount[4] = {0.75, 0.5, 0.25, 0.0}; |
| 11:04 |
RealBadAngel |
light = core::clamp(core::round32(light*light_amount[ambient_occlusion]), 0, 255); |
| 11:08 |
|
hintss joined #minetest-dev |
| 11:09 |
RealBadAngel |
ah, just need to put there sqrt of those values ;) |
| 11:10 |
sapier |
ok but please add comments ;-) |
| 11:13 |
RealBadAngel |
for comments make any sense i should leave original code propably |
| 11:15 |
RealBadAngel |
https://github.com/RealBadAngel/minetest/compare/lights1#diff-c2f90db5de8c33a259c27113939c63c5L273 |
| 11:16 |
sapier |
not sure but is there a way to make preprocessor calc those strange numbers from better ones? |
| 11:17 |
sapier |
and now you really have to explain why ambient_occlusion -= 5; ;-) |
| 11:17 |
RealBadAngel |
ok, will do that |
| 11:18 |
RealBadAngel |
anyway i have to recalc those values, theyre not really correct |
| 11:18 |
RealBadAngel |
pow here was 2.2 not 2.0 |
| 11:18 |
RealBadAngel |
so its not really sqrt here |
| 11:18 |
sapier |
as I said if preprocessor yould do this it'd be better if not you should add a comment how they are calculated |
| 11:20 |
Zeno` |
I have an announcement |
| 11:20 |
Zeno` |
I haven't frequented this channel for very long, but this is the first time I've seen proper feedback and constructive crit. I like it. |
| 11:21 |
Zeno` |
Announcement over. I may get drunk now. |
| 11:22 |
RealBadAngel |
hehe |
| 11:27 |
|
Exio4 joined #minetest-dev |
| 11:49 |
|
PenguinDad joined #minetest-dev |
| 11:59 |
|
ImQ009 joined #minetest-dev |
| 12:01 |
|
Jordach joined #minetest-dev |
| 12:07 |
|
alexxs joined #minetest-dev |
| 12:17 |
sapier |
https://github.com/minetest/minetest/pull/1561 plz review, I fixed the remaining glitches (named top left and progress bar beeing cut on high dpi) ... formspecs are still broken on high dpi settings bu that's topic of Zefram_Fysh's work |
| 12:17 |
|
MichaelRpdx joined #minetest-dev |
| 12:18 |
sapier |
https://github.com/minetest/minetest/pull/875 ShadowNinja what's your opinion on this? |
| 13:00 |
|
proller joined #minetest-dev |
| 13:07 |
|
sapier joined #minetest-dev |
| 13:18 |
|
ImQ009 joined #minetest-dev |
| 13:27 |
|
BlockMen joined #minetest-dev |
| 13:56 |
|
NakedFury joined #minetest-dev |
| 14:05 |
|
virtualfall joined #minetest-dev |
| 14:06 |
|
Jordach joined #minetest-dev |
| 14:37 |
|
virtualfall left #minetest-dev |
| 14:44 |
|
hmmmm joined #minetest-dev |
| 14:47 |
|
hmmmm joined #minetest-dev |
| 14:51 |
|
casimir joined #minetest-dev |
| 15:21 |
sapier |
https://gist.github.com/sapier/de28cd52166453ce7e54 comments? it's supposed to avoid calling a playerevent without actually having a player to do an event for |
| 15:21 |
sfan5 |
looks ok |
| 15:27 |
sapier |
ok pushing that small fix |
| 15:29 |
|
domtron joined #minetest-dev |
| 15:30 |
|
domtron left #minetest-dev |
| 15:39 |
|
Calinou joined #minetest-dev |
| 15:56 |
|
Jordach joined #minetest-dev |
| 16:22 |
|
Hunterz joined #minetest-dev |
| 16:25 |
|
zat joined #minetest-dev |
| 16:34 |
|
khonkhortisan joined #minetest-dev |
| 16:38 |
|
Krock joined #minetest-dev |
| 16:54 |
|
^v joined #minetest-dev |
| 16:57 |
|
^v joined #minetest-dev |
| 17:19 |
|
OldCoder joined #minetest-dev |
| 17:59 |
|
cg72 joined #minetest-dev |
| 18:16 |
|
khonkhortisan joined #minetest-dev |
| 18:19 |
|
twoelk joined #minetest-dev |
| 18:30 |
|
twoelk joined #minetest-dev |
| 18:43 |
|
SoniEx2 joined #minetest-dev |
| 18:48 |
|
deltib joined #minetest-dev |
| 19:04 |
|
deltib joined #minetest-dev |
| 19:19 |
|
nore joined #minetest-dev |
| 19:30 |
|
Miner_48er joined #minetest-dev |
| 19:32 |
|
iqualfragile joined #minetest-dev |
| 19:36 |
|
deltib joined #minetest-dev |
| 19:42 |
|
deltib joined #minetest-dev |
| 20:10 |
|
domtron joined #minetest-dev |
| 20:36 |
|
deltib joined #minetest-dev |
| 20:39 |
|
proller joined #minetest-dev |
| 20:50 |
RealBadAngel |
sapier, https://github.com/RealBadAngel/minetest/commit/24efa37231113c1411c4002f14fb76d81511c8cc#diff-c2f90db5de8c33a259c27113939c63c5L273 |
| 20:51 |
RealBadAngel |
https://github.com/RealBadAngel/minetest/commit/bf8fc9b39e191879edd75985aa33a3180c15587c#diff-c2f90db5de8c33a259c27113939c63c5R270 |
| 20:51 |
RealBadAngel |
oops, wrong link before |
| 20:53 |
sapier |
seems to be fine |
| 20:57 |
RealBadAngel |
ok, so merging it and will code now improved lights for nodeboxes and special drawtypes |
| 20:58 |
RealBadAngel |
kinda like that one by darkrose but i hope without flaws |
| 21:05 |
iqualfragile |
RealBadAngel: oh, that would be wonderfull |
| 21:05 |
* VanessaE |
peeks in |
| 21:18 |
|
EvergreenTree joined #minetest-dev |
| 21:19 |
|
blaise joined #minetest-dev |
| 21:21 |
zat |
Guys, someone knows what are the humidity_point and heat_point supposed to mean? In respect to, are they equivalent to air humidity percentage and celcius degrees respectively? |
| 21:24 |
sapier |
zat for what I know humidity doesn't exist any longer |
| 21:24 |
zat |
sapier: in v7? |
| 21:24 |
zat |
how so |
| 21:24 |
sapier |
ah v7 ... ok that's something different |
| 21:25 |
sapier |
guess I was mixing up things |
| 21:25 |
zat |
isn't hmmmm working on it? (ping) |
| 21:26 |
proller |
s/working/worked/ |
| 21:26 |
hmmmm |
don't use it, it's not meant for end-users |
| 21:26 |
zat |
hmmmm: I am making the biomes definitions. |
| 21:28 |
VanessaE |
hmmmm: Zeno` was looking at the mapgen code the other day trying to sort out that vmanip vs. set_node() issue. might have a clue to it. the code seems to be passing the same map state/data to all on_generated() calls e.g. one read from the map, pass it to everyone. sound right to you? |
| 21:29 |
hmmmm |
yes... how is that news |
| 21:29 |
hmmmm |
i explained that 500 times |
| 21:29 |
VanessaE |
because now it makes sense? :P |
| 21:29 |
VanessaE |
and it explains the whole problem. |
| 21:29 |
hmmmm |
no, it still makes as much sense as it did back then |
| 21:29 |
zat |
hmmmm: but do you know what are the real world equivalent for these values? |
| 21:29 |
hmmmm |
zat, there is no real world equivalent. |
| 21:29 |
zat |
proller: who is currently working on it? |
| 21:30 |
zat |
hmmmm: its just 0 to 100 then? |
| 21:30 |
proller |
zat, nobody |
| 21:30 |
zat |
proller: so abandoned? |
| 21:30 |
hmmmm |
yes, 0 to 100. |
| 21:31 |
zat |
hmmmm: I am going to consider them from 0 to 100% humidity and 0 to 100% of 0 to 100°C. |
| 21:32 |
hmmmm |
great |
| 21:32 |
VanessaE |
hmmmm: well anyways I guess the proposal now is to have the engine mark a mapblock as dirty (not unlike what you proposed when this was last discussed) but have the writeback occur before the next pass through the loop that runs all the on_generated callbacks |
| 21:32 |
VanessaE |
i.e. transparent to the mods that use that callback |
| 21:33 |
hmmmm |
vanessae, I don't understand. what are you suggesting was the problem? |
| 21:33 |
VanessaE |
hmmmm: well remember how we thought it was mod A reads, mod B reads, mod B writes, then mod A writes? |
| 21:33 |
hmmmm |
we thought? |
| 21:33 |
VanessaE |
and how that was totally impossible?" |
| 21:33 |
VanessaE |
we being zeno and SPlizard and so forth, not you |
| 21:33 |
hmmmm |
which mod is using set_node/get_node, and which mod is using voxel manip |
| 21:33 |
hmmmm |
A or B |
| 21:34 |
VanessaE |
snow mod, mtz, paramat's mapgens all use vm's. call any one of those "mod A". plants_lib uses set_node, that's mod B. |
| 21:35 |
VanessaE |
well of course that's not what was happening. it's just that A and B were both starting with the same clean map state and it just happens that A was being executed last. |
| 21:35 |
VanessaE |
which is useless in either case because maybe B needs some of the *modified* map that was generated by A |
| 21:35 |
hmmmm |
so in other words, I was right about everything and you were mistaken about the order in which the mods were executed |
| 21:36 |
VanessaE |
no |
| 21:36 |
VanessaE |
order didn't matter |
| 21:36 |
hmmmm |
the order does matter |
| 21:36 |
VanessaE |
if they both start with the exact same clean map state, then they are both gonna try to write that same clean map |
| 21:36 |
twoelk |
random at it's best ;-P |
| 21:36 |
VanessaE |
meaning that one can't possibly have a chance to modify the other's results |
| 21:36 |
VanessaE |
i.e. I can no longer add trees to snow mod's biomes because of this |
| 21:37 |
VanessaE |
because I will never see snow mod's biome data. I will only ever get to see the mapgen's default data - the self same data that snow mod gets from the mapgen |
| 21:37 |
VanessaE |
(mgv6) |
| 21:37 |
hmmmm |
the only order in which this works okay is if the mods using voxelmanip execute first |
| 21:37 |
hmmmm |
and then the get/set node ones do their thing after |
| 21:37 |
VanessaE |
but if they do that, then I never get to see their modified map |
| 21:37 |
VanessaE |
s/I/mod B/ |
| 21:37 |
hmmmm |
the order that causes problems is if you were to run a mod that uses get/set node first, and then a voxelmanip mod runs after |
| 21:37 |
VanessaE |
no |
| 21:37 |
hmmmm |
?? |
| 21:37 |
VanessaE |
either order will fail |
| 21:38 |
hmmmm |
why would the first circumstance fail |
| 21:38 |
VanessaE |
because both mods are getting the exact same map data |
| 21:38 |
VanessaE |
i.e. a mapblock full of dirt, stone, trees, etc. |
| 21:38 |
VanessaE |
snow mod modifies it, saves it. but then plants_lib will never get to see it |
| 21:38 |
VanessaE |
plants_lib only ever gets to see that same dirt/stone/trees mapblock that was given to snow mod |
| 21:39 |
hmmmm |
plants_lib meaning the get/set_node mod |
| 21:39 |
VanessaE |
yes. |
| 21:39 |
hmmmm |
and snow mod being the vmanip one |
| 21:39 |
VanessaE |
yes. |
| 21:39 |
hmmmm |
now why is that |
| 21:39 |
VanessaE |
that appears to be why it fails. |
| 21:39 |
hmmmm |
but how does that make any sense |
| 21:39 |
hmmmm |
how do they "see the same map" |
| 21:40 |
VanessaE |
I don't know, I'm going by what Zeno saw in the code - appearently there's one map read that's then passed to all on_generated callbacks |
| 21:40 |
hmmmm |
yes.. that one map read is the voxelmanip read |
| 21:40 |
VanessaE |
yes. |
| 21:40 |
VanessaE |
and then it enters the loop that runs all the on_generated callbacks |
| 21:40 |
VanessaE |
and never writes their results back to the map until after the loop complet |
| 21:40 |
VanessaE |
completes* |
| 21:41 |
hmmmm |
set_node writes back to the map immediately |
| 21:41 |
hmmmm |
the results of get_node are the map as it is right then at that state |
| 21:41 |
VanessaE |
but not if a vmanip is involved. |
| 21:41 |
hmmmm |
that doesn't make any sense though |
| 21:41 |
VanessaE |
I know it doesn't. |
| 21:42 |
hmmmm |
look, I never even observed this bug by myself so I am going 100% based off of what you're reporting |
| 21:42 |
hmmmm |
all of this is speculation as far as i'm concerned |
| 21:42 |
VanessaE |
not just me. zeno confirmed the same on one of his mapgen mods too |
| 21:42 |
VanessaE |
SPlizard also |
| 21:42 |
VanessaE |
and someone before him was the first to report it |
| 21:43 |
VanessaE |
he had to rewrite his mapgen mod to not use vm's just so it could work alongside plants_lib, which btw just does two on_generated calls now. |
| 21:45 |
VanessaE |
so anyway my theory here is that there's one last vm that's "pending" at the end of the on_generated loop, that gets written out finally, and that it contains the results of whatever was done in the meantime, but only if a vm was used and only the results thereof |
| 21:45 |
VanessaE |
but since I can't really read C++ too well I can only speculate as well. |
| 21:46 |
VanessaE |
s/he had to/zeno had to/ |
| 21:53 |
|
casimir joined #minetest-dev |
| 21:55 |
VanessaE |
I just figured I'd grab your ear before you had a chance to wander off :P |
| 21:56 |
VanessaE |
since Zeno` won't be showing up for a while yet. |
| 21:57 |
|
SEx2 joined #minetest-dev |
| 21:57 |
|
paramat joined #minetest-dev |
| 21:58 |
|
ImQ009 joined #minetest-dev |
| 22:00 |
paramat |
VanessaE, have you tried snow mod plus plants_lib since you speeded up your plants_lib code? sometimes i have seen weird results if one mod is very slow |
| 22:00 |
VanessaE |
paramat: not since then, no. |
| 22:01 |
paramat |
i haven't seen your bug but then i don't often run mods together |
| 22:01 |
VanessaE |
the only functional difference, from that standpoint, is that plants_lib registers only 2 mapgen hooks (and around 40 actions) instead of 120-ish. |
| 22:02 |
paramat |
i was considering your use of 'find nodes in area' might have been the slow code? |
| 22:03 |
paramat |
'find nodes near' was always very slow for me even with a small radius |
| 22:04 |
VanessaE |
it's the fastest way to grab a chunk of map data while being able to filter it by node name |
| 22:04 |
VanessaE |
else I'd have to use a vm and compare every node manually. |
| 22:05 |
paramat |
perhaps use dependancies to have snow mod run first |
| 22:05 |
VanessaE |
tried that. |
| 22:06 |
VanessaE |
snow mod has a hack in place to disable its mapgen code outside of its own biome areas, but that still means I can't e.g. add trees and dry grass on a snow biome. |
| 22:14 |
paramat |
zat, mgv7 heat is from -25 to +75 so you can think of it as celcius if you want |
| 22:14 |
paramat |
humidity is from 0 to 100 so i would consider that %humidity |
| 22:15 |
proller |
heat is from -25 to +75 - wat ?? |
| 22:15 |
VanessaE |
just don't go trying to calculate a dewpoint from it :P |
| 22:15 |
proller |
nparams_biome_def_heat(50, 50, |
| 22:20 |
zat |
uh? |
| 22:20 |
zat |
paramat: are you sure |
| 22:22 |
paramat |
oh i was going by .conf 'mgv7_np_heat = 25, 50, (500, 500, 500), 35293, 1, 0' |
| 22:23 |
paramat |
thats latest git |
| 22:24 |
paramat |
biome definition docs may be out of date |
| 22:28 |
proller |
and its working? |
| 22:31 |
Zefram_Fysh |
screenshots and analysis on label/button alignment with my form patch now available at http://www.fysh.org/~zefram/tmp/form_align.html |
| 22:31 |
paramat |
'25, 50' are offset and scale so unless that's a typo heat will be 50 either side of 25 |
| 22:32 |
paramat |
... but only because there's 1 octave |
| 22:34 |
VanessaE |
Zefram_Fysh: looks good |
| 22:36 |
proller |
paramat, and this setting working ? |
| 22:38 |
proller |
Zefram_Fysh, what about 240x240 screen ? |
| 22:40 |
VanessaE |
what are you playing on, a VC-20? :P |
| 22:40 |
paramat |
proller i can't be bothered to test |
| 22:40 |
proller |
no, its smallest available androids |
| 22:42 |
VanessaE |
what, a smartwatch? |
| 22:42 |
VanessaE |
what moron would play MT on a one of those? |
| 22:43 |
* proller |
. |
| 22:43 |
VanessaE |
still I think it's pretty clear that the formspec scaling will fit those small screens also. |
| 22:44 |
VanessaE |
the HUD will be a problem at that size |
| 22:44 |
VanessaE |
but that's not a formspec and not what this patch addresses. |
| 23:11 |
zat |
VanessaE: I am one of those morons apparently. |
| 23:11 |
VanessaE |
:) |
| 23:12 |
sapier |
VanessaE: if dpi is set correct hud will scale to same factor ... so only dependence is quality of your glasses ;-) |
| 23:12 |
VanessaE |
well enjoy your 2px tall fonts I suppose. seems like it would be impossible to play what you can't see :P |
| 23:12 |
VanessaE |
sapier: heh |
| 23:13 |
VanessaE |
you're still a moron for trying to play games on a smartwatch ;) |
| 23:13 |
sapier |
hmm ok sorry but smallest font size to be provided for non ttf will be 4 |
| 23:14 |
VanessaE |
sapier: no TTF on android? |
| 23:17 |
sapier |
for what I remember our offical build uses freetype but that's not a must have |
| 23:17 |
VanessaE |
hm ok |
| 23:17 |
VanessaE |
well seems like you'd want that on android |
| 23:20 |
sapier |
actually the non ttf fonts never would've been that bad if someone did spend just a little bit more time on implementation ;-) |
| 23:25 |
Zefram_Fysh |
I selected 500x400 as the smallest size for my screenshots simply because at the next size down that I would have used the old code didn't scale the form down to fit, so the part I was interested in wasn't in the shot. my patch incidentally makes the code more willing to scale forms down, but really you'd want to reduce gui_scaling if you're on a screen as small as 240x240 |
| 23:26 |
sapier |
Zefram_Fysh: any reason why you didn't do any screenshots with current default window size? ;-) |
| 23:28 |
Zefram_Fysh |
I wanted to use a consistent aspect ratio. to get screenshots the windows all had to fit on my screen, which is a 5:4 aspect ratio, so to get a shot with as many as 1000 lines I was constrained to use my screen's aspect ratio. that's all |
| 23:33 |
sapier |
not showing the default size is ... well ... doubtfull |
| 23:35 |
sapier |
still I'll support your version anyway because it's best chance to get scaling fonts in anytime soon |
