A modern programming language that makes developers happier.

kotlinlang

set the channel topic: <https://github.com/BenWoodworth/knbt>

set the channel description: Minecraft NBT library for kotlinx.serialization

set the channel topic: Minecraft NBT library for kotlinx.serialization

set the channel description: <https://github.com/BenWoodworth/knbt>

Hey, it would be nice to have every `put` functions set as `operator fun` so we can have an even fancier syntax :)
Also create `operator fun plus` for NbtList

Kotlinx.serialization did actually have this kind of API in the past for its Json builders, <https://github.com/Kotlin/kotlinx.serialization/blob/938a35f4922d0dfad389fdd73bc163d0772245d9/runtime/commonMain/src/kotlinx/serialization/json/JsonElementBuilders.kt|here> (plus `key to value` instead of `put(key, value)`), but they ended up changing it, <https://github.com/Kotlin/kotlinx.serialization/commit/fb90c7a8d517f6ee54d5c78efcc9d5cb056e4054|here>

I try to keep knbt's API very similar to what kotlinx.serialization has so I won't add any DSL fanciness unless they do too, but it's interesting to see that they had this at one point

In the future though, with `context` receivers, you'll be able to easily add it yourself, which I'm really excited about :eyes:
```context(NbtListBuilder&lt;NbtByte&gt;)
operator fun Byte.unaryPlus() = add(this)```

Hi, is there a way to mutate a NbtCompound ? I need dynamic modifyable nbt data.

Heya! Not really except for maybe e.g. constructing `NbtCompound(mutableMap)` and modifying the `mutableMap`. That might be a hack though (and also probably not the nicest to work with). I copied the behavior of the `JsonObject` and that's how its constructor is implemented

I've always been able to get away with a `MutableMap&lt;String, MyValueType&gt;` (or just `NbtTag` for the value type if you want to leave it open-ended). That might be an option depending on what you're doing

If you do want fine control over it though, it's pretty straightforward (just verbose) to create your own e.g. `MutableNbtTag` classes. I've got a good idea how that'd work if you want me to help with that

There was an issue opened about making `NbtTag` types mutable, and it's something I put a ton of thought into and don't plan on supporting for a few reasons. Mainly because I want to keep the scope of the library to serialization, so it makes sense to treat `NbtTag` as a representation of the serialized data (and serialized data is immutable). Plus that's the way kotlinx.serialization does it. There's also a lot of ways/assumptions in implementing separate mutable `NbtTag` classes which makes me hesitant to add them alongside the read-only ones in a general-purpose library like knbt (how copying should work, concurrency since the encoder assumes a lot about the data's immutability, ...). I think it makes more sense to leave it up to the person doing the serializing &amp; avoid the added scope

If kotlinx.serialization adds mutable versions of `JsonObject`, and `JsonArray` then 100% I'll follow suit with knbt. I'm kinda curious of they have a rationale, and might be worth opening an issue if you want, even just as a question for the insight

Nice thanks for the big reply !
I created my own implementation for `MutableNbtCompound` so (because it's precisely a mutable compound that I need) and it works like a charm using internally a `mutableMap` ^^

As polymorphic serialization isn't supported, what are the alternatives for doing it ? Do I have to create serializers for all my objects ?

What's the class you're trying to serialize? I could probably help come up with something. Or use it to help myself get polymorphic serialization supported

For v0.12 I am working on adding proper support, plus a serializer like ContentPolymorphicJspnSerializer, but I ran into a design issue that makes me have to fundamentally re-think how some things work.

I'm not aware of any polymorphic NBT used in game though which is why it wasn't a priority, but I'm also curious to know

It is for serializing the new Display Entities NBT data, I used an abstract class called `DisplayEntity` with transformation/billboard/shadow etc, and I have `ItemDisplay`, `BlockDisplay` &amp; `TextDisplay` that extends it with each their specific properties (an item for ItemDisplay, a block state for BlockDisplay and a JSON component for TextDisplay)

OOh <https://minecraft.fandom.com/wiki/Display#Entity_data|gotcha>. I'll take a closer look, but the solution I posted <https://kotlinlang.slack.com/archives/C7A1U5PTM/p1680884012070579?thread_ts=1680617292.319089&amp;cid=C7A1U5PTM|in your other thread> might work if you're only serializing and not deserializing

And I think I know I could go about implementing support, so there's a small chance I can get a `NbtContentPolymorphicSerializer` added to v0.11 this weekend

So you could have something like this

```@Serializable(DisplayEntitySerializer::class)
abstract class DisplayEntity

@Serializable
data class ItemDisplay(...) : DisplayEntity

@Serializable
data class BlockDisplay(...) : DisplayEntity

@Serializable
data class TextDisplay(...) : DisplayEntity

object DisplayEntitySerializer : NbtContentPolymorphicSerializer&lt;DisplayEntity&gt;(DisplayEntity::class) {
    override fun selectDeserializer(content: NbtTag) = when {
        "item_display" in content.nbtCompound -&gt; ItemDisplay.serializer()
        "block_state" in content.nbtCompound -&gt; BlockDisplay.serializer()
        "text" in content.nbtCompound -&gt; TextDisplay.serializer()
        else -&gt; throw SerializationException("some error")
    }
}```

I see, but each class has an optional data, like for example `BlockDisplay` has a `blockState` property which is nullable, maybe it's a simple fix using a default value (but then how do I know if user really want this default value as the actual value) ?

Hello, I really need polymorphic serialization for a specific thing (or maybe a `JsonAsNBTSerializer`), is there any progress on this ?

Hey!! I should have some time tomorrow to take a look and see what it would take to get it implemented quick as a patch release. What kind of polymorphic serialization specifically, so I can prioritize that? Like JsonContentPolymorphicSerializer, the automatic "type" based, both, just encoding without needing to deserialize, etc.

I put knbt on hold while I was getting my new <#C06083PAKEK|parameterize> library pushed out to help with testing knbt (which I did finally open up to the public last week :blush:). Which, testing knbt was a big motivation for it, especially with how tricky it was getting to be confident all edge cases were covered

I am also between jobs at the moment so I've had some extra time recently to work on projects :relieved:

Your library is very nice, great job !

I need polymorphism but I don't care about the `type` property, if it's easier to skip it do it, else I'll use `classDiscriminatorMode = ClassDiscriminatorMode.NONE` as a parameter (if your encoding support that)

Just a quick update. I've got polymorphic serialization working locally, with the built-in sealed/polymorphic serializers (with the "type" discriminator, which i'll probably leave as non-configurable for now), and also allowing PolymorphicKind serializers in general (which was a more artificial restriction, since I didn't fully grasp how polymorphic serializers interacted at the time)

And with polymorphic serializers being allowed in general, it should be trivial to add equivalent <https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-json/kotlinx.serialization.json/-json-content-polymorphic-serializer/|JsonContentPolymorphicSerializer> and <https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-json/kotlinx.serialization.json/-json-transforming-serializer/|JsonTransformingSerializer> serializers for NBT, either in knbt, or yourself until I do. Since you might not want the `type` property, `NbtContentPolymorphicSerializer` would probably work well for you, and simply failing if trying to deserialize

Right now I just need to clean up a little and make sure I've got predictable/helpful errors in cases where the polymorphic serialization is misused

Depending on how soon you'd want this released, I could also take some time to implement a `ClassDiscriminatorMode`, basically so you wouldn't need to create a custom serializer to tag onto every `type` property-less polymorphic class

Great progress ! Thank you for still working on this library and I can't wait to try these !

And, done! I'd just like you to try it locally and see that it works alright for you. (checkout the <https://github.com/BenWoodworth/knbt/tree/0.11-polymorphic|0.11-polymorphic branch>, publish to maven local, and try 0.11.4-SNAPSHOT)

I added support for the builtin sealed/polymorphic serializers, and added the `NbtContentPolymorphicSerializer` and `NbtTransformingSerializer` classes.

I didn't get to implement a classDiscriminatorMode yet, but I could next week with a little more time. It's possible to accomplish the same thing with the `NbtContentPolymorphicSerializer`, though

I'm also thinking of updating everything to the latest kotlin in a separate release. I'm iffy about jumping to it right away from kotlin 1.5.30, since Kotlin/Native isn't binary stable until 1.9.20, so bumping the version in a minor knbt release might cause dependency conflicts for anyone using it for Native

I'm going to try this tonight and I'll tell you if it works as expected in my case !

I'm sorry but I can't find this class in the artifact, are you sure it's correctly exported ?

No worries! It looks like it should be there if you've got the 0.11-polymorphic branch:
<https://github.com/BenWoodworth/knbt/blob/0.11-polymorphic/src/commonMain/kotlin/NbtContentPolymorphicSerializer.kt#L70|https://github.com/BenWoodworth/knbt/blob/0.11-polymorphic/src/commonMain/kotlin/NbtContentPolymorphicSerializer.kt#L70>

Unless you mean the discriminator mode, but I haven't had time to implement that yet

I installed the 0.11.4-SNAPSHOT and you said it should be there, but it's not ! :confused:

Oh, gotcha! I haven't merged this branch in yet so the published snapshots don't have it yet. But if you `publishToMavenLocal` (and add `mavenLocal()` to your gradle repositories) from this branch you should be able to test it out.

And to be sure, you could even change the version in gradle.properties to 0.11.4-polymorphic-SNAPSHOT or something before publishing to maven local so it's not pulling in the wrong artifact

Ah, I need to create the dependency myself okay x)

I haven't had time to test, I'll tell you when I try !

Quick update, but I updated to Kotlin 1.9 in the
<https://github.com/BenWoodworth/knbt/tree/0.11-polymorphic-kotlin1.9|0.11-polymorphic-kotlin1.9> branch.

I'm also alright with using this for the v0.11.4 release. I needed to update Okio from v2 to v3 and thought that would be a breaking change, but its changelog says it's more of a symbolic major version change and that it's not breaking.

I'm in no rush, but once I get your thumbs up I'll be good to push that out!

new_serialization.kt

old_serialization.kt

It's working well ! Thanks :kotlin-intensifies-purple:

I think you can publish it :ok_hand:

Hey, after trying multiple things I got a problem with this code :

```
@Serializable(with = Component.Companion.ComponentSerializer::class)
sealed class Component {
    companion object {
       class ComponentSerializer : KSerializer&lt;Component&gt; {
          val kClass = Component::class

          override val descriptor = serialDescriptor&lt;NbtTag&gt;()

          override fun deserialize(decoder: Decoder) = error("${kClass.simpleName} cannot be deserialized")

          @OptIn(ExperimentalSerializationApi::class)
          override fun serialize(encoder: Encoder, value: Component) {
             require(kClass.isInstance(value) &amp;&amp; value::class != kClass) { "Value must be instance of ${kClass.simpleName}" }
             val serializer =
                encoder.serializersModule.getPolymorphic(kClass, value) ?: encoder.serializersModule.getContextual(value::class)
                ?: encoder.serializersModule.serializer(value::class.createType())

             when (encoder) {
                is NbtEncoder -&gt; {
                   val valueJson = encoder.nbt.encodeToNbtTag(serializer as KSerializer&lt;Component&gt;, value)
                   encoder.encodeNbtTag(valueJson)
                }

                is JsonEncoder -&gt; {
                   val valueJson = encoder.json.encodeToJsonElement(serializer as KSerializer&lt;Component&gt;, value)
                   encoder.encodeJsonElement(valueJson)
                }

                else -&gt; error("Components can only be serialized to NBT or Json")
             }
          }
       }
    }
}```
The result is different from JSON and NBT, but only if it uses `encoder.serializersModule.serializer(value::class.createType())`, so when the class uses the default serializer from kx.ser :
With JSON :
```minecraft:stone_sword[can_break={"predicates":[{"blocks":"minecraft:diamond_block"}]}]```
With NBT :
```minecraft:stone_sword[can_break={"io.github.ayfri.kore.arguments.components.CanBreakComponent":{predicates:[{blocks:"minecraft:diamond_block",state:{test:"test"}},{blocks:["minecraft:stone","minecraft:ice"]}],showInTooltip:1b}}]```
It's logic that I don't get the `"` but it's not logic that I get `io.github.ayfri.kore.arguments.components.CanBreakComponent` as a parent of the result :thinking_face:

I think I see what's happening. `nbt.encodeToNbtTag` will encode the root class inside an NbtCompound under its SerialName. (Which is a behavior I don't quite like, and decided to remove it in the 0.12 branch)

You might be able to use encodeSerializableValue instead. Or maybe if you need to ensure it's a NbtCompound or something, use a JsonTransformingSerialiser (which does something similar to what you're doing, but works around the root SerialName nesting behavior

When using
```val valueNbt = encoder.nbt.encodeToNbtTag(serializer as KSerializer<Component>, value)
// When the NBT is serialized, it's sometimes wrapped in a compound tag with the class fqname as the key.
if (valueNbt is NbtCompound && valueNbt.isNotEmpty()) {
	val firstKey = valueNbt.keys.first()
	encoder.encodeSerializableValue(
		NbtTag.serializer(),
		if (firstKey == value::class.qualifiedName) valueNbt.values.first() else valueNbt
	)
} else encoder.encodeSerializableValue(NbtTag.serializer(), valueNbt)```
It works like expected, it's not the best workaround but at least works

Another missing feature from JSON Serialization is `namingStrategy = JsonNamingStrategy.SnakeCase` in configuration, now I'm getting `showinTooltip` instead of `show_in_tooltip`

Is there a reason you're encoding twice, creating the intermediate NbtTag (and JsonElement) in your example? Instead of directly with `encoder.encodeSerializableValue(serializer, value)`? I think that may solve your issue too.

If it is still an issue though, I could add a configuration to disable the root nesting behavior entirely, since the behavior will eventually be removed in the next minor release. (though with better support, like an annotation to explicitly opt into the root nesting for a class)

I think I was doing some intermediate operations that I removed but forgot to try this :')

I'll take one last sanity check through, but I think I've got everything how I want it for v0.11.4. So maybe in a few hours after I run some errands :)

Or... maybe tomorrow. Something isn't working anymore with publishing, so I'll have to look into it
<https://github.com/BenWoodworth/knbt/actions/runs/8446623190/job/23135688822#step:5:130>

And... <https://github.com/BenWoodworth/knbt/releases/tag/v0.11.4|released>! I already ran into the signing issue <https://github.com/BenWoodworth/Parameterize/blob/v0.3.0/buildSrc/src/main/kotlin/parameterize.library-conventions.gradle.kts#L88-L92|with Parameterize>, so a quick copy-paste did the trick :)

<@U021AJK3ZUL> Continuing this as a new thread to keep the other thread on topic :)
<https://kotlinlang.slack.com/archives/C046BGVBJEP/p1711295347859809?thread_ts=1710030185.126079&amp;cid=C046BGVBJEP>

I did consider implementing the naming strategy at one point, but decided not to because Minecraft's own NBT naming seems inconsistent enough that having a global automatic re-naming convention wouldn't make much sense. On the <https://minecraft.fandom.com/wiki/Chunk_format|Chunk Format> wiki page, for example, I'm seeing pascal case, camel case, and snake case from the top of the page (`DataVersion`, `xPos`, `block_states`)

That along with the cautionary message in its documentation <https://github.com/Kotlin/kotlinx.serialization/blob/v1.6.3/formats/json/commonMain/src/kotlinx/serialization/json/JsonNamingStrategy.kt#L33-L45|here>

You're using it for data packs though, right? I haven't done much with them, but are the compound entries consistently all snake cased?

Since 24w09a they introduced <https://www.minecraft.net/en-us/article/minecraft-snapshot-24w09a|components>, this will replace NBT data later, currently it's only used for items, so this means that items don't have NBT anymore
I'm working on adding support for all components and they are normalized as `snake_case`

Even if the rest of NBT data isn't normalized, you should still add this feature as it's a common simple (as far I know) feature to implement, that could be useful for anyone else using KNBT

Oh wow, that's interesting. And definitely a good reason to reconsider supporting naming strategies.

It does seem a little complicated to implement though. Which I'm fine with, but my (very much delayed) v0.12 release changes a lot of the internals, so I'm hesitant to implement more complicated features in v0.11 if I'm going to need to repeat the work again later for v0.12.

<https://github.com/Kotlin/kotlinx.serialization/commit/60c632c970d7da02151fd7c920f40ebc269c0f29|Here>'s the kotlinx.serialization commit that added it in. I think encoding looks more straightforward (just call `serialNameForJson` before writing a value), but decoding will is a little more in depth because the reverse mapping needs to be calculated ahead of time, and for that I need to get around to implementing a Descriptor cache (see <https://github.com/Kotlin/kotlinx.serialization/commit/6087755212c21224daa70d75080bd87d76845c4d#diff-f97be1d636e0d10f8e02ce4ca5e00a9b46c38aaa33ee959ec86e939019d225af|this commit that implements it>, and then <https://github.com/Kotlin/kotlinx.serialization/commit/08da7483354d343001ccc0b40c67132ab072be98|this one for a Native fix>). Definitely doable, but I'd prefer to wait and build it on the better foundation in the next release

And for (Item) Components, I'm wondering what that means for NBT in general. I'm interpreting that as binary NBT still being the underlying format, but that items will have their (unstructured) NBT "tag" field removed in favor of a (structured) NBT "components" field. So NBT is still here to stay, it's just the shape of the data that's changing? (including more consistent snake case naming, which I'm fully on board for :relieved:)

For you, since you're only encoding, I'm wondering how well a `NbtTag.convertNamesToSnakeCase()` function would work. Far from perfect, but the end result could be similar to what `namingStrategy` would get you

I didn't take the time to look at the code, but from what I've seen they removed multiple abstract layers from NBT reading and writing, but they renamed a lot of NBT things to Components, and it's far faster than before to get/edit data. You can still display data as SNBT with `/data get` command but to write it you don't have the SNBT syntax at all (for items though, but they will surely expand it to everything)

Also we can finally create NBT craftings (only for results) :')

Hey, I'm trying to create a complex serializer, it should work but don't with NBTEncoder because it's enclosed in an NBTCompound named after the serializer Serial Name, code in :thread-please:

SinglePropertySimplifierSerializer.kt

I know it's an ugly practice to do that, but that would help me so much

Here's my setup :
```@Serializable(with = Data.Companion.DataSerializer::class)
private class Data(
	val name: String,
	val optional: String? = null,
) {
	companion object {
		data object DataSerializer : SinglePropertySimplifierSerializer<Data, String>(Data::class, Data::name)
	}
}

val partialInstance = Data("name")
val fullInstance = Data("name", "optional")```
These tests are passing :
```json.encodeToString(Data.serializer(), partialInstance) assertsIsJson """
    "name"
""".trimIndent()

json.encodeToString(Data.serializer(), fullInstance) assertsIsJson """
    {
       "name": "name",
       "optional": "optional"
    }
""".trimIndent()```
But not these :
```snbt.encodeToString(Data.serializer(), partialInstance) assertsIsNbt """
	"name"
""".trimIndent()

snbt.encodeToString(Data.serializer(), fullInstance) assertsIsNbt """
	{
		name: "name",
		optional: "optional"
	}
""".trimIndent()

at io.github.ayfri.kore.serialization.SerializersKt.singlePropertySimplifierSerializer(Serializers.kt:54)
Line 0 differs: Expected: "name" Got: {DataSimplifiableSerializer:"name"}```

BenSinglePropertySimplifierSerializer.kt.cpp

Just a quick idea I want to put out there before getting too into it. Is it safe to assume that the values using your serializer will never be top level?

Also, I threw together a quick serializer that I think can accomplish the same thing, plus without reflection. (I named it starting with `Ben` so we know which one we're talking about)

You could tag each property you want to be simplified with `@Serializable(BenSinglePropertySimplifierSerializer::class)` and it should just work. (The serialization compiler plugin will pass the actual serializer into the constructor, so you don't need to worry about doing the fields yourself)

And if you do want the class itself to always be serialized that way without needing to annotate the properties yourself, there's this workaround (inspired by <https://github.com/Kotlin/kotlinx.serialization/issues/1169|this issue>, which I noticed you were interested in last year :P)

(Though note that <https://github.com/Kotlin/kotlinx.serialization/issues/2264|typealias serializers don't always get picked up when calling Json/Nbt.encode...() on the typealiased value directly>)

Data.kt.cpp

Let me know
• if my assumption about `SinglePropertySimplifierSerializer` never being used at the root is right
• and how these solutions work for you (or why they don't)
If it doesn't help then I might add a quick `disableRootNesting` configuration option/annotation/etc. to make this less painful

In my opinion, you should add this option, as NBT is often serialized without a root object, more often that you would think (components again changed the game, you have a lot of `my_component=simple_value`, for example : `damage=4`, `lore="test"`, `unbreaking={}` (yes that's a thing))
It may not be the best solution in my case as it would work but my code isn't very safe and might break with just a Kotlin update (I'm very afraid of 2.0, as from what I've tested : all betas break with a serialization issue, different every time :'), I hope none will occur for the final release)
But it's doing exactly what I want, serialize the single non-null property as an inline value if it's the only property in the object, maybe I could figure out a version where I don't have to give as an argument the property, but I prefer giving it to be sure that I know which property is targeted. And people using this serializer for Kore extensions/usage will also understand more what this serializer is used for

I agree, the nesting has definitely been problematic :sweat_smile:
I have this issue where the automatic nesting for classes will be removed in v0.12, and replaced with `@NbtNamed` so it's an opt-in behavior where needed.
<https://github.com/BenWoodworth/knbt/issues/29|https://github.com/BenWoodworth/knbt/issues/29>

For right now though in v0.11, it's a question of whether I need to implement an opt-out (like a `disableRootNesting` option) in the meantime

Could this be done with an annotation on top of the class ? Like `@NoRootNesting` ?

Also, I don't quite follow the rest of your last message. I'm not sure if the different times you say "it" are talking about my serializer/solution or yours

Ah, I'm talking about my serializer, sorry, I'm not a native English speaker, so my messages aren't always easy to understand :')

No worries, English speakers do the same thing. So that just means you *are* fluent :joy:

"I prefer giving it to be sure that I know which property is targeted."

What about a `SerialInfo` annotation to use on the one property, so you can change my serializer to find the targeted property in the descriptor (and check that there's exactly one) when the serializer is initialized. Then when serializing, also check that it's the same property/element

Oh, I never used SerialInfo, sorry but could you show me an example on how your idea could work ?

Sure! Basically it tells the compiler plugin to include the annotation in the SerialDescriptor when it generates a serializer. Or you can include it yourself in the serial descriptor annotations when building your own descriptor

Ben2SinglePropertySimplifierSerializer.kt.cpp

2 things : First your Ben2SinglePropertySimplifierSerializer is serializing the object encapsulated, for example with
```@Serializable
class DataSurrogate(
	@SimplifiableProperty
	val name: String,
	val optional: String? = null,
)```
I'm getting with JSON serialization `{name: "name"}`

And for NBT it's still serializing as an encapsulated objet with the descriptor name, so
```{"io.github.ayfri.kore.serialization.DataSurrogate":{name:"name"}}```
in this case

Could you release the update with the parameter to disable root nesting today or soon if it's easy for you ? Or should I start creating my own serializers for each object needing this by hand and simplify them once you release the update ?

I _think_ it should work fine in your library, since it doesn't encapsulate when it's part of another value. (If classes like your Data will ever be used as the root data, let me know)

Then for you tests you could nest the data it in a list to get the same behavior.

I could still add the configuration option, but don't think I'll have time until a day or two from now, but let me know

Untitled.cpp

Here's a working example. I was getting a compiler error with the old typealias setup so changed it a little. But let me know what you think

Sadly yes, I have multiple classes that are serialized top-level, as I'm using a list that is serialized with a custom format, at one step I serialize them as top-level classes

Okay! I just pushed up a new branch `0.11-nestRootClasses` that adds the configuration option, letting you set it to `false` and opt out of the functionality. Give it a try (publish to maven local), and if it's good I'll push out a new release :)
<https://github.com/BenWoodworth/knbt/tree/0.11-nestRootClasses>

I'll try when I have time ! Maybe this weekend

Alright! I just pushed a commit renaming it to `nameRootClasses`, since I thought that'd better captured what's going on

Hello, I tried the `0.11-nestRootClasses` branch and it's working well with my system, the tests are passing !
Waiting for you to release it so I can simplify a lot my code :smile:

Perfect! I'll try to push out a release with it later :relieved:

Sorry for taking so long to try it but I was very busy mixed with taking time in vacations :')

The faster you release it the happier I am :kotlin-intensifies-purple:

I also just posted a new design for NBT naming if you want to take a look. For you the main thing is that nesting the root tag in a compound wouldn't be a thing at all anymore, but take a look if you're curious what the future has in store! Or if you have any critiques :joy:
<https://github.com/BenWoodworth/knbt/issues/29#issuecomment-2059913153|https://github.com/BenWoodworth/knbt/issues/29#issuecomment-2059913153>

And I was wondering haha. I wasn't in any rush though so :man-shrugging:

Yup, I followed every comments in this discussion, it was very cool to see this taking shape, and your big documentation on how it will be done is correct to me !
I can't really have an opinion until I try it I think, so I'm waiting : >

Aaaaaand released! After some CI trouble because GitHub broke after an update to the macOS host, but all's sorted now and it should be in maven soon :)

Oh you released this soon : o
I though in some days, that's very nice !

Sorry to asking you something once more but could you help me simplify this serializer that I find too much bloated x)

It was already good to go so I just had to press the big ol' release button :joy:

Serializers.kt

differences.kt

utils.kt

assertions.kt

Here are the files I use for testing (it doesn't require any dependency, just you to fix the packages as I'm just sending some files)

And no worries! Would the Ben2SinglePropertySimplifierSerializer from earlier work?

It doesn't sadly, instead of `"name"` I get `{name: "name"}`

I've pushed to Kore master branch my current code with the ugly serializer, if you want a simpler way to try the tests for yourself !

Hmm. Intellij's crashing on me at the moment so I can take a closer look in a bit :eyes:

I was still on a 2023 IDE, so I didn't have that yet. But after (apparently) a couple hours of debuggling and updating and invalidating caches, I stumbled upon a youtrack issue where someone suggested to run a Memory test to check the RAM, and lo and behold...

20240507_221344.jpg

It seems some of the shiny new RAM I bought late last year might've broken. There shouldn't be any red lines there :sweat_smile:

Ah...
You're scaring me because I'm also having Intellij breaking right now, it just don't index anything, not even the Kotlin stdlib
I just updated my gradle from 8.5 to 8.7 :c

...Mine would get up to indexing a platform stdlib and then freeze &amp; crash :face_in_clouds:

Only thing I can think of is updating to Fedora 40 a couple days ago, though I don't think that would cause the RAM issues it looks like I might have

After searching more, I figured out that the Godot plugin update I downloaded earlier is causing that

I thiiiink I fixed my RAM :sweat_smile:
Not sure if it's me using canned air on the motherboard slot, or just taking the stick out and putting it back in, or just letting the ram physically cool down (because it was _hot_), but computer's happy and memory tests are passing and intellij is running :relieved:
(_for *now*_ :ghost:)

I've got Kore on my computer now to play around with it quick. Is there a .env file I need? When I run kore:run it's hitting me with `DotenvException: Could not find /.env on the classpath`

Ah yes, you need a .env with `TEST_FOLDER="absolute path"` in the `kore/test/resources` folder
It's just the path where to generate the files, you can put `.` for generating inside the project folder

It's very useful when you want to generate the tests inside a Minecraft world to try them directly

Got my serializer working! :)
If you use <https://kotlinlang.slack.com/archives/C046BGVBJEP/p1712776537416639?thread_ts=1711982124.447009&amp;cid=C046BGVBJEP|my working example>, you can get it working with the `Data` tests by passing the `DataSerializer` instead of `Data.serializer()`.

You only need to pass the serializer like that when serializing a simplifiable class directly, since kotlinx.serialization doesn't pick up the typealias serializer that way. It _does_ pick it up when `Data` is used as an element type in a class's generated serializer though

Ben3SinglePropertySimplifierSerializer.kt

Serializers.kt.py

(I added a check in the shiny new Ben3 serializer to make sure there's exactly one simplifiable property)

And it wasn't working for you because `Data.serializer()` is really `DataSurrogate.serializer()`. Using `@Serializer` in a typealias feels kind of messy and prone to errors, since it _does_ only seem to work with elements in generated serializers, but it seems like the easiest way until we can write a custom serializer for `Data` while <https://github.com/Kotlin/kotlinx.serialization/issues/1169|still having access to the plugin-generated serializer>

<https://github.com/Kotlin/kotlinx.serialization/issues/1169#issuecomment-2083213759|_Oh wait_>, a brand new comment :eyes:
&gt; Expected to be available in Kotlin 2.0.20.

Thanks for your work, sadly I will probably not use it as I wanted a solution without having to create a typealias every time
And your solution requires for each class a few more lines that my current solution x)
But I learned things so it wasn't a waste of time ! :kodee-welcoming:

Yes I'm so excited for this feature to release :kotlin-intensifies-purple:

Hello !
Why is it not possible to create a NBTList&lt;NbtTag&gt; ?

(moving messages from the channel into this thread)

From <@UEJCKPB63>:
> That's just because TAG_List is only able to have a specific type. In the binary when the list starts, it writes the tag type of the elements, the number of elements, and then the elements themselves
> (And could even put the  element type as `TAG_End` if it's empty)
> take a look at the notes under TYPE: 9 in the <https://web.archive.org/web/20110723210920/http://www.minecraft.net/docs/NBT.txt|spec>
> Was there something you wanted to do with multiple types in a list? Or are just curious
> I _am_ kind of curious what happens if Minecraft tries to parse a SNBT list of multiple types

image_720.png

From <@U021AJK3ZUL>:
> I wanted to simplify serialization shenanigans x)
> Here's a preview, if I was able to do a NbtList<NbtTag> I won't have to serialize it there

From <@UEJCKPB63>:
&gt; I guess in that case you can always know it's fine! Because one element is guaranteed to be all of the same type haha
&gt; 
&gt; I have thought about this though. The seemingly obvious solution for knbt is to have a NbtList&lt;NbtTag&gt;(content) constructor, &gt; and then check that content is all the same type in the constructor. But that adds overhead, and could also break if content changes. And I don't want to make a copy of content to prevent that (from the constructor at least), since the NbtTag classes act like thin wrappers similar to JsonElement
&gt; 
&gt; I (or you!) could add a List&lt;NbtTag&gt;.toNbtList() function, since there's the convention that "to" functions make copies, and have that verify they're all the same type. It would definitely be more performant that running an entire serializer haha. Or maybe something like NbtList.fromNbtTags(nbtTags) to make it clear that there's more overhead
&gt; 
&gt; Or have buildNbtList accept unspecific elements :shrug:

From <@U021AJK3ZUL>:
&gt; You could maybe store the fqName of the first entry of the content then check for each element if it's still the same, and throw an exception if not ?

Untitled.kt

That's what I was talking about in my last message, with the seemingly obvious solution. Here's the problem with that though