Time Nick Message 13:36 Wuzzy Bugfix PR that will fix tiled nodes rendering: #10742 13:36 ShadowBot https://github.com/minetest/minetest/issues/10742 -- Fix world-aligned node rendering at bottom by Wuzzy2 19:35 Krock rubenwardy: for some reason there's a tailing newline when it's using the "description" nodedef field 19:36 rubenwardy that's not something I've changed 19:36 rubenwardy the code uses std::getline(sstr, desc, '\n'); 19:36 rubenwardy to get the first line 19:37 rubenwardy is it \r\n? 19:37 Krock https://pastebin.com/raw/D50ZpgcM 19:37 Krock there's no newline in tools.lua (MTG) 19:39 Krock I thought enchantment used itemmeta, but apparently this is the same case all over again: "description" itemdef field 19:40 beit hello, I would like to go over the code of mindtest, is there some design document? 19:40 MTDiscord uh 19:40 Krock mindtest 19:40 MTDiscord github.com/minetest/minetest 19:40 Krock dev.minetest.net as well, though not very detailed and possibly outdated 19:40 rubenwardy beit: https://dev.minetest.net/Engine 19:41 MTDiscord or, the doxygen docs 19:41 MTDiscord of whose location, i am unsure of 19:41 rubenwardy you'd generate those yourself locally 19:41 MTDiscord ah, minetest is not hosting its own? 19:41 Krock do you mean this? http://doxy.minetest.net/ it's ancient 19:42 rubenwardy not that 19:42 MTDiscord oh deat 19:42 rubenwardy that really should be removed from the DNS 19:42 MTDiscord *dear 19:42 Krock sort of a wayback machine 19:43 MTDiscord also, is there any technical limitation in increasing the max nodes 19:43 rubenwardy yes, networking compat and integer size 19:44 Krock rubenwardy: this only happens when the string is translated 19:44 Krock weird 19:44 rubenwardy my tests don't include translations 19:44 MTDiscord so, can we hope to get it in mt6? 19:44 Krock apparently 19:44 beit is there some block diagram? 19:44 Krock s​rinivas: yes sure if you begin coding now 19:45 rubenwardy https://dev.minetest.net/Engine/Structure 19:45 rubenwardy there's a diagram there 19:45 Krock first time seeing this. Minetest 0.3. 19:45 rubenwardy it's still _mostly_ correct 19:45 rubenwardy only because it's not very detailed 19:46 MTDiscord > s​rinivas: yes sure if you begin coding now hm, what are the parts i would have to tweak? i am not very familiar with the internals 19:46 rubenwardy content_id and the node def manager 19:46 MTDiscord and, only have a very very rough understanding of what does what 19:46 Krock s​rinivas: nodedef manager, mapblock serialization, database migration code 19:47 rubenwardy there's already an issue to raise the limit up to 65536 without breaking compat. Currently, half the IDs are reserved by unknown nodes 19:47 Krock for a good reason 19:47 MTDiscord https://github.com/minetest/minetest/issues/6101 and https://github.com/minetest/minetest/issues/10916 for reading material 19:47 Krock coincidence, there's an issue where running out of free content ids results in stalls and other side-effects 19:48 Krock speaking of the devil 19:48 rubenwardy if you run out of free content IDs, it should either replace with air or crash 19:48 MTDiscord also, are there any ideas of a release timeframe 6.0? 19:48 rubenwardy not plained at all currently 19:48 MTDiscord ah i see 19:49 MTDiscord also https://forum.minetest.net/viewtopic.php?t=20052 by krock is another thing to read about increasing the limit 19:49 MTDiscord thanks wsor 19:50 MTDiscord this topic has been rehashed so many times while ive been around i practically have the reading material memorized lol 19:50 MTDiscord also, thanks krock, ruben for your time 19:50 Krock you're welcome 19:50 MTDiscord > this topic has been rehashed so many times while ive been around i practically have the reading material memorized lol 19:50 MTDiscord hehe 19:50 MTDiscord I've got a question about PRs but don't wann to interrupt while you're in the middle of something else, is this an ok time or should I wait a bit? 19:50 MTDiscord go ahead 19:51 MTDiscord I'm doing a fairly large PR and I want to know whether it's worth my time, whether there's interest in it. What process should I follow? Do I make on issue? Or draft a PR now with a (working) part that I've finished? 19:52 rubenwardy an issue is the best way to get feedback for that 19:52 MTDiscord Thanks. 19:53 rubenwardy I wonder if the problem with the short_description thing could be that it's processing a utf8 string rather than utf16 19:53 Krock rubenwardy: the newline issue only affects translations; colors are fine. weird. 19:55 Krock I'm also a bit confused why the "first line" actually consists of multiple lines, for example : 19:55 Krock > description = minetest.colorize("red", "Copper\n rail"), 19:55 rubenwardy https://gist.github.com/rubenwardy/1e185f940262c39f98d0d8dcc6e0d366 19:56 rubenwardy might help 19:57 rubenwardy I imagine this will break if a translation contains a new line 19:57 Krock error: corrupt patch at line 20 ah whatever. gonna copypaste 19:58 Krock that made no difference. same output 20:00 Krock "getline" includes the tailing \n 20:01 Krock i.e. needs trim() 20:02 MTDiscord hm, i may have an idea to make increasing the size of the content_id non breaking for maps 1. let legacy maps continue using old size (by simply enforcing the limit of 32k even though the engine supports more 2. Provide a conf option to set the size for new maps 3. provide migration scripts to migrate from old to new 20:03 MTDiscord so, as a result, only the client should break (if my understanding is correct) 20:03 rubenwardy the size is compiled it, so you'd need to choose one size 20:04 rubenwardy you could convert from and to when dealing with map storage and network 20:04 MTDiscord nono, while the size can be suitably large, provide a soft limit 20:04 rubenwardy you'd still need to convert 20:04 Krock this sort of tweak should really not be a setting. rather find a solution that works well for all use-cases 20:05 Krock it's mostly a per-world setting and needs more tweaking efforts than it's worth 20:06 MTDiscord hm, true 20:06 Krock in 5.5.0-dev, per-world settings could be implemented but not for that reason 20:08 MTDiscord but what are the main usecases i should support? I see the following 1. large server hosting (with significant maps) 2. small server hosting (smaller mapsizes, but still headless & over network) 3. home client-server pairs (variable maps, but all localhost) 20:09 Krock excuse me? I thought the content_id limit discussion was about the number of enabled mods or registered nodes, rather than server type 20:10 MTDiscord hm, that was concerning migration, looks like i misunderstood what you meant by usecase 20:11 MTDiscord i was under the (mistaken?) impression that you were talking about "end-user" usecases (as in the types of users and their needs) 20:12 Krock no sorry, I meant various scenarios that might happen. for example maps that were downloaded, but without any active mods -> many unknown nodes 20:13 MTDiscord ah i see 20:13 Krock problem here is that it's a sort of "pool" where the final size is yet not known. if there were a map-specific list of nodes that were ever placed, you could predict the limit and adjust that accordingly 20:14 Krock however, keeping track of such a list is perhaps insane and error-prone 20:14 Krock the only known thing is that there's a limit of 65k node IDs that can be given away 20:14 Krock s/node/content/ 20:15 celeron55 i'd say it would be stupid to create some crazy contraption just to double the node id space 20:15 MTDiscord hm, the alternate solution could be just reserving approx half of the new content id's for unknowns (like what is currently done) 20:15 celeron55 either it stays like it is, or people accept some performance degradation and it's increased considerably 20:15 celeron55 then don't complain MT is getting slower 20:16 celeron55 due to all these little things people keep asking for piling up 20:16 MTDiscord if you go with uint64 which will leave upto 9.223372036854776e+18 for unknowns (and the same for known nodes) 20:16 MTDiscord which is a large enough number that the ipv4 like scare will not happen for quite some time 20:16 celeron55 eh, what 20:17 MTDiscord uh, the shortage of ipv4 addresses 20:18 celeron55 it's a large enough number for people to notice an increase in RAM usage, then you'll have to explain to them that yeah, it's for this thing you'll never use and now half of the bits in your memory are used for nothing 20:18 Krock I wouldn't say RAM usage is a concern, but saved mapblocks 20:19 MTDiscord hm, in this era where 8gb+1tb is increasingly common, i wouldnt worry too much about ram? 20:19 celeron55 just look up how much RAM, say, a raspberry pi has 20:20 celeron55 or a phone that a parent might buy for their kid 20:20 celeron55 MT isn't just for gaming PCs 20:20 MTDiscord uh, my laptop from 2013 has about 6 gigs in it... I rarely cross 4 20:21 rubenwardy I think making the known/unknown ID barrier dynamic already gives a considerably higher limit on node ids with very little performance impact 20:21 MTDiscord my phone a ~100$ chinese one, has 4gigs 20:21 MTDiscord the cheapest raspi4 has 4? gigs 20:21 MTDiscord or was it 2 20:22 Krock model 2b has 1 GiB 20:23 celeron55 everything before rpi4 has 1 GiB 20:23 celeron55 and even that's beside the point 20:23 celeron55 people use VPSes and whatnot 20:23 celeron55 memory isn't free 20:23 MTDiscord hm, fair 20:23 celeron55 not RAM, not disk 20:24 celeron55 and people use mobile connections, so network isn't free either 20:24 MTDiscord but certainly cheaper than when the 65k limit was thought of 20:24 MTDiscord fair, but again, cheaper 20:25 celeron55 there needs to be a proper reason for increases in memory usage, it can't be done just for a few users so that it degrades the experience for others 20:25 MTDiscord but hey, that was for uint_64, even going with u_int 32 can work pro tempore? 20:25 celeron55 make a similar desicion 20 times and you'll make it actually unusable for some 20:26 MTDiscord well, if it made right, it will not need to be made for a long time 20:26 rubenwardy lol, 64bits would be ridiculous 20:26 MTDiscord true 20:27 celeron55 i think making the unknown id barrier dynamic is a workaround that will last maybe a year or less 20:27 MTDiscord and, with moores law, you can safely make your changes again, and again 20:27 MTDiscord simply because tech upgrades 20:27 celeron55 then you're back to the same issue and have to support a useless system in addition to increasing the bit space 20:27 rubenwardy the system is pretty trivial and means you can use all of the ID space, not just half 20:28 MTDiscord and if we can do it once, it certainly can be done again, and again, sure it may be a pita, but it can be done 20:28 MTDiscord the only thing is, will it be done 20:28 celeron55 rubenwardy: ok even then, you pretty much have to already decide what to do after a year, when the same users come back with the same problem again 20:28 celeron55 it needs to be decided what the final bit width of the node id is, and stick to it 20:30 MTDiscord hm, you should remember that over time sensibilities change what was too much 10 years ago, will be stifling today, case point, ipv4 was once thought to be very plentiful, yet look at us today 20:30 celeron55 of course keeping in mind that increasing it at all will mess up the current 4 byte length of each node 20:30 MTDiscord migration scripts can be provided 20:31 celeron55 compilers and processors won't like a 5, 6 or 7 bit length 20:31 celeron55 *byte 20:31 celeron55 in an array 20:31 celeron55 they'll probably pad it to 8 or so anyway 20:32 MTDiscord hm, arent most processors 64bit these days 20:32 MTDiscord with the exception of some cheap phones and ancient tech 20:32 MTDiscord that still run windows 98 :p 20:35 celeron55 to be fair i don't really understand this level of optimization like some people do, but i do know that cache misses ruin your day, and compilers pad structs if they don't like the field lengths 20:35 celeron55 an i3 has 32 kiB of L1 cache 20:36 celeron55 the current mapblock node array size is 4B*4096 = 16384 B 20:36 celeron55 if it's increased to 8B, nothing else will fit in the cache in addition to it 20:36 celeron55 which generally seems like a pretty bad idea 20:37 celeron55 altough it may have no effect also, who knows; it's mostly a matter of trying to maintain good odds 20:38 MTDiscord hm, although, i dont know which scheduler will let a single prog take up all of cache 20:38 celeron55 for me there are many unknowns though, for example i don't know how compilers actually handle the u16+u8+u8 structure that a node is 20:38 celeron55 it could be that it's already padded to something else 20:39 MTDiscord tbh, i am not sure my self, i should read up that 20:39 celeron55 or reordered to something else 20:39 Krock weren't there a few re-ordering PRs a while ago, either by s0far or numzer0. I don't remember. 20:40 celeron55 in any case i think this is what increasing the node id space comes down to 20:40 celeron55 the u16 is currently the id 20:40 celeron55 and MT completely relies in everything related to this to be fast 20:41 celeron55 go ahead change it and test, and report what kind of performance loss you get on old and new hardware 20:41 MTDiscord mhm 20:41 celeron55 just switch it to u32 and see 20:41 MTDiscord although, progress will be slow, as i have major exams coming up one in 10 days from today too 20:42 celeron55 https://github.com/minetest/minetest/blob/master/src/mapnode.h#L122 20:42 celeron55 that line 20:42 MTDiscord mhm 20:43 celeron55 if someone has time to do it, collect some benchmark of changing that to u32 and u64, and also the u16 baseline 20:43 MTDiscord uh, whats the util to use/ 20:43 celeron55 https://github.com/minetest/minetest/blob/master/src/mapnode.h#L36 20:43 celeron55 i guess also this one 20:44 celeron55 not sure, that's part of the task 8) figure out what the benchmark needs to be 20:44 Krock also use a new map for that. it would either cause errors or corrupt existing maps 20:44 MTDiscord > if someone has time to do it, collect some benchmark of changing that to u32 and u64, and also the u16 baseline also, what are the test cases to be used? 20:44 MTDiscord > also use a new map for that. it would either cause errors or corrupt existing maps was planning on a fresh run in place 20:49 celeron55 maybe measuring how long the worldedit //fixlight command takes for a certain large volume could be a usable benchmark 20:49 celeron55 that's backed by quite some node data crunching 20:50 MTDiscord and how do i time worldedit? i am not very well versed in this, so i hope you will pardon me 20:50 celeron55 you'll have to add some time measurement to its lua code 20:50 MTDiscord ah i see 20:51 MTDiscord a call to minetest.get_ustime before and after execution and subtract the results? 20:51 MTDiscord + divide by 1000 to get time in seconds 20:51 celeron55 just collecting statistics of world generation performance works too and could be a more relevant benchmark actually 20:52 MTDiscord uh, i use the profiler for that right? or is there a different method? 20:59 celeron55 not many directly useful values there, but maybe if you write down the "EmergeThread: Mapgen::makeChunk" millisecond values in a new world until the mapgen stops, always using the same seed for a new world, and take an average of those, that's a reasonable value to compare 21:00 celeron55 of course doing the same using some added logging code would be more robust but doing that by hand should work fine enough 21:01 celeron55 also record the final memory consumption when generation stops 21:01 MTDiscord mhm, would yall accept a debug build only pr that logs these values? may be useful? 21:01 celeron55 and don't move the mouse 21:37 celeron55 ok, did that myself just to see if there's a difference 21:38 celeron55 i measured the total Mapgen::makeChunk time in a new map with the same seed in u16, u32 and u64 content_t/param0 builds 21:39 celeron55 the results are: u16: 23635ms, u32: 24060ms, u64: 25564ms 21:40 celeron55 the cpu in this system is i7-4800MQ 21:42 celeron55 so the difference is visible 21:47 celeron55 did a third test for u32, the average time went down to 23569ms 21:47 celeron55 based on these it seems u32 isn't slower than u16, but u64 is slower 21:48 celeron55 that's weird and begs the question what does the MapNode structure actually look like in memory 22:00 celeron55 using the -Wpadded g++ option it seems the compiler wants 32-bit positions for pointers and integers, but char/bool is fine at 8-bit positions 22:00 celeron55 it doesn't say anything about MapNode which should mean that it stays intact 22:01 celeron55 yeah, if i move param0 after param1, it will say it will be padded 22:01 celeron55 so u16, u8, u8 is optimal 22:02 celeron55 u32, u8, u8 however says "padding struct size to alignment boundary" which means it's probably extendng the size of MapNode to 64 bits 22:03 celeron55 u64, u8, u8 also says the same, but 64+8+8 is 80 bits so it's padding the size to 32*3 = 96 bits probably 22:05 celeron55 oh, it's padding it to 128 bits 22:05 celeron55 u32, u8, u8 is 64 bits like i expected 22:05 celeron55 and u16, u8, u8 is 32 bits, confirmed 22:06 celeron55 so on this processor it doesn't matter speed-wise if MapNode is 64 bits instead of 32 bits total 22:06 celeron55 that also means if the id was 32 bits, there would be room for 16 extra bits after param1 and param2 22:08 sfan5 param1 could be made rgb565 for colored light 22:19 celeron55 or u16 for light to go much further 22:19 celeron55 however nobody knows how computing intensive that would be 22:20 celeron55 well rgb565 of course has one bit more already 22:20 MTDiscord Doesn't irrlicht have colored lighting? 22:20 sfan5 well hmm 22:20 sfan5 if you use rgb565 what about the day and night bank? 22:21 sfan5 (or artificial / natural bank as someone once proposed IIRC) 22:21 celeron55 well, then you just have two of them 22:22 celeron55 it's 3x the lighting calculation, plus 2x more for the double distance 22:22 celeron55 so 6x 22:22 celeron55 it would be interesting but possibly unusable 22:23 celeron55 also, double distance means 8 times the volume... so maybe more like 24x computation 22:23 numzero is distance larger than mapblock size feasible at all? 22:24 celeron55 no idea, it's true that just the distance could create some kind of unrepairable hell of glitches 22:25 celeron55 Flamore: of course, but it's just the simple lighting you see in any game, not node volume based 22:26 numzero rgb444 would fit MT better than rgb565 22:27 numzero and would fit these additional bits after proposed content_id expansion to 32 bits 22:27 numzero (64bit content_id is nonsensical) 22:27 celeron55 nothing stops you from cutting rgb565 short at 4 bit distance and just mapping the brightness appropriately 22:27 numzero nevertheless, 32 bits is too much for content_id IMO 22:27 celeron55 you get more dim colors that way 22:28 celeron55 or... does something stop one from doing that? 22:28 celeron55 actually 22:28 celeron55 rgb is a bad idea 22:28 celeron55 at least in theory 22:28 numzero if you mean using only 4 high-order bits for spread and low-order bits for more levels, that’s okay 22:29 numzero rgb? it won’t look perfect but is the only viable colorspace for MT-ish light spread 22:29 numzero (out of 3-channel colorspaces ofc) 22:30 celeron55 what about hsl? 22:31 numzero how to spread hsl from several sources? 22:31 celeron55 mixing colors can be a bit tricky but at least the L component can be handled with just as many bits as we want which is 4 22:31 numzero yeah ofc 22:31 numzero mixing is the problem 22:32 numzero it’s not a big problem to mix 2 colors, if you know the colors 22:32 celeron55 and L could be mixed just like now, that is, just take the brighter from the two colors 22:32 numzero but how to mix H? 22:34 numzero more precisely, how to *spread* H? 22:34 celeron55 when spreading it just stays the same 22:34 celeron55 but when mixing i'm not sure 22:34 numzero er, I mean, spreading H from several sources 22:35 numzero of different colors 22:35 celeron55 also S is problematic 22:35 celeron55 HSL or HSV directly works like paint while we're dealing with light, which would be better directly represented by RGB 22:35 rubenwardy RGB has problems but it's by far the simplest 22:35 MTDiscord true 22:36 numzero the great thing in the current light spread is that as soon as it meets a brighter node, it can stop 22:36 celeron55 but rgb colors at low bit depths look terrible 22:36 numzero with HSL that won’t be the case as that would mean no mixing at all 22:37 celeron55 well the thing about light is that in nature the brightness dynamic is so huge that if you take two lights, chances are one of them is so much dimmer it doesn't practically change the overall color of the lighting 22:37 celeron55 so one could get away with just not mixing unless L is the same or something almost equally silly sounding 22:39 celeron55 but also just using rgb444 and hoping for the best could work just as well 22:40 numzero I saw screenshots of rgb444, it looks okay (albeit imperfect) 22:40 celeron55 personally i'd really like more control on the hue and saturation, even while we can't have a huge range of lightness 22:40 celeron55 i could have very subtle colors of light 22:40 numzero heh, that’s where your proposal could work 22:40 celeron55 i mean, it would allow stuff like actually having the color of the light coming from a blue sky as a node lighting color 22:41 celeron55 in rgb444 i'm not sure there's a subtle enough blue available 22:41 celeron55 it would have to be 14, 14, 15 22:41 numzero um... but currently the same light value is used for skylight and sunlight 22:42 celeron55 what that actually looks like depends on the gamma and other mapping of course 22:42 celeron55 yeah, and there's clever shader code for coloring natural/sunlight a bit differently at different times of day 22:43 celeron55 wait 22:43 celeron55 was it time dependent or constant 22:43 numzero and that *should* be in the shader, just a bit differently 22:43 celeron55 i think it's constant actually 22:45 numzero hm... not sure of what *should* be there, actually 22:46 numzero currently the shader does smooth day/night transition as well as tints artificial light 22:46 numzero but due to lack of data, the tint is often wrong at daytime 22:46 numzero it tints *all* artificial light even if there is full daylight at the time 22:47 numzero as it can’t know that 22:47 numzero without #5155 22:47 ShadowBot https://github.com/minetest/minetest/issues/5155 -- Change light banks meaning 22:47 celeron55 14,14,15 (#eef) in rgb444 is #eeeeff in rgb888, and if that's rendered directly on this sRGB-ish screen it actually is a reasonable shadow blue, same goes for #dde, #ccd, #bbc and all the way down to #778 and #223 it does transition into a blue shadow 22:47 ShadowBot https://github.com/minetest/minetest/issues/778 -- Fixed wrong output from dump() by kaeza 22:47 ShadowBot https://github.com/minetest/minetest/issues/223 -- Game doesn't always disregard image filename extensions in the context of a mod's code 22:47 celeron55 so it is capable of a subtle enough color 22:48 numzero heh 22:48 celeron55 lol 22:48 numzero the remaining thing is to change spread mechanics 22:48 numzero to make direct sunlight become (15,15,14) and skylight become (14,14,15) 22:49 celeron55 i'm not sure if that's actually doable otherwise 22:49 celeron55 i just want the colorspace to be capable of it regardless 22:49 celeron55 btw, i want to see what it looks like if rgb444 is handled as simply three separate channels of the current light handling code 22:49 celeron55 no changes whatsoever otherwise 22:50 celeron55 dimmer color channels stopping at brighter ones has a chance of being a reasonable effect and it would be very simple and fast 22:51 celeron55 that means if there are two colors of similar brightness, they tend to mix towards white light of the same brightness 22:51 celeron55 which is realistic 22:54 numzero additive lighting is realistic. MT only needs to look good 22:56 numzero anyway, the question was on increasing content_id size, not on lighting at all) 22:57 celeron55 well, it all goes hand-in-hand 22:57 numzero somewhat 22:57 celeron55 if there are multiple well researched proposals that need more bits for nodes and the next node size in memory is double the current one regardless of what's added to it, it's more likely to happen 22:58 numzero I think doubling the node size is to happen eventually 22:58 celeron55 there's the everpresent question of "what about fields for node physics" too 22:59 celeron55 currently the only physics field is liquid level 22:59 numzero there is also a question: *why* are more content_ids necessary? 23:00 celeron55 i think they are not necessary and could be avoided by map management tools 23:00 celeron55 and mod management tools 23:00 numzero WDYM? 23:00 celeron55 it is an alternative to said tools though 23:00 sfan5 another example #9193 23:01 ShadowBot https://github.com/minetest/minetest/issues/9193 -- Add paramtype2 for node texture variants 23:01 celeron55 well, if users could easily determine which mods are adding way too many nodes, they could disable them, or if the tools even had the option of disabling some nodes without disabling the mods that would be even better 23:01 celeron55 and for maps that have unknown nodes that aren't used there could be clean up tools and node usage counters to help with cleaning up 23:02 numzero um... am I right node names are stored in each mapblock (on disk)? 23:02 celeron55 yes 23:02 numzero I just realized the on-disk format doesn’t need to change 23:02 celeron55 the disk format allows infinite node names in each map 23:03 numzero it renumbers nodes for each mapblock already IIRC 23:03 sfan5 yes 23:03 numzero and there may never be more than 4096 different nodes in a mapblock 23:03 numzero since there are just 4096 nodes in said block 23:03 numzero so the overall node type limit is irrelevant for on-disk format 23:04 numzero oh, network serialization uses the same format, doesn’t it? 23:04 sfan5 yes 23:06 celeron55 i guess it doesn't even take advantage of the fact that the client and server actually have synced node ids 23:07 numzero so it should be possible to experiment reasonably safely 23:07 numzero btw does the client need different node ids for different unknown nodes? 23:08 numzero (if it doesn’t doing map save ofc) 23:09 celeron55 the client and server of course otherwise do need synced node ids 23:09 celeron55 all commands rely on them being in sync 23:09 celeron55 oh actually 23:10 celeron55 the mapblock network serialization format does actually skip the mapping 23:10 sfan5 huh 23:10 sfan5 didn't know that off the top of my head 23:11 celeron55 and the client will not deserialize the mapping from the network data even if the data had it 23:11 celeron55 well good, at least that's optimized