The Insanity God

The tags field is part of the `CollectibleObject` class which is a shared base class for `Item` and `Block`, you can't really have an item that does not implement this. Though if I remember correctly tags where only added recently, don't think they even exist in the latest stable release. You can use an AddMerge patch for that: https://wiki.vintagestory.at/Modding:JSON_Patching#AddMerge_operation

This would be found in the `TcpNetConnection` class, though I can't seem to inspect the code as C# only as IL code so perhaps that's why you couldn't find it. A From the looks of it the max packet size is defined in how many bytes are in the packet. `MaxPacketSize` interestingly enough seems to be variable: it starts of at 5000 bytes then increases to 1000000 bytes once the player identification has been completed and increases to `int.MaxValue` if the player is in creative (I guess to better allow certain creative tooling) In general the best way is to simply not send large packets. Lets say you want to update the entire visible map, well don't send the entire map in 1 packet but instead send a packet for every chunk column and update it 1 chunk column at a time.

If this was a test to see if someone could point out all the issues then you certainly did a good job , I probably missed some things but here are my findings: 1. The `assets` folder and `modinfo.json` file should be directly in the zip and not in a sub folder, otherwise the game will complain. 2. You say it's a `client-side` mod but `Side` is not set to `Client` inside the `modinfo.json`, currently the game would see it as a universal mod that is required both on server and client. 3. You appear to be using the `World.Config` but not only is this global for all players, it's also server leading so changing it from the client side won't persist. Consider using a local config file with `api.LoadModConfig` and `api.StoreModConfig`. 4. HotKeys are handled client side so your sorting of the inventory is happening client side.... but inventories are server leading, so if you want this to be done client side you need to send the actual packets for opening the inventory and moving stuff to the server (just moving the `ItemStack` between slots on the client is not enough). Testing shows that the slots indeed only appear sorted but go back to normal once you try to interact (as the server sync overrides the local changes) *as for why it ignored the first 6 slots, see point 6. 5. Would recommend calling `MarkDirty` after modifying the `ItemSlot` manually even on client as this calls the `OnItemSlotModified` event. 6. The `SortyInventory` (and `ApplySorted`) is starting at index 10? This doesn't seem right to me... in the base game everything after slot 4 would be the actual backup content (1 to 4 being the slots for the actual backpacks themselves), also rather then using a hard coded number, check the actual slot types as mods might change the amount you have. (`ItemSlotBackpack` for the backpack slots and `ItemSlotBagContent` for the actual content of the bags) 7. `MergeStacks` is wrong, it assumes that all ItemStacks are equivelant as long as the `Code` is the same but this just isn't true, not only does this ignore transitions such as rotting (this requires extra logic for merging the transition progress) but some items like for instance clutter uses the attributes to differentiate meaning this will merge multiple different kinds of clutter into 1. The `StackSize` calculation is also wrong: the `ItemSlot` can also put a limit on the `StackSize` so `Collectible.MaxStackSize` is not enough, you need the actual `ItemSlot` to check the limit. (btw there was no need to call `ToString` on the code here as `AssetLocation` properly implements equality methods, meaning this is just unnecessary overhead) 8. In `SortInventory` you pass a sorting method that either calls `GetTypePriority` or `GetSmartPriority` depending on the `currentMode`, consider just passing the`GetTypePriority` or `GetSmartPriority` method based on `currentMode` that way it doesn't need to constantly compare `currentMode` (and you avoid the risk of it ever changing mid sort 9. Not necessarily wrong but your secondary sorting is using the `Collectible.Code.ToString()` which means you are for starters indirectly sorting on Mod since the Code exists of `Domain` (generally ModID) + `Path`, secondarily the code could be the same for multiple items if they are using attributes to differentiate so consider using `GetHeldItemName` instead. 10. `GetSmartPriority` and `GetTypePriority` checks for hard coded words to check the tool/material, which is very prone to error. Instead use `Collectible.Tool` which contains a nullable enum that can be matched to check for tool types and `Collectible` and if a `Block` use `GetBlockMaterial` to check the material instead. 11. Not very relevant since it shouldn't be stored in the world config in the first place but rather then storing locked slots as "lockedSlot" + slotNumber, you could have just stored a `BoolArrayAttribute` (it doesn't have a fluent method for it though) 12. `lockedSlots` has a max size of 40 but depending on the mods present you might have more so this size should really be increased at runtime if the backpack inventory ever go's over 40.

Light level would be decided by the `V` of `HSV`, normally this is stored inside the LightHsv field on the Collectible but the lantern has some extra custom logic on it which you will likely want to patch to achieve this: https://github.com/anegostudios/vssurvivalmod/blob/rc/Block/BlockLantern.cs#L56

You sure you didn't mean 1.21.6 (Considering its loading .NET8 assemblies)? The error you are showing suggests that it's attempting to load a newer version of .NET then the game version supports. (It's the game loading the mod DLL's, so the game needs a higher or equal version then the mods .NET version) Would recommend checking your Target Framework in the csproj file, should look as following: <TargetFramework>net8.0</TargetFramework> (if it has net10.0 there, then that would be your issue)

https://mods.vintagestory.at/morehudbars

I don't think emotes where meant to be set to repeat, I see no functionality for stopping them through commands so you will likely have to create your own command + entity packet to do this.

I can't say much about what you did wrong but this is not an engine limitation. `OnBeforeRender` runs for every ItemStack (not to be confused with ItemClass, which contains the shared data). I for instance use this method for rendering Ice Cubes in BrainFreeze (there is only 1 ItemClass instance, but each ItemStack renders differently depending on the liquid stored in the ItemStack attributes). If those variants are fixed (as in you have to chose from a list such as wood types) and not dynamic like with this post then I would recommend looking into Attribute Rendering

Fairly sure there isn't any command for that. Not sure why you would even need this but would be fairly simple to make a custom hotkey for this from code. public class SandBoxModModSystem : ModSystem { [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "CameraMode")] internal static extern ref EnumCameraMode CameraMode(Camera instance); public override void StartClientSide(ICoreClientAPI api) { base.StartClientSide(api); api.Input.RegisterHotKeyFirst("toggle-first-third-person", Lang.Get("Toggle between first and third person"), GlKeys.M, shiftPressed: true); api.Input.SetHotKeyHandler("toggle-first-third-person", input => { if(api.World is ClientMain client) { ref EnumCameraMode cameraModeRef = ref CameraMode(client.MainCamera); cameraModeRef = cameraModeRef switch { EnumCameraMode.FirstPerson => EnumCameraMode.ThirdPerson, _ => EnumCameraMode.FirstPerson }; } return true; }); } }

You don't need any c# code to make `/emote` work, the animation just needs to be registered as en emote in the Entity file:

Well you could add a listener to the chunk dirty event instead but point taken. Multiblocks in particular are indeed rather lacking in regards to this. What I mostly meant with that under the hood there is still a "tick-based system" is that for a variety of reasons (consistency and concurrency for instance) events are often triggered by something tick based (like physics, where every tick the player moves a bit based on their velocity) and/or result in enqueuing a task that is then run by a tick based system. For instance RegisterCallback just registers the delegate to a shared list which is then checked every tick to see if they should be called.

Yup, they are working on this though. Harmony allows for changing almost anything in code (except you can't edit generic methods and you can't add fields, though there are workarounds for the later), for most stuff you can just make Behaviors though. There is the IEventAPI for mods to push/listen to events and some base game events you can attach to but for the most part stuff is intended to be done through Behaviors. (Personally I'd say the distinction between "tick-based system" and "event-based systems" is always a bit weird though, since usually "event-based systems" still run a "tick-based system" under the hood to actually trigger those events so it's really more of an abstraction layer on top then a replacement system) Actually a lot of the framework for dimensions is already in place and in fact even used in some places already albeit with limitations (MiniDimensions) I haven't messed with this myself but I know there is a lot of possibilities in regards to this... not only from code, where you can straight up register your own ChunkGeneration steps using the IServerEventAPI but also from JSON using landforms. Someone with experience with terrain generation can probably tell you more about this. Idk about futuristic tech but I definitely think steampunk level tech is coming to VS, if not by the developers then by modders... it's only a matter of time.

That's certainly interesting... when debugging from the IDE it adds the folder it compiled into as an extra place to load mods from, perhaps this somehow affects the load order when it's not decided by dependencies.

To my understanding the Lang system is just a last entry wins system, meaning what matters is the load order.

Wait the modmaker puts stuff in game domain folder? I'm surprised I haven't seen this one before then.