Time Nick Message 01:38 MTDiscord Why is this a std map? std::map m_blocks_enqueued; This is in EmergeManager - not seeing the value in being ordered - small perf gain 10:51 sfan5 hoping we can get #16289 in for 5.13 to ease future changes 10:51 ShadowBot https://github.com/luanti-org/luanti/issues/16289 -- Add core.get_mapgen_chunksize() by sfan5 10:58 MTDiscord #1 10:58 ShadowBot https://github.com/luanti-org/luanti/issues/1 -- GlowStone code by anonymousAwesome 11:29 sfan5 also do we really not have comparison operators or helper functions for vectors in Lua? 11:36 MTDiscord not in lua vectors aren't even part of lua but we have vector in luanti 11:44 [MatrxMT] #14135 too please, we've been postponing it since 5.10 and it can be very useful for modders.. 11:44 ShadowBot https://github.com/luanti-org/luanti/issues/14135 -- Add persistent unique identifiers for objects by sfence 11:54 MTDiscord yeah I had to make this myself 15:36 [MatrxMT] Hmm, am I missing anything or why is it not feasible to assign entities UIDs by yourself? 15:40 MTDiscord you can, but your limited to engine scope/api. if you wanted to get and modify a non active entity iirc you cant do that 15:40 [MatrxMT] Does this branch enable you to load unloaded entities? 15:41 [MatrxMT] a global entity index, as it were 15:41 MTDiscord its been done as a mod before (no idea if this one is any good, fastest one i could find) https://content.luanti.org/packages/zeuner/mtobjid/ 15:41 MTDiscord no 15:41 [MatrxMT] There you have it then 15:41 MTDiscord i just used the non active entity thing as a an example 15:41 MTDiscord have what? 15:42 [MatrxMT] Mineclonia has a number of makeshift systems for entities that really require UIDs 15:42 [MatrxMT] It's a figure of speech which suggests that someone's point has been communicated 15:42 [MatrxMT] But does this branch actually provide this functionality? 15:43 MTDiscord https://irc.luanti.org/luanti-dev/2025-06-27#i_6268936 15:43 [MatrxMT] Well then I fail to see how this argument is material 15:44 [MatrxMT] as UIDs in their present condition hold no advantages over existing systems 15:45 MTDiscord of which i said in my first response. 15:45 [MatrxMT] and for most objects they would be redundant to begin with, such as sign text, chest visuals, etc. 15:46 MTDiscord im not the pr author, but its useful for two reasons currently, engine provided api so you dont have to reimplement it yourself, depend on some mod, etc. and its a building block potentially for expanded functionality 15:46 MTDiscord *seems usefule 15:47 [MatrxMT] It ought at least to be optional 15:47 MTDiscord ....why? 15:49 MTDiscord (absurd example to make a point) its not like this is the engine assuming all nodes should be red or something. that i would agree should be optional. this is just an api, if you dont want it, dont use it 15:51 [MatrxMT] Why would a completely ephemeral entity, say, an arrow, require a UID? 15:51 [MatrxMT] Occupying more resources in the map database and in memory? 15:52 [MatrxMT] re useless for signs, chest visuals: actually it might be useful, instead of doing get_objects_in_radius every time to find those entities, you could store their GUID in node metadata and get them from the global lookup table 15:52 [MatrxMT] or dropped items, of which there could literally exist several dozens in a single mapblock 15:52 MTDiscord by that logic, why support say (any feature), it just takes up more resources and memory 15:52 [MatrxMT] these entities are not persistent to begin with, I think 15:53 sfan5 if you cannot afford 16 additional bytes per entity I suggest switching to a different engine 15:53 MTDiscord i would agree if it was expensive/wasteful, but from a brief looking at the pr, that doesnt seem to be the case 15:53 [MatrxMT] No, that's a non sequitur 15:53 sfan5 or better yet write your own to work on constrained hardware 15:53 [MatrxMT] Features whose utility is only important in specialized circumstances should be optional 15:54 [MatrxMT] I don't think storage/memory is a concern here, it's just 16 bytes 15:54 [MatrxMT] Arrows, item entities, and non static_save objects generally don't need UUIDs and are the lion's share of objects on a server 15:55 [MatrxMT] It would be more complexity to make it optional, how is that complexity justified? 15:55 [MatrxMT] So why waste this perfectly good storage? Even if it's only 16 bytes per entity 15:55 MTDiscord grorp just ninjad me 15:55 [MatrxMT] It is justified in that it keeps a redundant feature from getting in my hair, and that it isn't very great 15:56 sfan5 wait how exactly does this feature obstruct you? 15:56 MTDiscord it wont be in your hair if you just dont use it lol 15:56 sfan5 actually nevermind I'll stop wasting time and instead construct the new table I bought 15:56 [MatrxMT] It'll probably alter the mapblock format 15:56 [MatrxMT] Consequently I need to update my fork of the old Java mapserver 15:57 MTDiscord sfan5, good point, i also have better things to do 15:57 [MatrxMT] Anyway, why not assign particles UIDs too as Minecraft does 15:58 [MatrxMT] since it's so imperative that everything should be globally and uniquely indexable 16:15 MTDiscord If you are concerned about memory, minecraft is a very bad example lol 16:16 [MatrxMT] That's my point 16:17 MTDiscord Darn, now I have to read 16:19 MTDiscord Okay so we have no access to particle entities in the lua api at all, I do not see why this was brought up 16:20 MTDiscord Secondly, I do not know why you are concerned about this being optional. Is your game bouncing against the 1024mb limit? 16:21 MTDiscord Thirdly, it seems like this is actually a computation improvement at the cost of memory 16:22 [MatrxMT] I simply don't see the necessity in assigning UUIDs to every entity, particularly entities that play much the same part as long-lasting particles 16:22 MTDiscord You might actually see a bigger difference in memory limiting the map generation threads to 1 than you would with this feature and particle entities having a uuid that you can index in a csm 16:23 MTDiscord That is okay, you do not need to see it. There are many components of the engine that I do not see on a daily basis. All you should know is that it is improving runtime performance 16:24 [MatrxMT] How is it improving runtime performance? 16:24 [MatrxMT] What are you on my dear friend 16:25 [MatrxMT] And the default emerge thread setting is 1 16:30 MTDiscord Well first of all, you are being quite rude now. Secondly let's see here, for example https://github.com/luanti-org/luanti/issues/5012 orwell maintains adv trains, adv trains uses entities to the extreme. I actually now see around 50-70 uses for this in crafter, within the translated components alone. So I do appreciate you complaining and whining about this or else I would have never seen this. Thirdly, it is improving runtime 16:30 MTDiscord performance because I can get an entity by it's UUID instead of scanning or holding an object reference to something that might not exist and having to check if it still exists every time. Fourthly, that is fantastic, but that does not mean you are using the stock settings. Fifthly, as grorp said, if you are having an issue with 16 bytes of data then having 1000 entities spawned into the world is using 16kb of data. Do you happen to be running 16:30 MTDiscord windows 98 se? 16:32 [MatrxMT] If you have applications in mind for such a feature, you can enable it for your objects, but it is simply not necessary to enable it by default, if only because most objects do not require identifiers or even remain existent across loads 16:33 [MatrxMT] and if it were actually 16kb my reaction would be far more frantic 16:34 [MatrxMT] on the average mineclonia server, most objects are item entities, followed by mobs 16:34 [MatrxMT] Of the mobs only participants in raids or jockeys require UUIDs, and item entities do not at all 16:36 [MatrxMT] > <@blocknerdgamesmatterbridge:matrix.org> performance because I can get an entity by it's UUID instead of scanning or holding an object reference to something that might not exist and having to check if it still exists every time. Fourthly, that is fantastic, but that does not mean you are using the stock settings. Fifthly, as grorp said, if you are having an issue with 16 bytes of data then having 1000 entitie 16:36 [MatrxMT] If you have applications in mind for such a feature, you can enable it for your objects, but it is simply not necessary to enable it by default, if only because most objects do not require identifiers or even remain in existence across loads 16:37 [MatrxMT] mobs and players, too, may have entities attached such as wielditems, or eyeballs with glow=14 16:37 [MatrxMT] Why would these need UUIDs? 16:37 [MatrxMT] or even to appear in get_objects_in_area? 16:37 MTDiscord Okay so because you think that this should not be enabled by default, we should stop mod developers from having access to this important feature? If you have to opt in that means that you have added in another layer of complexity to what is already a pretty complex system to learn by default 16:37 [MatrxMT] When did I propose this? 16:37 [MatrxMT] I only proposed that the feature be disabled by default 16:38 MTDiscord You just keep talking about it. Don't enable this by default. It's still going to exist in the background. You could just ignore it. I think you're losing more memory with every message that gets sent to your irc client than you will ever notice during runtime with every entity having this feature enabled 16:38 [MatrxMT] Which is not "denying mod developers this important feature" in any sense of the word, nevermind that this feature is already trivial to implement with a pair of on_(de)activate callbacks and a UUID generator 16:38 MTDiscord Well it sure seems like you are 16:39 MTDiscord Basically what I am seeing is: Make this optional or don't add it in. It's not going to be optional 16:39 MTDiscord That is another feature, another layer of complexity, on top of a new feature, that has to be maintained 16:40 [MatrxMT] Don't exaggerate to make a point and then you might actually sound persuasive 16:40 MTDiscord Same to you 16:40 [MatrxMT] I am not exaggerating 16:40 [MatrxMT] It is not very complex, and it is not universally necessary 16:41 [MatrxMT] Therefore it shouldn't be enabled by default 16:41 [MatrxMT] It is equally absurd as assigning particles UUIDs 16:41 [MatrxMT] It is not very complex, but it is not universally necessary 16:43 MTDiscord You know how grorp said this: " re useless for signs, chest visuals: actually it might be useful, instead of doing get_objects_in_radius every time to find those entities, you could store their GUID in node metadata and get them from the global lookup table" 16:43 MTDiscord https://codeberg.org/mineclonia/mineclonia/src/branch/main/mods/ITEMS/mcl_signs/init.lua#L328 I know this because I just rebuilt a predecessor to your mod, it could use this very feature 16:44 [MatrxMT] No it doesn't, since signs are not saved to begin with 16:44 MTDiscord Yes, but, they could be 16:45 [MatrxMT] Why should they? 16:45 [MatrxMT] Sign entities are _temporary_ 16:45 MTDiscord You're using more processing power having them regenerate every time. Every time that chunk gets unloaded you must regenerate a new entity in memory. It could be persistent data 16:46 MTDiscord If you have a lot of signs, you have to regenerate them all. They could be saving their texture modifiers 16:47 [MatrxMT] that's negligible given the number of signs that actually exist at any point in time 16:48 [MatrxMT] But this is a matter of principle: why assign UUIDs to entities that could as easily be particles 16:49 MTDiscord My honest question is: Why hasn't this been added already? Maybe we should be adding this first before we talk about making it optional 16:52 [MatrxMT] Or maybe people should ask why it is necessary to introduce what already exists, and force it upon everyone: https://codeberg.org/mineclonia/mineclonia/src/branch/raid_mechanics_rewrite/mods/ENVIRONMENT/mcl_raids/init.lua#L188 16:53 MTDiscord Ohhhh, you are just angry that you spent the time on it and it feels like a slap in the face that now everyone gets it by default 16:53 MTDiscord I understand now, thank you 16:54 [MatrxMT] No, but that's a very peculiar assessment I've never heard before 16:56 [MatrxMT] It would be infinitely more useful to have a place_schematic available in async environments, or a functioning VoxelManip:update_liquids, but instead the engine receives new facilities that are mostly redundant while existing features, which are never exercised, continue to languish 16:58 [MatrxMT] Simple example: trying to add liquids to the transformation queue in an async environment is impossible, because VMs copied into these environments don't receive their own transformation queues, as those in mapgen environments do 16:59 [MatrxMT] I forgot whether they crash or liquids simply aren't transformed, but that's .5 ms for every column of mapblocks that are processed 17:00 [MatrxMT] or where async environment auto-scaling rapidly inflates memory consumption by creating dozens of threads when a server has been idling for some time and has been swapped 17:00 [MatrxMT] Again, almost as though core.handle_async is never used 17:00 [MatrxMT] or utilized extensively 17:02 [MatrxMT] or where async environment auto-scaling rapidly inflates memory consumption by creating dozens of threads when a server has been idling for some time, has been swapped, and an existing async environment hangs waiting for I/O 17:14 sfan5 ok the table is done, have we reached a conclusion? 17:15 [MatrxMT] Not really 17:16 [MatrxMT] I just stand by my words that it comes off as redundant to enable it by default 17:16 [MatrxMT] almost Minecraft-ish in the undesirable sense of the word 17:16 [MatrxMT] where even particles receive UUIDs 17:17 sfan5 I suspect nobody agreed 17:17 sfan5 agrees* 17:18 [MatrxMT] btw could you answer my heightmap-related question? 17:18 [MatrxMT] is it impossible for Lua mapgens to provide an engine heightmap at the moment? 17:19 [MatrxMT] I am encountering some very peculiar lighting issues that come down to the engine's assuming that nodes above the default singlenode sea level are exposed to sunlight 17:31 sfan5 call it rude if you want but I am not in the mood to answer questions from someone who rants about features I have worked heavily on 17:32 sfan5 I'd rather not have people spit on my work 17:32 lhofhansl Merging #16288 is a few 17:32 ShadowBot https://github.com/luanti-org/luanti/issues/16288 -- Use MapBlock::copyTo to fill MeshMakeData by lhofhansl 17:36 lhofhansl And... Done. 17:38 lhofhansl By the way I closed #16152 for now. I cannot possibly prove that we have no multi-threading bugs in accessing MapBlocks. 17:38 ShadowBot https://github.com/luanti-org/luanti/issues/16152 -- Monoblocks: optimize blocks that contain a single type of node by lhofhansl 17:42 sfan5 manual code review works :) 17:42 sfan5 we might want to revisit that PR later 17:44 lhofhansl Maybe I'll leave it open, can always close later. :) 17:46 lhofhansl The only use of MapBlock::getData is now in test code, I intent to change the test code and then remove MapBlock::getData altogether (it's a bad abstraction leak IMHO). Any concerns? 17:48 lhofhansl Hmm... I force pushed into the mono-block branch before I re-opened, now it seems I can't reopen the PR. :( 17:51 lhofhansl I'll open a new one. 21:27 MTDiscord I'll jump in on the UUID discussion: 1. Same memory usage either way, arguably more if you push that work to Lua. 2. Fair on the whole temporary entity thing, but if they're that temporary, we should just make particles better, then all entities are ones that need unique IDs. 3. Fair on the other features stuff, but as with all things open source, progress happens in lots of random places, and often core issues never are fixed, or 21:27 MTDiscord long in coming. 4. Most importantly: good APIs built-in are always great. They help reduce the problem of that XKCD and the competing standards thing. 22:44 MTDiscord should particles be pointable? (also do particles have mesh and node drawtypes or drawtypes at all I can't really look at the docs right now) 22:48 cheapie AFAIK particles are just always sprites like in pretty much any other game, for the most part they're best for things like smoke effects 22:55 MTDiscord It would be kinda cool if we could do little cube sprites like vintage story to layer in effects 22:56 MTDiscord No rush though, it's just an idea 23:02 cheapie Do you have a picture/video of that effect? I'm curious now but I'm not familiar with that game(?) and searching isn't helping much with the effect 23:48 MTDiscord1 Oh sorry cheapie, I got distracted by my horrific code, one second 23:50 MTDiscord cheapie: https://youtu.be/tkq0tIX22WY&t=138 23:53 MTDiscord Okay so that's a really old version, but it shows you the effect completely by itself 23:54 cheapie I see... yeah, I'm not aware of any way to do that in Luanti (short of spawning a ton of entities) but you could probably do a mediocre approximation with the particle system 23:56 MTDiscord Okay you ready? So this is the blended mixture of particles: https://youtu.be/qV4ZLkug1n4&t=387 23:57 MTDiscord This is what I was referring to. You can give it some interesting texture