C# Optimized pathfinding After some tests of the community, we found that many instances of monsters on a map will cause a lot of memory usage. As I found out, the root of the cause was
C# Demo Console Client for MU Online For a test of the new nuget packages of MUnique.OpenMU.Network.Packets I wrote a small demo client. You can find the source code here: https://github.com/sven-n/MuConsoleTestClientIt encapsulates most
C# Generating message structs by data In this post I want to explain how I'm planning to generate ref structs in OpenMU and how this fits into the big picture.
C# Handling packet structures in .NET - a new way? Parsing and serializing network packets in .NET in a safe, performant and elegant way can be quite tricky. C# ref structs might be the answer.
MU Online SimpleModulus revisited Recently, I was working on getting game client version 0.75 to work with OpenMU. One big obstacle was the SimpleModulus encryption which was somehow different in the earlier versions of MU Online.
C# Loading complex data with PostgreSQL JSON functions Problem With an extension of initialization data, where I added definitions of NPCs and Monsters and their spawn points to about 10 game maps, I noticed that the time to start the server
Release MUnique OpenMU Network Analyzer Hey people, today I release a little tool to analyze network traffic between server and client which use the mu protocol. The cool thing is, the packet structures are defined in xml files,
OpenMU A closer look at the MU Online packet encryption in the past days I wondered why some parts of the encryption and decryption keys for the network packet encryption (aka SimpleModulus) are actually the same. So I tried to dig a bit
C# it compiles... ship it! :) Yesterday, I finally managed to get the Travis CI build running. This was a bit tricky, because Travis CI runs on Linux with xbuild (not msbuild) and uses the mono compiler. Because of
Entity Framework Core .Include(...) is not the right solution to load 1:n relationships When I read about what people suggest to load 1:n relations, it makes me wonder if they know what they are doing. In Entity Framework Core, basically every LINQ expression translates into
Entity Framework Core Workaround for missing n:m mapping feature in Entity Framework Core A lot of guys are complaining on GitHub that implicit mapping for many-to-many relationships is missing for Entity Framework Core. I don't see this missing feature as too critical. With some clever patterns