| Time |
Nick |
Message |
| 00:10 |
|
fluxionary joined #luanti-dev |
| 00:35 |
|
YuGiOhJCJ joined #luanti-dev |
| 01:38 |
MTDiscord |
<exe_virus> Why is this a std map? std::map<v3s16, BlockEmergeData> m_blocks_enqueued; This is in EmergeManager - not seeing the value in being ordered - small perf gain |
| 02:14 |
|
fluxionary joined #luanti-dev |
| 02:25 |
|
repetitivestrain joined #luanti-dev |
| 03:15 |
|
v-rob joined #luanti-dev |
| 03:24 |
|
alias joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 06:14 |
|
fluxionary joined #luanti-dev |
| 07:14 |
|
SFENCE_arch joined #luanti-dev |
| 09:48 |
|
TenPlus1 joined #luanti-dev |
| 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 |
<the4spaceconstants2181> #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 |
<the4spaceconstants2181> not in lua vectors aren't even part of lua but we have vector in luanti |
| 11:44 |
[MatrxMT] |
<Zughy> #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 |
<the4spaceconstants2181> yeah I had to make this myself |
| 13:12 |
|
SFENCE_arch joined #luanti-dev |
| 14:06 |
|
SFENCE joined #luanti-dev |
| 14:38 |
|
SFENCE joined #luanti-dev |
| 14:41 |
|
SFENCE joined #luanti-dev |
| 14:45 |
|
SFENCE joined #luanti-dev |
| 14:57 |
|
v-rob joined #luanti-dev |
| 14:57 |
|
SFENCE joined #luanti-dev |
| 15:07 |
|
SFENCE joined #luanti-dev |
| 15:15 |
|
SFENCE joined #luanti-dev |
| 15:19 |
|
tibtoblezob joined #luanti-dev |
| 15:34 |
|
SFENCE joined #luanti-dev |
| 15:36 |
[MatrxMT] |
<repetitivestrain> Hmm, am I missing anything or why is it not feasible to assign entities UIDs by yourself? |
| 15:40 |
MTDiscord |
<wsor4035> 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] |
<repetitivestrain> Does this branch enable you to load unloaded entities? |
| 15:41 |
[MatrxMT] |
<repetitivestrain> a global entity index, as it were |
| 15:41 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> no |
| 15:41 |
[MatrxMT] |
<repetitivestrain> There you have it then |
| 15:41 |
MTDiscord |
<wsor4035> i just used the non active entity thing as a an example |
| 15:41 |
MTDiscord |
<wsor4035> have what? |
| 15:42 |
[MatrxMT] |
<repetitivestrain> Mineclonia has a number of makeshift systems for entities that really require UIDs |
| 15:42 |
[MatrxMT] |
<repetitivestrain> It's a figure of speech which suggests that someone's point has been communicated |
| 15:42 |
[MatrxMT] |
<repetitivestrain> But does this branch actually provide this functionality? |
| 15:43 |
MTDiscord |
<wsor4035> https://irc.luanti.org/luanti-dev/2025-06-27#i_6268936 |
| 15:43 |
[MatrxMT] |
<repetitivestrain> Well then I fail to see how this argument is material |
| 15:44 |
[MatrxMT] |
<repetitivestrain> as UIDs in their present condition hold no advantages over existing systems |
| 15:45 |
MTDiscord |
<wsor4035> of which i said in my first response. |
| 15:45 |
[MatrxMT] |
<repetitivestrain> and for most objects they would be redundant to begin with, such as sign text, chest visuals, etc. |
| 15:46 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> *seems usefule |
| 15:47 |
[MatrxMT] |
<repetitivestrain> It ought at least to be optional |
| 15:47 |
MTDiscord |
<wsor4035> ....why? |
| 15:49 |
MTDiscord |
<wsor4035> (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] |
<repetitivestrain> Why would a completely ephemeral entity, say, an arrow, require a UID? |
| 15:51 |
[MatrxMT] |
<repetitivestrain> Occupying more resources in the map database and in memory? |
| 15:52 |
[MatrxMT] |
<grorp> 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] |
<repetitivestrain> or dropped items, of which there could literally exist several dozens in a single mapblock |
| 15:52 |
MTDiscord |
<wsor4035> by that logic, why support say (any feature), it just takes up more resources and memory |
| 15:52 |
[MatrxMT] |
<repetitivestrain> 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 |
<wsor4035> 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] |
<repetitivestrain> No, that's a non sequitur |
| 15:53 |
sfan5 |
or better yet write your own to work on constrained hardware |
| 15:53 |
[MatrxMT] |
<repetitivestrain> Features whose utility is only important in specialized circumstances should be optional |
| 15:54 |
[MatrxMT] |
<grorp> I don't think storage/memory is a concern here, it's just 16 bytes |
| 15:54 |
[MatrxMT] |
<repetitivestrain> 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] |
<grorp> It would be more complexity to make it optional, how is that complexity justified? |
| 15:55 |
[MatrxMT] |
<repetitivestrain> So why waste this perfectly good storage? Even if it's only 16 bytes per entity |
| 15:55 |
MTDiscord |
<wsor4035> grorp just ninjad me |
| 15:55 |
[MatrxMT] |
<repetitivestrain> 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 |
<wsor4035> 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] |
<repetitivestrain> It'll probably alter the mapblock format |
| 15:56 |
[MatrxMT] |
<repetitivestrain> Consequently I need to update my fork of the old Java mapserver |
| 15:57 |
MTDiscord |
<wsor4035> sfan5, good point, i also have better things to do |
| 15:57 |
[MatrxMT] |
<repetitivestrain> Anyway, why not assign particles UIDs too as Minecraft does |
| 15:58 |
[MatrxMT] |
<repetitivestrain> since it's so imperative that everything should be globally and uniquely indexable |
| 16:00 |
|
SFENCE joined #luanti-dev |
| 16:11 |
|
SFENCE joined #luanti-dev |
| 16:15 |
MTDiscord |
<jordan4ibanez> If you are concerned about memory, minecraft is a very bad example lol |
| 16:16 |
[MatrxMT] |
<repetitivestrain> That's my point |
| 16:17 |
MTDiscord |
<jordan4ibanez> Darn, now I have to read |
| 16:19 |
MTDiscord |
<jordan4ibanez> 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 |
<jordan4ibanez> Secondly, I do not know why you are concerned about this being optional. Is your game bouncing against the 1024mb limit? |
| 16:21 |
MTDiscord |
<jordan4ibanez> Thirdly, it seems like this is actually a computation improvement at the cost of memory |
| 16:22 |
[MatrxMT] |
<repetitivestrain> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> 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] |
<repetitivestrain> How is it improving runtime performance? |
| 16:24 |
[MatrxMT] |
<repetitivestrain> What are you on my dear friend |
| 16:25 |
[MatrxMT] |
<repetitivestrain> And the default emerge thread setting is 1 |
| 16:30 |
MTDiscord |
<jordan4ibanez> 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] |
<repetitivestrain> 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] |
<repetitivestrain> and if it were actually 16kb my reaction would be far more frantic |
| 16:34 |
[MatrxMT] |
<repetitivestrain> on the average mineclonia server, most objects are item entities, followed by mobs |
| 16:34 |
[MatrxMT] |
<repetitivestrain> Of the mobs only participants in raids or jockeys require UUIDs, and item entities do not at all |
| 16:36 |
[MatrxMT] |
<repetitivestrain> > <@blocknerdgamesmatterbridge:matrix.org> <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 entitie |
| 16:36 |
[MatrxMT] |
<repetitivestrain> 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] |
<repetitivestrain> mobs and players, too, may have entities attached such as wielditems, or eyeballs with glow=14 |
| 16:37 |
[MatrxMT] |
<repetitivestrain> Why would these need UUIDs? |
| 16:37 |
[MatrxMT] |
<repetitivestrain> or even to appear in get_objects_in_area? |
| 16:37 |
MTDiscord |
<jordan4ibanez> 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] |
<repetitivestrain> When did I propose this? |
| 16:37 |
[MatrxMT] |
<repetitivestrain> I only proposed that the feature be disabled by default |
| 16:38 |
MTDiscord |
<jordan4ibanez> 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] |
<repetitivestrain> 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 |
<jordan4ibanez> Well it sure seems like you are |
| 16:39 |
MTDiscord |
<jordan4ibanez> 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 |
<jordan4ibanez> That is another feature, another layer of complexity, on top of a new feature, that has to be maintained |
| 16:40 |
[MatrxMT] |
<repetitivestrain> Don't exaggerate to make a point and then you might actually sound persuasive |
| 16:40 |
MTDiscord |
<jordan4ibanez> Same to you |
| 16:40 |
[MatrxMT] |
<repetitivestrain> I am not exaggerating |
| 16:40 |
[MatrxMT] |
<repetitivestrain> It is not very complex, and it is not universally necessary |
| 16:41 |
[MatrxMT] |
<repetitivestrain> Therefore it shouldn't be enabled by default |
| 16:41 |
[MatrxMT] |
<repetitivestrain> It is equally absurd as assigning particles UUIDs |
| 16:41 |
[MatrxMT] |
<repetitivestrain> It is not very complex, but it is not universally necessary |
| 16:43 |
MTDiscord |
<jordan4ibanez> You know how grorp said this: "<grorp> 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 |
<jordan4ibanez> 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] |
<repetitivestrain> No it doesn't, since signs are not saved to begin with |
| 16:44 |
MTDiscord |
<jordan4ibanez> Yes, but, they could be |
| 16:45 |
[MatrxMT] |
<repetitivestrain> Why should they? |
| 16:45 |
[MatrxMT] |
<repetitivestrain> Sign entities are _temporary_ |
| 16:45 |
MTDiscord |
<jordan4ibanez> 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 |
<jordan4ibanez> If you have a lot of signs, you have to regenerate them all. They could be saving their texture modifiers |
| 16:47 |
[MatrxMT] |
<repetitivestrain> that's negligible given the number of signs that actually exist at any point in time |
| 16:48 |
[MatrxMT] |
<repetitivestrain> But this is a matter of principle: why assign UUIDs to entities that could as easily be particles |
| 16:49 |
MTDiscord |
<jordan4ibanez> 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] |
<repetitivestrain> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> I understand now, thank you |
| 16:54 |
[MatrxMT] |
<repetitivestrain> No, but that's a very peculiar assessment I've never heard before |
| 16:56 |
[MatrxMT] |
<repetitivestrain> 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] |
<repetitivestrain> 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] |
<repetitivestrain> 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] |
<repetitivestrain> 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] |
<repetitivestrain> Again, almost as though core.handle_async is never used |
| 17:00 |
[MatrxMT] |
<repetitivestrain> or utilized extensively |
| 17:02 |
[MatrxMT] |
<repetitivestrain> 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:07 |
|
fluxionary joined #luanti-dev |
| 17:14 |
sfan5 |
ok the table is done, have we reached a conclusion? |
| 17:15 |
[MatrxMT] |
<repetitivestrain> Not really |
| 17:16 |
[MatrxMT] |
<repetitivestrain> I just stand by my words that it comes off as redundant to enable it by default |
| 17:16 |
[MatrxMT] |
<repetitivestrain> almost Minecraft-ish in the undesirable sense of the word |
| 17:16 |
[MatrxMT] |
<repetitivestrain> where even particles receive UUIDs |
| 17:17 |
sfan5 |
I suspect nobody agreed |
| 17:17 |
sfan5 |
agrees* |
| 17:18 |
[MatrxMT] |
<repetitivestrain> btw could you answer my heightmap-related question? |
| 17:18 |
|
lhofhansl joined #luanti-dev |
| 17:18 |
[MatrxMT] |
<repetitivestrain> is it impossible for Lua mapgens to provide an engine heightmap at the moment? |
| 17:19 |
[MatrxMT] |
<repetitivestrain> 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. |
| 20:08 |
|
lhofhansl joined #luanti-dev |
| 21:07 |
|
tibtoblezob joined #luanti-dev |
| 21:27 |
MTDiscord |
<exe_virus> 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. |
| 21:59 |
|
SFENCE joined #luanti-dev |
| 22:02 |
|
SFENCE joined #luanti-dev |
| 22:31 |
|
SFENCE joined #luanti-dev |
| 22:33 |
|
panwolfram joined #luanti-dev |
| 22:44 |
MTDiscord |
<the4spaceconstants2181> 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 |
<jordan4ibanez> It would be kinda cool if we could do little cube sprites like vintage story to layer in effects |
| 22:56 |
MTDiscord |
<jordan4ibanez> 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:05 |
|
Eragon joined #luanti-dev |
| 23:16 |
|
MTDiscord joined #luanti-dev |
| 23:45 |
|
MTDiscord1 joined #luanti-dev |
| 23:48 |
MTDiscord1 |
<jordan4ibanez> Oh sorry cheapie, I got distracted by my horrific code, one second |
| 23:50 |
MTDiscord |
<jordan4ibanez> cheapie: https://youtu.be/tkq0tIX22WY&t=138 |
| 23:53 |
MTDiscord |
<jordan4ibanez> 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 |
<jordan4ibanez> Okay you ready? So this is the blended mixture of particles: https://youtu.be/qV4ZLkug1n4&t=387 |
| 23:57 |
MTDiscord |
<jordan4ibanez> This is what I was referring to. You can give it some interesting texture |
