[Warning: HarmonyX] AccessTools.Field: Could not find field for type ZDOMan and name m_dataPerSec [Error : HarmonyX] Failed to patch void ZDOMan::.ctor(int width): System.ArgumentException: No such field defined in class ZDOMan Parameter name: m_dataPerSec at HarmonyLib.Public.Patching.HarmonyManipulator.EmitCallParameter (HarmonyLib.Internal.Util.ILEmitter il, System.Reflection.MethodBase original, System.Reflection.MethodInfo patch, System.Collections.Generic.Dictionary`2[TKey,TValue] variables, System.Boolean allowFirsParamPassthrough, Mono.Cecil.Cil.VariableDefinition& tmpObjectVar, System.Collections.Generic.List`1[HarmonyLib.Public.Patching.HarmonyManipulator+ArgumentBoxInfo]& tmpBoxVars) [0x00216] in <116dd996dda44480a48a0fc9ee2308ed>:0 at HarmonyLib.Public.Patching.HarmonyManipulator.WritePostfixes (HarmonyLib.Internal.Util.ILEmitter il, System.Reflection.MethodBase original, HarmonyLib.Internal.Util.ILEmitter+Label returnLabel, System.Collections.Generic.Dictionary`2[TKey,TValue] variables, System.Collections.Generic.ICollection`1[T] postfixes, System.Boolean debug) [0x00146] in <116dd996dda44480a48a0fc9ee2308ed>:0 at HarmonyLib.Public.Patching.HarmonyManipulator.MakePatched (System.Reflection.MethodBase original, MonoMod.Cil.ILContext ctx, System.Collections.Generic.List`1[T] prefixes, System.Collections.Generic.List`1[T] postfixes, System.Collections.Generic.List`1[T] transpilers, System.Collections.Generic.List`1[T] finalizers, System.Collections.Generic.List`1[T] ilmanipulators, System.Boolean debug) [0x001a4] in <116dd996dda44480a48a0fc9ee2308ed>:0
Hello, The patch that is used by the mod to provide enhancements to the network part is used by most systems that provides a workaround about this problem. You can try modifying your config network part (the `NetworkDataPerSeconds` option) and try to change its value until it get better for your lags.
This is not the perfect solution of course, but it is the only real solution that we have right now, because the problem comes from the network-management part of Valheim, that can be only fixed by the devs.
Other points have been discovered that can be problematic on the CPU-side of optimization (you can find them on the issues page of the Github page of Longship), I am trying to find most of the "badly-optimized" and "bad models" used in Valheim to provide patches later to fix them and optimize them if I can !
This mod will not fix all Valheim's problems, it's the role of the devs to do that, but, while waiting for them, I'm trying to patch most of the things that I can fix !
For some reason when I install Longship in my server's BepInEx plugins, it no longer uses my pre-existing world and uses the default "Dedicated," despite the start_headless_server.bat file being unchanged. Is there another setting file to configure?
For what its worth, Id much rather use this than Bepin or InSlimVML solely on the principle that this seems to be targeted to creating server sided mods not requiring the client to have installed. I entirely understand what you mean by this being similar to bukkit for minecraft and entirely support your development.
I appreciate the work you're doing to provide easier to use methods for modding game functions.
However, there are already two pre-existing plugin systems (BepInEx for Valheim and InSlimVML) competing with each other. We really don't need a third to add to the confusion. Would you mind targeting one of those two instead?
Hello, You misunderstood the goal of the mod ! BepInEx and InSlimVML are code Injectors to provide easy hook on in-game methods. Using them in correlation with Harmony, you can change the behaviour of specific methods in the game.
Longship's goal is to provide a Plugins system based on in-game events. Not a way to rewrite behaviours by injecting data ! (you can compare it to Bukkit on Minecraft). I am using Harmony to rewrite game Behaviours ofc, but plugin developers will be able to interact with servers without the need at all to modify the game behaviours !
That's the goal of this Mod (in addition with the optimizations and bugfixes ofc)
No, I understood that. As I said, it is admirable that you are working on providing an api "based on in-game events".
The problem is, the way you are using Doorstop directly to load your system interferes with the (pre-existing) plugin systems (code injectors, mod loader, whatever you choose to call them).
It would be preferable if, for example, you designed your system to be loaded as a BepInEx plugin. This way you will not interfere with other mods that do not wish to use your system.
This does not make sense. BepInEx is first of all not a plugin system for Valheim. It's a unity thing. (Sayin that since you wrote "BepInEx for Valheim" although you probably wrote it like that for the context) InSlimVML is just Unity Doorstep Embedding and a branch of Doorstop tied to Harmony focused for Valheim. Making this work along with it is not a hard task to do. And why should there be any confusion? It's the user that decides what to use?
The core idea here as a foundation is a step forward in terms of simplicity. We seen this kind of approach with Bukkit for MC. Oxide for Rust. etc. And at the very end who is to blame if a server admin decides to use all at the same time and does not know how to merge them? Competition is needed everywhere.
Sure this could be done as a BepExIn Plugin. But what is the point of having a plugin that acts as a plugin system where everything is based on that system which is just a plugin of something else?
?BepInEx is first of all not a plugin system for Valheim. It's a unity thing. (Sayin that since you wrote "BepInEx for Valheim" although you probably wrote it like that for the context)
No, this is what I was referring to: BepInEx for Valheim (Which a number of other mods are already using)
Making this work along with it is not a hard task to do.
I guess I was unclear? That's exactly what I'm asking for. (Maybe you think this is the user's job? If so, I strongly disagree.)
?But what is the point of having a plugin that acts as a plugin system where everything is based on that system which is just a plugin of something else?
Because it's silly to reinvent the wheel, when someone else has already spent far more time and had far more experience building such a system.
The author should instead concentrate on the useful work he is doing to create "a foundation is a step forward in terms of simplicity". In other words, creating an simple, Valheim-focused API (on top of another plugin system) which modders can use instead of, for example, directly hooking functions using Harmony.
And why should there be any confusion? It's the user that decides what to use?
I'll refer you to SillyDashie's post for exactly what I'm talking about.
---
Anyways, I'm finished. I've made my pitch. If the author wishes to continue their attempt to further fragment the modding community (as BepInEx for Valheim and InSlimVML have already done), then on their head be it.
Fragmenting the community is absolutely not what I am trying to do. In my case, I am trying to provide more reliable ways to use Valheim by providing a high-level API and Event system to Plugin developers. I do not aim to replace BepInEx or any other injection system, in fact, I could change UnityDoorstop which is the injection system I am currently using in favor of BepInEx, it would not change much things to be honest.
As I stated, again, you just misunderstood the usage of this mod. It it NOT an injection mechanism, it is just a better way to manage some resources and interact with the game WITHOUT having to patch any methods (which requires retro-engineering)
And to continue my comparaison with minecraft, you can compare BepInEx with Minecraft developer pack (which aimed to provide modding tools to the community) and Longship with Bukkit (which aims to provide simplicity for managing dedicated servers and developing plugins)
EDIT: To avoid "dividing the community" (which is, as I stated, something that I want to avoid), I have added a planned feature to make Longship compatible and usable with BepInEx, because its usage seems to be more established in the community, an issue have been opened on Github for it: https://github.com/AlexMog/Longship/issues/10
?I guess I was unclear? That's exactly what I'm asking for. (Maybe you think this is the user's job? If so, I strongly disagree.)
Okay then I just misunderstood it. I thought you described the issue as a something hard to do and I also should have made myself clear what I mean with user here. I was referring to the server owners that should be fully aware what the most practical tool would be for their needs to fulfill their vision of their server and meant that owners that have development knowledge or a modder within staff should be capable to merge the tools it needs.
I totally get where you are coming from in regards of having too many systems. But the reason I argue with that to some degree is that server owners should be fully aware what is on the market and what tools fit the best. Some do not need a full-fledged system, some just need simple tools for simple things. That is why I support these kind of things. To be fair maybe I took this with a hint of salt cause I got triggered in the past weeks by some foolish statements within the Valheim modding community.
And since the mod author already stated that he plans to make it compatible I think we are already headin now in the right direction in that regard for the ease of use of the mod.
Looks nice. Can you explain how the server performance aspect of the mod works? Currently when together (5+ people in biome) we experience a lot of rubberbanding and enemies teleporting. We've read this is because the person with the weakest connection affects how things run, but whenever we're off in our own separate biomes lag is very minimal. What do you recommend setting the bandwidth limit to? I'm also curious if I can add this to the server itself and call it a day or if each person will need to download the mod and keep it updated.
Thanks :) What you are describing is clearly what the first version is trying to fix. I'll explain the problem: The server limits currently its own bandwidth to 65Ko/s, but, when you are in a highly populated area with multiple buildings and entities, the server starts to get limited by its own bandwidth limitations. You can imagine it easily: Each Building or any other entity sends an initial packet when loaded, this packet contains its position (3 x 8 octets) rotation (3x 8 octets) and some more metadata (name, type of building, ...) and, each "active" entity (movable entity) will send its position and rotation each tick (there are 20 ticks per second for network updates), it's very simple to understand how the 65Ko/s can be achieved very easily on high populated areas, that's why you have this problem only when you and other players are in the same populated area. It's clearly not the best approach (instead, the usage of incremental and step updated should be considered by Valheim's devs) and, without a massive override of most of their network methods, I can only provide a fix to enable more Bandwidth to be available for the server. That's exactly what happens here: https://github.com/AlexMog/Longship/blob/master/Longship/Patches/PatchZDOManDataPerSeconds.cs#L13 Other possible limitations and possible optimisations have been found, the devs seems to love using bruteforce calculations instead of geohash trees, it will probably be a problem for CPU usage if you have a high amount of players (see https://github.com/AlexMog/Longship/issues/7 https://github.com/AlexMog/Longship/issues/6), I am working on a fix by integrating a quadtree to these calculations to avoid having to bruteforce each frame.
Give Feedback
19 comments
[Warning: HarmonyX] AccessTools.Field: Could not find field for type ZDOMan and name m_dataPerSec
[Error : HarmonyX] Failed to patch void ZDOMan::.ctor(int width): System.ArgumentException: No such field defined in class ZDOMan
Parameter name: m_dataPerSec
at HarmonyLib.Public.Patching.HarmonyManipulator.EmitCallParameter (HarmonyLib.Internal.Util.ILEmitter il, System.Reflection.MethodBase original, System.Reflection.MethodInfo patch, System.Collections.Generic.Dictionary`2[TKey,TValue] variables, System.Boolean allowFirsParamPassthrough, Mono.Cecil.Cil.VariableDefinition& tmpObjectVar, System.Collections.Generic.List`1[HarmonyLib.Public.Patching.HarmonyManipulator+ArgumentBoxInfo]& tmpBoxVars) [0x00216] in <116dd996dda44480a48a0fc9ee2308ed>:0
at HarmonyLib.Public.Patching.HarmonyManipulator.WritePostfixes (HarmonyLib.Internal.Util.ILEmitter il, System.Reflection.MethodBase original, HarmonyLib.Internal.Util.ILEmitter+Label returnLabel, System.Collections.Generic.Dictionary`2[TKey,TValue] variables, System.Collections.Generic.ICollection`1[T] postfixes, System.Boolean debug) [0x00146] in <116dd996dda44480a48a0fc9ee2308ed>:0
at HarmonyLib.Public.Patching.HarmonyManipulator.MakePatched (System.Reflection.MethodBase original, MonoMod.Cil.ILContext ctx, System.Collections.Generic.List`1[T] prefixes, System.Collections.Generic.List`1[T] postfixes, System.Collections.Generic.List`1[T] transpilers, System.Collections.Generic.List`1[T] finalizers, System.Collections.Generic.List`1[T] ilmanipulators, System.Boolean debug) [0x001a4] in <116dd996dda44480a48a0fc9ee2308ed>:0
The patch that is used by the mod to provide enhancements to the network part is used by most systems that provides a workaround about this problem.
You can try modifying your config network part (the `NetworkDataPerSeconds` option) and try to change its value until it get better for your lags.
This is not the perfect solution of course, but it is the only real solution that we have right now, because the problem comes from the network-management part of Valheim, that can be only fixed by the devs.
Other points have been discovered that can be problematic on the CPU-side of optimization (you can find them on the issues page of the Github page of Longship), I am trying to find most of the "badly-optimized" and "bad models" used in Valheim to provide patches later to fix them and optimize them if I can !
This mod will not fix all Valheim's problems, it's the role of the devs to do that, but, while waiting for them, I'm trying to patch most of the things that I can fix !
However, there are already two pre-existing plugin systems (BepInEx for Valheim and InSlimVML) competing with each other. We really don't need a third to add to the confusion. Would you mind targeting one of those two instead?
You misunderstood the goal of the mod !
BepInEx and InSlimVML are code Injectors to provide easy hook on in-game methods.
Using them in correlation with Harmony, you can change the behaviour of specific methods in the game.
Longship's goal is to provide a Plugins system based on in-game events. Not a way to rewrite behaviours by injecting data ! (you can compare it to Bukkit on Minecraft).
I am using Harmony to rewrite game Behaviours ofc, but plugin developers will be able to interact with servers without the need at all to modify the game behaviours !
That's the goal of this Mod (in addition with the optimizations and bugfixes ofc)
The problem is, the way you are using Doorstop directly to load your system interferes with the (pre-existing) plugin systems (code injectors, mod loader, whatever you choose to call them).
It would be preferable if, for example, you designed your system to be loaded as a BepInEx plugin. This way you will not interfere with other mods that do not wish to use your system.
BepInEx is first of all not a plugin system for Valheim. It's a unity thing. (Sayin that since you wrote "BepInEx for Valheim" although you probably wrote it like that for the context)
InSlimVML is just Unity Doorstep Embedding and a branch of Doorstop tied to Harmony focused for Valheim.
Making this work along with it is not a hard task to do.
And why should there be any confusion? It's the user that decides what to use?
The core idea here as a foundation is a step forward in terms of simplicity. We seen this kind of approach with Bukkit for MC. Oxide for Rust. etc.
And at the very end who is to blame if a server admin decides to use all at the same time and does not know how to merge them?
Competition is needed everywhere.
Sure this could be done as a BepExIn Plugin.
But what is the point of having a plugin that acts as a plugin system where everything is based on that system which is just a plugin of something else?
(Which a number of other mods are already using)
The author should instead concentrate on the useful work he is doing to create "a foundation is a step forward in terms of simplicity". In other words, creating an simple, Valheim-focused API (on top of another plugin system) which modders can use instead of, for example, directly hooking functions using Harmony.
---
Anyways, I'm finished. I've made my pitch. If the author wishes to continue their attempt to further fragment the modding community (as BepInEx for Valheim and InSlimVML have already done), then on their head be it.
In my case, I am trying to provide more reliable ways to use Valheim by providing a high-level API and Event system to Plugin developers.
I do not aim to replace BepInEx or any other injection system, in fact, I could change UnityDoorstop which is the injection system I am currently using in favor of BepInEx, it would not change much things to be honest.
As I stated, again, you just misunderstood the usage of this mod. It it NOT an injection mechanism, it is just a better way to manage some resources and interact with the game WITHOUT having to patch any methods (which requires retro-engineering)
And to continue my comparaison with minecraft, you can compare BepInEx with Minecraft developer pack (which aimed to provide modding tools to the community) and Longship with Bukkit (which aims to provide simplicity for managing dedicated servers and developing plugins)
EDIT:
To avoid "dividing the community" (which is, as I stated, something that I want to avoid), I have added a planned feature to make Longship compatible and usable with BepInEx, because its usage seems to be more established in the community, an issue have been opened on Github for it: https://github.com/AlexMog/Longship/issues/10
I totally get where you are coming from in regards of having too many systems.
But the reason I argue with that to some degree is that server owners should be fully aware what is on the market and what tools fit the best. Some do not need a full-fledged system, some just need simple tools for simple things. That is why I support these kind of things.
To be fair maybe I took this with a hint of salt cause I got triggered in the past weeks by some foolish statements within the Valheim modding community.
And since the mod author already stated that he plans to make it compatible I think we are already headin now in the right direction in that regard for the ease of use of the mod.
What you are describing is clearly what the first version is trying to fix.
I'll explain the problem:
The server limits currently its own bandwidth to 65Ko/s, but, when you are in a highly populated area with multiple buildings and entities, the server starts to get limited by its own bandwidth limitations.
You can imagine it easily: Each Building or any other entity sends an initial packet when loaded, this packet contains its position (3 x 8 octets) rotation (3x 8 octets) and some more metadata (name, type of building, ...) and, each "active" entity (movable entity) will send its position and rotation each tick (there are 20 ticks per second for network updates), it's very simple to understand how the 65Ko/s can be achieved very easily on high populated areas, that's why you have this problem only when you and other players are in the same populated area.
It's clearly not the best approach (instead, the usage of incremental and step updated should be considered by Valheim's devs) and, without a massive override of most of their network methods, I can only provide a fix to enable more Bandwidth to be available for the server.
That's exactly what happens here: https://github.com/AlexMog/Longship/blob/master/Longship/Patches/PatchZDOManDataPerSeconds.cs#L13
Other possible limitations and possible optimisations have been found, the devs seems to love using bruteforce calculations instead of geohash trees, it will probably be a problem for CPU usage if you have a high amount of players (see https://github.com/AlexMog/Longship/issues/7 https://github.com/AlexMog/Longship/issues/6), I am working on a fix by integrating a quadtree to these calculations to avoid having to bruteforce each frame.