11:43 < minus> reminder that this almost existed at one point https://github.com/chaosk/trinitee
11:45 < nev> minus: what is that supposed to be?
11:53 < minus> a new website for teeworlds
12:07 < ChillerDragon> new as in 12yo ago axaxaxax
12:08 < bridge> <lukure> Thats new
12:08 < ChillerDragon> imagine the maintenance effort this would have caused
12:08 < ChillerDragon> maintaining some py app for 12yrs sounds pain
12:09 < minus> https://mnus.de/screenshots/trinitee.png
12:10 < bridge> <lukure> 16 Players 😲
12:18 < bridge> <d_une> On the flipside, we wouldn't have so much spam, I suppose
16:42 < bridge> <blade67> Can somebody guide me the right way? I'm trying to parse the layers inside maps (specifically the tilemap layers) but I'm a bit confused about the data structure. Looking at it here https://github.com/heinrich5991/libtw2/blob/master/doc/map.md#layers says its a nested item, but the item data I get only holds the base data, not the extension containing the data..
16:44 < bridge> <blade67> In the file it's described as
16:44 < bridge> <blade67> ```
16:44 < bridge> <blade67> item_data base for all layer items (different types have different extensions):
16:44 < bridge> <blade67>     [1] _version (not used, was uninitialized)
16:44 < bridge> <blade67>     [1] type
16:44 < bridge> <blade67>     [1] flags
16:44 < bridge> <blade67> ```
16:44 < bridge> <blade67> With the extension being
16:44 < bridge> <blade67> ```
16:44 < bridge> <blade67> item_data extension for tilemap layers:
16:44 < bridge> <blade67>     [1] version
16:44 < bridge> <blade67>     [1] width
16:44 < bridge> <blade67>     [1] height
16:44 < bridge> <blade67>     [1] flags
16:44 < bridge> <blade67>     [4] color: Color
16:44 < bridge> <blade67>     [1] opt *color_envelope
16:44 < bridge> <blade67>     [1] color_envelope_offset
16:44 < bridge> <blade67>     [1] opt *image
16:44 < bridge> <blade67>     [1] &data: 2d-array of the the tile type 'Tile'
16:44 < bridge> <blade67>     
16:44 < bridge> <blade67>     version 3 extension:
16:44 < bridge> <blade67>     [3] name: I32String
16:44 < bridge> <blade67>     
16:45 < bridge> <blade67>     DDNet extension (no version change):
16:45 < bridge> <blade67>     [1] opt &data_tele
16:45 < bridge> <blade67>     [1] opt &data_speedup
16:45 < bridge> <blade67>     [1] opt &data_front
16:45 < bridge> <blade67>     [1] opt &data_switch
16:45 < bridge> <blade67>     [1] opt &data_tune
16:45 < bridge> <blade67> ```
16:45 < bridge> <blade67> Which confuses me. The base doesn't have any data or a data index reference
16:54 < bridge> <blade67> Just realised its christmas eve and it's very unlikely that I'll get a reply - yikes
17:36 < bridge> <AssassinTee> There is a twmap tool by patiga which does that already, i would search it for you but I am literally in the swiss mountains and have bad internet
17:49 < bridge> <chillerdragon> cargo install twmap
17:49 < bridge> <chillerdragon> pip install twmap
17:49 < bridge> <chillerdragon> It’s really good
17:55 < bridge> <jxsl13> tried reading the rust code (somewhere on gitlab, sratch for patiga) and was lost pretty fast as I don't know any rust. Gave up implementing map parsing in Go (for now). What are you attempting to do Blade? Implementing a livrary in a different language or do you want to just use an existing library as mentioned above?
17:55 < bridge> <jxsl13> search*, library*
18:00 < ChillerDragon> no need to read rust
18:00 < ChillerDragon> the python bindings are really easy to use and there is lots of docs using the help() method
18:01 < bridge> <jxsl13> In order to implement parsing
18:02 < bridge> <jxsl13> either heinrich's docs, the c++ implementation or the rust implementation are your routes
18:03 < bridge> <jxsl13> if Blade wants to implement that for typescript or whatever else, he'd need to actually understand how that map format works.
18:06 < bridge> <jxsl13> -routes
18:06 < bridge> <jxsl13> + your reference implementations that you can look at
18:30 < ChillerDragon> ah but why xd
18:34 < ChillerDragon> I assumed he wants to work on a map with code. Because for that you do not have to reinvent the wheel anymore.
18:40 < bridge> <blade67> For context I'm porting the map format to GDScript (Godot)
23:41 < bridge> <patiga> @blade67 think of it as inheritance, all layers have the base fields, but depending on the type of layer, in this instance a tilemap layer, there are more fields to read
23:41 < bridge> <patiga> the item is just longer
23:41 < ChillerDragon> pogtiga
23:41 < ChillerDragon> woke
23:41 < ChillerDragon> the map pro
23:41 < bridge> <patiga> o/
23:42 < ChillerDragon> > Just realised its christmas eve and it's very unlikely that I'll get a reply - yikes
23:42 < ChillerDragon> got quality responses and more activity in the channel than the whole month combined
23:43 < bridge> <patiga> tbh the rust code is harder to navigate, an ide helps a lot
23:43 < ChillerDragon> patiga C++ promoter hehe
23:44 < bridge> <patiga> the complexity comes from lots more checks, and harder typing (which helps when actually working with the maps, but makes parsing a little longer)
23:44 < bridge> <patiga> here, fixed it ChillerDragon :p
23:44 < ChillerDragon> fixed wot
23:45 < ChillerDragon> did u edit a message? xd
23:45 < bridge> <patiga> promoting C++ too much ^^
23:45 < ChillerDragon> all hail ferris the crab
23:48 < bridge> <patiga> https://gitlab.com/Patiga/twmap/-/blob/f41ce2253920ea69769e3f36ebe0636c55be84be/twmap/src/map/parse.rs#L1456 @jxsl13 here is the code for parsing tilemaps
23:49 < bridge> <jxsl13> I don't know enough rust for that, I gave up on understanding it using rust.
23:52 < bridge> <patiga> but afaik, the map docs at https://github.com/heinrich5991/libtw2/blob/0085b3eb76ff1ffc7136f874129c79fce0f955ee/doc/map.md *should* be sufficient afaik
23:52 < bridge> <jxsl13> will look at them at some point. I might have started the wrong way
23:53 < bridge> <jxsl13> using your implementation as reference
23:53 < bridge> <AssassinTee> Isnt it 'just' unzipping and reading the binary?