| Time |
Nick |
Message |
| 00:16 |
|
Miner_48er joined #minetest-dev |
| 00:28 |
waressearcher2 |
I found that piece of code "const u32 jj = 10000; for (u32 j = 0; j < jj; j++)" why not to use "for (u32 j = 0; j < 10000; j++)" ? or is it just to make code more readable ? |
| 00:33 |
waressearcher2 |
I mean the variable doesn't named in any meaningfull way like: "number_of_apples" its just "jj" so why bother creating it ? |
| 00:51 |
EUGD |
const? |
| 00:51 |
EUGD |
although agreed 'j' and 'i' is bad |
| 00:51 |
|
EUGD left #minetest-dev |
| 01:39 |
|
proller joined #minetest-dev |
| 02:00 |
|
EUGD joined #minetest-dev |
| 02:02 |
VanessaE |
so, what's the word on how stable (or not) mgv7 is? |
| 02:03 |
VanessaE |
since I put all my servers back online, I'm thinking of replacing one that's never used anyway, with something based on mgv7 |
| 02:04 |
EUGD |
oooh, i got an awesome seed for you if you do |
| 02:04 |
est31 |
mgv7 places ugly trees |
| 02:04 |
EUGD |
iveice? or iceive |
| 02:04 |
est31 |
you cant farm them easily |
| 02:04 |
VanessaE |
est31: oh, because of the branches |
| 02:04 |
VanessaE |
? |
| 02:04 |
EUGD |
giant toon-like mountain spire at 0,0 , literally exactly 0,0 |
| 02:04 |
est31 |
yea |
| 02:05 |
VanessaE |
yeah, skyblock has that problem - treecapitator mod doesn't know how to deal with the newer jungle trees |
| 02:05 |
est31 |
they dont decay because they are the same material as the trunk |
| 02:43 |
hmmmm |
VanessaE, I think paramat made it stable |
| 02:43 |
hmmmm |
due to popular demand and increasing usage of mapgen v7 and now that users rely on consistent output |
| 02:44 |
VanessaE |
by "stable" I mean "no major changes to the biome system, decorations, etc" that would uglify a map after some time |
| 02:44 |
VanessaE |
ok good |
| 02:50 |
VanessaE |
has that l-system bug been fixed yet? |
| 02:50 |
VanessaE |
(the big black shadows) |
| 03:05 |
|
paramat joined #minetest-dev |
| 03:06 |
paramat |
mgv7 isn't stable, it's settled down a bit but still tuning it |
| 03:07 |
paramat |
terrain is fairly settled, still tweaking biomes |
| 03:07 |
paramat |
the idea was to tune it from feedback during 0.4.13 |
| 03:08 |
VanessaE |
ok. |
| 03:08 |
VanessaE |
fix the shadows. :) |
| 03:09 |
paramat |
not my fault, l-system |
| 03:09 |
paramat |
oh mgv7 has a few shadow bugs yes |
| 03:09 |
paramat |
game#687 is the next biome tweak |
| 03:09 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/687 -- Mgv5/7 biomes: Add shallow dirt waters by paramat |
| 03:09 |
waressearcher2 |
is there documentation that explains the different of mapgen v5/v6/v7 ? |
| 03:10 |
waressearcher2 |
difference |
| 03:10 |
waressearcher2 |
main differences |
| 03:10 |
paramat |
erm not really |
| 03:10 |
VanessaE |
paramat: you should add a screenshot showing that ^^^ |
| 03:10 |
waressearcher2 |
paramat: can you describe their difference ? |
| 03:10 |
waressearcher2 |
its hard to tell just looking on source code |
| 03:12 |
ShadowNinja |
waressearcher2: v6 is boring, but stable, v7 is "cooler", and v5 is "coolest" (because it uses 3D noise). |
| 03:13 |
paramat |
well it's complex .. the info is there but scattered around |
| 03:13 |
ShadowNinja |
Of course ther're probably in the opposite order for speed. |
| 03:14 |
ShadowNinja |
they're* |
| 03:14 |
paramat |
v6 is simple 2D noise, v5 is simple 3D noise, v7 combines both |
| 03:15 |
paramat |
v5/v7 use the biome api, v6 has hardcoded biomes |
| 03:25 |
paramat |
only v7 has rivers, it's the most complex and developed mg. i intend to add optional floatlands too |
| 03:30 |
hmmmm |
I disagree that v6 is "boring" |
| 03:31 |
hmmmm |
for just 6 2d noises it generates very impressive output |
| 03:32 |
hmmmm |
a lot of the features seem to repeat because everything is too small. if you double the spread parameters, it becomes very nice looking |
| 03:32 |
paramat |
sfan5 ShadowNinja game#688 |
| 03:32 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/688 -- Rename to Minetest Game by paramat |
| 03:37 |
est31 |
paramat, hmmmm since you both mapgen guys are here: what do we want to do about the world border: the limit enforced by the mapblock.h calls objectpos_over_limit and blockpos_over_limit doesn't match what's generated by the mapgen, due to chunk alignment. This makes map border and object border be different, with content_ignore filled blocks between those two borders. Should we either generate the "border blocks" between the block border and the |
| 03:37 |
est31 |
object border? should we now either generate the map between those two positions somehow, or should objectpos_over_limit be adjusted so that it alings with the mapchunk borders? |
| 03:38 |
est31 |
that first question should not be there... |
| 03:39 |
hmmmm |
i posed this question a couple days ago... nobody seemed interested then |
| 03:39 |
paramat |
i was thinking about that earlier.. |
| 03:39 |
ShadowNinja |
paramat: The mods can be separated from the game, so they really are "Minetest 0.4" mods. |
| 03:39 |
ShadowNinja |
Otherwise seems good. |
| 03:39 |
paramat |
ah |
| 03:39 |
paramat |
0.4 should be removed though |
| 03:40 |
VanessaE |
est31: adjust the limit to match the existing chunk borders. |
| 03:40 |
ShadowNinja |
hmmmm: Relative to the other mapgens I meant. |
| 03:40 |
VanessaE |
that would surely be less likely to break things than generating "extra" chunks, and it would work with existing maps |
| 03:41 |
paramat |
i agree with Vanessa |
| 03:41 |
hmmmm |
I might add the ability to generate up to the map generation limit |
| 03:43 |
VanessaE |
why was it that the map didn't go all the way out to the logical maximum? |
| 03:43 |
VanessaE |
(I mean +/-32767) |
| 03:43 |
hmmmm |
because it's not aligned to a chunk boundary |
| 03:43 |
paramat |
mm that might be okay, mapchunks overshooting the object limit by a little |
| 03:44 |
hmmmm |
hum |
| 03:44 |
paramat |
just not partial mapchunks |
| 03:44 |
hmmmm |
I think I might boost the map generation limit to 32000 while i'm at it |
| 03:44 |
hmmmm |
lol |
| 03:44 |
hmmmm |
people who currently have things "at the edge of the world" are going to be disappointed |
| 03:44 |
VanessaE |
take it all the way to 32680-ish then. |
| 03:44 |
VanessaE |
haha |
| 03:45 |
paramat |
that'll keep em happy |
| 03:45 |
hmmmm |
BUT BUT THERE'S NOT ENOUGH ROOOOOM |
| 03:45 |
est31 |
<VanessaE> take it all the way to 32680-ish then. <<<--------- I wouldn't do that |
| 03:45 |
est31 |
bc we could align heightmaps between edges of the map |
| 03:45 |
VanessaE |
why? worst case the edge of a chunk goes to 32760. |
| 03:45 |
est31 |
future proof ness |
| 03:45 |
EUGD |
i'm glad we're discussing this |
| 03:45 |
est31 |
if you want to add looping |
| 03:45 |
VanessaE |
est31: you mean for that "wraparound" idea? |
| 03:46 |
hmmmm |
huh |
| 03:46 |
EUGD |
what was the reason for the 31000 thing in the first place? |
| 03:46 |
hmmmm |
I'm not following you est |
| 03:46 |
hmmmm |
anyway the biggest I'd feel comfortable with is 32500 |
| 03:46 |
hmmmm |
take it or leave it |
| 03:46 |
VanessaE |
hmmmm: east border smoothly joins with west border, north to south |
| 03:46 |
EUGD |
i thought i'd understood but then realized i never did |
| 03:46 |
hmmmm |
oh |
| 03:46 |
hmmmm |
that's not ever going to happen |
| 03:46 |
hmmmm |
bleh |
| 03:46 |
EUGD |
that is my primary goal |
| 03:46 |
est31 |
why not hmmmm? |
| 03:47 |
hmmmm |
because of the seed |
| 03:47 |
EUGD |
it's why i was implementing the x/y/z mapgen limit split |
| 03:47 |
EUGD |
as a step to looping worlds |
| 03:47 |
VanessaE |
hmmmm: blend it between the edges then? |
| 03:47 |
est31 |
what does the seed have to do with this |
| 03:47 |
VanessaE |
(think biome blend) |
| 03:47 |
hmmmm |
you're never going to be able to seemlessly integrate both edges of the map |
| 03:47 |
VanessaE |
why not? |
| 03:47 |
est31 |
the heightmap is generated with perlin, right? |
| 03:47 |
VanessaE |
if you make sure there's only ever water at the edge? |
| 03:47 |
hmmmm |
est: yes? |
| 03:48 |
hmmmm |
well |
| 03:48 |
VanessaE |
ramp it down to 0 a few dozen meters from the edge |
| 03:48 |
hmmmm |
that's exactly it |
| 03:48 |
hmmmm |
you'd need to include that custom piece of merge logic |
| 03:48 |
est31 |
perlin is basically this thing with the vector grid, right? |
| 03:48 |
hmmmm |
some kind of interpolation ramp |
| 03:48 |
paramat |
loop world would need a new mapgen |
| 03:48 |
est31 |
Z^2 where every point is a vector |
| 03:48 |
hmmmm |
yeah |
| 03:48 |
VanessaE |
paramat: mgv7 territory then |
| 03:48 |
paramat |
no that couldn't do it |
| 03:49 |
VanessaE |
hmmmm: double-declining average |
| 03:49 |
est31 |
so if you are at the limit, why can't you flip over, and take the noise for the flipped over values? |
| 03:49 |
EUGD |
blending could have other benefits |
| 03:49 |
hmmmm |
because that wouldn't line up with the last generated chunk |
| 03:49 |
EUGD |
like infinite world by giving environment multiple maps |
| 03:49 |
hmmmm |
you need to do what vanessae is talking about |
| 03:49 |
hmmmm |
where you have a terrain blending function applied starting at some point or another |
| 03:49 |
hmmmm |
and each mapgen would need to support this |
| 03:50 |
paramat |
2 sets of noises and a gradual blend |
| 03:50 |
VanessaE |
I don't know what the modern term is for it, but it amounts to for each n: n = n/2 + last_n or some such. been years since I used it, but it's fast and simple. |
| 03:50 |
est31 |
why wouldn't that line up with the last generated chunk? |
| 03:50 |
paramat |
i'm not even sure how to do it in 2 dimensions.. |
| 03:50 |
EUGD |
bigger issue is how to make entity transition seamless |
| 03:51 |
EUGD |
treadmill effect |
| 03:51 |
EUGD |
and question of what happens in edge case of very small maps where a block is loaded in two places simultaneously |
| 03:51 |
EUGD |
you basically need portals |
| 03:52 |
EUGD |
OR |
| 03:52 |
EUGD |
trickery of multiple maps (or map instances) sharing entity tracking |
| 03:52 |
EUGD |
near edge |
| 03:53 |
est31 |
you'd just need to get inttoFloat and floatToInt right |
| 03:54 |
EUGD |
you could just run it out forever, maybe, but would eventually hit float precision limit |
| 03:54 |
EUGD |
so you need to move the entities back to other side of map for real |
| 03:54 |
est31 |
how sparse is the grid of perlin points? |
| 03:54 |
est31 |
one per mapchunk? |
| 03:57 |
EUGD |
did i kill the conversation? :'( |
| 03:57 |
EUGD |
sorry if i get too excited about this, this is just my 'thing' for MT |
| 04:00 |
paramat |
irc has a lot of silences, people are busy doing stuff |
| 04:01 |
|
EUGD1 joined #minetest-dev |
| 04:01 |
OldCoder |
Is there a core flag I am supposed to set to disable lava cooling? |
| 04:01 |
OldCoder |
Sokomine implied this and has fallen asleep |
| 04:01 |
est31 |
no its mtgame |
| 04:02 |
paramat |
any looping mapgen would be complex, if it happens at all probably only a specialist mapgen, too much of a nightmare for the main mapgens |
| 04:02 |
EUGD1 |
i don't understand what is complex about the blending |
| 04:03 |
OldCoder |
est31, ty |
| 04:03 |
EUGD1 |
not just graduated averaging of values? i understand it may not be |
| 04:04 |
est31 |
note that if we have looping, it should IMO be entirely optional |
| 04:04 |
hmmmm |
hehe |
| 04:05 |
paramat |
we wouldn't consider looping needed enough to justify the hassle, for most mapgens. i don't like the idea either |
| 04:05 |
hmmmm |
the last ~200 or so nodes should be "farlands" or something |
| 04:05 |
hmmmm |
make some really weird messed up terrain |
| 04:05 |
hmmmm |
there, no need to blend |
| 04:05 |
waressearcher2 |
how about 31337 border ? |
| 04:05 |
hmmmm |
lol. |
| 04:05 |
EUGD |
anyway what about idea of many maps? |
| 04:06 |
paramat |
it removes something interesting: the edge. also in a way it makes the world smaller |
| 04:06 |
EUGD |
rather than partitioning one main map |
| 04:06 |
EUGD |
for VAEs |
| 04:07 |
paramat |
writing a looping lua mapgen would be an interesting challenge though, try that |
| 04:07 |
hmmmm |
erm, that wouldn't work at all... |
| 04:07 |
hmmmm |
I don't get why the approach I first described isn't used |
| 04:07 |
est31 |
farlands? |
| 04:09 |
VanessaE |
paramat: I disagree, I think it would make the world seem larger |
| 04:10 |
VanessaE |
besides, eventually players would realize where the "edge" was, and build structures there, like they do when they find 0,0,0 in a current world. |
| 04:11 |
VanessaE |
in one of my maps, 0,0,0 bears a plaque that reads something like "An origin-al location" or so. |
| 04:11 |
VanessaE |
in another, a small lighted spot in the middle of a crossroads. in another, it's the entrance to a deep mine |
| 04:13 |
VanessaE |
I can imagine things like a sign reading "you are 32 km from nowhere" (like "7 miles from nowhere") at the vertex. |
| 04:13 |
waressearcher2 |
so instead of making looped map you just "teleported", you stepp on 31337 block face north and jump 3 times and that makes you teleport to the other edge 31337 on the other side of the map, if you wat back you have to face south and jump again 10 times |
| 04:14 |
EUGD |
could be cool gameplay of actually finding it, if there are mapgen artifacts of the blending or the particular mapgen uses some cheesed solution like ocean/mountains |
| 04:15 |
EUGD |
waressearcher2 theere are already mods that teleport you when nearing edge |
| 04:18 |
EUGD |
about VAEs; env[entities, lighting] entity[pos, rot, map] map[sectors->blocks->nodes] |
| 04:19 |
VanessaE |
VAE's should be stored in a separate database, just as entities should in general |
| 04:19 |
VanessaE |
mapdir/(map db, entity db, VAE db) |
| 04:20 |
EUGD |
but then you miss cool stuff from map as entity |
| 04:20 |
VanessaE |
how so? |
| 04:20 |
EUGD |
well for example not having any singular main map |
| 04:20 |
VanessaE |
eh |
| 04:20 |
EUGD |
space game |
| 04:21 |
EUGD |
and using entity-map to break mapsize limit |
| 04:21 |
VanessaE |
well who's to say only one map could be stored there? |
| 04:21 |
VanessaE |
there's no logical reason to cram all of this into a single database, really |
| 04:22 |
EUGD |
no |
| 04:22 |
VanessaE |
let the filesystem do its job |
| 04:22 |
est31 |
no |
| 04:22 |
est31 |
you can have many small VAEs |
| 04:22 |
est31 |
and then you can have VAEs that are as large as normal maps |
| 04:23 |
EUGD |
yes exactly |
| 04:23 |
EUGD |
by just not having VAE as any kind of special case |
| 04:23 |
VanessaE |
which lends to the argument that a separate db be used for VAE's. |
| 04:23 |
hmmmm |
lol |
| 04:23 |
EUGD |
VAE is only thing in game |
| 04:23 |
VanessaE |
if one could be as big as an entire map, definitely don't cram it into an existing map db |
| 04:23 |
hmmmm |
by the time you finish arguing about it, i could have a prototype finished already |
| 04:24 |
EUGD |
what overhead is there for DB? i've asked this before |
| 04:24 |
EUGD |
depends on backend i'd guess |
| 04:24 |
est31 |
hmmmm, I dont want to code if there is no consensus |
| 04:24 |
EUGD |
but probably very small maps don't need |
| 04:24 |
est31 |
because there are tons of PRs in the list rotting away due to missing consensus |
| 04:25 |
est31 |
also, still no idea for how to do the lighting thing |
| 04:25 |
VanessaE |
hmmmm: but that begs the question -- what would you code? |
| 04:25 |
VanessaE |
(which idea) |
| 04:25 |
EUGD |
that's why we have chat :-D |
| 04:25 |
hmmmm |
the idea I had written out already in the TODO page |
| 04:25 |
hmmmm |
storage is not really important. i'd probably stick them in a separate table in the same map db and have a tool to extract them into their own files for sharing. |
| 04:26 |
EUGD |
could work |
| 04:26 |
hmmmm |
what is important, though, is everything else |
| 04:26 |
hmmmm |
how would you edit them? |
| 04:26 |
|
asl97 joined #minetest-dev |
| 04:26 |
EUGD |
game issue ideally |
| 04:26 |
hmmmm |
celeron's idea of having a VAE workbench could do the trick |
| 04:27 |
hmmmm |
but that implies they cannot be edited while active |
| 04:27 |
est31 |
yea thats ba |
| 04:27 |
est31 |
d |
| 04:27 |
hmmmm |
if we go with the simpler idea first this can be done fast |
| 04:27 |
EUGD |
my idea too ('great minds'_ |
| 04:27 |
est31 |
it should be like the normal workd |
| 04:27 |
est31 |
world* |
| 04:27 |
hmmmm |
you place nodes on a "workbench" |
| 04:27 |
EUGD |
'active' meaning what? |
| 04:27 |
hmmmm |
then when it's finished, you activate the workbench |
| 04:27 |
hmmmm |
all of the nodes on the workbench that are not air become part of the VAE |
| 04:28 |
VanessaE |
that's how I'd have done it |
| 04:28 |
hmmmm |
i.e. a mesh gets generated for it, and it works just like a regular object |
| 04:28 |
hmmmm |
it would literally be a SAO when "activated" |
| 04:28 |
hmmmm |
when "deactivated", the contents would be blitted to the map at that position |
| 04:28 |
EUGD |
that's not VAE, that's SAO |
| 04:28 |
VanessaE |
blitted? what if it's turned at an angle? |
| 04:28 |
EUGD |
that is literally already a (mc) mod |
| 04:29 |
EUGD |
rotate blocks individually was one idea |
| 04:29 |
EUGD |
hold on |
| 04:29 |
hmmmm |
caveat being that it would need to clip to the nearest 90 degree rotation |
| 04:29 |
hmmmm |
this is really stupid and simple and it's a great start |
| 04:29 |
VanessaE |
clip the rotation of the whole structure? |
| 04:29 |
VanessaE |
good idea. |
| 04:29 |
hmmmm |
if you want to add the ability to edit it while active, you'd /add/ things to the existing implementation, not have to change anything else |
| 04:30 |
hmmmm |
like you'd have to add handlers for interact when the pointed object is determined to be a VAE |
| 04:30 |
hmmmm |
this would need a special handler in fact |
| 04:30 |
EUGD |
http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/requests-ideas-for-mods/1320536-true-voxel-world |
| 04:31 |
EUGD |
see all gets complex |
| 04:31 |
hmmmm |
if it's a SAO, then check if it's a VoxelAreaSAO or something |
| 04:31 |
hmmmm |
then re-route all player interactions to that SAO |
| 04:31 |
EUGD |
much better just make it fundamental |
| 04:31 |
EUGD |
everything is a VAE, full stop |
| 04:31 |
hmmmm |
ehh |
| 04:32 |
EUGD |
same block picking as ever |
| 04:32 |
est31 |
<hmmmm> like you'd have to add handlers for interact when the pointed object is determined to be a VAE <---- just add the realm coordinate for pointed_thing.above and under |
| 04:32 |
hmmmm |
are you really implying that it should be part of the map itself |
| 04:32 |
est31 |
yes |
| 04:32 |
hmmmm |
do you realize how incredibly messy that is due to the map being broken up into mapblocks |
| 04:32 |
est31 |
yes |
| 04:33 |
est31 |
thats where areastore helps |
| 04:33 |
EUGD |
what overhead is there in maps right now? not much or nothing, right? |
| 04:33 |
hmmmm |
look, if you want to mess around with an overly complicated setup go right ahead |
| 04:33 |
hmmmm |
why don't we make competing implementations |
| 04:33 |
hmmmm |
and the most flexible, easiest to use, performant, etc. version wins |
| 04:34 |
EUGD |
split effort not actually good |
| 04:34 |
est31 |
hmmmm, fine with me |
| 04:34 |
EUGD |
not large enough poopulation here for capitalism, we're definitely tribal |
| 04:35 |
VanessaE |
capitalism? |
| 04:35 |
EUGD |
analogy :P |
| 04:36 |
VanessaE |
looking at the TODO, http://dev.minetest.net/TODO#Occlusion_Culling.2FOcclusion_Query should be addressed soon |
| 04:37 |
hmmmm |
lol all these things need to be done soon |
| 04:37 |
EUGD |
what DOES irrlicht support? |
| 04:37 |
hmmmm |
this is why voxel area entities are still a concept 2 years later |
| 04:37 |
EUGD |
yes |
| 04:37 |
hmmmm |
this is a volunteer driven project with not enough /competent/ developers who do this in their spare time |
| 04:37 |
hmmmm |
there are so many more higher priority things |
| 04:38 |
hmmmm |
and some of the design decisions made early on drove us into a wall |
| 04:38 |
EUGD |
there's not even any PR for it at all is there |
| 04:38 |
EUGD |
like what? |
| 04:39 |
EUGD |
hmmmm a list of those would be a wonderful thing |
| 04:39 |
hmmmm |
.. |
| 04:39 |
hmmmm |
I gotta stop talking and start coding |
| 04:39 |
hmmmm |
you should too |
| 04:39 |
EUGD |
not as recrimination but in spirit of comprehending engine structure |
| 04:39 |
est31 |
good idea |
| 04:39 |
est31 |
hmmmm, can you review a commit |
| 04:39 |
hmmmm |
sure |
| 04:39 |
waressearcher2 |
so minetest engine doesn't do any occlusion culling ? but it will be implemented later ? |
| 04:39 |
VanessaE |
good idea, depending on just what you'd be coding.. |
| 04:39 |
est31 |
https://github.com/est31/minetest/commit/90ebe80ec8e16a01747b0ceba8ed00e9d60c58e4 |
| 04:39 |
hmmmm |
waressearcher2, it implements occlusion culling, but it's incredibly broken |
| 04:40 |
waressearcher2 |
hmmmm: if it wasn't broken fps would be higher ? |
| 04:40 |
hmmmm |
yes |
| 04:40 |
hmmmm |
you can do sooo many things to get FPS higher though |
| 04:41 |
hmmmm |
minetest just needs a LOT OF WORK. |
| 04:41 |
waressearcher2 |
that should be a priority |
| 04:41 |
VanessaE |
hmmmm: it just occurred to me - could RBA's video system be doing its own form of occlusion culling, something est31's and my systems don't do? |
| 04:41 |
hmmmm |
est31: dammit est |
| 04:41 |
EUGD |
about that est31 i'll say the same thing i did before |
| 04:41 |
VanessaE |
(hence he gets way higher FPS than est and I) |
| 04:41 |
EUGD |
that last bit is just obvious but worries me because the old version is inherently silly it makes me think i'm missing something |
| 04:41 |
est31 |
hmmmm, ?? |
| 04:42 |
hmmmm |
the leaks |
| 04:42 |
hmmmm |
:( |
| 04:42 |
est31 |
sorry for it |
| 04:42 |
hmmmm |
well at least they only happened during authentication |
| 04:42 |
hmmmm |
0.4.13 went out leaky |
| 04:42 |
hmmmm |
gah |
| 04:42 |
waressearcher2 |
hmmmm: by "broken' you mean it does it "per chunk" not "per entire area" ? |
| 04:42 |
est31 |
I think its only on exotic systems |
| 04:42 |
est31 |
lemme check |
| 04:42 |
hmmmm |
waressearcher2, no the algorithm just doesn't work correctly at all |
| 04:43 |
hmmmm |
it would be much simpler/accurate if we used GL's occlusion query |
| 04:43 |
waressearcher2 |
hmmmm: why not to copy and past from other open source projects ? where it is working |
| 04:43 |
est31 |
yea the leak was only when fopen("/dev/urandom", "r"); fails |
| 04:43 |
est31 |
I consider that as exotic system |
| 04:43 |
est31 |
still, a leak. |
| 04:43 |
hmmmm |
est31: looks good to me, but do you think you should handle malloc() returning NULL in other places? |
| 04:44 |
est31 |
like? |
| 04:44 |
hmmmm |
well how about util/srp.cpp:538 for starters |
| 04:44 |
hmmmm |
you do things half and half |
| 04:44 |
hmmmm |
if you decide you're going to gracefully handle out-of-memory failures, you should do it everywhere throughout your code |
| 04:45 |
est31 |
well, if we are on an exotic system which has no ram, it should be justified to just read some arbitrary memory |
| 04:45 |
est31 |
I've ctrl+f'd the file there should be no other malloc problem |
| 04:46 |
hmmmm |
definitely not an exotic system |
| 04:46 |
hmmmm |
OOM can happen for various reasons unrelated to running out of ram |
| 04:46 |
hmmmm |
like not a large enough address space, if it's running as a 32 bit process on a 64 bit computer, |
| 04:47 |
est31 |
if you have no /dev/urandom I'd consider that as exotic system |
| 04:47 |
hmmmm |
or maybe somebody has a quota set on the minetest process |
| 04:47 |
est31 |
ofc a system with low ram is not exotic |
| 04:47 |
est31 |
thats natural |
| 04:48 |
hmmmm |
also you should be aware that not all modern operating systems disallow allocating memory at address 0x0000000 |
| 04:48 |
hmmmm |
so that code might even have potential for being an exploit |
| 04:49 |
hmmmm |
er, exploited |
| 04:49 |
est31 |
should I call abort() then or do sth similar to really point out "I dont want anymore" |
| 04:50 |
hmmmm |
that's fine |
| 04:53 |
est31 |
so, what should be done about oit |
| 04:53 |
est31 |
it* |
| 04:53 |
hmmmm |
i dunno |
| 04:53 |
hmmmm |
FATAL_ERROR_IF(r == NULL);? |
| 04:54 |
est31 |
I'd like to use c-only utilities, you know I maintain that file as library as well |
| 04:54 |
est31 |
keeping the diff small |
| 04:54 |
hmmmm |
then why not make it util/srp.c? |
| 04:55 |
hmmmm |
anyway |
| 04:55 |
est31 |
I knew the reason, now I forgot |
| 04:55 |
hmmmm |
if you're really making a library, the correct thing to do here is to return a failure |
| 04:55 |
est31 |
ah yes because sha2 is a class |
| 04:55 |
est31 |
sounds good |
| 04:55 |
hmmmm |
let the application using your library decide what to do in the case of an out of memory condition |
| 04:56 |
est31 |
will restructure it |
| 04:56 |
hmmmm |
at least this is what 99.99% of applications do |
| 04:57 |
hmmmm |
also, since you're a library and all, i recommend adding a hook for custom allocator functions |
| 04:57 |
hmmmm |
you should s/malloc/srp_malloc/ and have srp_malloc be a function pointer set to malloc by default, but settable by the application using your library |
| 04:57 |
hmmmm |
same with free and realloc |
| 05:05 |
|
paramat left #minetest-dev |
| 05:10 |
|
Hunterz joined #minetest-dev |
| 05:18 |
|
Puma_rc joined #minetest-dev |
| 05:19 |
|
OldCoder joined #minetest-dev |
| 05:28 |
est31 |
hmmmm, what if I added srp_memory_error ? |
| 05:28 |
hmmmm |
??? |
| 05:28 |
est31 |
as customizeable pointer |
| 05:29 |
hmmmm |
pointer to what |
| 05:29 |
est31 |
function pointer |
| 05:29 |
hmmmm |
oh a callback for a memory error? |
| 05:29 |
est31 |
called if the library encounters malloc to return NULL |
| 05:29 |
hmmmm |
i'm not going to tell you what to do with your own library, but I will say that is kind of tacky |
| 05:30 |
hmmmm |
how on earth will applications be able to handle the failure without setting/checking global variables? |
| 05:30 |
est31 |
hrmm the whole thing needs restructuring... |
| 05:50 |
|
johnnyjoy joined #minetest-dev |
| 05:57 |
est31 |
have abandoned implemented making the callbacks customizeable |
| 05:57 |
est31 |
because it would have needed synchronisation with gmp i think |
| 05:58 |
est31 |
ermm no |
| 06:04 |
|
everamzah joined #minetest-dev |
| 06:44 |
|
est31 joined #minetest-dev |
| 06:49 |
est31 |
hmmmm, PTAL https://github.com/est31/minetest/commit/757475130f8b2c249a67a9240d71a36295db19ef |
| 06:51 |
est31 |
ahmm |
| 06:51 |
est31 |
needs more error checking |
| 06:51 |
est31 |
(on the minetest side) |
| 06:52 |
hmmmm |
hmm I suppose so |
| 06:53 |
hmmmm |
by the way are you setting pointers to 0 instead of NULL on purpose |
| 06:53 |
est31 |
I know NULL exists in cpp, does it exist in c as well? |
| 06:53 |
hmmmm |
absolutely |
| 06:53 |
waressearcher2 |
why don't you use "nullptr" ? |
| 06:54 |
est31 |
hmmmm, do you want to make a PR? |
| 06:54 |
hmmmm |
?? |
| 06:54 |
hmmmm |
why |
| 06:54 |
hmmmm |
for what |
| 06:54 |
est31 |
replacing 0 with NULL |
| 06:54 |
hmmmm |
it's just in your library where it does that |
| 06:55 |
est31 |
yea ik |
| 06:55 |
est31 |
well, shrug |
| 06:55 |
hmmmm |
I guess it's up to you honestly, it's in the spec that the integer representation of NULL must compare equivalent to 0 |
| 06:55 |
hmmmm |
ahh in fact that won't compile under C |
| 06:55 |
hmmmm |
invalid types |
| 06:56 |
hmmmm |
in C++, 0 is a special number that pointer values can freely be set to without any cast |
| 06:56 |
hmmmm |
this is not so with C |
| 06:56 |
est31 |
worksforme |
| 06:56 |
hmmmm |
for this https://github.com/est31/minetest/commit/757475130f8b2c249a67a9240d71a36295db19ef#diff-2f6369328116e9b654242a7597658a48R609 |
| 06:57 |
est31 |
I always compile csrp under c |
| 06:57 |
est31 |
to test it |
| 06:57 |
hmmmm |
maybe a warning *shrug* |
| 06:57 |
hmmmm |
whenever you have this pattern of code where you goto on error to clean up resources, I suggest initializing the result variable to STATUS_ERROR or whatever is the equivalent |
| 06:58 |
hmmmm |
and setting status to STATUS_SUCCESS at the very end, right before the goto label |
| 06:58 |
hmmmm |
this way there's no way you can possibly leave it unset in case of error |
| 06:58 |
est31 |
either that |
| 06:58 |
hmmmm |
fail closed instead of fail open kind of principle |
| 06:58 |
hmmmm |
(this also eliminates the need for having two goto labels) |
| 06:58 |
est31 |
yea little salad I made |
| 06:59 |
est31 |
but salad is healthy |
| 06:59 |
est31 |
xD |
| 06:59 |
hmmmm |
lol |
| 06:59 |
hmmmm |
kinda reminds me of the Apple SSL bug |
| 06:59 |
hmmmm |
they had code exactly like that where it gotoed on error |
| 06:59 |
est31 |
goto fail |
| 07:00 |
hmmmm |
and due to a merge problem it placed two gotos |
| 07:00 |
hmmmm |
so it was like |
| 07:00 |
hmmmm |
if (thing_errored) |
| 07:00 |
hmmmm |
goto failure; |
| 07:00 |
hmmmm |
goto failure; |
| 07:00 |
est31 |
ah thats mean |
| 07:01 |
hmmmm |
if the status was set to STATUS_ERROR instead then the function would always fail instead of always pass, forcing you to realize there's a bug somewhere |
| 07:07 |
est31 |
okay updated the commit https://github.com/est31/minetest/commit/b46f3bfc3a15b5efe86a7866a68efb64ad48b1e9 |
| 07:08 |
|
nrzkt joined #minetest-dev |
| 07:08 |
hmmmm |
https://github.com/est31/minetest/commit/b46f3bfc3a15b5efe86a7866a68efb64ad48b1e9#diff-2f6369328116e9b654242a7597658a48R565 |
| 07:08 |
hmmmm |
what is "32"? |
| 07:08 |
hmmmm |
why "32"? |
| 07:09 |
est31 |
it was a direct conversion from OPENSSL |
| 07:09 |
est31 |
the old call is still commented |
| 07:09 |
hmmmm |
ewww |
| 07:09 |
hmmmm |
in any case it's in bad taste to use another library's prefix for your own function |
| 07:10 |
hmmmm |
https://github.com/est31/minetest/commit/b46f3bfc3a15b5efe86a7866a68efb64ad48b1e9#diff-2f6369328116e9b654242a7597658a48R626 |
| 07:10 |
hmmmm |
same thing here with 16 |
| 07:10 |
est31 |
I think the issue was bits vs bytes |
| 07:10 |
hmmmm |
also sizeof(char) is always going to be 1, that's useless |
| 07:10 |
est31 |
Openssl has bits, gmp has bytes |
| 07:10 |
nrzkt |
est31: oh you find how to reproduce the allocation bug i mentioned yesterday ? |
| 07:10 |
nrzkt |
hi :) |
| 07:11 |
hmmmm |
the two sure signs of a C novice are "if (foo) free(foo);" and "len * sizeof(char)" |
| 07:11 |
est31 |
nrzkt, no idea to reproduce it |
| 07:11 |
hmmmm |
in any case you need to make this library bulletproof since it's being used for auth |
| 07:11 |
nrzkt |
the admin mentionned that a 0.4.12 connects, then another player with 0.4.12 after then boom |
| 07:11 |
hmmmm |
any mistakes here can be fatal for applications who decided to go with est31's implementation of SRP |
| 07:14 |
est31 |
nrzkt, if 0.4.12 connects, srp shouldnt be touched nrzkt |
| 07:14 |
nrzkt |
i know, this is why it's very strange |
| 07:20 |
est31 |
hmmmm, removed them now https://github.com/est31/minetest/commit/0bf1984d2c9fb3a9dc73303551c18906c3c9482b |
| 07:20 |
hmmmm |
ah so you decided to keep the cleanup_and_exit and error_and_exit |
| 07:21 |
hmmmm |
about size_to_fill |
| 07:21 |
hmmmm |
it's obvious (to me, anyway) that you're filling 16 bytes of stuff |
| 07:21 |
hmmmm |
what the name of a constant instead should be is the purpose behind that number |
| 07:22 |
est31 |
I've thought that a variable makes it easier to change the number of bytes if you want |
| 07:22 |
hmmmm |
true |
| 07:23 |
hmmmm |
I mean other than minor stylistic concerns it looks alright to me, but I doubt I am catching everything simply due to unfamiliarity with this code |
| 07:33 |
est31 |
good to merge? |
| 07:33 |
hmmmm |
sure, I guess |
| 07:35 |
|
Krock joined #minetest-dev |
| 07:38 |
|
asl joined #minetest-dev |
| 07:49 |
|
julienrat joined #minetest-dev |
| 07:49 |
|
julienrat left #minetest-dev |
| 08:05 |
OldCoder |
I have done an MTS load and there is no light in the sector. Comments? |
| 08:05 |
OldCoder |
A known bug related to biomes and moretrees is not involved |
| 08:06 |
OldCoder |
Water level was 1; area was mostly aboveground |
| 08:57 |
|
thatgraemeguy joined #minetest-dev |
| 08:57 |
|
julienrat joined #minetest-dev |
| 09:17 |
|
Megaf_ joined #minetest-dev |
| 09:25 |
|
julienrat left #minetest-dev |
| 09:35 |
|
T4im joined #minetest-dev |
| 09:51 |
|
Krock joined #minetest-dev |
| 10:20 |
|
julienrat joined #minetest-dev |
| 10:20 |
|
julienrat left #minetest-dev |
| 10:40 |
|
blaze joined #minetest-dev |
| 10:48 |
|
Calinou joined #minetest-dev |
| 11:00 |
|
proller joined #minetest-dev |
| 11:09 |
|
Fritigern joined #minetest-dev |
| 11:34 |
|
VargaD joined #minetest-dev |
| 11:38 |
|
EUGD joined #minetest-dev |
| 12:12 |
|
rubenwardy joined #minetest-dev |
| 12:42 |
|
Fritigern joined #minetest-dev |
| 12:49 |
|
Darcidride joined #minetest-dev |
| 13:45 |
|
Player_2 joined #minetest-dev |
| 14:03 |
|
eugd joined #minetest-dev |
| 14:12 |
|
ElectronLibre joined #minetest-dev |
| 14:56 |
|
Guest33205 joined #minetest-dev |
| 15:04 |
|
CraigyDavi joined #minetest-dev |
| 15:19 |
|
hmmmm joined #minetest-dev |
| 15:46 |
|
eugd left #minetest-dev |
| 15:48 |
|
eugd joined #minetest-dev |
| 15:51 |
|
eugd left #minetest-dev |
| 15:54 |
|
nrzkt joined #minetest-dev |
| 16:11 |
|
Amaz joined #minetest-dev |
| 16:18 |
|
waressea1cher2 joined #minetest-dev |
| 16:22 |
|
waressea1cher2 left #minetest-dev |
| 16:51 |
|
MinetestForFun joined #minetest-dev |
| 16:58 |
|
eugd joined #minetest-dev |
| 16:59 |
|
eugd left #minetest-dev |
| 17:05 |
|
Robert_Zenz joined #minetest-dev |
| 17:12 |
|
OldCoder joined #minetest-dev |
| 17:15 |
|
zupoman joined #minetest-dev |
| 17:32 |
|
H-H-H joined #minetest-dev |
| 17:54 |
|
proller joined #minetest-dev |
| 18:03 |
|
jin_xi joined #minetest-dev |
| 18:06 |
|
OldCoder joined #minetest-dev |
| 18:13 |
|
Miner_48er joined #minetest-dev |
| 18:52 |
|
proller joined #minetest-dev |
| 18:53 |
|
proller joined #minetest-dev |
| 19:43 |
|
H-H-H joined #minetest-dev |
| 20:20 |
|
technics joined #minetest-dev |
| 21:49 |
|
proller joined #minetest-dev |
| 22:25 |
|
paramat joined #minetest-dev |
| 22:31 |
paramat |
now merging game#688 |
| 22:31 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/688 -- Rename to Minetest Game by paramat |
| 22:32 |
|
Player_2 joined #minetest-dev |
| 22:46 |
paramat |
RBA good to see you on the forum, any progress with #3166 ? |
| 22:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/3166 -- Send to clients only changed node metadata instad of whole mapblock by RealBadAngel |
| 22:54 |
|
paramat left #minetest-dev |
| 23:13 |
|
Siva joined #minetest-dev |
| 23:17 |
VanessaE |
paramat: there has been no announced progress on 3166. and RBA hasn't been in here in almost 2 weeks. His regular internet is down, I'm told. |
| 23:20 |
|
VanessaE joined #minetest-dev |
| 23:34 |
|
pozzoni joined #minetest-dev |
