| Time |
Nick |
Message |
| 00:17 |
|
boingman joined #minetest |
| 00:33 |
|
Noisytoot joined #minetest |
| 00:34 |
|
ShadowBot joined #minetest |
| 00:43 |
|
Noisytoot joined #minetest |
| 01:03 |
|
Izaya left #minetest |
| 01:03 |
|
Izaya joined #minetest |
| 01:34 |
|
Noisytoot joined #minetest |
| 01:44 |
|
Noisytoot joined #minetest |
| 02:48 |
|
Izaya left #minetest |
| 02:50 |
|
Izaya joined #minetest |
| 03:00 |
|
behalebabo joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:23 |
|
Izaya left #minetest |
| 04:24 |
|
fluxionary joined #minetest |
| 04:27 |
|
liceDibrarian joined #minetest |
| 04:34 |
|
Izaya joined #minetest |
| 05:03 |
|
liceDibrarian joined #minetest |
| 05:32 |
|
gregon joined #minetest |
| 05:32 |
|
TomTom joined #minetest |
| 05:42 |
|
YuGiOhJCJ joined #minetest |
| 06:46 |
|
jaxon-dozier joined #minetest |
| 07:10 |
|
jaca122 joined #minetest |
| 07:47 |
|
jaxon-dozier joined #minetest |
| 07:49 |
|
Hanicef joined #minetest |
| 07:51 |
|
gregon joined #minetest |
| 08:08 |
|
mrkubax10 joined #minetest |
| 08:09 |
|
jaxon-dozier joined #minetest |
| 08:10 |
|
Noisytoot joined #minetest |
| 08:27 |
|
Yenoxel joined #minetest |
| 08:36 |
|
frostsnow joined #minetest |
| 08:37 |
|
SliverFlowCipher joined #minetest |
| 08:44 |
|
Noisytoot joined #minetest |
| 08:47 |
|
Loveaabb joined #minetest |
| 09:08 |
|
mrkubax10 joined #minetest |
| 10:29 |
|
gregon joined #minetest |
| 10:30 |
|
ireallyhateirc joined #minetest |
| 11:16 |
Hanicef |
how do you set a name on a label in formspec, so it can be styled independently of other labels? |
| 11:16 |
Hanicef |
i already tried setting it to the text, but no luck |
| 11:18 |
MTDiscord |
<rollerozxa> formspec styling is applied in the order they come, so you can set a style_type for labels, put the label you want to style and then reset the styling |
| 11:18 |
Hanicef |
ah, thanks, rollerozra! |
| 11:37 |
|
Furi0us_mat joined #minetest |
| 11:47 |
|
gregon joined #minetest |
| 13:05 |
|
Nusakan joined #minetest |
| 13:41 |
|
peterz joined #minetest |
| 14:08 |
|
jaca122 joined #minetest |
| 14:13 |
|
peterz joined #minetest |
| 14:18 |
|
peterz joined #minetest |
| 14:20 |
|
silverwolf73828 joined #minetest |
| 14:43 |
|
Road_Killer joined #minetest |
| 14:43 |
|
ireallyhateirc joined #minetest |
| 16:01 |
|
Nusakan joined #minetest |
| 16:04 |
|
peterz joined #minetest |
| 16:11 |
|
peterz joined #minetest |
| 17:01 |
|
mrkubax10 joined #minetest |
| 17:25 |
|
book` joined #minetest |
| 17:44 |
|
gregon joined #minetest |
| 18:00 |
|
bodiccea joined #minetest |
| 18:10 |
|
gregon joined #minetest |
| 18:26 |
|
mrkubax10 joined #minetest |
| 18:45 |
|
Nusakan joined #minetest |
| 19:10 |
|
Lunatrius joined #minetest |
| 19:49 |
|
germ joined #minetest |
| 19:58 |
|
liceDibrarian joined #minetest |
| 19:59 |
|
diceLibrarian2 joined #minetest |
| 20:19 |
|
ireallyhateirc joined #minetest |
| 20:20 |
|
diceLibrarian2 joined #minetest |
| 20:22 |
Mantar |
question: I'm trying to attach a particlespawner to an invisible entity. If I set the entity to visible=false, the particlespawner doesn't seem to attach and fall with the entity, it just hangs there in space |
| 20:22 |
Mantar |
If I set visible=true, I can watch the entity fall to the ground, but now no particles appear at all. 🤔 |
| 20:23 |
Mantar |
can anybody think of a mod or something that does this, so I could see how they got it to work? |
| 20:37 |
MTDiscord |
<warr1024> Entities that are visible=false are not added to the scene at all, and thus things cannot be attached to them. The only workaround I know for that is to use an empty model or transparent texture or something. |
| 20:38 |
MTDiscord |
<warr1024> In my experience I also don't rely on it being possible to attach anything to an entity as soon as it's created. I generally create an entity in one step and then attach things to it in later steps. Of course, I've had a LOT of issues with entity attachments (particlespawners I presume use a similar system) so I'm a bit paranoid. |
| 20:42 |
Mantar |
ah, so maybe attaching too soon is causing the attachment to fail somehow and the particlespawner just doesn't appear |
| 20:45 |
|
bodiccea joined #minetest |
| 20:56 |
Mantar |
got it -- forgot to alter pos when it attached, since the pos becomes relative instead of absolute,oops ¯\_(ツ)_/¯ |
| 20:57 |
Mantar |
figured it out by increasing the particle size and spread to colossal, and then spotted them coming out of the sky off to one side |
| 20:57 |
* Mantar |
facepalms |
| 21:06 |
|
Guest87 joined #minetest |
| 21:17 |
|
SpaceManiac joined #minetest |
| 21:27 |
|
SpaceManiac joined #minetest |
| 21:42 |
|
down200 joined #minetest |
| 21:56 |
|
down200 joined #minetest |
| 22:10 |
|
jaca122 joined #minetest |
| 22:17 |
* cheapie |
joins some random creative server that popped up recently, is greeted by unified inventory with 253 pages and a few roads with intersections that each have about 10 traffic lights all showing different things, then is attacked by a random mob (despite damage being off), then the server crashed |
| 22:17 |
Mantar |
lol |
| 22:35 |
|
panwolfram joined #minetest |
| 22:40 |
|
BluebirdGrey51 joined #minetest |
| 22:42 |
BluebirdGrey51 |
About mapgens: I've just discovered that in the async mapgen environment, the blockseed is the same for all chunks. In the "main thread" environment, the blockseed is different for every chunk (the expected behavior). I didn't test to see if this occurs in unmodified minetest_game, but I doubt there's any way my custom game environment could have |
| 22:42 |
BluebirdGrey51 |
screwed this up. Can someone confirm this? |
| 22:43 |
ireallyhateirc |
could make a test now, but I do my own seed |
| 22:43 |
BluebirdGrey51 |
What led to this discovery: I was using PseudoRandom to randomize tree placement per-chunk. I noticed that the trees were in the EXACT same locations in every chunk. Then I printed out the blockseed on the console. Result: same blockseed printed for every mapchunk. |
| 22:46 |
ireallyhateirc |
I generate mapchunk hash this way: https://codeberg.org/lord_of_the_dumpster/perfect_city/src/commit/be61144a71bfda41a488a7e217105d66c5f06ed4/mods/pcity_mapgen/utils.lua#L85 |
| 22:47 |
ireallyhateirc |
So basically take pos_min of the mapchunk, run minetest.hash_node_position |
| 22:47 |
ireallyhateirc |
math.randomseed(hash, mapgen_seed) |
| 22:48 |
ireallyhateirc |
hash is the hash produced above, mapgen_seed is simply the world seed |
| 22:49 |
ireallyhateirc |
BluebirdGrey51, can confirm blockseed is the same for each chunk in mapgen env |
| 22:50 |
BluebirdGrey51 |
thanks |
| 22:59 |
BluebirdGrey51 |
Reported: https://github.com/minetest/minetest/issues/14868 |
| 23:05 |
|
Eragon joined #minetest |
| 23:06 |
ireallyhateirc |
this bug boosts reproducibility :) |
| 23:37 |
|
BluebirdGrey51 joined #minetest |
| 23:38 |
BluebirdGrey51 |
I'm jumping in again to say that using minetest.hash_node_position() to generate blockseeds from chunk coords produces insufficiently random results. Examples follow: |
| 23:38 |
BluebirdGrey51 |
pos: (26048,23168,5008), blockseed: 1.6225035045421e+14, rnd: 23544 |
| 23:39 |
BluebirdGrey51 |
pos: (26048,23168,5088), blockseed: 1.6259394783789e+14, rnd: 23544 |
| 23:39 |
BluebirdGrey51 |
pos: (26048,23168,5168), blockseed: 1.6293754522157e+14, rnd: 23544 |
| 23:39 |
BluebirdGrey51 |
pos: (26048,23168,5248), blockseed: 1.6328114260525e+14, rnd: 23544 |
| 23:39 |
BluebirdGrey51 |
All 4 produce the same output sequence (the final number) |
| 23:39 |
ireallyhateirc |
I first turn node position to mapchunk coordinates |
| 23:40 |
BluebirdGrey51 |
here `blockseed` is the value from minetest.hash_node_position() |
| 23:40 |
MTDiscord |
<luatic> math.randomseed possibly only uses something like the lowest 32 bits |
| 23:40 |
MTDiscord |
<luatic> and minetest.hash_node_position encodes as a 3*16 = 48 bit number |
| 23:40 |
ireallyhateirc |
The code from my repo provices distinct enough results |
| 23:41 |
MTDiscord |
<luatic> yep hash_node_position encodes as zyx, 16 bits each |
| 23:41 |
MTDiscord |
<luatic> so the lowest 32 bits will be yx only |
| 23:41 |
BluebirdGrey51 |
Are you sure? From what I see here, mapchunks on the same Z-axis will produce the same results (a change of X or Y axis produces a different random sequence) |
| 23:41 |
ireallyhateirc |
luatic, btw my vector utils PR is ready for review, don't plan doing more work on that, seems ready enough |
| 23:42 |
MTDiscord |
<luatic> and your block positions differ in z only |
| 23:42 |
ireallyhateirc |
BluebirdGrey51, I generate a road system from that and each chunk is different |
| 23:42 |
MTDiscord |
<luatic> ireallyhateirc: thanks for letting me know. i'm afraid it'll have to wait till 5.10.0 due to the feature freeze however. |
| 23:42 |
BluebirdGrey51 |
ireallyhateirc, IDK what to make of that, then |
| 23:43 |
BluebirdGrey51 |
Note: I was using the value from minetest.hash_node_position() as the param for PsueoRandom, which according to docs accepts a 64bit number |
| 23:44 |
MTDiscord |
<luatic> by the way ireallyhateirc: math.randomseed only takes a single argument |
| 23:44 |
BluebirdGrey51 |
Oops I am wrong |
| 23:44 |
ireallyhateirc |
it takes two actuallyu |
| 23:44 |
BluebirdGrey51 |
PseudoRandom only accepts a 32bit number |
| 23:45 |
MTDiscord |
<luatic> ireallyhateirc: are you sure that you're checking the 5.1 reference manual? |
| 23:45 |
ireallyhateirc |
checking right now |
| 23:45 |
MTDiscord |
<luatic> the lua RNG was changed to xoshiro in a newer version (5.3 or 5.4 iirc) |
| 23:45 |
MTDiscord |
<luatic> and that needs more seed i think |
| 23:45 |
MTDiscord |
<luatic> but 5.1 is just using C stdlib APIs |
| 23:45 |
ireallyhateirc |
oh right, I trolled myself again |
| 23:46 |
BluebirdGrey51 |
I just read this (I am slow) "yep hash_node_position encodes as zyx, 16 bits each", OK, that explains why I see my results |
| 23:46 |
ireallyhateirc |
well, this explains why the second one wasn't doing anything lol |
| 23:47 |
MTDiscord |
<luatic> btw the implementation of math.randomseed in PUC Lua casts the number to a 32-bit signed integer. so only the lowest 32 bits of whatever you pass to it will make a difference. |
| 23:47 |
BluebirdGrey51 |
But wait ... I did an earlier test, moduo'ing minetest.hash_node_position()'s result by 2147483648, e.g., return minetest.hash_node_position(pos) % 2147483648. And I still saw the same results |
| 23:48 |
MTDiscord |
<luatic> PUC Lua 5.1, to be precise, which is what MT uses |
| 23:48 |
BluebirdGrey51 |
So I guess the modulo kills the effect of the Z-axis? |
| 23:48 |
MTDiscord |
<luatic> yes |
| 23:50 |
BluebirdGrey51 |
I hope this can get fixed kinda soonish, https://github.com/minetest/minetest/issues/14868 I was hoping I could use the position hash as a crutch, but it seems I am in for some pain if I want to figure out how to do it right |
| 23:50 |
ireallyhateirc |
it's really easy |
| 23:50 |
MTDiscord |
<luatic> 2147483648 is just 2^31. that could make a difference for extreme y axis values. in this case you were only getting rid of the z axis - which math.randomseed or seeding pseudorandom would've gone rid of anyways, since they cast to int. |
| 23:50 |
MTDiscord |
<luatic> note that you should not use pseudorandom. |
| 23:51 |
MTDiscord |
<luatic> use pcgrandom instead. it also allows a 64-bit seed. |
| 23:51 |
BluebirdGrey51 |
Can do for some cases but not all. PcgRandom is definitely slower. |
| 23:51 |
ireallyhateirc |
why are you using RcgRandom? any advantage of using that over math.random? |
| 23:51 |
MTDiscord |
<luatic> BluebirdGrey51: Interesting, by how much? In my benchmarking the opposite was the case. |
| 23:52 |
MTDiscord |
<luatic> ireallyhateirc: You don't need to reseed anything after you're done; it's safer |
| 23:52 |
BluebirdGrey51 |
I didn't measure, but doing PcgRandom for 80*80*80 mapchunk was noticably slower that PseudoRandom |
| 23:52 |
MTDiscord |
<luatic> math.random is much faster though. |
| 23:52 |
BluebirdGrey51 |
By "noticeably slower" I mean the difference was really obvious: full seconds. |
| 23:52 |
ireallyhateirc |
I just remember to reseed and that's it |
| 23:52 |
MTDiscord |
<luatic> this might be hardware-dependent but could you try benchmarking the random individually? |
| 23:53 |
MTDiscord |
<luatic> ireallyhateirc: yeah, if you want perf you should use math.random and reseed. |
| 23:53 |
BluebirdGrey51 |
Not sure how to do that correctly? I've never bothered to learn proper benchmarking |
| 23:53 |
ireallyhateirc |
BluebirdGrey51, as for the mapchunk hash, you use the hash of hash pos_min, right? |
| 23:53 |
ireallyhateirc |
pos_min of the mapchunk that is |
| 23:53 |
BluebirdGrey51 |
yes, I used chunk minp |
| 23:53 |
ireallyhateirc |
and it doesn't work? |
| 23:53 |
BluebirdGrey51 |
It did not |
| 23:54 |
ireallyhateirc |
okay, weird. Thoug I don't use bare pos_min |
| 23:54 |
BluebirdGrey51 |
chunks where minp only differed on the Z-axis produced the same RNG sequence |
| 23:54 |
ireallyhateirc |
I calculate "mapchunk coordinates" first |
| 23:54 |
ireallyhateirc |
the chunk that starts at xyz: -32 is the 0,0,0 chunk |
| 23:54 |
ireallyhateirc |
read this function: https://codeberg.org/lord_of_the_dumpster/perfect_city/src/commit/be61144a71bfda41a488a7e217105d66c5f06ed4/mods/pcity_mapgen/utils.lua#L184 |
| 23:55 |
ireallyhateirc |
Or better: this: https://codeberg.org/lord_of_the_dumpster/perfect_city/src/commit/be61144a71bfda41a488a7e217105d66c5f06ed4/mods/pcity_mapgen/utils.lua#L42 |
| 23:55 |
MTDiscord |
<luatic> BluebirdGrey51: Here's my benchmarking code: https://gist.github.com/appgurueu/0fcbe99941064b639c014c2d43318730 |
| 23:55 |
ireallyhateirc |
Mapchunk coords are what I put into minetest.hash_node_position |
| 23:56 |
ireallyhateirc |
and it produces different outcomes |
| 23:56 |
BluebirdGrey51 |
I would guess you're seeding PRNG that accepts 48-bit values |
| 23:57 |
BluebirdGrey51 |
I did PsuedoRandom which only does 32bit, so it makes sense to me, that Z-axis is getting dropped |
| 23:57 |
ireallyhateirc |
you can use the bit operators to scramble it for your needs I guess? |
| 23:57 |
BluebirdGrey51 |
luatic: thanks, but I'm not sure I really understand the benchmark code? |
| 23:57 |
BluebirdGrey51 |
I would need to look at it for aqhile |
| 23:57 |
BluebirdGrey51 |
*awhile |
| 23:59 |
MTDiscord |
<luatic> it is a pretty basic benchmark, not very fancy |
| 23:59 |
MTDiscord |
<luatic> what might make it a bit harder to read is that i generate lua code via string format but that's about it |
