00:35 < bridge> [teeworlds] We could build the mapconverter directly into the server, besides the community need not care about the map conversion, only the hosters do 00:36 < bridge> [teeworlds] the hosters have shown they're not great at keeping up with map converters 00:37 < bridge> [teeworlds] so it should at least be made easy/obvious 00:37 < bridge> [teeworlds] Well what maps are hosted anyway? ddnet would convert the entire collection of ddrace/race maps and vanilla seems to mostly revolve around the official maps anyway 00:38 < bridge> [teeworlds] fng people will convert the 3 or so fng maps that exists, and that's about the entire community 10:55 < bridge> [teeworlds] theres a lot of fng maps actually 10:55 < bridge> [teeworlds] but only one that really gets played 12:37 < ChillerDragon> lol tw is not only vanilla ddnet and fng Learath2 ur in a big ddnet bubble 12:38 < bridge> [teeworlds] I see a lot of unconverted maps around when joining servers in teeworlds 13:05 < bridge> [teeworlds] 😅 13:27 < bridge> [teeworlds] maybe a hard break is better than tiny incompatibilities, so people have to upgrade maps 😄 13:31 < bridge> [teeworlds] that could make the update very unpopular though 13:31 < bridge> [teeworlds] is it worth the feature bonus? 13:46 < bridge> [teeworlds] if the server and editor included a converter, it wouldn't be a big deal 13:46 < bridge> [teeworlds] the most important benefit would be extendability I think 13:46 < bridge> [teeworlds] however, one could try to improve the current format to be more extendable as well 13:47 < bridge> [teeworlds] map compatibility break is best justified by a big selection of new standard maps and new map themes / tilesets 14:19 < bridge> [teeworlds] That doesn't break backwards compatibility 14:19 < bridge> [teeworlds] You can add new stuff without breaking old maps 14:22 < bridge> [teeworlds] Or have a converter when it does break 16:11 < bridge> [teeworlds] ChillerDragon oh I'm sorry I forgot about the 5 obscure mods with 1 map each. I wonder how they will ever use a map convert tool. 16:11 < bridge> [teeworlds] oof 16:11 < bridge> [teeworlds] It might even break their hands and their 10 players yearly might suffer 16:11 < bridge> [teeworlds] salty 16:13 < bridge> [teeworlds] @Dune It won't make the update unpopular except for a couple goofs trying to make a statement. If the major mods move along, so will the community. The players don't care what the map format is 16:13 < bridge> [teeworlds] that i agree 16:41 < bridge> [teeworlds] if we have in mind that whatever we do is fine as long as ddnet can keep up with it we might as well dev directly on the ddnet repo 16:42 < bridge> [teeworlds] even ddrace-like gametypes, or race. there are plenty of maps and some servers that just haven't (properly) converted them 16:43 < bridge> [teeworlds] even 1 year in I see graphical bugs due to the tileset changes 17:04 < ChillerDragon> well also 1 year in nobody updated lol 17:19 < bridge> [teeworlds] what do you mean? 17:50 < bridge> [teeworlds] 0.8 will already be network incompatible, so a map format upgrade would really not matter for the players. ddnet can break map compatibility right now if backwards compatibility wasn't a concern 17:51 < bridge> [teeworlds] Besides a converter being bad is not evidence that all converters are bad 17:52 < bridge> [teeworlds] Through proper testing, we could make a conveter that does not suffer from issues of the past 17:53 < bridge> [teeworlds] Again, seems reasonable. Maps for the most part are hosters concern. Also having a converter that deal with map version does sounds better than having both servers and clients to deal with versions. 17:53 < bridge> [teeworlds] I +1 17:59 < bridge> [teeworlds] @Learath2 you say that, yet tileset compatibility was a huge problem in 0.7, so unless there is a very accessible and visible solution to convert maps there is no reason 0.8 would be any different 18:01 < bridge> [teeworlds] Well I don't really know what you changed between 0.6 and 0.7 about the tilesets but the proposed changes to the map format would all be restructuring. As long as the client unpacks the thing correctly I don't see how any issue can occur 18:02 < bridge> [teeworlds] Besides any mistake we make will be quite obvious when ddnet migrates the hundreds of maps we have. We had tileset and quad issues too when making our 0.7 converter and it took like a week to iron out the mistakes. Community size really helps with testing 18:02 < bridge> [teeworlds] Isn't having the converter directly in server the point of being accessable? Just have the any version of map loaded and the server does the magic auto magically. 18:03 < bridge> [teeworlds] that'd be a solution yeah 18:03 < bridge> [teeworlds] @TsFreddie that's what I would propose if people not being able to use or find a converter is a legitimate concern 18:04 < bridge> [teeworlds] I'd just like this problem not to be ignored like it was for 0.7 18:04 < bridge> [teeworlds] 👀 conv always goes in weird ways. 18:04 < bridge> [teeworlds] people not being able to use or find a converter is a legitimate concern 18:04 < bridge> [teeworlds] as proven by the amount of chats and support requests I've had with server hosters 18:04 < bridge> [teeworlds] So is baking them into the server a solution for the concern or not. 18:05 < bridge> [teeworlds] I imagine that'd be a solution yeah 18:05 < bridge> [teeworlds] 👀 conv's hard man 18:05 < bridge> [teeworlds] Anyway, there is no proposal for a new map format yet. Maybe we can have the new layer extensions within the old format 18:06 < bridge> [teeworlds] (Though I think that would create more issues as people can load new maps with old servers) 18:06 < bridge> [teeworlds] Ye. If we does do a converter maybe drag 0.5 in as well just for good deed. 18:06 < bridge> [teeworlds] Are there 0.5 maps that aren't converted? 18:08 < bridge> [teeworlds] if it is not much difficult then why not. I don't know much about 0.5 format. If it is drastically different then probably don't. 18:08 < bridge> [teeworlds] No it's exactly the same as 0.6 iirc 18:08 < bridge> [teeworlds] Then it would be an extra tileset map data 18:08 < bridge> [teeworlds] There might have been minor changes as to where some data goes but that should be it 18:09 < bridge> [teeworlds] Well, we'll see. 18:15 < bridge> [teeworlds] envelopes support changed maybe? 18:15 < bridge> [teeworlds] So it is just me or do our conversation sometimes goes in circles where everyone is having the almost the same idea but still having an argument back and forth.👀 18:15 < bridge> [teeworlds] I don't feel that way 18:18 < bridge> [teeworlds] A converter that can load 0.6 maps can also handle 0.5 maps. The tilesets are the major issue. You don't know which one was used. 18:18 < bridge> [teeworlds] We definitely need versioning for external tilesets, then it's kindas easy to update the tile layers 18:18 < bridge> [teeworlds] it's just a index -> new index mapping 18:19 < bridge> [teeworlds] Do you mean a 0.6 map using a 0.5 tileset? 18:19 < bridge> [teeworlds] a real problem with 0.6 -> 0.7 is that many mods extend the map format in various ways 18:20 < bridge> [teeworlds] format hardly changed between 0.6 and 0.5, but the tilesets were changed. You just dont know whether it is a 0.5 or 0.6 map 18:23 < bridge> [teeworlds] Right. If we can find a way to identify 0.5 maps then we can assume the tileset. If not, we don't have to support 0.5 tilesets, like Learath2 said, there aren't many that haven't been ported and still being used. 18:23 < bridge> [teeworlds] Also I think most mods doesn't change the standard part so vanilla clients can read it. 18:23 < bridge> [teeworlds] For vanilla server I think it is enough to simply deal with the part we know. 18:24 < bridge> [teeworlds] Devs that does format extension will definately have their own solutions. 18:24 < bridge> [teeworlds] If they are willing to upgrade 18:25 < bridge> [teeworlds] That's the problem... the are not because it's just additional work 18:25 < bridge> [teeworlds] This would be one thing I definitely want for a new map format. Every assets hash is saved 18:25 < bridge> [teeworlds] Thshould be/ would be one thing I definitely want for a new map format. Every assets hash is saved 18:26 < bridge> [teeworlds] But they can't upgrade without also dealing with protocols. So if they can upgrade protocols they probably can do maps as well 18:26 < bridge> [teeworlds] i'm not sure about the hash. what about fixing visual bugs in external tilesets? 18:26 < bridge> [teeworlds] This would be one thing I definitely want for a new map format. Every assets hash should be saved 18:26 < bridge> [teeworlds] It probably should come with a map update 18:26 < bridge> [teeworlds] Or else information is lost 18:27 < bridge> [teeworlds] Hashes allow things like asset retrieval from the gameserver or an external server. 18:27 < bridge> [teeworlds] that would mean we need to ship several versions of a tileset so old versions of maps still work 18:28 < bridge> [teeworlds] I guess we could make it fall back? 18:28 < bridge> [teeworlds] If the asset can't be found with the exact hash, use whatever's available 18:28 < bridge> [teeworlds] yeah that would be okay i guess 18:28 < bridge> [teeworlds] I think Learath2's idea is to identify the version when doing the convertion for future tileset update, we can always just load the existing ones if the hash does trigger the map converter 18:29 < bridge> [teeworlds] Does not* 18:29 < bridge> [teeworlds] Does not trigger* 18:29 < bridge> [teeworlds] The idea is mostly to allow maps to be completely preserved as is 18:30 < bridge> [teeworlds] It's a side effect that it also allows us to "upgrade" maps to the newest assets if needed 18:30 < bridge> [teeworlds] completely automatically 18:32 < bridge> [teeworlds] Oh and it allows things like matricks' bluesky branch 18:32 < bridge> [teeworlds] But hash might be overkill probably. A single number baked into the editor code corresponding the tileset that ships with it is probably enough? 18:32 < bridge> [teeworlds] Numbers require discrete parties to agree on things. Hashes don't 18:33 < bridge> [teeworlds] Well hash is probably good for everything. And probably can detect ppl swapping tilesets accidentally. 18:33 < bridge> [teeworlds] But keep tracking multiple hashes across a major version might be tough 18:34 < bridge> [teeworlds] Why do we need to keep track of it? 18:34 < bridge> [teeworlds] So when you need to upgrade the tileset, you know which ones need to be upgraded. 18:34 < bridge> [teeworlds] Ah, we can extract that from git even 18:35 < bridge> [teeworlds] Right. Just hope that won't be too much data. 18:35 < bridge> [teeworlds] Also, you almost always upgrade to the latest. So if hash != latest, upgrade 18:36 < bridge> [teeworlds] Wait. You need to know the original tilesets formations 18:36 < bridge> [teeworlds] Oh, yeah if you want to allow tiles to move around 18:36 < bridge> [teeworlds] Yeah, that 18:37 < bridge> [teeworlds] I mean what kind of changes were you talking about 18:37 < bridge> [teeworlds] I imagine a future where we can have a nice assetdb where all the assets can just be fetched by the client 18:37 < bridge> [teeworlds] I was thinking of things like color adjustments, shadowing changes and stuff 18:38 < bridge> [teeworlds] But anyway, not much more trouble to handle that too 18:39 < bridge> [teeworlds] I think tilesets positions changes are the main concern 18:39 < bridge> [teeworlds] You don't need to worry about visual fix. Plus the assetsdb thing probably won't happen anyt time soon in vanilla if at all. 18:40 < bridge> [teeworlds] Well the easiest solution is just "don't do that" but we can just keep a log of the tile moves anyway 18:40 < bridge> [teeworlds] @TsFreddie who cares whether vanilla adopts it? The ability for it to be implemented in a nice non breaking way would be more than enough for me 18:40 < bridge> [teeworlds] from 0.6 to 0.7 some tiles were actually moved to a new tileset >.< 18:41 < bridge> [teeworlds] shadow tiles 18:42 < bridge> [teeworlds] Also again even with the assetsdb thing, why would you need to update the maps hash if you can just fetch the latest assets to have it just works 18:42 < bridge> [teeworlds] Besides maybe matricks' interest in bluesky might inspire the vanilla lot 18:42 < bridge> [teeworlds] I probably missed your point 18:42 < bridge> [teeworlds] If it is for the small visual changes your were taking about lol. 18:42 < bridge> [teeworlds] I don't want the latest assets for all maps. I want the maps to always look the same as when they were created 18:43 < bridge> [teeworlds] Oh that 18:43 < bridge> [teeworlds] Updates to visuals should almost always be an explicit choice 18:43 < bridge> [teeworlds] So that's entirely different from what we were taking about.😋 18:44 < bridge> [teeworlds] Or I missed it 18:44 < bridge> [teeworlds] Anyway ðŸĪŠ 18:44 < bridge> [teeworlds] Yeah, then hash is probably the way to go. 18:45 < bridge> [teeworlds] Enough of this hypothetical that will never happen. Realistically we'll be stuck with undefined behaviour, unextendable map format and an unextendable datafile format for the forseeable future 18:45 < bridge> [teeworlds] I wish we can have a hash that can describe the tilesets formations tho. But I'm probably just imagining, since we don't have that data anywhere to hash. 18:46 < bridge> [teeworlds] We could create such data by hand 18:46 < bridge> [teeworlds] Can we give each tile a name, and hash that 18:46 < bridge> [teeworlds] Exactly 18:47 < bridge> [teeworlds] We should do that. For the upgrade thing, it would probably be more sensible than having a list of hash for each tilesets form change. 18:48 < bridge> [teeworlds] I had a nice thought actually. It's not much trouble to repack maps at server launch. We could get a new map format and do a beta on ddnet 18:48 < bridge> [teeworlds] Just need to send the old version to old clients 18:49 < bridge> [teeworlds] Then we can safely test it and maybe get it in a form that might be acceptable by vanilla 20:02 < bridge> [teeworlds] @Learath2 unfortunately @Zatline absolutely wants a reorder of the tileset 20:02 < bridge> [teeworlds] so we have to come up with a proper solution this time 20:03 < bridge> [teeworlds] ðŸĨ°