Time Nick Message 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 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! 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 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 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: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 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: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:06 ireallyhateirc this bug boosts reproducibility :) 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 math.randomseed possibly only uses something like the lowest 32 bits 23:40 MTDiscord 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 yep hash_node_position encodes as zyx, 16 bits each 23:41 MTDiscord 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 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 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 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 ireallyhateirc: are you sure that you're checking the 5.1 reference manual? 23:45 ireallyhateirc checking right now 23:45 MTDiscord the lua RNG was changed to xoshiro in a newer version (5.3 or 5.4 iirc) 23:45 MTDiscord and that needs more seed i think 23:45 MTDiscord 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 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 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 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 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 note that you should not use pseudorandom. 23:51 MTDiscord 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 BluebirdGrey51: Interesting, by how much? In my benchmarking the opposite was the case. 23:52 MTDiscord 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 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 this might be hardware-dependent but could you try benchmarking the random individually? 23:53 MTDiscord 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 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 it is a pretty basic benchmark, not very fancy 23:59 MTDiscord what might make it a bit harder to read is that i generate lua code via string format but that's about it